De fem faserna i ett penetrationstest

Fas 1: Scope och förutsättningar

Allt börjar med att definiera vad som ska testas — och minst lika viktigt, vad som inte ska testas. Scope-definitionen är den fas som avgör om pentestet levererar verkligt värde eller bara producerar brus.

Här fastställs:

• Testtyp: black box (testaren har ingen förkunskap), grey box (begränsad information, till exempel användaruppgifter) eller white box (full insyn i arkitektur och källkod)
• Målsystem: specifika applikationer, nätverkssegment, API:er, molnmiljöer eller hela infrastrukturen
• Testdjup: ska testaren stanna vid initial exploatering eller försöka eskalera till domänadministratör?
• Regler för engagemang: tidsfönster, kontaktpersoner vid incidenter, miljöer som är off-limits
• Regulatoriska krav: om testet syftar till att uppfylla NIS2, ISO 27001 eller PCI DSS påverkar det rapporteringsformatet

Vår erfarenhet på Opsio är att grey box-tester ger bäst avkastning för de flesta organisationer. Black box låter dramatiskt men slösar testartid på rekognosering som kunden redan kunde tillhandahållit. White box är idealiskt för applikationssäkerhet där källkodsanalys ingår.

Fas 2: Rekognosering (information gathering)

Med scope på plats börjar testaren samla information om målet. Det här är den fas som skiljer amatörer från proffs — en erfaren pentestare lägger ofta 20–30 procent av den totala testtiden här.

Passiv rekognosering sker utan direkt kontakt med målet:

• DNS-uppslag, WHOIS, certifikattransparensloggar
• OSINT (open source intelligence): LinkedIn-profiler, GitHub-repon, Shodan-exponering
• Läckta credentials i publika databaser

Aktiv rekognosering innebär direkt interaktion:

• Portskanning (Nmap) och service-fingerprinting
• Webbapplikationskartläggning: endpoints, parametrar, autentiseringsflöden
• Identifiering av teknologistack: webbserver, ramverk, CMS-versioner

Det här steget resulterar i en attackyta — en kartbild över exponerade tjänster, potentiella ingångspunkter och preliminära hypoteser om vilka attackvägar som kan fungera.

Fas 3: Exploatering

Nu börjar den aktiva attackfasen. Testaren försöker utnyttja de sårbarheter som identifierats under rekognoseringen. Det är här det manuella arbetet är avgörande — en skicklig testare kombinerar kända exploits med kreativ problemlösning.

Typiska exploateringsaktiviteter:

• Webbapplikationsattacker: SQL injection, cross-site scripting (XSS), server-side request forgery (SSRF), broken access control (OWASP Top 10)
• Nätverksattacker: exploatering av föråldrade tjänster, man-in-the-middle mot osäkra protokoll, relay-attacker (NTLM)
• Autentiseringsattacker: credential stuffing, password spraying, kringgående av MFA
• Molnspecifika attacker: felkonfigurerade S3-buckets, överprivilegierade IAM-roller, exponerade metadata-endpoints i eu-north-1 (Stockholm) eller Sweden Central
• Social engineering (om det ingår i scope): riktade phishing-kampanjer mot utvalda medarbetare

Varje lyckad exploatering dokumenteras noggrant: vilken sårbarhet som utnyttjades, vilken metod som användes, vilken åtkomst som uppnåddes och vilken data som exponerades.

Fas 4: Eskalering och lateral rörelse

Att ta sig in är steg ett. Att visa vad en angripare kan göra efter initial åtkomst är ofta det som öppnar ögonen på ledningsgruppen.

I den här fasen försöker testaren:

• Eskalera privilegier: från vanlig användare till lokal administratör, från lokal administratör till domänadministratör
• Röra sig lateralt: pivotera mellan system, hoppa mellan nätverkssegment, nå känsligare resurser
• Exfiltrera data: demonstrera att kunddata, affärshemligheter eller systemkonfigurationer faktiskt kan tas ut ur miljön
• Etablera persistens: visa att en angripare kan behålla åtkomst över tid (utan att faktiskt plantera bakdörrar — detta är ett kontrollerat test)

Det är i den här fasen som pentestet visar sitt verkliga värde jämfört med sårbarhetsskanning. En enskild medium-sårbarhet som kedjas ihop med en felkonfiguration och svag nätverkssegmentering kan resultera i fullständig kompromittering. Skannern rapporterar en "medium"-brist. Pentestet visar att den medför total förlust av konfidentialitet.

Fas 5: Rapportering och åtgärdsförslag

Rapporten är det bestående resultatet av pentestet. En undermålig rapport — oavsett hur bra testet var — innebär bortkastade pengar.

En professionell pentestrapport innehåller:

Executive summary (1–2 sidor): Skrivs för ledningsgruppen och styrelsen. Affärsrisk, inte teknisk jargong. Svarar på frågan: "Hur illa är det, och vad kostar det att åtgärda?"

Teknisk detaljrapport för varje fynd:

• Beskrivning av sårbarheten
• Riskklassificering (kritisk/hög/medium/låg) baserad på CVSS och affärskontext
• Steg-för-steg-reproduktion (så att ert utvecklings- eller driftteam kan verifiera)
• Beviskedjor: skärmdumpar, exfiltrerad testdata, loggar
• Konkreta åtgärdsförslag med prioritering

Attacknarrative: En sammanhängande berättelse om hur testaren tog sig från initial åtkomst till slutmålet. Det här är det mest värdefulla avsnittet för dem som ska förbättra försvaret.

Åtgärdsmatris: Tabell med alla fynd, prioritering, ansvarig part och rekommenderad åtgärdsdeadline.

Typer av penetrationstest

Beroende på vad ni vill testa finns det flera varianter, och de överlappar ofta:

Red team-övningar skiljer sig fundamentalt genom att de testar inte bara om ni kan bli kompromitterade utan om ert SOC och era försvarsmekanismer upptäcker attacken. Det är relevant först när organisationen redan har grundläggande säkerhetsåtgärder på plats — annars vet ni redan svaret.

Molnsäkerhet

Regulatoriska krav som driver pentestning

NIS2-direktivet

NIS2-direktivet, som trädde i kraft inom EU under 2024 och nu implementeras i svensk lag, ställer uttryckliga krav på att organisationer inom väsentliga och viktiga sektorer genomför regelbundna säkerhetstester. Penetrationstestning nämns inte ordagrant i direktivtexten men är den de facto-metod som tillsynsmyndigheter förväntar sig. Underlåtelse att testa kan medföra sanktionsavgifter.

ISO 27001:2022

ISO 27001 kräver att organisationer bedömer sårbarheter och verifierar säkerhetsåtgärders effektivitet. Annex A-kontroll A.8.8 (Technical vulnerability management) och A.5.36 (Compliance with policies and standards) gör pentestning till ett naturligt verktyg i certifieringsarbetet.

GDPR och Integritetsskyddsmyndigheten (IMY)

GDPR Artikel 32 kräver "regelbunden testning, bedömning och utvärdering av effektiviteten hos tekniska och organisatoriska åtgärder". IMY har i flera tillsynsbeslut pekat på bristande säkerhetstestning som en försvårande omständighet vid personuppgiftsincidenter.

Managerade molntjänster

Vad vi ser i praktiken — ett Opsio-perspektiv

Från vår 24/7 SOC/NOC i Karlstad och Bangalore ser vi resultaten av penetrationstester på daglig basis. Några mönster som återkommer:

Överprivilegierade tjänstekonton i molnet. Organisationer som migrerat till AWS eller Azure har ofta IAM-roller med administratörsrättigheter som skapades "tillfälligt" under migreringen och aldrig stramades åt. Ett pentest avslöjar att en kompromitterad Lambda-funktion eller Azure Function ger tillgång till hela kontot.

Bristfällig nätverkssegmentering. Flat nätverkstopologi där en kompromitterad arbetsstation i reception ger lateral rörelse rakt in till produktionsdatabaser. Vanligare än man vill tro, särskilt i organisationer som växt snabbt.

Svag MFA-implementation. MFA finns — men bara för VPN. Intern åtkomst till administrativa gränssnitt, molnkonsoler och CI/CD-pipelines saknar ofta andra faktorn. Testaren loggar in med credentials från en phishing-övning och har full åtkomst.

Föråldrade tredjepartskomponenter. Log4j-sårbarheten är historia vid det här laget, men vi ser fortfarande föråldrade Java-bibliotek, ouppdaterade WordPress-plugins och EOL-operativsystem i produktionsmiljöer.

Managerad DevOps

Så väljer ni rätt pentestleverantör

Marknaden för penetrationstester är ojämn. Några saker att titta efter:

• Certifieringar: OSCP, OSCE, CREST, eller GPEN visar att testarna har verifierad kompetens. Certifieringar är inte allt, men de filtrerar bort de oseriösa aktörerna.
• Metodik: Fråga efter deras testramverk. PTES (Penetration Testing Execution Standard) och OWASP Testing Guide är branschstandard.
• Rapportkvalitet: Be om en anonymiserad exempelrapport. Om den bara listar CVE-nummer utan affärskontext, gå vidare.
• Scope-förståelse: En bra leverantör ställer minst lika många frågor till er som ni ställer till dem under scope-fasen.
• Åtgärdsstöd: Testet har inget värde om ni inte kan åtgärda fynden. Fråga om de erbjuder stöd vid remediation och verifierande omtest.

Cloud FinOps

Vad händer efter pentestet?

Rapporten är inte slutstationen — det är startskottet för åtgärdsarbetet. En mogen organisation följer en tydlig cykel:

1. Prioritera: Adressera kritiska och höga fynd omedelbart. Medium-fynd inom 30 dagar. Låga inom 90 dagar eller nästa release-cykel.

2. Åtgärda: Patcha, konfigurera om, arkitekturförändringar — beroende på fyndets natur.

3. Verifiera: Genomför omtest (retest) för att bekräfta att åtgärderna faktiskt stänger sårbarheterna.

4. Integrera: Mata in resultaten i ert riskregister, uppdatera hotmodeller, justera SOC-detektionsregler.

5. Upprepa: Planera nästa test — inte som en engångsövning utan som en del av er kontinuerliga säkerhetsprocess.

Flexeras State of the Cloud-rapport har konsekvent visat att säkerhet och compliance är bland de största utmaningarna i molnmiljöer. Penetrationstestning är det mest konkreta verktyget för att faktiskt validera era skyddsåtgärder — inte bara anta att de fungerar.

Molnmigrering

Vanliga frågor

Hur ofta bör vi genomföra penetrationstest?

Minst årligen, och alltid efter större förändringar som nya applikationer, infrastrukturombyggnad eller förvärv. NIS2 ställer krav på regelbunden testning, och ISO 27001-certifierade organisationer behöver visa kontinuerlig förbättring. Verksamheter med hög exponering — e-handel, fintech, hälso- och sjukvård — bör testa kvartalsvis.

Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?

En sårbarhetsskanning är automatiserad och identifierar kända brister (CVE:er) utan att verifiera om de går att utnyttja. Ett penetrationstest går vidare: en erfaren testare försöker aktivt exploatera sårbarheterna, kedja ihop dem och eskalera åtkomst — precis som en riktig angripare. Skanningen ger bredd, pentestet ger djup.

Kan penetrationstestet störa vår produktion?

En seriös testare arbetar med tydligt definierat scope och eskaleringsrutiner. Tester mot produktionsmiljö utförs typiskt under kontrollerade former med överenskommet tidsfönster. Riktigt destruktiva tester (till exempel DoS) görs mot stagingmiljöer om det inte uttryckligen avtalats annat. Risken för driftstörning är låg vid professionellt genomförande.

Vad kostar ett penetrationstest?

Priset varierar kraftigt beroende på scope: ett avgränsat webbapplikationstest kan ligga på 50 000–150 000 SEK, medan en fullskalig red team-övning mot hela infrastrukturen kan kosta 300 000 SEK eller mer. Avgörande faktorer är antal system, testdjup, typ av test (black/grey/white box) och rapporteringskrav.

Behöver vi penetrationstest om vi redan har SOC-övervakning?

Ja. SOC-övervakning och penetrationstest fyller helt olika funktioner. SOC detekterar och responderar på pågående incidenter i realtid. Penetrationstestet identifierar proaktivt de sårbarheter som en angripare kan använda innan SOC ens behöver reagera. De kompletterar varandra — SOC utan pentest innebär att ni bara reagerar på hot ni inte försökt förebygga.