Varför pentest är affärskritiskt — inte bara tekniskt

Regulatorisk verklighet 2026

NIS2-direktivet, som nu är implementerat i svensk lag, ställer explicita krav på att väsentliga och viktiga entiteter ska bedriva riskhantering som inkluderar testning av säkerhetsåtgärder. GDPR artikel 32 kräver att personuppgiftsansvariga har "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten" i tekniska och organisatoriska åtgärder. Integritetsskyddsmyndigheten (IMY) har i tillsynsbeslut refererat till avsaknad av penetrationstester som en faktor vid bedömning av bristande säkerhet.

Dokumenterade pentestrapporter är det mest konkreta bevis du kan lägga på bordet — både mot tillsynsmyndigheter och i kunddialoger. PCI DSS kräver det explicit (krav 11.3). ISO/IEC 27001 Annex A hänvisar till teknisk sårbarhetsbedömning. SOC 2:s trust service criteria täcker det under CC7.1.

Ekonomisk kalkyl

Att identifiera och åtgärda en sårbarhet under ett pentest kostar en bråkdel jämfört med att hantera samma sårbarhet efter en intrångsincident. Förutom de direkta kostnaderna — forensisk analys, återställning, eventuella böter — tillkommer produktionsbortfall och den svårmätta men reella kostnaden av skadat förtroende. Organisationer som tar pentest på allvar ser det som en försäkringspremie, inte en kostnad.

De tre ansatstyperna: black-box, grey-box, white-box

Valet av ansats avgör vad testet kan avslöja och till vilken kostnad. Det finns ingen universellt "bästa" typ — det beror på vad du vill veta.

Vår rekommendation från Opsios SOC-perspektiv: grey-box är nästan alltid rätt startpunkt för organisationer som inte har ett moget pentestprogram. Du får djup nog att hitta allvarliga brister utan att bränna hälften av budgeten på rekognosering som inte ger säkerhetsinsikt.

Black-box har sitt värde — särskilt för att testa den yttre attackytan och verifiera att exponeringsminimering fungerar. Men om du bara har budget för ett test per år, ger grey-box mer per krona.

Pentestmetodik: steg för steg

1. Scopedefinition och avtal

Det här steget är viktigare än de flesta inser. Ett otydligt scope leder till frustration, budgetöverdrag och resultat som inte går att jämföra över tid. Definiera:

• Mål-system: Vilka IP-adresser, domäner, applikationer och API:er ingår?
• Exkluderingar: Produktionsdatabaser med riktig kunddata? Tredjepartssystem ni inte äger?
• Regler för engagemang: Tidsram, tillåtna metoder, eskaleringsvägar om kritiska fynd upptäcks mitt under testet
• Juridiskt avtal: Formellt godkännande som skyddar testaren juridiskt. Utan det är pentest tekniskt sett dataintrång.

2. Rekognosering (reconnaissance)

Testaren kartlägger attackytan: DNS-struktur, öppna portar, exponerade tjänster, läckta credentials i publika databaser, metadata i publika dokument, information på sociala medier. OSINT-metodik (open source intelligence) ger ofta förvånansvärt mycket utan att röra ett enda system direkt.

3. Sårbarhetskartläggning

Här kombineras automatiserade verktyg med manuell analys. Nmap för nätverksskanning, Burp Suite för webbapplikationer, Nessus eller OpenVAS för sårbarhetsskanning. Men det manuella arbetet är det som skiljer ett pentest från en sårbarhetsskanning — testaren analyserar affärslogik, autentiseringsflöden och auktorisering som inget verktyg förstår.

4. Exploatering

Den fas som de flesta tänker på när de hör "pentest". Testaren försöker aktivt utnyttja identifierade sårbarheter för att verifiera att de är reella och visa vilken påverkan de har. Det kan handla om SQL-injektion för att dumpa databaser, SSRF för att nå interna tjänster, privilege escalation för att gå från vanlig användare till admin, eller kedjeexploatering där flera lågrisk-brister kombineras.

Viktigt: en professionell pentestare dokumenterar exakt hur exploateringen gick till, steg för steg, så att utvecklingsteamet kan reproducera och åtgärda.

5. Post-exploatering och lateral förflyttning

Om testaren får initial åtkomst — vad kan hen nå därifrån? Kan hen röra sig lateralt i nätverket? Nå andra segment? Eskalera rättigheter? Det här stadiet avslöjar hur väl segmentering, övervakning och zero trust-principer fungerar i praktiken. Många organisationer har bra perimeterskydd men svagt internt försvar.

6. Rapportering och remedieringsplan

Rapporten är produkten som kunden betalar för. Den ska innehålla:

• Sammanfattning för ledningsgruppen (affärspåverkan, risknivå, prioriterade åtgärder)
• Teknisk detaljrapport per fynd (sårbarhet, bevis, steg-för-steg reproduktion, CVSS-poäng, rekommenderad åtgärd)
• Prioriteringsmatris baserad på kombinationen av exploaterbarhet och affärspåverkan

7. Återtestning

En ofta förbisedd fas. Efter att teamet har åtgärdat de identifierade sårbarheterna bör pentestaren verifiera att åtgärderna faktiskt löser problemet — inte bara flyttar det. Vi ser regelbundet att "fixar" introducerar nya sårbarheter eller bara adresserar symptomet.

Specialområden: moln, applikationer och social engineering

Pentest i molnmiljö

Att pentesta i AWS, Azure eller GCP kräver förståelse för shared responsibility-modellen. Du äger säkerheten i molnet — konfiguration, IAM-policies, nätverkssegmentering, applikationssäkerhet — medan leverantören ansvarar för säkerheten av molnet (hypervisor, fysisk infrastruktur).

Vanliga fynd i molnpentester som Opsios team ser:

• Överdrivna IAM-rättigheter: Roller med :-permissions som ger fullständig åtkomst
• Publikt exponerade S3-buckets eller Azure Blob Storage med känslig data
• Avsaknad av nätverkssegmentering — alla resurser i samma VPC/VNet utan restriktioner
• Oanvända säkerhetsfunktioner: GuardDuty avstängt, Security Center på gratisplan, CloudTrail utan alarmering

AWS tillåter pentest mot egna resurser utan förhandsansökan, men förbjuder DDoS-simulering och DNS-zonattacker. Azure har liknande villkor. Kontrollera alltid aktuell policy innan test.

Managerad molnsäkerhet

Applikationspentest (OWASP-perspektiv)

Webbapplikationer är den vanligaste attackvektorn. OWASP Top 10 ger en vettig utgångspunkt, men ett bra applikationspentest går långt bortom listan. Affärslogikbrister — som att kunna manipulera prisberäkningar, hoppa över betalsteg, eller eskalera sin roll — syns inte i automatiserade verktyg.

API-säkerhet förtjänar särskild uppmärksamhet. Med mikrotjänstarkitekturer och öppna API:er har attackytan exploderat. OWASP API Security Top 10 är relevant, men vi ser oftast problem med broken object level authorization (BOLA) — att API:et inte verifierar att användaren har rätt att komma åt just det objektet.

Social engineering och phishing-tester

Tekniska sårbarheter är bara halva bilden. Phishing-simuleringar och social engineering-tester visar hur motståndskraftiga era medarbetare faktiskt är. Det handlar inte om att "fånga" folk och skälla ut dem — utan om att mäta organisationens försvarsförmåga och identifiera var utbildningsinsatser behövs.

Verktygsarsenalen

Rätt verktyg i rätt fas gör skillnad. Här är vad professionella pentestare faktiskt använder:

En erfaren testare förlitar sig aldrig på ett enda verktyg. Automatisering hanterar det repetitiva — mänsklig analys hittar det intressanta.

Så väljer du pentestleverantör

Marknaden har inget brist på aktörer som erbjuder pentest, men kvalitetsskillnaderna är enorma. Här är vad du bör titta på:

Certifieringar som faktiskt betyder något: OSCP (Offensive Security Certified Professional) är branschstandard och kräver praktisk exploatering, inte bara kryssrutor. CREST-certifiering är stark för organisationer med brittisk koppling. CEH (Certified Ethical Hacker) är bättre än inget men anses inte tillräckligt av de flesta seniora säkerhetsspecialister.

Rapportkvalitet: Be om en anonymiserad exempelrapport. Om den bara listar CVE:er utan kontext, exploateringsbevis och prioriteringsmatris — leta vidare.

Återtestning inkluderad: Seriösa leverantörer inkluderar återtestning i priset, eller erbjuder det till reducerat pris.

Branschkännedom: En leverantör som förstår er branschs regulatoriska krav (finans, sjukvård, kritisk infrastruktur) kan fokusera testet på det som faktiskt spelar roll.

Opsios säkerhetstjänster

Från pentest till kontinuerlig säkerhetsförmåga

Ett pentest per år är bättre än inget — men det är en ögonblicksbild. Hotlandskapet förändras snabbare än så. Organisationer med mogen säkerhetsförmåga kombinerar:

• Regelbundna pentester (minst årligen, kvartalsvis för kritiska system)
• Kontinuerlig sårbarhetsskanning (veckovis eller dagligen för exponerade system)
• Bug bounty-program för att komplettera med crowdsourcad testning
• Red team-övningar som testar hela försvarskedjan — inklusive SOC:ens detektionsförmåga
• Threat intelligence som styr vad som testas baserat på aktuella hot

Det handlar om att bygga en säkerhetskultur där pentest inte är en årlig plåga utan en naturlig del av utvecklings- och driftsprocessen. DevSecOps-tänket — att bygga in säkerhetstestning i CI/CD-pipelinen — kompletterar traditionella pentester för applikationer som uppdateras ofta.

Managerad DevOps med säkerhet

Organisationer som tar pentest på allvar ser inte bara färre incidenter — de hanterar de incidenter som ändå inträffar snabbare och billigare. Det är inte en fråga om om ni kommer att angripas. Det är en fråga om huruvida ni vet var era svagheter finns innan angriparen gör det.

Vanliga frågor

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

Minst en gång per år för kritisk infrastruktur, men helst kvartalsvis för internetexponerade tjänster. Vid större förändringar — ny applikation, migrering till molnet, eller arkitekturombyggnad — bör du köra pentest innan produktionssättning. NIS2 kräver regelbundna tester utan att specificera exakt intervall, men årliga tester är branschminimum.

Vad är skillnaden mellan sårbarhetsskanning och pentest?

Sårbarhetsskanning är automatiserad och identifierar kända sårbarheter från databaser som CVE. Pentest går steget längre: en testare försöker faktiskt exploatera sårbarheterna, kedja ihop dem och visa reell påverkan. Skanning hittar att dörren kanske är olåst — pentest öppnar dörren och visar vad angriparen faktiskt når.

Vad kostar ett pentest?

Priset varierar kraftigt beroende på scope. En fokuserad webbapplikationstest kan kosta 50 000–150 000 SEK, medan ett fullskaligt red team-engagemang mot en komplex infrastruktur kan landa på 500 000 SEK eller mer. Det avgörande är att definiera scope tydligt — en vag avgränsning driver alltid upp kostnaden.

Kan vi köra pentest mot system i AWS eller Azure?

Ja, men du måste följa leverantörens regler. AWS tillåter pentest mot egna resurser utan förhandsgodkännande sedan 2019, men DDoS-tester och DNS-zonattacker är undantagna. Azure har liknande policy. Tänk på att testa rätt lager — du ansvarar för allt ovanför hypervisorn i shared responsibility-modellen.

Behöver vi pentest om vi redan har en SOC?

Absolut. En SOC övervakar och reagerar — pentest validerar att SOC:en faktiskt upptäcker attacker. Vi ser regelbundet att kunder med mogen SOC-förmåga ändå har blinda fläckar som bara framkommer under kontrollerade tester. Pentest och SOC kompletterar varandra; de ersätter inte varandra.