Typer av penetrationstestning

Extern nätverkstestning

Testar er exponerade yta från internet – precis som en angripare utan insiderinformation ser er organisation. Fokus ligger på publikt exponerade tjänster, DNS-konfiguration, e-postsäkerhet (SPF/DKIM/DMARC), VPN-gateways och webbapplikationer. För företag med infrastruktur i AWS eu-north-1 (Stockholm) eller Azure Sweden Central innebär det att testa alla publika endpoints, inklusive molnbaserade API:er och storage buckets.

Intern nätverkstestning

Simulerar en angripare som redan tagit sig förbi perimeterskyddet – eller en illvillig insider. Här testar vi lateral rörelse genom nätverket, Active Directory-konfiguration, segmentering och privilegieeskalering. Det är den här typen av test som avslöjar om ert "noll-tillit"-koncept faktiskt håller, eller om en angripare med ett enda komprometterat användarkonto kan nå kronjuvelerna.

Webbapplikationstestning

Följer OWASP Top 10 som ramverk men går långt bortom checklistan. Erfarna testare granskar autentiseringsflöden, sessionshantering, API-säkerhet och affärslogikbrister som inget automatiserat verktyg kan fånga. En vanlig brist vi ser vid Opsios granskningar: applikationer som korrekt validerar behörighet i gränssnittet men saknar kontroller i backend-API:erna.

Molnkonfigurationstestning

Med arbetsbelastningar i AWS, Azure och GCP räcker det inte att testa applikationerna – ni måste testa molnkonfigurationen. IAM-policies, nätverksgrupper, krypteringsinställningar, loggning och incidentdetektering. AWS Well-Architected Framework och Azure Architecture Center definierar best practice, men verkligheten i produktion avviker nästan alltid. Molnsäkerhet

Red team-övningar

Den mest avancerade formen. Ett red team har ett specifikt mål – exempelvis att komma åt en viss databas eller få domain admin-åtkomst – och använder alla tillgängliga metoder: tekniska exploits, social engineering, fysisk tillgång. Till skillnad från en standardpentest pågår en red team-övning ofta i veckor och testar hela säkerhetskedjan, inklusive er SOC/NOC:s förmåga att detektera och reagera.

Black box, grey box och white box – vilken passar er?

Vår rekommendation: börja med grey box. Ni får ett realistiskt angreppsperspektiv utan att slösa testtimmar på rekognosering som en riktig angripare ändå skulle klara med tillräcklig uthållighet. Spara black box-testning för red team-övningar där tidshorisonten är längre.

Så går en penetrationstestning till – fas för fas

1. Omfattning och regelengagemang

Allt börjar med ett tydligt avtal: vilka system testas, vilka metoder är tillåtna, under vilka tider och vem kontaktas vid kritiska fynd? Det här steget skyddar både er och testarna. Utan tydlig avgränsning riskerar ni antingen att missa viktiga system eller att testningen stör affärskritisk drift.

2. Rekognosering och informationsinsamling

Testarna kartlägger er exponerade yta: domäner, IP-adresser, anställdas e-postadresser, teknikstack, publikt tillgänglig information. OSINT-verktyg (Open Source Intelligence) ger ofta förvånansvärt detaljerad insyn. Vi ser regelbundet att organisationer omedvetet exponerar intern information via GitHub-repositorier, felkonfigurerade S3-buckets eller metadata i publika dokument.

3. Sårbarhetsdetektion och analys

Med kartläggningen som grund identifierar testarna potentiella ingångspunkter. Här kombineras automatiserade skanningsverktyg med manuell analys. Fokus ligger på att hitta sårbarheter som faktiskt går att utnyttja i er specifika miljö – inte generiska varningslistor.

4. Exploatering

Kärnfasen. Testarna försöker utnyttja identifierade sårbarheter, etablera fotfäste och eskalera åtkomst. Varje steg dokumenteras noggrant: vilken sårbarhet utnyttjades, vilken åtkomstnivå uppnåddes, vilka data exponerades. Det är den här fasen som genererar det affärskritiska värdet – beviset på vad en angripare faktiskt kan åstadkomma.

5. Rapportering och åtgärdsrekommendationer

En professionell pentestrapport innehåller:

• Sammanfattning för ledningen – affärsrisk i klartext, utan jargong
• Tekniska fynd – varje sårbarhet med svårighetsgrad (CVSS), bevis och reproducerbarhet
• Attackberättelse – hur fynden kedjades samman till en realistisk attackväg
• Åtgärdsrekommendationer – prioriterade efter affärspåverkan och implementeringskomplexitet

6. Uppföljning och omtest

En rapport utan åtgärder är meningslös. Planera alltid in omtestning efter att de mest kritiska bristerna åtgärdats – typiskt 4–8 veckor efter leverans. Det bekräftar att åtgärderna fungerar och att inga nya brister introducerats.

NIS2 och regelefterlevnad: varför pentestning inte längre är valfritt

NIS2-direktivet, som trädde i kraft i EU-medlemsstaterna 2024–2025, ställer explicita krav på riskhantering och systematisk säkerhetstestning för organisationer inom 18 definierade sektorer. Artikel 21 kräver att väsentliga och viktiga entiteter vidtar "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" – och penetrationstestning är den mest direkta metoden att validera att dessa åtgärder fungerar.

Utöver NIS2 påverkar även:

• Cyber Resilience Act (CRA) – krav på säkerhetstestning av produkter med digitala element
• GDPR artikel 32 – "tekniska och organisatoriska åtgärder" för att säkerställa lämplig säkerhetsnivå
• SOC 2 och ISO/IEC 27001 – båda ramverken förutsätter regelbunden säkerhetstestning som del av certifieringen
• DORA – för finanssektorn specifikt kravställer digital operationell resiliens inklusive "threat-led penetration testing"

Integritetsskyddsmyndigheten (IMY) har i tillsynsärenden påpekat att organisationer som inte systematiskt testar sin säkerhet har svårt att visa att de uppfyller GDPR:s krav. En dokumenterad pentest är konkret bevis på att ni tar säkerhet på allvar. Managerade molntjänster

Vanliga fynd – vad Opsios SOC ser i praktiken

Efter tusentals analyserade incidenter och säkerhetsgranskningar ser vi tydliga mönster:

Felkonfigurerade IAM-policies i molnet. Överdimensionerade behörigheter är normen, inte undantaget. En utvecklare som "tillfälligt" fick admin-rättigheter för två år sedan har dem fortfarande.

Bristande nätverkssegmentering. Lateral rörelse från DMZ till interna system lyckas i en oroväckande hög andel av testerna. Platta nätverksarkitekturer utan mikrosegmentering är en angripares bästa vän.

Svaga autentiseringsflöden. Avsaknad av MFA på kritiska system, lösenordspolicies som tillåter "Sommar2025!" och sessions-tokens som aldrig expirerar.

Exponerade API:er. Microservice-arkitekturer skapar en enorm attackyta om inte varje tjänst-till-tjänst-kommunikation autentiseras och auktoriseras korrekt.

Bristande loggning och detektionsförmåga. Många organisationer har tekniska skydd men saknar förmågan att upptäcka när de kringgås. En SOC utan korrekta loggkällor är som en brandstation utan brandlarm. Managerad DevOps

Så integrerar ni pentestning i säkerhetsarbetet

Penetrationstestning ska inte vara en isolerad årlig händelse. Integrera det i er löpande säkerhetscykel:

1. Kontinuerlig sårbarhetsskanning – veckovis automatiserad skanning av all infrastruktur

2. Kvartalsvisa riktade tester – fokuserade pentester av nya applikationer eller förändrade miljöer

3. Årlig fullskalig pentest – bred testning av hela den exponerade ytan

4. Vartannat år: red team-övning – helhetsbedömning inklusive social engineering och fysisk säkerhet

Koppla resultaten till er riskregister och rapportera till ledningen i affärstermer. En CVSS-score på 9.8 betyder ingenting för en CFO, men "en angripare kan komma åt all kunddata inom två timmar" skapar handling. Cloud FinOps

Att välja rätt partner för penetrationstestning

Marknaden för penetrationstestning varierar enormt i kvalitet. Några vägledande principer:

• Certifieringar – OSCP, OSCE, CREST och liknande visar att testarna har verifierbar kompetens. Be om CV:n, inte bara företagscertifieringar.
• Branschförståelse – en testare som förstår er bransch identifierar relevantare attackscenarier. Hälso- och sjukvård, finans och kritisk infrastruktur har helt olika hotlandskap.
• Rapportkvalitet – be om exempelrapporter (anonymiserade). En bra rapport är åtgärdsorienterad, inte en automatgenererad sårbarhetslistning.
• Uppföljning – välj en partner som erbjuder omtestning och rådgivning vid åtgärdsarbetet, inte bara leverans av en PDF.
• Oberoende – testaren ska inte granska sin egen implementation. Separation mellan den som bygger och den som testar är grundläggande. Molnmigrering

Vanliga frågor

Hur ofta bör ett företag genomföra penetrationstestning?

Minst årligen och vid varje större förändring i infrastrukturen – ny applikation, molnmigrering eller arkitekturskifte. Organisationer som omfattas av NIS2 eller hanterar känsliga data bör överväga halvårsvis testning. Kontinuerlig sårbarhetsskanning kompletterar men ersätter inte manuella pentester.

Vad kostar penetrationstestning för ett medelstort svenskt företag?

Priset varierar kraftigt beroende på omfattning. En fokuserad webbapplikationstest kan ligga på 80 000–150 000 SEK, medan en bred infrastrukturtest med red team-inslag landar på 200 000–500 000 SEK. Jämför det med genomsnittskostnaden för ett dataintrång som enligt IBM:s Cost of a Data Breach-rapport konsekvent ligger på miljontals kronor.

Vad är skillnaden mellan black box, grey box och white box-testning?

Black box simulerar en extern angripare utan förkunskap. Grey box ger testaren viss information, exempelvis användarkonton eller nätverksdiagram. White box innebär full insyn inklusive källkod. Grey box ger oftast bäst avkastning: realistiskt angreppsscenario kombinerat med effektiv tidsanvändning.

Behöver vi penetrationstestning om vi redan kör sårbarhetsskanning?

Ja. Sårbarhetsskanning identifierar kända brister automatiskt men missar logiska fel, kedjade attackvägar och affärslogikbrister. En skicklig pentestare tänker som en verklig angripare och kombinerar fynd på sätt som inget automatiserat verktyg klarar. Båda metoderna kompletterar varandra.

Omfattas vi av NIS2-kravet på penetrationstestning?

NIS2-direktivet gäller "väsentliga" och "viktiga" entiteter inom 18 sektorer – energi, transport, hälso- och sjukvård, digital infrastruktur, offentlig förvaltning med flera. Om er organisation levererar samhällsviktiga tjänster eller har fler än 50 anställda och omsätter över 10 miljoner euro bör ni utgå från att ni omfattas och planera för systematisk säkerhetstestning.

For hands-on delivery in India, see drift for enterprise.