De fem faserna i ett penetrationstest

Fas 1: Scopning och avtalsstyrd planering

Innan en enda port skannas krävs en tydlig överenskommelse. Det här steget avgör hela testets kvalitet och relevans.

Vad som definieras:

• Vilka system, nätverk och applikationer som ingår (och uttryckligen inte ingår)
• Testperiod — start- och slutdatum, tillåtna tider på dygnet
• Tillåtna metoder — får testaren använda social engineering? Fysiskt tillträde?
• Eskaleringsvägar — vem kontaktas vid kritiska fynd under pågående test?
• Juridiskt ramverk — skriftligt auktorisering (ofta kallat "Rules of Engagement")

Det här steget ignoreras ofta i billigare tester, och det märks. Vi har sett fall där testare oavsiktligt tagit ner produktionssystem för att scopet var otydligt. Investera tid här.

Fas 2: Rekognosering och informationsinsamling

Nu börjar det tekniska arbetet. Testaren kartlägger er attackyta — allt som är exponerat och potentiellt sårbart.

Passiv rekognosering (utan direkt kontakt med målet):

• DNS-uppslag, WHOIS, certifikattransparensloggar
• Öppen källkodsinformation (OSINT): LinkedIn-profiler, GitHub-repon, läckta credentials i databaser
• Shodan/Censys för att identifiera exponerade tjänster

Aktiv rekognosering (direkt interaktion med målet):

• Portskanning med Nmap — vilka tjänster lyssnar på vilka portar?
• Tjänsteidentifiering — vilken version av Apache, Nginx, Exchange körs?
• Webbapplikationsfingerprinting — teknologistack, CMS-version, API-endpoints

I Opsios erfarenhet är den här fasen ofta den mest avslöjande för kunden. Många organisationer vet inte exakt vad som är exponerat mot internet. Vi ser regelbundet "glömda" testservrar, äldre API:er och subdomäner med föråldrad mjukvara som ingen längre äger internt.

Fas 3: Exploitation — den faktiska intrångstestningen

Med en karta över attackytan börjar testaren systematiskt exploatera identifierade sårbarheter. Det här är kärnan i testet.

Vanliga attackvektorer vi ser i produktion:

• Webbapplikationer: SQL-injection, cross-site scripting (XSS), broken access control (OWASP Top 10 är fortfarande relevant som referensram)
• Autentisering: Svaga lösenord, credential stuffing med läckta databaser, avsaknad av MFA
• Nätverkstjänster: Föråldrade SMB-versioner, osäkra RDP-exponeringar, felkonfigurerade VPN:er
• Molnmiljöer: Öppna S3-buckets, överprivilegierade IAM-roller, felkonfigurerade Security Groups i AWS (eu-north-1) eller NSG:er i Azure (Sweden Central)
• Social engineering: Phishing-kampanjer riktade mot specifika medarbetare (om det ingår i scopet)

Testaren dokumenterar varje lyckad exploitation med bevis: skärmdumpar, loggutdrag, exfiltrerad testdata. Målet är inte att orsaka skada utan att bevisa vad som är möjligt.

Molnsäkerhet

Fas 4: Lateral rörelse och privilegieeskalering

Att ta sig in är ofta bara det första steget. I verkliga angrepp rör sig angripare vidare internt — från en komprometterad arbetsstation till Active Directory-domänkontrollanten, från ett användarkonto till administratörsrättigheter.

I den här fasen testar testaren:

• Privilegieeskalering: Kan ett vanligt användarkonto bli domänadmin? Finns det lokala admin-lösenord som återanvänds?
• Lateral rörelse: Pass-the-hash, Kerberoasting, exploatering av förtroenden mellan system
• Dataåtkomst: Vilken känslig information kan nås med den uppnådda åtkomstnivån? Kunddata? Finansiell information? Källkod?
• Persistens: Skulle en angripare kunna bibehålla åtkomst även efter att den initiala sårbarheten åtgärdats?

Den här fasen avslöjar hur långt en angripare kan nå — och det är ofta betydligt längre än organisationer förväntar sig. Från Opsios SOC har vi sett att det vanligaste mönstret vid verkliga intrång är just lateral rörelse via Active Directory-felkonfigurationer.

Fas 5: Rapportering och åtgärdsrekommendationer

Rapporten är det ni faktiskt betalar för. En bra pentestrapport är inte en lista med CVE-nummer — det är ett beslutsunderlag.

En komplett rapport innehåller:

Klassificeringen följer typiskt CVSS (Common Vulnerability Scoring System) men bör kompletteras med kontextuell risk — en sårbarhet med CVSS 7.0 i en internetexponerad betalningsapplikation är allvarligare än samma sårbarhet i ett internt testsystem.

Penetrationstest och compliance: NIS2, ISO 27001, GDPR

Med NIS2-direktivets implementering i svensk lag ställs tydligare krav på att väsentliga och viktiga entiteter regelbundet testar sina säkerhetsåtgärder. Penetrationstester är det mest vedertagna sättet att visa att ni uppfyller kravet på att "testa och utvärdera effektiviteten i åtgärder för riskhantering av cybersäkerhet."

ISO/IEC 27001 refererar till penetrationstester under kontroll A.8.8 (hantering av tekniska sårbarheter) och som del av den kontinuerliga förbättringscykeln. En certifieringsrevisor vill se dokumenterade testresultat och bevis på att identifierade brister åtgärdats.

GDPR (särskilt artikel 32) kräver "förfaranden för att regelbundet testa, undersöka och utvärdera effektiviteten hos tekniska och organisatoriska åtgärder." IMY (Integritetsskyddsmyndigheten) har i flera tillsynsbeslut refererat till avsaknad av regelbunden säkerhetstestning som en brist.

Det betyder i praktiken: ni behöver inte bara genomföra tester, utan också dokumentera dem, visa att ni följt upp fynden och kunna presentera förbättringar vid tillsyn.

Managerade molntjänster

Vad skiljer ett bra pentest från ett dåligt?

Vi ser stora kvalitetsskillnader i de pentestrapporter som våra kunder delar med oss. Här är de vanligaste bristerna:

Tecken på ett undermåligt test:

• Rapporten är i princip en Nessus-utskrift med logotyp — ingen manuell verifiering
• Inga bevis på faktisk exploitation, bara "potentiella" sårbarheter
• Generiska åtgärdsrekommendationer som "uppdatera mjukvaran" utan kontext
• Testet tog 2–3 dagar för ett scope som realistiskt kräver 2 veckor
• Testaren frågade aldrig om er molnarkitektur, CI/CD-pipeline eller Active Directory-struktur

Tecken på ett kvalitativt test:

• Tydlig narrativ: "Vi tog oss in via X, eskalerade via Y, och nådde Z"
• Kontextuell riskbedömning kopplad till er verksamhet
• Rekommendationer som är specifika och prioriterade
• Testaren ställde relevanta frågor under scopningen
• Debriefing-möte där testaren förklarar fynden och svarar på frågor

Penetrationstest i molnmiljöer — särskilda överväganden

Molnleverantörer har specifika regler för penetrationstester. AWS tillåter tester mot era egna resurser i eu-north-1 utan förhandsanmälan (sedan 2019), men förbjuder fortfarande vissa testtyper som DNS zone walking via Route 53 och DDoS-simulering. Azure kräver ingen förhandsanmälan men har liknande begränsningar. Google Cloud tillåter tester utan godkännande så länge de följer deras Acceptable Use Policy.

Molnspecifika attackytor som bör ingå:

• IAM-konfigurationer (överprivilegierade roller, accessnycklar i kod)
• Nätverkssegmentering (Security Groups, NACLs, VPC Peering)
• Lagring (S3/Blob storage-behörigheter, kryptering i vila)
• Kubernetes-kluster (RBAC, network policies, pod security)
• Serverless-funktioner (Lambda/Azure Functions med överprivilegierade exekveringsroller)

Managerad DevOps

Så ofta bör ni testa — och hur ni kommer igång

Enligt NIST Cybersecurity Framework och ISO 27001 bör penetrationstester genomföras regelbundet och vid väsentliga förändringar. I praktiken innebär det:

• Årligen som minimum för alla organisationer med internetexponerade system
• Kvartalsvis för organisationer som omfattas av NIS2 eller hanterar känsliga personuppgifter
• Vid varje större förändring — ny applikation, molnmigrering, förvärv, ny kontorsplats
• Efter en incident — för att verifiera att åtgärderna fungerar

Första steget är att identifiera ert scope. Börja med det som är mest kritiskt och internetexponerat. Ett fokuserat test av era viktigaste system ger mer värde än ett ytligt test av allt.

Molnmigrering

Vanliga frågor

Hur ofta bör vi genomföra penetrationstester?

Minst en gång per år som baslinje, men även efter större infrastrukturändringar, nya applikationsreleaser eller förvärv. Organisationer som omfattas av NIS2 bör testa oftare — kvartalsvis eller vid varje större förändring. Opsios SOC ser regelbundet att kunder som testar sällan har fler oupptäckta sårbarheter som ackumulerats över tid.

Vad är skillnaden mellan en sårbarhetsskanning och ett penetrationstest?

En sårbarhetsskanning är automatiserad och identifierar kända sårbarheter mot en databas (som CVE). Ett penetrationstest går längre: en människa försöker aktivt exploatera sårbarheterna, kedja ihop dem och visa faktisk affärspåverkan. Skanningen hittar potentiella problem — pentestet bevisar vilka som faktiskt går att utnyttja.

Kan ett penetrationstest störa vår produktionsmiljö?

Risken finns men minimeras genom tydlig scopning. Testare undviker destruktiva tekniker mot produktionssystem om ni inte uttryckligen godkänner det. Kritiska system kan testas mot staging-miljöer. Vi rekommenderar alltid att ha rollback-planer och att ert driftteam är informerat under testperioden.

Vad kostar ett penetrationstest?

Kostnaden varierar kraftigt beroende på scope: en extern nätverkstest för ett medelstort företag kan ligga på 50 000–150 000 SEK, medan en omfattande red team-övning med fysisk och social ingenjörskonst kan kosta betydligt mer. Avgörande faktorer är antal IP-adresser, applikationer, testdjup och om det inkluderar molnmiljöer.

Måste vi genomföra penetrationstester för att uppfylla NIS2?

NIS2-direktivet kräver att väsentliga och viktiga entiteter vidtar lämpliga tekniska åtgärder för riskhantering, inklusive testning av säkerhetsåtgärdernas effektivitet. Penetrationstester är det mest vedertagna sättet att uppfylla det kravet. Direktivet specificerar inte exakt metod, men regulatorisk praxis pekar tydligt mot regelbunden pentesting.