Typer av penetrationstest och när de är relevanta

Innan ni begär offert behöver ni förstå vilken typ av test er organisation behöver. Att be om "ett pentest" utan specifikation är som att be om "en försäkring" – det finns dussintals varianter med helt olika värde.

Externt penetrationstest

Simulerar en attack från internet mot era publikt exponerade system: webbservrar, e-postgateway, VPN-terminaler, DNS-infrastruktur. Det här är startpunkten för de flesta organisationer och den typ av test som direkt adresserar den attackyta som varje hotaktör kan nå utan förkunskap.

Internt penetrationstest

Utgår från att en angripare redan har fotfäste i ert nätverk – exempelvis genom phishing eller en komprometterad endpoint. Testet kartlägger lateral rörelse: hur långt kan angriparen nå? Kan de eskalera privilegier? Når de domänkontrollanten, backupsystem eller produktionsdata? I molnmiljöer innebär detta ofta att testa IAM-konfigurationer och nätverkssegmentering.

Applikationstester

Fokuserar på en specifik webbapplikation, mobilapp eller API. OWASP Top 10 är den etablerade referensramen, men ett bra applikationstest går djupare: affärslogik-brister, autentiseringsflöden, auktoriseringsluckor som automatiserade verktyg inte fångar.

Molnspecifika tester

Testar konfiguration och säkerhet i AWS, Azure eller GCP-miljöer. Felkonfigurerade IAM-policyer, publikt exponerade storage-resurser och otillräcklig loggning är de vanligaste fynden vi på Opsio ser i kundmiljöer. Molnsäkerhet

Vad en pentest-offert bör innehålla

Här är kärnan: hur bedömer ni om en offert faktiskt levererar värde? Vi har granskat hundratals offerter åt kunder och ser samma brister om och om igen.

1. Scope-definition

Offerten måste exakt specificera vad som testas. "Era externa system" är inte ett scope. Kräv:

• Antal och specificerade IP-adresser eller IP-intervall
• Domäner och subdomäner
• Specifika applikationer och deras URL:er
• Molnkonton och regioner (exempelvis eu-north-1 för AWS eller Sweden Central för Azure)
• Explicita undantag – vad testas inte?

2. Testmetodik

En seriös leverantör refererar till etablerade ramverk: OWASP Testing Guide, PTES (Penetration Testing Execution Standard) eller NIST SP 800-115. Var skeptiska till offerter som bara nämner egna "proprietära metoder" utan att förankra dem i branschstandard.

3. Fördelning automatiserat kontra manuellt arbete

Det här är den enskilt viktigaste faktorn att förstå. Fråga leverantören: hur många mantimmar manuellt testarbete ingår? En offert på 40 000 SEK med 8 timmars manuellt arbete är i praktiken en sårbarhetsskanning med en rapport ovanpå. En offert på 150 000 SEK med 60 timmars manuellt arbete av OSCP-certifierade testare är ett helt annat erbjudande.

4. Rapportstruktur

Rapporten är den leverans ni faktiskt betalar för. Den bör innehålla:

• Executive summary på max en sida – för ledningsgrupp och styrelse
• Tekniska fynd med CVSS-klassificering och bevisunderlag (screenshots, loggutdrag)
• Affärsprioriterade åtgärdsrekommendationer – inte "uppdatera OpenSSL" utan "denna sårbarhet möjliggör åtkomst till kunddata, prioritet: kritisk, åtgärdsförslag: ..."
• Verifieringstest – erbjuder leverantören omtest efter åtgärd?

5. Eskaleringsprocess

Vad händer om testarna hittar en kritisk, aktivt utnyttjbar sårbarhet klockan 14 en tisdag? En ansvarsfull leverantör har en definierad process för omedelbar eskalering – inte en rapport tre veckor senare.

Prisjämförelse: varför offerter varierar så kraftigt

Vi ser prisintervall från 30 000 SEK till över 500 000 SEK för vad som på ytan ser ut som samma typ av test. Det beror på att det inte är samma test.

Poängen är inte att det billiga alltid är dåligt. En ren sårbarhetsskanning med rapport kan vara precis rätt för en årlig baslinjekontroll. Men om ni behöver uppfylla krav från NIS2, ISO 27001 eller en kund som kräver SOC 2-verifikation – då behöver ni det professionella alternativet, och då måste ni förstå vad ni jämför.

Regulatoriska drivkrafter: NIS2, GDPR och ISO 27001

Penetrationstest har gått från "bra att ha" till "regulatoriskt förväntat" för de flesta organisationer.

NIS2-direktivet

NIS2, som gäller i Sverige sedan oktober 2024, kräver att väsentliga och viktiga entiteter genomför regelbundna riskbedömningar och vidtar lämpliga tekniska åtgärder. Penetrationstest nämns inte explicit som krav, men det är svårt att visa att man uppfyller direktivets krav på "proportionerliga tekniska åtgärder" utan att ha testat sina system. Integritetsskyddsmyndigheten (IMY) och MSB förväntar sig dokumenterad säkerhetstestning.

GDPR artikel 32

Kräver "tekniska och organisatoriska åtgärder" för att säkerställa en lämplig säkerhetsnivå. En penetrationstest-rapport är ett konkret bevis på att ni aktivt arbetar med att identifiera och åtgärda risker för personuppgifter.

ISO 27001

Annex A, kontroll A.8.8 (Management of technical vulnerabilities) kräver att sårbarheter identifieras, utvärderas och åtgärdas. Penetrationstest är den etablerade metoden för att verifiera att detta fungerar i praktiken, inte bara på papper.

Managerade molntjänster

Fallgropar vi ser från Opsios SOC

Baserat på de hundratals pentest-rapporter vi granskat åt kunder – och de incidenter vi hanterat i vårt SOC – finns det mönster som återkommer:

"Grön rapport"-fällan. En leverantör levererar en rapport utan kritiska fynd, och kunden slår sig till ro. Men scopet var för snävt – de testade bara tre IP-adresser av femtio, eller utelämnade interna system helt. En grön rapport är bara meningsfull om scopet var komplett.

Ingen koppling till verklig hotbild. Rapporten listar 47 "medium"-sårbarheter utan att kontextualisera dem. Vilka av dessa kan kedjas ihop? Vilka är relevanta för just er bransch och hotprofil? Det är den manuella analysen som skapar värde.

Pentest som engångshändelse. En organisation genomför ett pentest, åtgärdar fynden och gör inte ett nytt test på två år. Under tiden har infrastrukturen förändrats radikalt. Penetrationstest bör vara en del av ett kontinuerligt säkerhetsarbete, inte en punkt på en checklista. Managerad DevOps

Testar produktionsmiljön utan förberedelse. Vi har sett kunder vars leverantör körde aggressiva skanningar mot produktionssystem mitt under kontorstid utan förvarning till driftteamet. Offerten bör specificera testfönster, och ert NOC/SOC bör vara informerat.

Så utvärderar ni en offert: checklista

Använd den här listan nästa gång ni jämför pentest-offerter:

• [ ] Är scopet exakt definierat med IP-adresser, applikationer och miljöer?
• [ ] Framgår det hur många mantimmar manuellt testarbete som ingår?
• [ ] Refererar leverantören till etablerad metodik (OWASP, PTES, NIST)?
• [ ] Inkluderar rapporten affärsprioriterade rekommendationer?
• [ ] Ingår omtest efter åtgärd?
• [ ] Finns en eskaleringsprocess för kritiska fynd?
• [ ] Har testarna relevanta certifieringar (OSCP, CREST)?
• [ ] Har leverantören erfarenhet av er typ av miljö (moln, on-prem, hybrid)?
• [ ] Är testfönster och kommunikationsplan specificerade?
• [ ] Uppfyller rapportformatet era regulatoriska krav (NIS2, ISO 27001, GDPR)?

Penetrationstest i molnmiljöer – specifika överväganden

Molnmiljöer kräver ett annat angreppssätt än traditionell on-prem-infrastruktur. Shared responsibility-modellen innebär att AWS, Azure eller GCP ansvarar för säkerheten av molnet, men ni ansvarar för säkerheten i molnet.

De vanligaste fynden vi på Opsio ser i molnmiljöer:

• Överdrivet tillåtande IAM-policyer – särskilt :-rättigheter på AWS eller Contributor-roller utan scope i Azure
• Publikt exponerade storage-resurser – S3-buckets, Azure Blob Storage utan åtkomstkontroll
• Avsaknad av nätverkssegmentering – alla resurser i samma VPC/VNet utan Security Groups eller NSG:er
• Otillräcklig loggning – CloudTrail eller Azure Monitor inaktiverat eller med för kort retention

En pentest-leverantör som ska testa er molnmiljö behöver specifik kompetens i just den plattform ni använder. Fråga efter referensuppdrag i AWS, Azure eller GCP – inte bara generell nätverkstestning. Cloud FinOps

Att välja Opsio som partner

Opsio kombinerar penetrationstest med kontinuerlig säkerhetsövervakning från vårt 24/7 SOC/NOC. Det innebär att pentest-fynden inte stannar i en rapport – de integreras i vår övervakning, våra larmregler och era åtgärdsplaner. Vi ser det som en del av en löpande säkerhetscykel, inte en isolerad händelse.

Vår erfarenhet av molninfrastruktur i AWS (eu-north-1) och Azure (Sweden Central) gör att vi förstår de plattformsspecifika risker som generella pentest-firmor ofta missar. Molnmigrering

Vanliga frågor

Vad kostar ett penetrationstest för ett medelstort företag?

Priset varierar beroende på scope, men för ett medelstort företag med ett externt nätverkssegment och en till två webbapplikationer hamnar offerter typiskt mellan 50 000 och 200 000 SEK. Skillnaden handlar främst om hur mycket manuellt testarbete som ingår kontra ren automatiserad scanning. Begär alltid specificering av mantimmar.

Hur ofta bör vi genomföra penetrationstest?

Minst årligen, men även efter större förändringar i infrastruktur, lansering av nya applikationer eller vid byte av molnleverantör. NIS2-direktivet kräver regelbunden riskbedömning, och penetrationstest är det naturliga verktyget för att uppfylla det kravet i praktiken.

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

En sårbarhetsskanning är automatiserad och listar kända sårbarheter baserat på databaser som CVE. Ett penetrationstest går vidare genom att manuellt försöka utnyttja sårbarheterna, kedja ihop attackvägar och bedöma den faktiska affärsrisken. Scanningen hittar dörren – pentestet visar vad som finns bakom den.

Vilka certifieringar bör en pentest-leverantör ha?

OSCP (Offensive Security Certified Professional) och CREST-ackreditering är branschens tyngsta kvalitetsstämplar för teknisk kompetens. GPEN och CEH är vanliga men säger mindre om praktisk förmåga. Fråga även efter leverantörens erfarenhet av just er typ av miljö – molninfrastruktur kräver annan kompetens än traditionella on-prem-tester.

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

Absolut. Molnmiljöer har sin egen attackyta: felkonfigurerade IAM-roller, publikt exponerade storage-resurser, överdrivet tillåtande nätverkspolicyer. Shared responsibility-modellen innebär att molnleverantören säkrar infrastrukturen, men konfigurationen och applikationslagret är ert ansvar – och det är just de lagren ett pentest granskar.