NIS2 och penetrationstester – vad lagen kräver

NIS2 ställer skärpta krav på hur organisationer hanterar cybersäkerhetsrisker. För säkerhetschefer och compliance-ansvariga väcker det en konkret fråga: vad innebär det egentligen för säkerhetstestningen?

Om du vill ha en övergripande genomgång av NIS2, vilka som omfattas, kravbilden och konsekvenserna vid bristande efterlevnad, börja med vår introduktionsartikel: Vad är NIS2 och vad innebär det för dig?

Den här artikeln fokuserar på en specifik fråga som sällan får ett konkret svar: kräver NIS2 penetrationstester, och vad räknas egentligen som tillräckligt?

Kräver NIS2 pentest? Kort svar

NIS2 namnger inte penetrationstester explicit, men direktivet kräver att organisationer genomför riskanalyser, hanterar sårbarheter systematiskt och verifierar att säkerhetsåtgärder faktiskt fungerar. I praktiken pekar det mot strukturerad säkerhetstestning, och för kritiska system och väsentliga entiteter innebär det i regel penetrationstester.

Tillsynsmyndigheter i EU har också börjat precisera vad "lämpliga och proportionella åtgärder" faktiskt innebär. Automatiserade skanningar räcker sällan på egen hand för system med hög riskklass. Manuell, metodisk testning är vad som förväntas.

‍

Läs vår guide: NIS2 — vad behöver ditt företag göra?

‍

Relevanta delar av artikel 21

Artikel 21 i NIS2 slår fast att organisationer som omfattas ska vidta tekniska och organisatoriska åtgärder för att hantera risker mot sina nätverks- och informationssystem. Flera av punkterna är direkt relevanta för säkerhetstestning.

‍

• Riskanalys och informationssäkerhet kräver att organisationen löpande bedömer sin riskbild. Ett penetrationstest ger konkret underlag: vad är faktiskt exploaterbart, och hur allvarligt?
  ‍
• Sårbarhetshantering innebär att organisationen ska identifiera, prioritera och åtgärda sårbarheter systematiskt. Pentest är ett av de effektivaste sätten att validera att sårbarheterna är reella och faktiskt går att utnyttja i er specifika miljö.
  ‍
• Säkerhet i system och nätverk täcker krav på att skydda kritisk infrastruktur och applikationer. Att testa dessa system under kontrollerade former är ett direkt sätt att visa att kraven efterlevs.
  ‍
• Incidenthantering hänger ihop med testning på ett sätt som ofta förbises. Regelbundna penetrationstester minskar sannolikheten för att en incident inträffar, och ger organisationen bättre beredskap att förstå och begränsa skador om något ändå händer.

NIS2 kräver alltså inte pentest i exakta ordalag, men kraven på verifiering, riskbedömning och sårbarhetshantering gör det svårt att argumentera för att man uppfyller direktivet utan det. I alla fall för system med hög riskklass.

‍

Vilken typ av pentest möter kraven?

Alla penetrationstester är inte likvärdiga ur ett NIS2-perspektiv. Direktivet kräver proportionella åtgärder, vilket innebär att testningen ska matcha riskklassen på de system som testas. För väsentliga entiteter och kritiska system räcker varken automatiserade skanningar eller ytliga manuella tester.

Det är också här många organisationer snubblar. Man bockar av "pentest genomfört" utan att fundera på om testet faktiskt håller för granskning. Det gör det inte alltid.

Vad tillsynspraxis pekar mot:

• Erkänd metodik. Testet bör följa etablerade ramverk som OWASP, OSSTMM, PTES eller ISSAF. Det visar att testningen är systematisk och jämförbar med branschstandard.
  ‍

• Kvalificerade testare. Certifieringar som OSCP, CREST eller likvärdiga är ett sätt att dokumentera kompetensen hos de som utför testet. Tillsynsmyndigheter förväntar sig att testarna har relevant erfarenhet och kan motivera sina metoder.
  ‍

• Oberoende från utvecklingsteamet. NIS2:s krav på oberoende granskning talar tydligt mot att låta det egna säkerhets- eller utvecklingsteamet utföra testningen på kritiska system. Interna team har ofta djup teknisk kunskap, men de saknar det externa perspektivet som krävs för att se det en angripare ser. Alla blir hemmablinda förr eller senare.
  ‍

• Dokumenterad rapport med klassificerade fynd. Testet ska resultera i en skriftlig rapport där sårbarheter är klassificerade efter allvarlighetsgrad och åtgärder är tydligt definierade. En rapport som bara listar fynd utan kontext eller prioritering uppfyller inte det som förväntas.

‍

Hur ofta ska man testa?

NIS2 anger ingen specifik testfrekvens. Vad direktivet kräver är att säkerhetsåtgärderna är löpande och anpassade efter riskbilden, vilket innebär att frekvensen styrs av verksamhetens förändringstakt och systemens riskklass.

Jämförbara regelverk ger en praktisk riktlinje. PCI-DSS kräver minst ett externt penetrationstest per år och test vid betydande förändringar i nätverksmiljön. ISO 27001 förutsätter att säkerhetstestning ingår som en del av det systematiska informationssäkerhetsarbetet och utförs regelbundet.

För organisationer som omfattas av NIS2 är en rimlig utgångspunkt:
‍

• Minst en gång per år för kritiska system och infrastruktur

• Vid betydande systemförändringar, nya integrationer eller efter säkerhetsincidenter

• Löpande sårbarhetsskanning som komplement mellan de djupare testerna

Det viktiga är att testningen är regelbunden och riskbaserad. Ett fast schema som rullar på oavsett vad som hänt i miljön ger dig varken bättre säkerhet eller starkare underlag vid tillsyn.

‍

Dokumentation för tillsynsmyndigheten

MSB begär inte penetrationstestrapporter rutinmässigt, men vid tillsyn förväntas organisationen kunna visa upp underlag som demonstrerar att säkerhetsarbetet är systematiskt och faktiskt genomfört.

Vad som bör finnas dokumenterat:
‍

• Testrapporter med metodik, scope, fynd och allvarlighetsklassificering. Rapporten ska vara daterad och signerad av ansvarig testare.
  ‍

• Åtgärdsplan som visar hur identifierade sårbarheter har hanterats, av vem och inom vilken tidsram.
  

• Verifiering av åtgärder, helst i form av ett uppföljningstest eller dokumenterad intern verifiering som bekräftar att bristerna är åtgärdade.
  ‍

• Ledningens godkännande av säkerhetsåtgärderna. NIS2 lägger ett tydligt ansvar på ledningen, och dokumentationen ska spegla att säkerhetsarbetet är förankrat på rätt nivå i organisationen.

Samla all dokumentation från varje testtillfälle i ett systematiskt arkiv, strukturerat per system och tidsperiod. Vid tillsyn vill du kunna visa upp ett sammanhängande spår snabbt, inte leta igenom mejltrådar från tre år tillbaka.