Pentestmetodik steg för steg

En strukturerad metodik säkerställer att testet täcker rätt ytor och producerar åtgärdsbara resultat. Här är den process vi tillämpar:

1. Scope och hotmodellering

Innan en enda request skickas behöver ni definiera vad som testas, varför, och med vilka begränsningar. En bristfällig scope-definition är den vanligaste orsaken till pentester som inte ger värde.

Scope-definition bör inkludera:

• Vilka miljöer (produktion, staging, specifika microservices)
• Vilka användarroller som ska simuleras (anonym, autentiserad, admin, API-konsument)
• Specifika exkluderingar (tredjepartstjänster ni inte äger, destruktiva tester)
• Rules of engagement: tidsfönster, kontaktpersoner, eskaleringsrutiner

Hotmodellering identifierar var de mest kritiska riskerna finns. Vi använder STRIDE eller liknande ramverk för att systematiskt gå igenom spoofing, tampering, information disclosure, denial of service och privilege escalation i er specifika arkitektur.

2. Rekognosering och informationsinsamling

I denna fas kartlägger testaren plattformens exponerade yta: subdomäner, API-endpoints, teknologistack, publicerade integrationer och eventuella informationsläckor i publikt tillgängligt material (GitHub-repos, felmeddelanden, HTTP-headers).

För SaaS-plattformar som körs i AWS eu-north-1 (Stockholm) eller Azure Sweden Central granskar vi även molnkonfigurationen: publika S3-buckets, exponerade metadata-endpoints, felkonfigurerade security groups.

3. Aktiv testning

Här sker den faktiska attacksimuleringen. Den följer i regel tre spår parallellt:

• Automatiserad skanning (Burp Suite, Nuclei, semgrep) för att snabbt identifiera kända sårbarheter och felkonfigurationer
• Manuell logikgranskning där testaren systematiskt försöker bryta behörighetsmodellen, manipulera arbetsflöden och kringgå valideringar
• Infrastrukturtestning av den underliggande molnmiljön: IAM-policies, nätverkssegmentering, kryptering i vila och transit

4. Verifiering och riskklassificering

Varje identifierat fynd verifieras manuellt för att eliminera false positives. Fynden klassificeras inte bara efter teknisk allvarlighetsgrad (CVSS) utan även efter affärspåverkan. En medium-sårbarhet som exponerar alla kunders fakturadata har högre prioritet än en tekniskt kritisk sårbarhet i en intern testmiljö.

5. Rapportering och åtgärdsplan

En pentest-rapport som bara listar CVE:er är värdelös för er utvecklingsorganisation. Vi strukturerar rapporter med:

• Executive summary för ledning och styrelse (affärsrisk, inte tekniska detaljer)
• Tekniska fynd med steg-för-steg-reproduktion, skärmdumpar och föreslagna åtgärder
• Prioriterad åtgärdsplan baserad på risk × insats-matris
• Verifieringstest efter åtgärd för att bekräfta att fixarna faktiskt fungerar

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

Valet av testtyp påverkar vad ni kan förvänta er att hitta — och vad ni missar.

Vår rekommendation: För SaaS-plattformar ger grey-box-tester bäst avkastning. Ni får testning av realistiska attackscenarier med tillgång till autentiserade sessioner, utan att slösa tid på rekognosering som en verklig angripare ändå skulle klara av.

White-box-tester är motiverade vid säkerhetskritiska komponenter som autentisering, betalningshantering och tenant-isolering, där ni vill ha kodgranskning utöver dynamisk testning.

Regulatoriska krav som driver pentestbehov

GDPR och IMY

GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" för att skydda personuppgifter. Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut poängterat vikten av regelbunden säkerhetstestning. Pentest är inte explicit nämnt i förordningstexten, men det är i praktiken det starkaste sättet att demonstrera att ni faktiskt validerar era säkerhetsåtgärder.

NIS2-direktivet

NIS2, som trädde i kraft 2024, utvidgar kretsen av organisationer som omfattas av cybersäkerhetskrav avsevärt. SaaS-leverantörer som tillhandahåller tjänster till kritiska sektorer behöver dokumenterade processer för riskhantering — inklusive regelbunden testning av säkerhetskontroller. NIS2-krav för molntjänster

ISO 27001

ISO 27001 Annex A.12.6 (hantering av tekniska sårbarheter) och A.14.2 (säkerhetstestning) förutsätter båda att organisationen proaktivt identifierar och åtgärdar sårbarheter. Pentest är den mest trovärdiga formen av validering vid en certifieringsrevision.

SOC 2

SOC 2 Trust Services Criteria kräver att organisationen övervakar och testar effektiviteten av sina säkerhetskontroller. Pentest-rapporter är standardmässig bevisföring vid SOC 2-revisioner.

Vad Opsio ser i praktiken

Från vår SOC/NOC i Karlstad och Bangalore hanterar vi säkerhetsmonitorering dygnet runt för SaaS-plattformar i olika mognadsfaser. Några mönster som återkommer:

De flesta allvarliga fynd är inte Zero Days. De är konfigurationsfel, bristfällig behörighetskontroll och utdaterade beroenden. En organisation som håller sina beroenden uppdaterade, implementerar strikta IAM-policies och kör regelbundna pentester eliminerar den absoluta merparten av realistiska attackvektorer.

Pentester som inte följs upp är bortkastade pengar. Vi ser organisationer som beställer årliga pentester, får rapporter med kritiska fynd, och inte åtgärdar dem förrän nästa års test visar samma brister. Integrering av pentestresultat i er sprint-planering är lika viktig som själva testet. Managerad säkerhet för molnmiljöer

Continuous security slår årliga tester. En kombination av automatiserade sårbarhetsskanningar i CI/CD-pipelinen, bug bounty-program och fokuserade manuella pentester vid releaser ger bättre säkerhetsutfall än ett årligt stortest. DevSecOps med Opsio

Bygga ett pentestprogram — inte bara köpa ett test

Enstaka pentester är bättre än inga tester, men verklig säkerhetsmognad kräver ett program:

1. Kvartalsvis automatiserad skanning av hela den exponerade ytan (DAST + infrastruktur)

2. Halvårsvis grey-box-pentest av applikation och API:er

3. Årligt white-box-pentest av säkerhetskritiska komponenter

4. Continuous integration av säkerhetstester i CI/CD-pipelinen (SAST, SCA, container scanning)

5. Åtgärdsverifiering inom 30 dagar efter varje pentest

6. Trendspårning över tid — minskar antalet fynd? Ändras allvarlighetsgraden?

Denna kombination ger er en faktisk bild av säkerhetsläget snarare än en ögonblicksbild. FinOps för säkerhetsinvesteringar

Vanliga misstag vid SaaS-pentester

• För snäv scope: Att bara testa webbgränssnittet och missa API:er, webhooks och administrativa gränssnitt
• Fel testtyp: Black-box-test av en komplex plattform där testaren spenderar 60 % av tiden på rekognosering istället för faktisk testning
• Ingen hotmodellering: Testaren testar allt lika grundligt istället för att fokusera på de mest kritiska komponenterna
• Rapport utan kontext: Fynd listade med CVSS-poäng men utan affärspåverkan eller åtgärdsförslag anpassade till er teknologistack
• Ingen retest: Åtgärder implementeras men verifieras aldrig, vilket skapar en falsk känsla av säkerhet

Vanliga frågor

Hur ofta bör en SaaS-plattform pentestas?

Minst en gång per år som baslinje, men vid större releaser, arkitekturförändringar eller efter en incident bör ni köra kompletterande tester. Plattformar med känslig data eller regulatoriska krav (fintech, healthtech) tjänar på kvartalsvis testning av kritiska ytor.

Vad är skillnaden mellan pentest och sårbarhetsskanning?

En sårbarhetsskanning är automatiserad och identifierar kända CVE:er och felkonfigurationer. Ett pentest går djupare: en säkerhetsspecialist testar affärslogik, behörighetseskalering, tenant-isolering och attackkedjor som verktyg inte hittar. Båda behövs — de ersätter inte varandra.

Kan vi pentesta i produktion utan att påverka våra kunder?

Ja, med rätt förberedelse. Definiera tydliga rules of engagement, undvik destruktiva tester mot produktionsdata, och kör intensiva belastningstester i staging. Många tester — som autentiseringsbrister och IDOR — kan köras säkert i produktion med rätt avgränsning.

Räcker det med pentest för att uppfylla NIS2-kraven?

Nej. NIS2 kräver ett bredare riskhanteringsramverk som inkluderar incidenthantering, leverantörskedjesäkerhet och ledningsansvar. Pentest är en viktig komponent i den tekniska valideringen, men inte tillräckligt som enskild åtgärd.

Vad kostar ett pentest av en SaaS-plattform?

Priset varierar kraftigt beroende på scope, komplexitet och testdjup. En fokuserad applikationstest kan starta runt 80 000–150 000 SEK, medan en omfattande white-box-granskning av en komplex multi-tenant-plattform kan kosta 300 000 SEK eller mer. Billiga tester som bara kör automatiserade verktyg ger sällan verkligt värde.