Testmetoder: black-box, white-box och grey-box

Vilken metod som passar beror på vad du vill veta. De tre vanligaste ansatserna ger olika perspektiv och kompletterar varandra.

Vår rekommendation

Börja inte med black-box om du aldrig har genomfört penetrationstest tidigare. Det låter dramatiskt att "testa som en extern angripare", men utan kunskap om den interna miljön missar testaren ofta de allvarligaste sårbarheterna. Grey-box ger bäst avkastning per testad timme för de flesta organisationer. Komplettera med riktade black-box-tester mot externexponerade ytor.

Standarder och ramverk som styr testningen

Professionell penetrationstestning bygger på etablerade ramverk. Det säkerställer reproducerbarhet, etik och jämförbarhet mellan tester.

OWASP Testing Guide

OWASPs ramverk är de facto-standarden för webapplikationssäkerhet. OWASP Top 10 uppdateras regelbundet och täcker de vanligaste sårbarhetstyperna – från injektionsattacker till bristfällig åtkomstkontroll. Varje seriös testleverantör bör kunna visa hur deras testmetodik mappar mot OWASP.

NIST SP 800-115

NIST SP 800-115 ("Technical Guide to Information Security Testing and Assessment") ger en bredare ram för säkerhetstestning som inkluderar penetrationstest men även granskning och sårbarhetsskanning. Ramverket är särskilt relevant för organisationer som redan arbetar med NIST CSF.

PTES och OSSTMM

Penetration Testing Execution Standard (PTES) definierar sju faser från pre-engagement till rapportering. OSSTMM (Open Source Security Testing Methodology Manual) fokuserar på mätbarhet och operationell säkerhet. Båda är användbara som komplement.

Regulatorisk kontext: NIS2 och CRA

NIS2-direktivet, som trädde i kraft inom EU, kräver att väsentliga och viktiga entiteter genomför riskbaserade säkerhetsåtgärder – inklusive regelbunden testning och utvärdering av säkerhetsåtgärdernas effektivitet. Penetrationstest är det mest direkta sättet att uppfylla det kravet.

Cyber Resilience Act (CRA) riktar sig mot tillverkare av produkter med digitala element och ställer krav på säkerhetstestning genom hela produktens livscykel. Om er organisation utvecklar uppkopplade produkter bör penetrationstest vara en integrerad del av utvecklingsprocessen, inte en engångsinsats före lansering.

Molnsäkerhet

Hur ett penetrationstest genomförs – steg för steg

1. Planering och avgränsning (scope)

Det viktigaste steget och det som oftast görs för hastigt. Här definieras:

• Testomfattning: vilka system, nätverk, applikationer och miljöer som ingår
• Testtyp: black-box, white-box eller grey-box
• Regler: vad som är tillåtet (social engineering? fysiskt intrång? DoS-simulering?)
• Tidsfönster och eskaleringsrutiner: vem kontaktas om testaren hittar en kritisk brist i realtid?
• Juridiska ramar: skriftligt avtal som ger testaren explicit tillstånd

2. Informationssamling (reconnaissance)

Testaren kartlägger målet. Vid black-box innebär det passiv och aktiv spaning: DNS-uppslag, port-skanning, analys av publikt tillgänglig information (OSINT), identifiering av teknologier och ramverk. Vid white-box tillhandahålls dokumentation direkt.

3. Sårbarhetsbedömning

Identifierade tjänster och exponerade ytor analyseras mot kända sårbarheter. Här kombineras automatiserade verktyg (Burp Suite, Nmap, Metasploit) med manuell analys. Automatik hittar det uppenbara – den manuella analysen hittar det intressanta.

4. Aktiv exploatering

Testaren försöker utnyttja identifierade sårbarheter. Det kan handla om SQL-injektion, autentiseringsbypass, privilege escalation, lateral förflyttning i nätverket eller utnyttjande av felkonfigurerade molntjänster. Varje framgångsrik exploatering dokumenteras med beviskedja.

5. Post-exploatering och konsekvensanalys

Vad kan angriparen göra efter initialt intrång? Kommer testaren åt känslig data? Kan åtkomsten eskaleras till domänadmin? Kan angriparen röra sig lateralt till andra segment? Det här steget visar den verkliga affärsrisken – inte bara att en sårbarhet existerar, utan vad den faktiskt kostar om den utnyttjas.

6. Rapportering och åtgärdsplan

Rapporten bör innehålla:

• Sammanfattning för ledningen: affärsrisk, inte bara tekniska detaljer
• Detaljerade fynd: varje sårbarhet med riskklassificering (CVSS), beviskedja och reproduktionssteg
• Prioriterade rekommendationer: vad som bör åtgärdas först baserat på risk och insats
• Omtestning: datum för verifiering av att åtgärder faktiskt fungerar

En rapport som ingen agerar på är bortkastad investering. Vi ser tyvärr att detta händer oftare än man tror.

Molnmiljöer kräver anpassad testmetodik

Penetrationstestning i molnet skiljer sig från traditionell infrastrukturtestning på flera avgörande sätt.

Shared responsibility-modellen innebär att du inte testar molnleverantörens infrastruktur – du testar din konfiguration av den. AWS, Azure och GCP har alla policies för penetrationstestning. AWS tillåter numera test mot de flesta tjänster utan förhandsanmälan, men med tydliga undantag (t.ex. DNS-zonöverföringar och DoS). Azure och GCP har liknande regler.

Det vi ser mest av i produktionsmiljöer hos svenska organisationer:

• Överdimensionerade IAM-roller – principen om minsta behörighet ignoreras konsekvent
• Exponerade lagringsutrymmen – S3-buckets och Azure Blob Storage med felaktig åtkomstkontroll
• Hemliga nycklar i kod – API-nycklar och lösenord hårdkodade i repositories
• Bristfällig nätverkssegmentering – platta VPC:er utan isolation mellan arbetsbelastningar

Penetrationstest av molnmiljöer bör specifikt granska IAM-konfigurationer, nätverksflöden, kryptering i transit och vila, samt loggning och övervakning.

Managerade molntjänster

Välja rätt leverantör för penetrationstest

Marknaden för penetrationstestning är ojämn. Prisskillnaderna är stora och korrelerar inte alltid med kvalitet. Här är vad du bör utvärdera:

Teknisk kompetens

Certifieringar som OSCP (Offensive Security Certified Professional), CREST eller GPEN visar en basnivå. Men certifikat räcker inte – fråga efter anonymiserade exempelrapporter och referenscase.

Branschförståelse

En testare som förstår din regulatoriska kontext (NIS2, GDPR, branschspecifika krav) levererar mer relevanta rekommendationer. Det är skillnad på att hitta en sårbarhet och att förklara varför just den utgör en affärsrisk i din verksamhet.

Rapportkvalitet

Be om exempelrapporter innan du signerar. En bra rapport har tydlig riskklassificering, reproduktionssteg och prioriterade åtgärdsförslag. En dålig rapport listar CVE-nummer utan kontext.

Omtestning ingår

Leverantören bör erbjuda omtestning (verifieringstest) efter att ni åtgärdat fynd – det bör inkluderas i priset, inte faktureras separat.

Oberoende

Anlita inte samma leverantör som byggt systemet för att testa det. Oberoende testning är en grundprincip.

Kontinuerlig säkerhetstestning slår punktinsatser

Ett årligt penetrationstest är bättre än inget, men det räcker sällan. Mellan testerna ändras infrastrukturen: nya tjänster driftsätts, konfigurationer justeras, personal byts ut. En effektiv strategi kombinerar:

• Kontinuerlig sårbarhetsskanning (veckovis eller dagligen i CI/CD-pipelines)
• Årliga eller halvårliga penetrationstest (manuella, djupgående)
• Red team-övningar (mer omfattande, inkluderar social engineering och fysisk säkerhet)
• Bug bounty-program (för mogna organisationer med beredskap att hantera inflödet)

Från vår SOC-verksamhet ser vi att organisationer med kontinuerlig testning har signifikant kortare tid till upptäckt (time-to-detect) och åtgärd (time-to-remediate) jämfört med dem som testar en gång om året.

Managerad DevOps

IoT och OT: den växande attackytan

Uppkopplade enheter och operativ teknologi (OT) utgör en allt större del av attackytan. Penetrationstestning av IoT-ekosystem kräver specialiserad kompetens som spänner över firmware-analys, trådlösa protokoll (Zigbee, BLE, LoRaWAN), API-säkerhet och fysisk manipulation.

Cyber Resilience Act ställer specifika krav på tillverkare av uppkopplade produkter. Om din organisation utvecklar eller driftsätter IoT-lösningar bör testmetodiken täcka hela kedjan: enhet → kommunikationsprotokoll → molnbackend → användarapplikation.

Opsios perspektiv: vad vi ser i drift

Med 24/7 SOC/NOC i Karlstad och Bangalore övervakar vi kontinuerligt kundmiljöer. Det ger oss en tydlig bild av vilka sårbarheter som faktiskt utnyttjas i praktiken – inte bara i teori. Tre mönster återkommer:

1. Konfigurationsfel dominerar – det är sällan sofistikerade zero-days som fäller organisationer. Det är felkonfigurerade brandväggar, glömda testmiljöer med produktionsdata och servicekontion med standardlösenord.

2. Lateralrörelse underskattas – det initiala intrånget är sällan det farliga. Det är vad angriparen gör efter att den tagit sig in. Penetrationstest som slutar vid "vi fick shell" missar halva bilden.

3. Åtgärdstakten är för låg – rapporter läses men åtgärder prioriteras bort. Vi rekommenderar att koppla penetrationstestfynd direkt till ärendehantering med tidsatta SLA:er.

Molnmigrering

Vanliga frågor

Hur ofta bör vi genomföra penetrationstest?

Som minimum årligen, och alltid efter större förändringar i infrastruktur, applikationer eller integrationer. Organisationer som omfattas av NIS2 eller hanterar känslig data bör testa oftare – kvartalsvis eller vid varje releaseperiod. Automatiserade sårbarhetsskanningar kompletterar men ersätter inte manuella penetrationstest.

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

En sårbarhetsskanning är automatiserad och identifierar kända brister mot en databas. Ett penetrationstest går längre: en mänsklig testare försöker aktivt utnyttja sårbarheterna, kedja ihop flera brister och visa vad en verklig angripare faktiskt kan åstadkomma. Sårbarhetsskanning hittar enskilda luckor – penetrationstestet visar konsekvensen.

Kan penetrationstest störa vår produktion?

Ja, det är en reell risk om testet genomförs slarvigt. Därför definieras alltid testomfattning, tidsfönster och eskaleringsrutiner innan start. Professionella testare undviker destruktiva tester mot produktionsmiljöer om det inte är explicit överenskommet. En bra leverantör har alltid en rollback-plan.

Vad kostar ett penetrationstest?

Priset varierar kraftigt beroende på testomfattning, miljöns komplexitet och testtyp. En enklare webbapplikationstest kan ligga på 50 000–100 000 SEK, medan ett fullskaligt red team-uppdrag kostar avsevärt mer. Det billigaste testet är alltid dyrare än det ser ut om leverantören saknar kompetens – en tunn rapport utan verkliga fynd är bortkastad budget.

Behöver vi penetrationstest om vi redan kör i molnet?

Absolut. Molnleverantörens ansvar sträcker sig till infrastrukturen (shared responsibility model), men konfigurationer, åtkomstkontroller, applikationskod och integrationer är ditt ansvar. Felkonfigurerade S3-buckets, överdimensionerade IAM-roller och exponerade API-nycklar är precis det som penetrationstest avslöjar.