Penetrationstest: mänsklig kreativitet mot era försvar

Penetrationstestning — pentest — är en kontrollerad, auktoriserad attack mot era system utförd av skickliga säkerhetsspecialister. Till skillnad från automatiserad skanning handlar det om att tänka som en angripare: hitta den svagaste länken, kedja ihop brister och demonstrera verklig påverkan.

Ett kvalificerat pentest följer vanligtvis en metodik som OWASP Testing Guide eller PTES (Penetration Testing Execution Standard) och innehåller:

• Rekognosering — kartläggning av attackytan, ofta med en kombination av automatiserade verktyg och manuell analys
• Sårbarhetsutnyttjande — testaren försöker aktivt exploatera brister, inklusive kedjning av flera mindre brister
• Lateral förflyttning — om första fotfästet vinns, testar man hur långt det går att komma i miljön
• Rapportering — detaljerad rapport med bevis, affärspåverkan och prioriterade åtgärdsförslag

Vad pentest fångar som skanning missar

Det är i gränslandet mellan teknik och affärslogik som pentest verkligen visar sitt värde. Här är konkreta exempel vi stöter på regelbundet:

• Trasig åtkomstkontroll — en API som tekniskt sett är korrekt konfigurerad men där en användare kan manipulera en parameter för att komma åt andras data. Ingen skanner hittar det.
• Kedjning av lågriskbrister — en SSRF med CVSS 4.0 kombinerad med en informationsläcka som tillsammans ger tillgång till interna metadata-endpoints i AWS (169.254.169.254), vilket leder till IAM-rollstöld.
• Social engineering-vektorer — testning av hur organisationen reagerar på phishing, pretexting eller fysisk åtkomst.
• Affärslogikfel — en e-handelsplattform där priset sätts av klienten, eller ett API som låter dig ändra orderstatus utan autentisering.

Jämförelse: skanning vs pentest i praktiken

Regulatoriska krav: NIS2, ISO 27001 och PCI DSS

Regulatorisk efterlevnad är ofta den utlösande faktorn för att formalisera säkerhetstestning. Här är vad de viktigaste ramverken kräver i praktiken:

NIS2-direktivet

NIS2, som trätt i kraft för väsentliga och viktiga entiteter i EU, kräver "lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder" för att hantera risker. Direktivet nämner specifikt krav på incidenthantering, riskbedömning och säkerhet i leveranskedjan. I praktiken tolkar tillsynsmyndigheter detta som att organisationer måste kunna visa att de aktivt testar sina försvar — inte bara skannar efter kända brister.

ISO/IEC 27001

Annex A-kontrollerna i ISO 27001 (specifikt A.8.8 om teknisk sårbarhetshantering) förutsätter att organisationen har en process för att identifiera, utvärdera och hantera tekniska sårbarheter. Certifieringsrevisorer förväntar sig vanligen att se bevis på både automatiserad skanning och periodiska pentest.

PCI DSS

PCI DSS är mest explicit: kvartalsvis nätverksskanning av en Approved Scanning Vendor (ASV) och årligt penetrationstest krävs. Organisationer som hanterar kortdata har inget val — båda metoderna är obligatoriska.

Molnsäkerhet

Så bygger du en kombinerad strategi

Den vanligaste fällan vi ser hos nya kunder är att de behandlar skanning och pentest som ett antingen/eller-beslut. Det är ungefär som att fråga om du ska ha brandvarnare eller sprinklersystem — du vill ha båda, men de fyller helt olika funktioner.

Steg 1: Klassificera era tillgångar efter riskprofil

Inte alla system förtjänar samma testnivå. En kundvänd betalningsapplikation har en helt annan riskprofil än ett internt wiki-system. Börja med att dela in era tillgångar i tre kategorier:

• Kritiska — externexponerade system med känslig data eller betalningsflöden
• Viktiga — interna system med åtkomst till produktionsdata
• Stödjande — system utan direkt koppling till känslig data

Steg 2: Bestäm frekvens per riskkategori

Steg 3: Integrera resultat i en gemensam åtgärdsprocess

Skanning och pentest ska inte producera separata rapporter som hamnar i olika inkorgar. Integrera alla fynd i samma ärendehanteringssystem med tydliga SLA:er för åtgärd baserat på allvarlighetsgrad:

• Kritisk (CVSS 9.0+, aktivt exploaterad): åtgärd inom 24 timmar
• Hög (CVSS 7.0–8.9): åtgärd inom 7 dagar
• Medel (CVSS 4.0–6.9): åtgärd inom 30 dagar
• Låg (CVSS < 4.0): åtgärd vid nästa underhållsfönster

Steg 4: Använd pentest-resultat för att förbättra skanningen

Det smartaste organisationer gör är att använda pentest-resultat som feedback-loop. Om en pentestare hittar en angreppsväg via en typ av brist som skannern missade, bör ni konfigurera skannern att leta efter liknande mönster framöver. Det skapar en positiv spiral där varje pentest gör er automatiserade övervakning bättre.

Managerade molntjänster

Molnspecifika överväganden

I moderna molnmiljöer — särskilt på AWS, Azure och GCP — förändras attackytan kontinuerligt. Infrastruktur skapas och förstörs via Terraform eller CloudFormation, containerimages byts ut dagligen och serverless-funktioner har egna behörighetsmodeller.

Det ställer specifika krav:

För sårbarhetsskanning i molnet behöver ni verktyg som förstår molnkontexten. AWS Inspector skannar EC2-instanser och Lambda-funktioner. Azure Defender for Cloud täcker hela Azure-stacken. Men ingen av dem testar applikationslogik eller IAM-policyer i kombination. Komplettera med CSPM-verktyg (Cloud Security Posture Management) som kontinuerligt validerar er konfiguration mot best practices — exempelvis CIS Benchmarks.

För pentest i molnet gäller särskilda regler. AWS tillåter pentest utan förhandsnotifiering mot de flesta tjänster sedan 2019, men nätverksstresstest kräver fortfarande godkännande. Azure har liknande regler. Välj alltid en pentestleverantör som har erfarenhet av molnmiljöer — att testa en traditionell on-prem-miljö och en modern cloud-native-arkitektur är fundamentalt olika discipliner.

I vår NOC ser vi regelbundet att kunder som kör i eu-north-1 (Stockholm) eller Sweden Central har bättre utgångsläge för datalokaliseringskrav, men det hjälper inte om IAM-rollerna ger bredare åtkomst än nödvändigt. Skanning fångar offentliga S3-buckets, men det krävs ett pentest för att visa att en Lambda-funktion med överprivilegierad roll kan användas som språngbräda till hela kontot.

Molnmigrering

Vanliga misstag vi ser — och hur ni undviker dem

Misstag 1: Att köra skanning utan att agera på resultaten. Vi har sett organisationer med tusentals oåtgärdade fynd i sin skanningsportal. Verktygen producerar rapport efter rapport, men ingen äger åtgärdsprocessen. Lösning: koppla skanning till ITSM-verktyg med automatisk ärendeskapning och tydliga ansvarsroller.

Misstag 2: Att beställa pentest som en checkbox-övning. Ett årligt pentest med standardscope mot er publika webbplats uppfyller kanske en revisors minimikrav, men ger marginellt säkerhetsvärde. Lösning: variera scope mellan tester — ett kvartal mot webappen, nästa mot API:erna, därefter mot intern infrastruktur.

Misstag 3: Att tro att skanningsverktygens riskpoäng alltid stämmer. CVSS-poäng sätts generiskt. En kritisk sårbarhet i ett system som bara är åtkomligt via VPN och kräver autentisering är en helt annan risk än samma sårbarhet i en publik-exponerad tjänst. Lösning: addera affärskontext och nätverksexponering i er riskbedömning.

Managerad DevOps

Opsios perspektiv: vad som faktiskt fungerar

Vi driver 24/7 SOC/NOC och ser dagligen skillnaden mellan organisationer som har en genomtänkt teststrategi och de som inte har det. Mönstret är tydligt:

Organisationer som kombinerar kontinuerlig skanning med regelbundna pentest har kortare tid till åtgärd (mean time to remediate, MTTR), färre kritiska brister i produktion och enklare revisioner. Det är ingen raketvetenskap — det handlar om att göra automatiseringen till din dagliga hygien och pentesten till din periodiska verklighetscheck.

Det vi rekommenderar som startpunkt för de flesta medelstora organisationer:

1. Implementera kontinuerlig skanning med integration i er SIEM

2. Beställ ett brett pentest för att etablera en baslinje

3. Baserat på pentest-resultaten, finjustera skanningskonfigurationen

4. Inför kvartalsvis pentest mot kritiska system, årligt mot övriga

5. Mät och rapportera MTTR per allvarlighetskategori till ledningen

Säkerhetstestning är inte ett projekt med slutdatum. Det är en löpande process som mognar över tid — precis som resten av er säkerhetsförmåga.

Cloud FinOps

Vanliga frågor

Kan sårbarhetsskanning ersätta penetrationstest?

Nej. Skanning identifierar kända sårbarheter i bredd men saknar förmåga att testa affärslogik, kedja ihop brister eller bedöma reell exploaterbarhet. Pentest kompletterar med mänsklig kreativitet och kontextuell bedömning. De fyller olika roller i en komplett säkerhetsstrategi.

Hur ofta bör vi genomföra penetrationstest?

För de flesta organisationer räcker ett till två pentest per år mot externexponerade system, plus extra test efter större förändringar som ny applikationsrelease eller infrastrukturmigrering. Verksamheter under NIS2 eller med hög riskprofil bör testa kvartalsvis.

Vad kostar sårbarhetsskanning jämfört med pentest?

Kontinuerlig skanning kostar typiskt 50 000–200 000 SEK per år beroende på antal tillgångar och verktygsval. Ett kvalificerat pentest landar ofta på 80 000–300 000 SEK per genomförande. Skanning ger bred täckning till lägre styckekostnad, pentest ger djup till högre engångskostnad.

Räcker automatiserad skanning för att uppfylla NIS2-kraven?

NIS2-direktivet kräver att organisationer vidtar "lämpliga och proportionella tekniska och organisatoriska åtgärder". Enbart automatiserad skanning räcker sällan — direktivet förutsätter att ni kan visa att ni testar era försvars verkliga motståndskraft, vilket i praktiken innebär regelbundna pentest.

Vilka verktyg använder Opsio för kontinuerlig sårbarhetsskanning?

Vi kombinerar molnbaserade skanningsverktyg som AWS Inspector, Microsoft Defender for Cloud och Qualys med egen SOC-integration. Alla fynd korreleras i vår SIEM-plattform och prioriteras efter affärskritikalitet — inte bara CVSS-poäng. Resultatet är handlingsbara åtgärdslistor, inte rapportberg.