Grey Box Pentest: Så testar ni säkerheten effektivt
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Grey Box Pentest: Så testar ni säkerheten effektivt
Grey box pentest ger testaren begränsad kunskap om era system — nätverkstopologi, användarroller, viss dokumentation — och kombinerar det med realistiska attackscenarier. Resultatet är en testmetod som identifierar kritiska sårbarheter snabbare än black box, utan att tappa den verklighetskoppling som renodlad kodgranskning ofta saknar. För organisationer som omfattas av NIS2-direktivet är metoden ett kostnadseffektivt sätt att validera säkerheten löpande.
Viktiga slutsatser
- Grey box pentest ger bäst balans mellan realism och effektivitet — testaren har begränsad systemkunskap, precis som en angripare med initial tillgång
- Metoden identifierar kritiska sårbarheter snabbare och billigare än black box, utan att tappa verklighetsperspektivet som white box ofta missar
- NIS2 och Cyber Resilience Act gör penetrationstestning obligatorisk för de flesta svenska organisationer i kritiska sektorer
- Resultaten blir mest värdefulla i en kontinuerlig cykel — inte som en engångsinsats en gång om året
Vad grey box pentest faktiskt innebär
Begreppet är enkelt: pentestaren får partiell information om målmiljön innan testet börjar. Det kan vara nätverksdiagram, grundläggande API-dokumentation, användarkontonmed begränsade behörigheter eller arkitekturöversikter. Tanken är att simulera en angripare som redan har ett fotfäste — exempelvis genom en komprometterad medarbetare, en stöld av grundläggande autentiseringsuppgifter eller insiderinformation från en underleverantör.
Det här scenariot är inte teoretiskt. I Opsios SOC ser vi regelbundet incidenter där angriparen redan har viss intern kunskap när attacken eskalerar. Lateral movement — att röra sig sidledes i nätverket efter initial åtkomst — förutsätter precis den typ av begränsad insyn som grey box simulerar.
Metodiken följer etablerade ramverk. MITRE ATT&CK Framework och Cyber Kill Chain-modellen ger strukturen, men det är den partiella kunskapen som gör grey box unikt: testaren vet tillräckligt för att rikta insatserna mot de mest kritiska ytorna, men inte så mycket att testet blir en akademisk övning.
Vill ni ha expertstöd med grey box pentest: så testar ni säkerheten effektivt?
Våra molnarkitekter hjälper er med grey box pentest: så testar ni säkerheten effektivt — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Jämförelse: Black box, grey box och white box
Valet av testmetod beror på vad ni vill uppnå. Här är en ärlig jämförelse:
| Egenskap | Black box | Grey box | White box |
|---|---|---|---|
| Testarens förkunskap | Ingen | Begränsad (nätverkstopologi, roller, viss dokumentation) | Full (källkod, arkitektur, all dokumentation) |
| Realism | Hög — simulerar extern angripare | Hög — simulerar angripare med initial tillgång | Lägre — avviker från verklig attackvektor |
| Tidsåtgång | Hög — mycket tid på rekognosering | Medel — fokuserad testning | Medel till hög — djupgående kodgranskning |
| Kostnad per sårbarhet funnen | Hög | Låg till medel | Medel |
| Täckningsgrad | Begränsad av tid | Bred — riktar sig mot kritiska ytor | Mycket bred — men missar produktionsspecifika brister |
| Bäst för | Extern attackytevalidering | Löpande säkerhetsvalidering | Kodgranskning, compliance-revision |
När black box inte räcker
Black box-testning har en charm i sin renhet: testaren vet ingenting och måste arbeta sig fram precis som en verklig angripare. Problemet är att det tar tid — och tid kostar pengar. I praktiken innebär det att testaren lägger dagar på rekognosering som kunde ha ägnats åt att hitta faktiska sårbarheter. Vi har sett organisationer betala för veckolånga black box-tester där de mest kritiska fynden ändå kom från de sista dagarna, när testaren äntligen hade tillräcklig förståelse för miljön.
När white box blir för teoretisk
White box ger full insyn — källkod, arkitekturdokumentation, databasscheman. Det möjliggör grundlig statisk analys, men missar något viktigt: hur systemen faktiskt beter sig i produktion. Konfigurationsfel, felaktigt uppsatta brandväggsregler och driftspecifika sårbarheter dyker ofta bara upp när man testar mot en levande miljö med begränsad kunskap.
Grey box: sweet spot
Grey box hamnar där det gör mest nytta. Testaren har tillräckligt med information för att fokusera, men tillräckligt lite för att behöva tänka som en angripare. I vår erfarenhet ger det 20–40 % fler kritiska fynd per testdag jämfört med black box — helt enkelt för att tiden används bättre.
Metodik: Så genomförs en grey box pentest
Fas 1: Scope och kunskapsdefinition
Innan ett enda paket skickas behöver vi definiera exakt vad som testas och vilken information testaren får. Det här är det steg som oftast underskattas. Ett dåligt definierat scope leder till antingen för breda tester som inte går tillräckligt djupt, eller för smala tester som missar kritiska angreppsvektorer.
Typisk information som delas:
- Nätverkstopologi (övergripande, inte nödvändigtvis detaljerad)
- Användarkonton med standardbehörigheter
- API-dokumentation för de system som ska testas
- Grundläggande arkitekturbeskrivning
- Eventuella kända begränsningar eller system som ska undantas
Fas 2: Rekognosering och kartläggning
Trots den partiella förkunskapen genomför testaren egen rekognosering. Syftet är att validera den information som delats, identifiera avvikelser och hitta ytor som inte täcks av dokumentationen. Verktyg som Nmap, Burp Suite och specialiserade OSINT-verktyg kompletterar den givna informationen.
Det är ofta i gapet mellan dokumentation och verklighet som de mest intressanta sårbarheterna gömmer sig. En API som enligt dokumentationen kräver autentisering men i praktiken accepterar anonyma anrop. En nätverkssegmentering som ser korrekt ut på diagrammet men har en öppen port som ingen visste om.
Fas 3: Sårbarhetsbedömning och exploitation
Med kartläggningen klar flyttas fokus till identifiering och verifiering av sårbarheter. Testaren utnyttjar OWASP Testing Guide för webbapplikationer, PTES (Penetration Testing Execution Standard) för infrastruktur och MITRE ATT&CK för att strukturera attackkedjan.
Varje identifierad sårbarhet verifieras genom kontrollerad exploitation — inte bara skanningsresultat. Skillnaden är avgörande: en sårbarhetsskanner kan rapportera hundratals potentiella problem, men en pentest visar vilka som faktiskt går att utnyttja och vad konsekvenserna blir.
Fas 4: Lateral movement och privilegieeskalering
Den mest värdefulla fasen i en grey box pentest. Med initial tillgång (ofta via de delade användarkontona) försöker testaren eskalera behörigheter och röra sig genom nätverket. Det här speglar exakt vad en verklig angripare gör efter att ha fått ett fotfäste.
I Opsios NOC-arbete ser vi gång på gång att det är just lateral movement som avgör om en incident blir en mindre händelse eller en fullskalig katastrof. Grey box pentest avslöjar hur långt en angripare kan komma med begränsad initial tillgång — och det är information som är direkt handlingsbar.
Fas 5: Rapportering och åtgärdsplan
Rapporten är det testaren faktiskt levererar. En bra pentestrapport innehåller:
- Executive summary för ledningsgruppen (affärspåverkan, inte teknisk jargong)
- Teknisk detalj per sårbarhet med CVSS-poäng, bevis och reproducerbarhet
- Prioriterad åtgärdslista sorterad efter risk och implementeringsbarhet
- Strategiska rekommendationer för att adressera grundorsaker, inte bara symptom
NIS2 och regulatoriska krav: Varför pentest inte längre är valfritt
NIS2-direktivet, som trädde i kraft i EU-länderna under 2024–2025, ställer explicita krav på att organisationer i väsentliga och viktiga sektorer genomför proportionella tekniska säkerhetsåtgärder. Penetrationstestning nämns inte ordagrant som enda krav, men i praktiken är det svårt att uppfylla direktivets krav på riskhantering och säkerhetsvalidering utan regelbunden testning.
Cyber Resilience Act (CRA) skärper ytterligare genom att kräva säkerhetsvalidering av produkter med digitala element genom hela livscykeln. För svenska organisationer som utvecklar eller driftar digitala tjänster innebär det att pentest bör vara en integrerad del av utvecklings- och driftsprocessen.
Integritetsskyddsmyndigheten (IMY) har dessutom i sina tillsynsbeslut konsekvent betonat vikten av tekniska säkerhetsåtgärder — och penetrationstest är ett av de mest konkreta sätten att demonstrera att ni faktiskt testar era skydd, inte bara dokumenterar dem.
Vanliga misstag — och hur ni undviker dem
Engångstest utan uppföljning
Det vanligaste misstaget vi ser: organisationen beställer en pentest, får rapporten, åtgärdar de mest kritiska fynden och lägger sedan rapporten i en låda. Hotbilden förändras kontinuerligt. Ny kod deployas. Konfigurationer ändras. En pentest har ett bäst-före-datum.
För brett scope med för lite tid
En pentest som försöker täcka hela infrastrukturen på fem dagar kommer att vara ytlig överallt. Bättre att testa tre kritiska system ordentligt än tio system på ytan.
Fel kunskapsnivå
Om testaren får för mycket information blir det en white box i förklädd. För lite, och ni betalar för rekognosering istället för fynd. Diskutera kunskapsnivån noggrant med er testleverantör — det är en strategisk beslut, inte en administrativ detalj.
Ingen koppling till incidenthantering
Pentestresultaten bör matas direkt in i er incidenthanteringsplan. Om testet visar att en angripare kan nå er databas via en specifik attackkedja, bör er SOC ha detektionsregler för just den kedjan.
Integration med molnmiljöer
Grey box pentest i molnmiljöer kräver särskilda överväganden. AWS, Azure och Google Cloud har alla acceptable use policies för penetrationstestning som ni måste förstå innan testet börjar.
I AWS (eu-north-1, Stockholm) är pentest tillåtet mot egna resurser utan föranmälan sedan 2022, men med tydliga begränsningar kring DDoS-simulering och DNS zone walking. Azure Sweden Central har liknande regler. Testaren behöver tillgång till IAM-konfigurationer och nätverksgrupper som del av grey box-informationen.
Molnspecifika angreppsvektorer som testaren bör undersöka:
- IAM-felkonfigurationer — alltför breda roller, oanvända behörigheter
- Publikt exponerade storage buckets/blobs
- Nätverkssegmentering mellan VPC:er/VNets
- Secrets management — hårdkodade nycklar i kod eller konfiguration
- Container breakout i Kubernetes-miljöer
Så väljer ni rätt pentestleverantör
Marknaden för penetrationstestning i Sverige har vuxit snabbt, och kvalitetsskillnaderna är stora. Några konkreta kriterier:
- Certifieringar — OSCP, OSCE, CREST eller motsvarande. Inte bara "certifierad etisk hackare" (CEH), som är en grundläggande kunskapscertifiering snarare än en kompetensbeviser.
- Metodik — Fråga efter deras testramverk. PTES, OWASP Testing Guide och NIST SP 800-115 är branschstandard.
- Rapportkvalitet — Be om en anonymiserad exempelrapport. Kvaliteten på rapporten avgör om fynden faktiskt leder till förbättring.
- Kommunikation under test — Kritiska fynd ska rapporteras omedelbart, inte efter testperiodens slut.
- Scope-diskussion — En bra leverantör hjälper er definiera rätt scope, inte bara accepterar vad ni ber om.
Från test till kontinuerlig säkerhet
En enskild pentest, oavsett hur väl genomförd, är en ögonblicksbild. Verklig säkerhet kräver en kontinuerlig cykel:
1. Grey box pentest — identifiera sårbarheter
2. Åtgärda — prioriterat enligt risknivå
3. Verifiera — omtest av åtgärdade brister
4. Övervaka — löpande detektering via SOC/NOC
5. Upprepa — ny testcykel, gärna med utökat scope
I Opsios dygnet-runt SOC/NOC kopplar vi pentestresultat direkt till detektionsregler och övervakningspolicyer. Det innebär att fynden inte bara åtgärdas utan även bevakas — om en liknande sårbarhet introduceras igen, fångar vi det i realtid.
Vanliga frågor
Vad skiljer grey box pentest från black box och white box?
Vid black box har testaren ingen förkunskap alls — realistiskt men tidskrävande. White box ger full insyn i kod och arkitektur — grundligt men missar produktionsspecifika brister. Grey box ger testaren begränsad information (nätverkstopologi, användarroller, viss dokumentation) och träffar sweet spot mellan realism och djup.
Hur ofta bör vi genomföra grey box pentest?
Minst årligen, men helst kvartalsvis för kritisk infrastruktur. Vid större förändringar — ny applikation, migrering, arkitekturändringar — bör ni alltid köra ett nytt test. NIS2 kräver att säkerhetsåtgärder är proportionella och aktuella, vilket i praktiken innebär regelbunden testning.
Räcker grey box pentest för att uppfylla NIS2-kraven?
Penetrationstestning är en del av NIS2-efterlevnad, men inte tillräckligt i sig. Direktivet kräver ett helhetsperspektiv: riskhantering, incidenthantering, leverantörsgranskning och kontinuitetsplanering. Grey box pentest är ett starkt verktyg för att identifiera tekniska brister inom det ramverket.
Vilken information ger vi testaren vid grey box pentest?
Typiskt delar ni nätverksdiagram, användarroller med begränsade behörigheter, API-dokumentation och grundläggande arkitekturbeskrivning. Exakt vad som delas beror på testmål — en bra pentestleverantör hjälper er definiera rätt kunskapsnivå utifrån er hotbild.
Vad kostar en grey box pentest?
Kostnaden varierar beroende på scope, men grey box är generellt 20–40 % billigare än black box för samma täckningsgrad, eftersom testaren slipper lägga dagar på grundläggande rekognosering. Räkna med att en gedigen test av en medelkomplex miljö tar 5–15 arbetsdagar.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
