Metodik: så genomförs en extern pentest steg för steg

En seriös extern pentest följer en strukturerad metodik. Vi utgår från ramverk som OWASP Testing Guide, PTES (Penetration Testing Execution Standard) och NIST SP 800-115, anpassade efter er specifika miljö.

1. Förberedelse och scope-definition

Innan ett enda paket skickas definierar vi scope, regler och ansvar. Det innebär:

• Målidentifiering: Vilka IP-adresser, domäner, subdomäner och tjänster ingår?
• Rules of Engagement: Vilka metoder är tillåtna? Ska social engineering ingå? Finns tidsfönster att respektera?
• Juridisk grund: Skriftligt avtal som ger testaren tillstånd. Utan det är testet olagligt, oavsett intention.
• Kommunikationsplan: Vem kontaktas vid kritiska fynd under testperioden? Vem har incidentberedskap?

Det här steget underskattas ofta, men det är avgörande. Dåligt definierat scope leder till antingen onödig risk eller utebliven testning av kritiska ytor.

2. Rekognosering (Reconnaissance)

Testaren samlar information om er organisation och infrastruktur – exakt som en angripare gör. Det innefattar:

• Passiv rekognosering: DNS-poster (A, MX, TXT, SPF, DMARC), WHOIS-data, Certificate Transparency-loggar, cached content, läckta credentials i publika databaser, information på sociala medier.
• Aktiv rekognosering: Portskanning (Nmap), tjänsteidentifiering, fingerprinting av webbservrar och ramverk, identifiering av WAF-lösningar.

Det som dyker upp i det här steget sätter tonen för hela testet. En subdomän som pekar mot en avvecklad utvecklingsserver med exponerad phpMyAdmin – det är precis den typen av skugg-IT som leder till intrång i praktiken.

3. Sårbarhetsbedömning och exploatering

Med kartlagd attackyta börjar den verkliga testningen. Testaren kombinerar automatiserade verktyg (Burp Suite, Nuclei, Metasploit) med manuella tekniker:

• Webbapplikationstestning: OWASP Top 10 – injektionsattacker, autentiseringsbrister, SSRF, osäker deserialisering, åtkomstkontrollbrister.
• Nätverksbaserad testning: Kända CVE:er i exponerade tjänster, felkonfigurerade brandväggsregler, svag kryptering.
• API-testning: Broken object level authorization (BOLA), mass assignment, bristfällig rate limiting.
• Konfigurationsbrister: Default credentials, exponerade admin-gränssnitt, information disclosure via felmeddelanden och debug-läge.

Skillnaden mot en sårbarhetsskanning är att testaren inte bara rapporterar att en sårbarhet finns – de bevisar att den kan exploateras, kedjar ihop brister och visar exakt vilken påverkan det har på verksamheten.

4. Rapportering och åtgärdsplan

En pentestrapport som ingen förstår eller agerar på är värdelös. En bra rapport innehåller:

• Executive summary – affärsrisken i klartext för ledning och styrelse
• Teknisk detaljrapport – varje sårbarhet med CVSS-poäng, steg-för-steg proof of concept, skärmdumpar
• Åtgärdsrekommendationer – prioriterade efter risk och komplexitet, med konkreta konfigurationsändringar
• Strategiska rekommendationer – arkitekturförbättringar, processförändringar, investerings­prioriteringar

Vi rekommenderar alltid en genomgång (debrief) med både tekniskt team och ledning. Pentestens värde realiseras först när åtgärderna faktiskt implementeras – och sedan verifieras med ett retest.

Regulatoriska krav: NIS2, ISO 27001 och GDPR

Extern pentest är inte bara god praxis – det är i allt högre grad ett regulatoriskt krav.

NIS2-direktivet

NIS2, som trädde i kraft i EU:s medlemsländer, ställer uttryckliga krav på riskhantering och säkerhetstestning för väsentliga och viktiga entiteter. Artikel 21 kräver att organisationer vidtar lämpliga tekniska och organisatoriska åtgärder – och penetrationstestning är en av de mest erkända metoderna för att visa att man faktiskt gör det.

Tillsynsmyndigheten (i Sverige MSB) kan kräva bevis på att ni aktivt testar er säkerhet. Att ha en daterad pentestrapport med åtgärdslogg är ett starkt argument vid en granskning.

ISO/IEC 27001

Annex A i ISO 27001:2022 refererar till teknisk sårbarhetsbedömning (A.8.8) och informationssäkerhetstestning. Extern pentest stödjer direkt certifieringsprocessen och visar att organisationen aktivt identifierar och behandlar risker.

GDPR

Artikel 32 i GDPR kräver regelbunden testning och utvärdering av tekniska skyddsåtgärder. IMY (Integritetsskyddsmyndigheten) har i flera tillsynsärenden pekat på bristfällig teknisk testning som en bidragande faktor. En genomförd extern pentest med dokumenterade åtgärder visar att ni tar dataskyddet på allvar.

Molnsäkerhet

Vanliga fynd: vad vi ser i praktiken

Från Opsios säkerhetsteams erfarenhet av hundratals externa pentester ser vi återkommande mönster. Här är de vanligaste fynden:

Ingen av dessa brister är exotisk. De flesta beror på konfigurationsfel, bristfällig patchhantering eller glömd infrastruktur. Det är just därför regelbunden testning behövs – angreppsprofilen förändras med varje deployment, varje ny tjänst och varje glömd server.

Automatiserad sårbarhetsskanning kontra manuell pentest

En vanlig fråga är om automatiserade verktyg räcker. Svaret är nej – men de är en viktig del av helheten.

Bäst resultat ger en kombination: kontinuerlig automatiserad skanning som baslinje, kompletterad med manuella pentester som djupdykning. Opsios Managerade molntjänster inkluderar automatiserad sårbarhetsskanning som standard – pentest adderas som en dedikerad insats.

Extern pentest i molnmiljö: AWS, Azure och GCP

Att testa externa system i molnmiljö kräver anpassning. Varje hyperscaler har sina egna regler:

• AWS kräver ingen förhandsanmälan för de flesta pentester mot era egna resurser sedan 2025, men förbjuder fortfarande testning av AWS-infrastruktur (DNS, DDoS mot deras tjänster). Tänk på att testa inte bara EC2-instanser utan även S3-buckets, Lambda-endpoints och API Gateway-konfigurationer.
• Azure tillåter pentest utan förhandsanmälan mot era egna tjänster. Sweden Central är den naturliga regionen för svenska organisationer, och specifik uppmärksamhet bör riktas mot Azure AD-exponering och felkonfigurerade Blob Storage-containers.
• GCP har liknande policyer – test mot egna resurser tillåtet, men inte mot Googles underliggande infrastruktur.

Molnspecifika attackvektorer som SSRF mot metadata-tjänster (169.254.169.254), felkonfigurerade IAM-policies och exponerade storage buckets bör alltid ingå i scopet.

Molnmigrering

Så väljer ni rätt pentest-leverantör

Marknaden är full av aktörer som erbjuder pentest. Här är vad ni bör kräva:

1. Certifieringar som betyder något: OSCP, OSCE, CREST eller motsvarande. Undvik leverantörer som bara kör automatiserade verktyg och kallar det pentest.

2. Referenscase inom er bransch: En testare som förstår er regulatoriska kontext (NIS2, GDPR, sektorspecifika krav) levererar bättre resultat.

3. Transparent metodik: Be om en beskrivning av testprocessen. Seriösa aktörer refererar till PTES, OWASP eller NIST.

4. Rapportkvalitet: Be om ett anonymiserat rapportexempel. Om det bara är en automatgenererad Nessus-rapport – gå vidare.

5. Retest inkluderat: Åtgärdsverifiering bör ingå. En pentest utan retest är bara halva jobbet.

6. Försäkring och juridik: Leverantören bör ha ansvarsförsäkring och tydliga avtal kring datahantering.

Managerad DevOps

Bygg en löpande säkerhetscykel

Extern pentest är inte en engångsföreteelse. De organisationer som vi ser lyckas bäst med sin säkerhet behandlar det som en del av en kontinuerlig cykel:

1. Kontinuerlig skanning – automatiserad sårbarhetsskanning varje vecka

2. Kvartalsvis pentest – fokuserat på nya tjänster och förändringar

3. Årlig fullskalig pentest – komplett perimeter-test med nytt scope

4. Incidentdriven testning – efter en incident eller en nästan-incident

5. Åtgärdsverifiering – retest inom 30 dagar efter rapporterad sårbarhet

Denna cykel integreras naturligt med Cloud FinOps – säkerhetsinvesteringar bör vägas mot den kostnad som ett intrång faktiskt medför. Enligt IBM:s Cost of a Data Breach Report har mediankostnaden för dataintrång stadigt ökat de senaste åren, och den nordiska marknaden är inget undantag.

Vanliga frågor

Hur ofta bör man genomföra extern pentest?

Minst årligen, men även vid större infrastrukturförändringar, nya tjänster som exponeras mot internet eller efter en incident. NIS2-direktivet förväntar sig riskbaserad frekvens – för organisationer med hög exponering rekommenderar vi kvartalsvis.

Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?

Sårbarhetsskanning är automatiserad och identifierar kända brister. Pentest går steget längre: en erfaren testare kedjar ihop sårbarheter, testar affärslogik och visar faktisk exploatering. Skanning hittar dörrar – pentest visar vad som händer när någon öppnar dem.

Räcker extern pentest för att uppfylla NIS2?

Nej. NIS2 kräver ett bredare riskhanteringsarbete som inkluderar incidenthantering, leverantörskedja och intern säkerhet. Extern pentest är en viktig pusselbit, men behöver kompletteras med intern testning, kontinuerlig övervakning och dokumenterade processer.

Hur lång tid tar en extern pentest?

Typiskt 1–3 veckor beroende på scopets storlek. En fokuserad test av en enskild webbapplikation kan genomföras på 3–5 dagar, medan en komplett perimeter-test med många IP-adresser och tjänster kräver mer tid. Rapportering tillkommer med ytterligare 3–5 arbetsdagar.

Kan pentest påverka produktionsmiljön?

I teorin ja, men i praktiken hanteras risken genom tydliga regler för engagemanget (Rules of Engagement). Testaren undviker destruktiva attacker mot produktion om inte annat avtalats. Vi rekommenderar alltid att ha incidentberedskap och rollback-planer på plats under testperioden.