Penetrationstest vs. sårbarhedsscanning: de vigtigste forskelle

Hvad det er

En sårbarhedsscanning kører et værktøj mod hosts, websites eller applikationer og rapporterer de problemer, det kan genkende: manglende patches, forældede softwareversioner, eksponerede tjenester, svage TLS-indstillinger eller almindelige fejlkonfigurationer. Scanninger er hurtige og kan gentages, hvilket gør dem velegnede til løbende sikkerhedshygiejne. Deres begrænsninger er velkendte. Scannere giver falske positiver, overser problemer, der afhænger af forretningslogik, og kan ikke fortælle jer, om et fund med lav vurdering bliver alvorligt i kombination med et andet. En penetrationstest tager udgangspunkt i et skriftligt omfang og aftalte testregler. Testeren bruger værktøjer, herunder scannere, men arbejder derefter manuelt: validerer fund, tester autentifikation og autorisation, kontrollerer, hvordan roller og tenants er adskilt, og følger realistiske veje, som en angriber kunne forsøge. Resultatet er en rapport med beviser, alvorlighedsgrad og vejledning i afhjælpning frem for en rå liste med værktøjsoutput. Kort sagt fortæller en scanning jer, hvad der måske er galt; en penetrationstest fortæller jer, hvad der påviseligt er galt inden for det aftalte omfang, og hvorfor det har betydning.

Hvem er det for?

Denne sammenligning er nyttig for teams, der:

• Har modtaget en anmodning fra en kunde, partner eller et forsikringsselskab om „sikkerhedstest“ og har brug for at forstå, hvad der egentlig bliver bedt om
• Allerede kører regelmæssige scanninger og vil vide, om en manuel test vil give væsentlig indsigt
• Lancerer en ny webapplikation, API eller mobilapp og skal beslutte, hvor dybtgående testen før lancering skal være
• Skal forklare ledelsen, hvorfor to tilbud på „test“ ser meget forskellige ud i indsats og resultat

Hvad det hjælper med at afklare

Når de to læses side om side, hjælper det med at afklare:

• Om jeres spørgsmål handler om hygiejne for kendte problemer (scanning) eller udnyttelig risiko i et bestemt system (penetrationstest)
• Hvilke fund i en eksisterende scanningsrapport sandsynligvis er støj, og hvilke der fortjener manuel validering
• Hvordan forretningslogik, adgangskontrol og angrebsveje i flere trin ligger uden for det, automatiserede værktøjer normalt opdager
• Hvilke beviser en interessent vil forvente at se i en endelig rapport

Hvad er inkluderet

• Tjekliste for scanning: definér listen over aktiver, planlæg regelmæssige scanninger, udpeg en ejer til at triagere resultaterne, og følg afhjælpningen over tid
• Tjekliste for penetrationstest: aftal mål, miljøer, testvindue, adgangsmetode, navngivne kontaktpersoner og stopbetingelser skriftligt, før arbejdet begynder
• Bekræft skriftlig autorisation fra systemejeren og fra enhver hostingudbyder eller leverandør, der driver systemer inden for omfanget
• Beslut, om der er behov for autentificeret test (testkonti for hver rolle), så problemer med adgangskontrol kan undersøges
• Aftal, hvordan fund skal vurderes, og hvordan beviser deles sikkert med navngivne kontaktpersoner
• Planlæg et vindue til gentest, så afhjulpne fund kan bekræftes efter afhjælpningen

Hvad er ikke inkluderet?

• En påstand om, at en scanning alene viser, at en applikation er sikker
• En påstand om, at en penetrationstest finder alle svagheder; den undersøger et aftalt omfang inden for en aftalt tid
• Vejledning i udnyttelse eller test af systemer, som I ikke ejer eller ikke har tilladelse til at teste
• Certificering, godkendelse af compliance eller en formel revisionserklæring

Hvornår du skal vælge det

Vælg scanning, når I har brug for regelmæssigt og bredt overblik over mange aktiver og har en proces til at triagere og rette det, den rapporterer. Vælg en penetrationstest, når et bestemt system er vigtigt for forretningen, når en kunde eller partner beder om dokumentation for manuel test, før en betydelig lancering eller efter større ændringer i autentifikation, betalinger eller datahåndtering. Mange organisationer bruger begge: planlagte scanninger for at holde hygiejnen stabil og en periodisk penetrationstest for at undersøge de systemer, der bærer størst risiko. Hvis I endnu ikke kan opliste jeres aktiver eller ejere, kan en bredere baselinegennemgang være et mere nyttigt første skridt end begge dele.

Vores tilgang

Start med den beslutning, I skal træffe. Hvis et kundespørgeskema beder om en årlig penetrationstest, vil en scanningsrapport normalt ikke være tilstrækkelig. Hvis I blot skal vide, om internetvendte servere er patchet, kan en fuld manuel test være mere, end I har brug for. Bekræft dernæst omfanget: hvilke applikationer, API’er, miljøer og brugerroller der er med, og hvilke der udtrykkeligt er udeladt. Aftal testvinduet, og hvem der kan sætte arbejdet på pause. Vores tjeneste Penetration Testing følger dette mønster: omfang, skriftlig autorisation, test inden for de aftalte testregler, en skriftlig rapport over fund med prioriteret vejledning i afhjælpning, en gennemgang af resultaterne og, hvor det er inkluderet, en gentest af aftalte fund. Uanset hvilken udbyder I bruger, så bed om at se en eksempelrapport, før I forpligter jer, og kontrollér, at den adskiller validerede fund fra informative observationer. Afsæt til sidst tid til afhjælpning. En test, der giver fund, som ingen har tid til at rette, tilfører kun lidt værdi, så tilpas testdatoen til jeres teams kapacitet til at handle på resultaterne.

Penetration Testing

Ofte stillede spørgsmål

Relaterede artikler