Penetrationstest vs sårbarhetsskanning: viktiga skillnader

Vad det är

En sårbarhetsskanning kör ett verktyg mot värdar, webbplatser eller applikationer och rapporterar problem som det kan känna igen: saknade uppdateringar, föråldrade programversioner, exponerade tjänster, svaga TLS-inställningar eller vanliga felkonfigurationer. Skanningar är snabba och upprepningsbara, vilket gör dem lämpliga för löpande säkerhetshygien. Begränsningarna är välkända. Skannrar ger falska positiva, missar problem som beror på affärslogik och kan inte avgöra om ett lågt klassat fynd blir allvarligt i kombination med ett annat. Ett penetrationstest utgår från en skriftlig omfattning och överenskomna testregler. Testaren använder verktyg, även skannrar, men arbetar sedan manuellt: validerar fynd, testar autentisering och auktorisering, kontrollerar hur roller och kunder (tenants) hålls åtskilda och följer realistiska vägar som en angripare skulle kunna pröva. Resultatet är en rapport med belägg, allvarlighetsgrad och vägledning för åtgärder i stället för en rå lista med verktygsutdata. Kort sagt: en skanning berättar vad som kan vara fel; ett penetrationstest berättar vad som bevisligen är fel inom den överenskomna omfattningen och varför det spelar roll.

Vem det är för

Jämförelsen är användbar för team som:

• Har fått en förfrågan från en kund, partner eller ett försäkringsbolag om ”säkerhetstestning” och behöver förstå vad som faktiskt efterfrågas
• Redan kör regelbundna skanningar och vill veta om ett manuellt test skulle ge meningsfull insikt
• Lanserar en ny webbapplikation, ett API eller en mobilapp och behöver avgöra hur djup testningen före lansering bör vara
• Behöver förklara för ledningen varför två offerter på ”testning” ser mycket olika ut i insats och resultat

Vad det hjälper till att klargöra

Att läsa de två sida vid sida hjälper till att klargöra:

• Om frågan gäller hygien kring kända problem (skanning) eller utnyttjbar risk i ett specifikt system (penetrationstest)
• Vilka fynd i en befintlig skanningsrapport som sannolikt är brus och vilka som förtjänar manuell validering
• Hur affärslogik, åtkomstkontroll och angreppsvägar i flera steg ligger utanför vad automatiserade verktyg vanligtvis upptäcker
• Vilka belägg en intressent förväntar sig att se i en slutrapport

Vad ingår

• Checklista för skanning: definiera tillgångslistan, schemalägg regelbundna skanningar, utse en ansvarig som bedömer resultaten och följ upp åtgärderna över tid
• Checklista för penetrationstest: kom skriftligt överens om mål, miljöer, testfönster, åtkomstmetod, namngivna kontaktpersoner och stoppvillkor innan arbetet börjar
• Bekräfta skriftlig auktorisering från systemägaren och från eventuella hostingleverantörer eller leverantörer som driver system inom omfattningen
• Avgör om autentiserad testning behövs (testkonton för varje roll) så att problem med åtkomstkontroll kan undersökas
• Kom överens om hur fynd ska klassas och hur belägg ska delas säkert med namngivna kontaktpersoner
• Planera ett fönster för omtest så att åtgärdade fynd kan bekräftas efter åtgärd

Vad som inte ingår

• Ett påstående om att en skanning ensam visar att en applikation är säker
• Ett påstående om att ett penetrationstest hittar alla svagheter; det undersöker en överenskommen omfattning inom en överenskommen tid
• Instruktioner för utnyttjande eller testning av system som ni inte äger eller inte har tillstånd att testa
• Certifiering, godkännande av regelefterlevnad eller ett formellt revisionsutlåtande

När det passar att välja den

Välj skanning när ni behöver regelbunden, bred överblick över många tillgångar och har en process för att bedöma och åtgärda det som rapporteras. Välj ett penetrationstest när ett specifikt system är viktigt för verksamheten, när en kund eller partner begär belägg för manuell testning, före en betydande lansering eller efter större förändringar i autentisering, betalningar eller datahantering. Många organisationer använder båda: schemalagda skanningar för att hålla hygienen stabil och ett periodiskt penetrationstest för att undersöka de system som bär störst risk. Om ni ännu inte kan lista era tillgångar eller ägare kan en bredare baslinjegranskning vara ett mer användbart första steg än något av dem.

Vår strategi

Börja med det beslut ni behöver fatta. Om ett kundformulär efterfrågar ett årligt penetrationstest räcker en skanningsrapport vanligtvis inte. Om ni bara behöver veta om internetexponerade servrar är uppdaterade kan ett fullständigt manuellt test vara mer än ni behöver. Bekräfta sedan omfattningen: vilka applikationer, API:er, miljöer och användarroller som ingår och vilka som uttryckligen är undantagna. Kom överens om testfönstret och om vem som kan pausa arbetet. Vår tjänst Penetration Testing följer detta mönster: omfattning, skriftlig auktorisering, testning inom de överenskomna testreglerna, en skriftlig rapport med fynd och prioriterad vägledning för åtgärder, en genomgång och, där det ingår, omtest av överenskomna fynd. Oavsett vilken leverantör ni anlitar, be att få se en exempelrapport innan ni binder er och kontrollera att den skiljer validerade fynd från informativa iakttagelser. Avsätt slutligen tid för åtgärder. Ett test som ger fynd som ingen har tid att åtgärda tillför lite värde, så anpassa testdatumet efter teamets kapacitet att agera på resultaten.

Penetration Testing

Vanliga frågor

Relaterade artiklar