Hur ofta bör ni göra penetrationstest?

Ett årsintervall antar att risken ökar med tiden. Det gör den inte av sig själv. Risken ökar när något förändras: ny kod, ny integration, ny behörighet, ny leverantör, eller en ny teknik hos angriparna som gör en gammal konstruktion sårbar.

Konsekvensen är att ett årligt schema både testar för ofta och för sällan. Det stabila systemet testas i onödan, och det system som ändras varje sprint hinner drifta långt från det tillstånd som en gång godkändes.

Det finns ett undantag värt att erkänna: en ny teknik eller en ny klass av sårbarhet kan göra ett oförändrat system sårbart. Men den utlösaren är också en händelse, inte ett datum, och den bevakas genom sårbarhetsskanning och omvärldsbevakning snarare än genom ett årligt test.

2 kap. 3 § listar tio områden som riskhanteringen ska omfatta, och punkt 6 avser strategier för att bedöma åtgärdernas effektivitet. Ordet strategier är återigen värt att stanna vid: det som krävs är ett sätt att arbeta, inte en händelse per år.

Frånvaron av intervall betyder inte frihet från bevis. Om det inte finns en föreskriven frekvens att uppfylla kan ni inte heller peka på att ni uppfyllt den, och får i stället visa hur ni resonerade: vilka utlösare ni valt, varför, och vad ni gjorde när de inträffade.

Det är också därför en händelsestyrd modell är lättare att försvara än en kalenderstyrd. Kalendern besvarar frågan när, men inte frågan varför just då, och det är den andra frågan en tillsynsmyndighet ställer.

Verksamhetsutövare ska vidta lämpliga och proportionella tekniska, driftsrelaterade och organisatoriska åtgärder för att skydda nätverks- och informationssystem.

Argumentet ovan talar mot kalenderstyrning som hela strategin, inte mot att ha ett återkommande test alls. Ett fast tillfälle gör två saker som händelsestyrning inte gör.

Det första är att det fångar den drift ingen registrerade som en förändring. Små justeringar som var för sig inte utlöste något ackumuleras, och ingen av dem hade en ändringsbegäran som pekade på behovet av ett test.

Det andra är organisatoriskt. Ett bokat test skapar en deadline som får saker åtgärdade i förväg, och det ger en jämförelsepunkt mellan år. Båda effekterna är verkliga och ingen av dem handlar om säkerhet i teknisk mening, vilket är värt att vara ärlig om när kadensen motiveras.

Skriv den som en tabell med två kolumner: utlösare och omfattning. Utlösarna är händelser i era egna processer, och omfattningen anger hur stort testet blir när utlösaren inträffar.

Koppla sedan tabellen till era befintliga flöden. Om er förändringshantering redan har ett steg för säkerhetsbedömning är det där utlösarna hör hemma, inte i ett separat dokument som ingen öppnar mellan revisionerna.

Lägg till ett golv: minst ett test per period för de system som bär verksamheten, oavsett om någon utlösare inträffat. Motivera golvet med drift snarare än med säkerhet, eftersom det är den faktiska anledningen och en granskare känner igen skillnaden.