Vad är penetrationstestning?

Penetrationstestning (pen-test) är en kontrollerad, manuell attack mot din miljö – utförd av en kvalificerad säkerhetskonsult som tänker och agerar som en verklig angripare. Målet är inte bara att hitta brister utan att kedja ihop dem till fungerande attackvägar som leder till konkreta konsekvenser: dataexfiltration, lateral rörelse, privilegieeskalering eller fullständig domänkompromiss.

Tre angreppsmodeller

I Opsios SOC ser vi regelbundet att organisationer beställer black-box-tester för att det "känns mest realistiskt". I praktiken innebär det att pen-testaren ägnar timmar åt att göra samma rekognosering som en automatiserad skanning hade fixat på minuter. Gray-box är standardvalet vi rekommenderar – det ger testaren tillräckligt med kontext för att fokusera på de riktigt intressanta attackkedjorna istället för att jaga lågthängande frukt.

Sårbarhetsbedömning vs penetrationstestning – detaljerad jämförelse

Varför du behöver båda – inte bara den ena

Det finns en farlig logik som vi stöter på regelbundet: "Vi kör ju sårbarhetsskanning varje vecka, så vi behöver inget pen-test." Eller tvärtom: "Vi gör årliga pen-tester, det räcker."

Bägge resonemangen lämnar blinda fläckar.

Sårbarhetsskanning utan pen-test

Du får en lång lista med CVE:er men ingen bild av den faktiska risken. Ditt team patchar i CVSS-ordning, men de farligaste attackvägarna kanske inte ens involverar den högst rankade CVE:n – utan en kedja av tre "medium"-brister som tillsammans ger fullständig åtkomst. Utan pen-test vet du inte vilka kedjor som existerar.

Pen-test utan sårbarhetsskanning

Pen-testaren ägnar dyrbar konsulttid åt att hitta brister som en automatiserad skanning hade rapporterat på fem minuter. Dessutom gör du pen-test en gång om året – resten av tiden har du ingen löpande insyn i nya sårbarheter som dyker upp varje dag.

Rätt ordning

1. Löpande sårbarhetsskanning – automatiserad, integrerad i CI/CD eller schemalagd mot produktion

2. Triage och åtgärdshantering – prioritera baserat på exponering, inte bara CVSS

3. Periodiskt penetrationstest – mot en avgränsad scope, utfört efter att kända brister åtgärdats

4. Retest – verifiera att pen-testets fynd faktiskt är åtgärdade

Den här cykeln ger dig både bredd och djup. Molnsäkerhet

Regelverk som driver behovet

NIS2-direktivet

NIS2, som trädde i kraft i EU under 2024–2025, kräver att väsentliga och viktiga entiteter implementerar "lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder" för att hantera risker. Direktivet specificerar inte exakt vilka testmetoder som krävs, men tillsynsmyndigheter – inklusive MSB i Sverige – tolkar det som att regelbunden teknisk verifiering av säkerhetsåtgärder är en förväntan. I praktiken innebär det både löpande skanning och periodisk pen-testning.

ISO/IEC 27001

Annex A-kontroller i ISO 27001:2022 – specifikt A.8.8 (hantering av tekniska sårbarheter) – kräver att organisationer regelbundet identifierar, värderar och åtgärder sårbarheter. Penetrationstestning nämns explicit som verifieringsmetod i ISO 27001-implementeringsriktlinjer (27002).

GDPR och IMY

Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut under 2024–2025 understrukit att personuppgiftsansvariga måste vidta tekniska åtgärder för att regelbundet testa och utvärdera säkerheten i behandlingen – direkt kopplat till artikel 32 i GDPR. Sårbarhetsskanning och pen-test är de mest uppenbara sätten att påvisa detta.

Vad Opsios SOC ser i praktiken

Från vårt 24/7 SOC/NOC i Karlstad och Bangalore hanterar vi sårbarhetsskanning och incidentrespons för organisationer som kör arbetsbelastningar i AWS (eu-north-1), Azure (Sweden Central) och multimoln-uppsättningar. Några mönster vi ser upprepade gånger:

Skanningsresultat som ignoreras. Organisationer kör Qualys eller Nessus men saknar en process för att faktiskt åtgärda fynden. Listan växer, teamet drunknar, och kritiska brister faller mellan stolarna. En managerad approach där triagering och åtgärdsspårning ingår löser detta. Managerade molntjänster

Pen-test som engångshändelse. En del företag beställer ett pen-test för att bocka av en revisionsruta. Rapporten hamnar i en låda. Inget retest, ingen uppföljning. Det ger en falsk trygghet som är värre än att inte ha testat alls – för nu tror ledningen att man är säker.

Molnkonfigurationsbrister dominerar. I AWS och Azure handlar de allvarligaste fynden ofta inte om mjukvarusårbarheter utan om felkonfigurationer: publikt exponerade S3-buckets, överdrivna IAM-rättigheter, avsaknad av nätverkssegmentering. Dessa fångas bäst av en kombination av CSPM-verktyg (Cloud Security Posture Management) och manuell granskning. Molnmigrering

Så bygger du en verifieringsplan – steg för steg

1. Inventera din yta. Kartlägg alla exponerade tjänster, API:er, molnkonton och interna nätverkssegment. Du kan inte testa det du inte vet att du har.

2. Välj skanningsverktyg. För molnmiljöer: AWS Inspector, Azure Defender for Cloud eller tredjepartsverktyg som Qualys/Rapid7. Integrera med CI/CD via Managerad DevOps för att fånga brister innan deploy.

3. Etablera en åtgärdsprocess. Varje skanningsfynd behöver en ägare, en prioritering baserad på exponering (inte bara CVSS) och en tidsfrist.

4. Beställ pen-test mot avgränsad scope. Börja med din mest affärskritiska applikation eller det nätverkssegment som exponerar mest data.

5. Genomför retest. Efter att pen-testets fynd åtgärdats, verifiera att åtgärderna håller. Många pen-testleverantörer inkluderar ett retest i priset.

6. Rapportera till ledning och styrelse. NIS2 kräver att ledningen tar ansvar för cybersäkerhet. Översätt tekniska fynd till affärsrisk: "Denna attackkedja ger åtkomst till 50 000 kundposter inom 4 timmar."

Kostnadsoptimering – FinOps-perspektiv på säkerhetstester

Säkerhetstestning är en investering, inte en kostnad – men det betyder inte att du ska bränna budget utan plan. Flexeras State of the Cloud har konsekvent visat att kostnadshantering är organisationers största molnutmaning. Samma disciplin bör gälla för säkerhetstestning:

• Automatisera det repetitiva. Sårbarhetsskanning ska inte vara manuellt arbete. Lägg in det i pipeline.
• Fokusera pen-test-scope. Testa inte allt varje gång. Rotera scope: externt nätverk ett kvartal, webbapplikation nästa, molnkonfiguration efter det.
• Koppla till FinOps. Säkerhetsbrister har en kostnad – inte bara i potentiell incident, utan i teknisk skuld, patchcykler och incidentresponsberedskap. Cloud FinOps

Vanliga frågor

Kan en sårbarhetsskanning ersätta penetrationstestning?

Nej. Sårbarhetsskanning identifierar kända brister men verifierar inte om de faktiskt går att utnyttja i just din miljö. Penetrationstestning simulerar en verklig angripare och visar vilka attackvägar som leder till faktisk kompromiss. Du behöver båda – skanning som löpande hygienkontroll och pen-test som djupgående verifiering.

Hur ofta bör vi genomföra sårbarhetsskanning respektive pen-test?

Sårbarhetsskanning bör ske minst veckovis, helst dagligen i en automatiserad pipeline. Penetrationstester rekommenderas minst en gång per år samt vid större arkitekturförändringar, nya applikationslanseringar eller efter incidenter. NIS2-direktivet specificerar regelbunden teknisk verifiering utan exakt frekvens – branschpraxis pekar på årliga pen-test.

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

Automatiserad sårbarhetsskanning kostar typiskt några tusen kronor per månad via verktyg som Qualys, Nessus eller Rapid7. Ett externt penetrationstest startar från cirka 50 000–80 000 SEK för en avgränsad scope och kan överstiga 300 000 SEK för komplexa miljöer. Skillnaden i pris speglar skillnaden i manuellt expertarbete.

Räcker sårbarhetsbedömning för att uppfylla NIS2?

Inte ensamt. NIS2-direktivet kräver att väsentliga och viktiga entiteter vidtar "lämpliga och proportionerliga tekniska åtgärder" för riskhantering. Tillsynsmyndigheter tolkar detta som att det krävs både löpande sårbarhetsskanning och periodisk penetrationstestning för att visa att man aktivt verifierar sin säkerhetsnivå.

Black-box, gray-box eller white-box – vilken typ av pen-test ska vi välja?

Det beror på hotmodellen. Black-box simulerar en extern angripare utan förkunskap – bra för att testa perimetern. Gray-box ger testaren viss insyn och liknar en komprometterad insider. White-box ger full tillgång till källkod och arkitektur och hittar flest brister per timme. Vi rekommenderar gray-box som standardval – det ger bäst balans mellan realism och effektivitet.