Hvad er en Pentest?

Softwaren har med garanti fejl. Der kan være mange tusinde linjer kode i software, og menneskelig fejlbarhed betyder, at i det mindste nogle af dem ikke bliver hele efter hensigten. Softwareudviklingens livscyklus er en proces designet til at forsøge at minimere disse problemer ved regelmæssigt at teste.

Problemet er, at testning ofte udføres af udviklere, som måske har lært at kode noget, men måske ikke har lært sikker kodningspraksis. Selv i gennemtestede systemer kan det hjælpe med at identificere nye problemer, hvis man ser udefra og bringer et nyt perspektiv ind.

En almindelig måde at gøre dette på er via en penetrationstest, typisk forkortet til en pentest. Dette indebærer at få en professionel, etisk hacker, en pentester, til at se på systemet og finde eventuelle sikkerhedsproblemer.

Tip: Det er "pentest" og "pentester", ikke "pentest." En pentester tester ikke penne. "Pen-test" er lidt mere acceptabel end "pen-test", men bør generelt også undgås.

Målet for en Pentest

Målet med enhver pentest er at identificere alle sikkerhedssårbarheder i det system, der testes, og at rapportere dem til klienten. Typisk er engagementer dog noget tidsbegrænsede baseret på omkostninger. Hvis en virksomhed har et internt pentester- eller pentest-team, kan de arbejde permanent for virksomheden. Alligevel har mange virksomheder med skalaen til det en bred portefølje af systemer, der skal testes. Dette omfatter både produkter, der sælges, og virksomhedens forretningssystemer.

Som sådan kan de ikke bruge al deres tid på at teste én ting. Mange virksomheder foretrækker at hyre en ekstern pentesting virksomhed til at udføre engagementet. Dette er stadig tidsbegrænset baseret på omkostningerne. Omkostningerne er drevet af, at en pentest er en meget manuel proces, og at kompetencer er en mangelvare.

Typisk vil en pentest være scopet til en bestemt tidsramme. Dette gøres ud fra det pågældende mål, og hvor lang tid det skal tage at være nogenlunde sikker på at have fundet alt. Tidslinjen for at finde sårbarheder er generelt en klokkekurve. Der findes ikke meget med det samme, når pentesteren kigger rundt på applikationen. Så kan langt de fleste fund opnås inden for en specifik tidsskala, før de aftager. På et tidspunkt er omkostningerne ved at bruge mere tid på at lede ikke chancen værd, at der ikke er andet at finde.

Nogle gange er selv den angivne pris for den anbefalede tid for meget. I dette tilfælde kan testen være "time boxed". Det er her, klienten accepterer, at de ikke tester så meget som anbefalet, men ønsker, at pentesterne skal gøre det bedste, de kan inden for en reduceret tidsramme. Typisk indgår dette som et forbehold i rapporten.

Manuel proces

Nogle værktøjer er tilgængelige til at udføre sikkerhedstest automatisk. Disse kan være nyttige. Imidlertid har de ofte høje falske positive og falske negative rater. Det betyder, at du skal bruge tid på at grave gennem at verificere problemer, vel vidende at det måske ikke er omfattende. De fleste af disse værktøjer leder efter specifikke indikatorer, såsom kendte sårbare versioner af software eller kendte sårbare funktioner. Der er dog masser af måder, hvorpå disse ikke kan være reelle problemer eller afbødes i praksis.

Sikkerhedssårbarheder kan komme sammen fra en masse tilsyneladende uskadelige stykker. Den bedste måde at få øje på dette er gennem manuel menneskelig indsats. Pentesters bruger værktøjer, men ved, hvordan de skal fortolke resultaterne, manuelt verificere dem og udføre uafhængige manuelle handlinger. Denne manuelle indsats adskiller en pentest fra en sårbarhedsscanning eller sårbarhedsvurdering.

Typer af Pentest

Typisk involverer en pentest at teste et helt produkt, som det ville blive implementeret. Ideelt set sker dette i et rigtigt produktionsmiljø. Dette er dog ikke altid praktisk. For det første er der frygten for, at den pentest kunne slå målet offline. Generelt er denne frygt i det væsentlige ubegrundet. Pentests genererer generelt ikke for meget netværkstrafik, måske det svarer til et par ekstra aktive brugere. Pentesters vil heller ikke bevidst teste for problemer med denial-of-service, især i produktionsmiljøer. I stedet vil de typisk rapportere mistanke om denial-of-service-problemer for at give klienten mulighed for selv at undersøge det.

Derudover er det værd at bemærke, at hvis systemet er forbundet til internettet, er det konstant underlagt "gratis pentests" fra rigtige black hat hackere og deres bots. En anden grund til at undgå produktionsmiljøer er privatlivsproblemer med live brugerdata. Pentesters er etiske hackere i henhold til NDA'er og kontrakter, men hvis et testmiljø findes og ligner, kan det bruges.

Tip: En "gratis pentest" er en sjov måde at henvise til at være under angreb fra sorte hatte på internettet.

Pentests kan udføres mod stort set ethvert teknisk system. Hjemmesider og netværksinfrastruktur er de mest almindelige typer test. Du får også API-test, "tyk klient"-test, mobiltest, hardwaretest og meget mere.

Variationer over temaet

Realistisk set er phishing-, OSINT- og red team-øvelser relaterede, men lidt anderledes. Du er sandsynligvis klar over truslen om phishing. Nogle test involverer test for at se, hvordan medarbejdere reagerer på phishing-e-mails. Ved at spore, hvordan brugere interagerer – eller ikke gør – med phishen, er det muligt at lære at skræddersy fremtidig phishing-træning.

OSINT står for Open Source Intelligence. En OSINT-test drejer sig om at skrabe offentligt tilgængelig information for at se, hvordan værdifulde data kan indsamles, og hvordan de kan bruges. Dette involverer ofte generering af lister over medarbejdere fra steder som LinkedIn og virksomhedens hjemmeside. Dette kan gøre det muligt for en angriber at identificere ledende personer, der kan være gode mål for et spear-phishing-angreb, phishing specifikt skræddersyet til den enkelte modtager.

Et rødt teamengagement er typisk meget mere dybdegående og kan involvere nogle eller alle andre komponenter. Det kan også omfatte test af fysisk sikkerhed og overholdelse af sikkerhedspolitikken. På den politiske side af tingene involverer dette social engineering. Det forsøger at overbevise dig ind i bygningen. Dette kan være så simpelt som at hænge ud i rygeområdet og komme tilbage med rygerne efter en røgpause.

Det kan være at udgive sig som embedsmand eller bede nogen om at få en dør til dig, mens du bærer en kaffekopbakke. På den fysiske sikkerhedsside kan det endda involvere forsøg på at bryde ind fysisk, test af kameradækning, kvalitet af låse og lignende. Røde team-engagementer involverer typisk et team af mennesker og kan løbe over meget længere tidsskalaer end normale pentests.

Røde hold

En rød holdøvelse kan virke mindre etisk end en standard pentest. Testeren jager aktivt intetanende medarbejdere. Det centrale er, at de har tilladelse fra virksomhedens ledelse, typisk fra bestyrelsesniveau. Dette er den eneste grund til, at det er ok for en rød holdspiller at prøve at bryde ind. Intet tillader dog, at det er voldeligt. En rød holdøvelse vil aldrig forsøge at skade eller undertrykke en sikkerhedsvagt, at omgå eller narre dem.

For at forhindre den røde holdspiller i at blive arresteret, vil de generelt bære en underskrevet kontrakt med underskrifter fra de godkendende bestyrelsesmedlemmer. Hvis de bliver fanget, kan dette bruges til at bevise, at de havde tilladelse. Selvfølgelig bruges dette nogle gange som et dobbelt bluff. Den røde holdspiller kan medbringe to tilladelsessedler, en rigtig og en falsk.

Når de bliver fanget, afleverer de i første omgang den falske tilladelsesseddel for at se, om de kan overbevise sikkerheden om, at den er legitim, selv når den ikke er det. Til det formål vil den ofte bruge de faktiske navne på virksomhedens bestyrelse, men inkludere et bekræftelsestelefonnummer, der går til en anden rød teamer, der er orienteret om at bekræfte forsidehistorien. Hvis sikkerheden gennemskuer dette, udleveres den rigtige tilladelsesseddel naturligvis. Dette kan dog behandles med stor mistænksomhed.

Afhængigt af hvordan den røde holdspiller blev fanget, kan det være muligt at fortsætte testen, forudsat at de har forbigået den enkelte sikkerhedsvagt, der har fanget dem. Det er dog muligt, at testerens identitet kan være "sprængt", hvilket i det væsentlige fjerner dem fra enhver yderligere personlig test. På dette tidspunkt kan et andet teammedlem bytte ind med eller uden at informere sikkerheden.

Konklusion

En pentest er et engagement, hvor en cybersikkerhedsprofessionel bliver bedt om at teste sikkerheden af ​​et computersystem. Testen involverer manuelt at søge efter og verificere tilstedeværelsen af ​​sårbarheder. Automatiserede værktøjer kan bruges som en del af dette. Ved afslutningen af ​​testen leveres en rapport, der beskriver de fundne problemer og giver råd om afhjælpning.

Det er vigtigt, at denne rapport ikke kun er det automatiserede output fra et værktøj, men alt er blevet manuelt testet og verificeret. Ethvert computersystem, hardware, netværk, applikation eller enhed kan gennemprøves. De nødvendige færdigheder varierer, men er ofte komplementære.