Penetrationstest kontra sårbarhetsskanning: en avgörande skillnad

En av de vanligaste felmatchningarna vi ser hos kunder som försöker uppfylla NIS2 är att de förväxlar automatiserad sårbarhetsskanning med penetrationstest. Det är som skillnaden mellan att kontrollera att dörren har ett lås och att faktiskt försöka bryta sig in.

Båda behövs. Sårbarhetsskanning ger kontinuerlig överblick. Penetrationstest ger den verklighetsförankring som NIS2 kräver när tillsynsmyndigheten frågar: "Hur vet ni att era skyddsåtgärder faktiskt fungerar?"

Praktisk metodik: så strukturerar ni ert NIS2-anpassade penetrationstest

Baserat på vad vi ser fungera i produktion hos våra kunder — och vad som håller vid granskning — rekommenderar vi en struktur i fem faser.

Fas 1: Scope och riskanalys

Börja inte med att testa allt. Börja med att identifiera vad som faktiskt är kritiskt enligt NIS2:s perspektiv. Det handlar om de nätverks- och informationssystem som stödjer de tjänster ni levererar som väsentlig eller viktig enhet. Kartlägg:

• Kritiska tjänster — vilka tjänster gör att ni faller under NIS2?
• Stödjande system — vilka IT-system, molnmiljöer och OT-komponenter understödjer dessa tjänster?
• Leverantörskedjor — NIS2 ställer explicit krav på att ni bedömer risker i leverantörskedjan (artikel 21.2d)

Fas 2: Hotmodellering

Slumpmässig testning ger slumpmässiga resultat. Utgå från den hotbild som faktiskt är relevant för er sektor. Energisektorn har andra hotaktörer än en SaaS-leverantör. Vi rekommenderar att utgå från MITRE ATT&CK-ramverket och anpassa angreppsscenarierna efter:

• Kända taktiker, tekniker och procedurer (TTP:er) som används mot er bransch
• Geopolitisk hotbild — särskilt relevant för kritisk infrastruktur i Norden
• Insider-hot — NIS2 nämner explicit den mänskliga faktorn

Fas 3: Teknisk testning

Det här är själva penetrationstestet. Det bör täcka minst:

• Extern testning — perimetern sedd utifrån: exponerade tjänster, VPN-gateways, webbapplikationer, API:er
• Intern testning — vad händer när en angripare redan har fotfäste i nätverket (komprometterad arbetsstation, stulen VPN-åtkomst)?
• Molnmiljöer — felkonfigurationer i AWS, Azure eller GCP är en av de vanligaste vektorerna vi ser i Opsios SOC. IAM-policyer, publika S3-buckets, överexponerade Kubernetes-kluster
• Active Directory / Entra ID — identitetsinfrastruktur är nästan alltid angriparens primära mål
• OT/SCADA (om tillämpligt) — kritisk infrastruktur har ofta IT/OT-konvergenspunkter som är bristfälligt skyddade

Managerad molnsäkerhet

Fas 4: Testning av processer och människor

Teknisk testning ensam räcker inte för NIS2-efterlevnad. Artikel 21 kräver organisatoriska åtgärder, och det inkluderar:

• Social engineering / nätfiske-simuleringar — testar medarbetarnas motståndskraft och era processer för att hantera phishing
• Incidenthanteringsövning — kan ni faktiskt rapportera en incident inom 24 timmar som NIS2 kräver? Testa det skarpt
• Behörighetsgranskningar — har rätt personer rätt åtkomst? Principen om minsta behörighet är grundläggande

Fas 5: Rapportering och åtgärdsplan

En penetrationstestrapport som bara listar CVE-nummer är värdelös för NIS2. Rapporten måste:

• Koppla fynd till affärsrisk — inte bara "SQLi i webbappen" utan "vi fick åtkomst till 40 000 kundposter via SQLi i betalningsportalen"
• Prioritera enligt faktisk exploaterbarhet — CVSS-poäng ljuger ibland. Kontextuell riskbedömning är viktigare
• Innehålla en konkret åtgärdsplan med ansvarig, tidslinje och verifieringsmetod
• Vara strukturerad för tillsynsmyndigheten — MSB (Myndigheten för samhällsskydd och beredskap) eller sektorsspecifik tillsynsmyndighet kan begära dokumentation

Managerade molntjänster

Svensk kontext: tillsyn och nationell implementering

I Sverige ansvarar MSB för den övergripande tillsynen av NIS2-implementeringen, med sektorsspecifika tillsynsmyndigheter för respektive bransch. Integritetsskyddsmyndigheten (IMY) hanterar GDPR-aspekter som ofta sammanfaller med NIS2-krav — en dataintrångsincident är typiskt sett både en NIS2-incident och en GDPR-incident.

Några praktiska konsekvenser för svenska organisationer:

• Incidentrapportering ska ske inom 24 timmar (tidig varning) och med fullständig rapport inom 72 timmar
• Tillsyn blir proaktiv för väsentliga enheter — räkna med att bli granskade utan att en incident har inträffat
• Dokumentationskrav är höga: ni ska kunna visa policyer, riskanalyser, testresultat och åtgärdsplaner

Penetrationstestrapporter blir en del av er efterlevnadsdokumentation. Strukturera dem därefter från dag ett.

Vanliga misstag vi ser i praktiken

Från Opsios SOC och vårt arbete med NIS2-efterlevnad ser vi återkommande mönster:

1. Testning som alibi, inte som säkerhetsåtgärd. Årligt penetrationstest som aldrig leder till åtgärder. NIS2 kräver inte bara att ni testar — ni ska visa att ni agerar på resultaten.

2. Molnmiljöer utanför scope. Många organisationer exkluderar sina AWS- eller Azure-miljöer från penetrationstestet för att "molnleverantören ansvarar för säkerheten". Shared responsibility model betyder att er konfiguration är ert ansvar. Och det är nästan alltid i konfigurationen som bristerna sitter.

3. Ingen koppling till incidenthantering. Penetrationstestets fynd ska mata in i era incidenthanteringsplaner. Hittade testaren en väg in via VPN? Då ska er SOC ha detektionsregler för det scenariot.

4. Leverantörskedjan glöms bort. NIS2 artikel 21.2(d) nämner explicit "säkerhet i leverantörskedjan." Ni behöver inte penetrationstesta era leverantörer, men ni behöver verifiera att de genomför adekvat testning.

Managerad DevOps

Bygga ett kontinuerligt testprogram

NIS2-efterlevnad är inte ett årligt projekt — det är ett kontinuerligt program. Så här rekommenderar vi att strukturera det:

Det här är ingen önskelista — det är vad vi ser krävs för att hålla en NIS2-efterlevnad som är verklig, inte bara på papper.

Cloud FinOps

Att välja rätt testpartner

En penetrationstestare som ska stödja NIS2-efterlevnad behöver mer än teknisk skicklighet. Utvärdera:

• Certifieringar: OSCP, OSCE, CREST eller motsvarande — inga genvägar
• Sektorskunskap: förstår testaren er branschs hotbild och regelverk?
• Rapporteringskvalitet: begär exempelrapporter. Är fynden kopplade till affärsrisk?
• Molnkompetens: kan testaren arbeta i AWS, Azure och GCP med förståelse för respektive plattforms säkerhetsmodell?
• Uppföljning: erbjuder partnern verifieringstest efter att ni åtgärdat fynden?

En managerad tjänsteleverantör (MSP) med integrerad SOC-kapacitet kan koppla penetrationstestets fynd direkt till er löpande övervakning — det är så testning blir operationell säkerhet istället för en hyllvärmare.

Molnmigrering

Vanliga frågor

Hur ofta kräver NIS2 penetrationstest?

NIS2 specificerar inte exakt frekvens i direktivtexten, men kräver att säkerhetsåtgärder "regelbundet" testas och utvärderas. I praktiken innebär det minst årliga tester för väsentliga enheter och vid varje väsentlig infrastrukturförändring. Nationella tillsynsmyndigheter kan ställa strängare krav.

Vad är skillnaden mellan NIS2-penetrationstest och DORA:s TLPT?

DORA (Digital Operational Resilience Act) kräver hotbildsstyrd penetrationstestning (TLPT) enligt TIBER-EU-ramverket för systemviktiga finansiella aktörer, minst vart tredje år. NIS2 är bredare och täcker fler sektorer men ger mer flexibilitet i testmetodik. Organisationer som omfattas av båda måste uppfylla DORA:s strängare krav.

Kan vi använda sårbarhetsskanning istället för penetrationstest?

Nej, inte som enda åtgärd. Sårbarhetsskanning identifierar kända brister automatiskt men testar inte om de faktiskt kan utnyttjas i er specifika miljö. NIS2 kräver att ni verifierar er faktiska motståndskraft — det kräver manuell, kvalificerad testning som simulerar verkliga angreppsscenarier.

Vilka sektorer omfattas av NIS2:s krav på penetrationstest?

NIS2 omfattar 18 sektorer uppdelade i väsentliga (energi, transport, hälso- och sjukvård, dricksvatten, digital infrastruktur, offentlig förvaltning, rymd) och viktiga (post, avfallshantering, livsmedel, kemikalier, tillverkning, digitala tjänster m.fl.). Alla omfattade organisationer ska ha proportionerliga säkerhetstester.

Vad händer om vi inte genomför penetrationstest enligt NIS2?

Väsentliga enheter riskerar sanktioner upp till 10 miljoner euro eller 2 % av global årsomsättning. Viktiga enheter riskerar upp till 7 miljoner euro eller 1,4 %. Utöver böter kan tillsynsmyndigheter kräva omedelbara åtgärder, och ledningen kan hållas personligt ansvarig.