Hotbilden 2026: vad Opsios SOC ser i produktion

Från vårt 24/7 SOC i Karlstad och Bangalore observerar vi tydliga skiften i hur angripare opererar. Tre trender dominerar:

AI-assisterade angrepp

Angripare använder stora språkmodeller för att generera skräddarsydda phishing-kampanjer på felfri svenska. Vi ser spear-phishing-mejl som refererar till verkliga interna projekt – information hämtad från LinkedIn, pressmeddelanden och offentliga upphandlingsdokument. Volymen har ökat markant sedan 2024 och den språkliga kvaliteten gör att traditionella e-postfilter missar fler meddelanden.

Ransomware-as-a-Service (RaaS)

Tröskeln för att genomföra ransomware-attacker är lägre än någonsin. RaaS-plattformar säljer kompletta attackkit på darknet, inklusive kundsupport. Det innebär att hotet inte bara kommer från avancerade statsaktörer – det kommer från opportunistiska kriminella som letar efter den lägst hängande frukten. Små och medelstora företag utan segmenterade nätverk och testade backuper är primära mål.

Angrepp via leveranskedjan

Supply-chain-attacker riktar sig mot era leverantörer och deras mjukvara. En komprometterad CI/CD-pipeline hos en SaaS-leverantör kan ge angriparen åtkomst till hundratals nedströmskunder. Detta är precis den typen av angreppsvektorer som ett penetrationstest bör simulera – men som många testleverantörer fortfarande inte inkluderar.

NIS2 och regulatoriska krav på säkerhetstester

NIS2-direktivet, som trädde i kraft i EU och implementeras i svensk lag, ställer explicita krav på riskhantering och tekniska säkerhetsåtgärder för väsentliga och viktiga entiteter. Artikel 21 kräver bland annat:

• Riskanalys och säkerhetspolicyer för informationssystem
• Incidenthantering med definierade processer
• Kontinuitetstester inklusive backup-verifiering
• Säkerhet i leveranskedjan
• Testning och revision av säkerhetsåtgärder

Det sista punkten är avgörande: regulatorer förväntar sig att ni kan visa att era säkerhetsåtgärder faktiskt fungerar under realistiska förhållanden. En sårbarhetsskanning som producerar en PDF-rapport en gång om året räcker inte.

GDPR (artikel 32) kräver dessutom tekniska och organisatoriska åtgärder som säkerställer en säkerhetsnivå anpassad till risken, inklusive "förfaranden för att regelbundet testa, undersöka och utvärdera effektiviteten" i dessa åtgärder. Integritetsskyddsmyndigheten (IMY) har i sina granskningar pekat på just bristen på regelbundna tester som en överträdelse.

ISO/IEC 27001 och penetrationstest

ISO 27001:2022 (Annex A, kontroll A.8.8) specificerar hantering av tekniska sårbarheter. Certifierade organisationer förväntas genomföra regelbundna tekniska tester – och revisorer frågar allt oftare efter penetrationstestrapporter, inte bara skanningsresultat.

Molnsäkerhet

Typer av penetrationstest

Vilken typ av test ni behöver beror på er hotmodell, er mognad och vad regulatorer kräver. Här är de vanligaste:

Black-box (extern angripare)

Testaren har ingen förhandsinformation om er miljö. Simuleringen speglar en extern angripare som börjar från noll. Bra för att testa er exponerade yta – webbapplikationer, VPN-tjänster, publika API:er.

Grey-box (insiderperspektiv)

Testaren får begränsad information, till exempel ett användarkonto eller nätverksdiagram. Speglar en angripare som fått initial åtkomst via phishing. Detta är den testform vi på Opsio rekommenderar oftast – den ger mest affärskritisk insikt per investerad krona.

White-box (full insyn)

Testaren har tillgång till källkod, arkitekturdokumentation och nätverksscheman. Mest grundlig, men också mest resurskrävande. Lämplig för affärskritiska applikationer som hanterar känsliga data.

Red team-engagemang

Ett steg längre: ett red team-test simulerar en fullskalig attack inklusive social engineering, fysisk åtkomst och långvarig uthållighet i nätverket. Tidshorisonten är veckor till månader istället för dagar. Krävs sällan regulatoriskt men ger den mest realistiska bilden av er försvarsförmåga.

Hur ni väljer rätt penetrationstestföretag

Det här är där många organisationer gör misstag. Marknaden har exploderat och kvalitetsskillnaderna är enorma. Här är konkreta kriterier:

Certifieringar som faktiskt betyder något

• OSCP (Offensive Security Certified Professional) – branschstandard för manuell testförmåga
• CREST-ackreditering – organisationsnivå, kräver kvalitetssäkrade processer
• GPEN (GIAC Penetration Tester) – validerar teknisk kompetens
• CEH (Certified Ethical Hacker) – grundnivå, men otillräcklig som ensam certifiering

Opsios rekommendation: Fråga alltid vilka certifieringar de namngivna testarna har – inte bara företaget. En CREST-ackrediterad firma som skickar en junior utan OSCP ger inte det ni betalar för.

Metodik och ramverk

Seriösa leverantörer arbetar enligt etablerade ramverk:

• OWASP Testing Guide – standard för webbapplikationstester
• PTES (Penetration Testing Execution Standard) – helhetsmässigt ramverk
• NIST SP 800-115 – teknisk vägledning för säkerhetstester
• TIBER-EU – för finanssektorn, hotbildsbaserad testning

Fråga efter leverantörens testmetodik innan ni signerar. Om svaret är vagt, leta vidare.

Rapportkvalitet

En penetrationstestrapport ska innehålla:

1. Sammanfattning för ledningen – affärspåverkan i klartext

2. Teknisk detaljredovisning – varje sårbarhet med reproduktionssteg

3. Riskklassificering – enligt CVSS eller liknande med kontext för just er verksamhet

4. Åtgärdsrekommendationer – prioriterade, konkreta, genomförbara

5. Återtest-scope – vad som ska verifieras efter åtgärd

Undvik leverantörer vars rapport i praktiken är en Nessus-export med företagslogga.

Managerade molntjänster

Penetrationstest i molnmiljöer

Molninfrastruktur kräver specifik testkompetens. AWS, Azure och Google Cloud har alla regler för penetrationstest, och testaren måste förstå den delade ansvarsmodellen.

AWS (eu-north-1, Stockholm)

AWS tillåter penetrationstest mot de flesta tjänster utan förhandsgodkännande sedan 2019, men med viktiga undantag: DNS zone walking via Route 53, DDoS-simulering och tester mot AWS-infrastrukturen själv är förbjudna. Testfokus bör ligga på IAM-konfiguration, S3-bucket-policyer, Security Groups och eventuella Lambda-funktioner.

Azure (Sweden Central)

Microsoft kräver inget förhandsgodkännande för standardtester men förbjuder DDoS-tester, deliberat hög belastning och tester mot andra kunders resurser. Fokusområden: Azure AD-konfiguration, RBAC-tilldelningar, nätverkssegmentering och Key Vault-åtkomst.

Delade ansvarsmodellen i praktiken

Molnleverantören ansvarar för säkerheten av molnet (fysisk infrastruktur, hypervisor). Ni ansvarar för säkerheten i molnet (konfiguration, åtkomstkontroll, data). Ett penetrationstest i molnet testar primärt det ni ansvarar för – och det är där de flesta bristerna finns.

Enligt Datadog State of Cloud har felkonfigurationer konsekvent varit den vanligaste orsaken till säkerhetsincidenter i molnmiljöer. Det är inte sofistikerade zero-day-attacker som drabbar de flesta – det är publikt exponerade S3-buckets och alltför generösa IAM-roller.

Molnmigrering

Processen steg för steg

Ett väl genomfört penetrationstest följer en tydlig struktur:

1. Scoping och avtalsfas

Definiera exakt vad som ska testas: IP-adressintervall, applikationer, testperiod, tillåtna metoder. Dokumentera detta i ett Rules of Engagement-dokument (RoE) och säkerställ att rätt beslutsfattare signerar.

2. Reconnaissance (spaning)

Testaren samlar information om er miljö: DNS-poster, WHOIS-data, exponerade tjänster, publicerade CVE:er. Detta speglar vad en riktig angripare kan ta reda på innan själva attacken.

3. Aktiv testning

Den manuella testfasen: sårbarhetsutnyttjande, privilegieeskalering, lateral rörelse i nätverket. Testaren dokumenterar varje steg och tar skärmdumpar som bevis.

4. Rapportering

Resultaten sammanställs enligt den struktur vi beskrev ovan. Leveransmöte med både teknisk personal och ledning.

5. Åtgärd och återtest

Ni åtgärdar identifierade brister. Leverantören verifierar att åtgärderna faktiskt eliminerar sårbarheterna. Utan återtest vet ni inte om åtgärderna fungerar.

Opsios perspektiv: vad vi ser som driftpartner

Från vårt SOC/NOC-perspektiv observerar vi ett mönster: organisationer som genomför penetrationstest men aldrig följer upp med åtgärder och återtest. Rapporten hamnar i en mapp och samma sårbarheter ligger kvar tills de utnyttjas på riktigt.

Vår rekommendation är tydlig: koppla penetrationstestresultaten direkt till er förändringshantering (change management). Varje kritisk och hög sårbarhet bör generera ett ärende med ägare, deadline och verifieringsmetod. Vi ser också att organisationer som integrerar testresultat i sin Managerad DevOps-pipeline – där säkerhetstester är en del av CI/CD – har dramatiskt snabbare åtgärdstider.

FinOps-perspektivet

Penetrationstest är en investering, inte en kostnad. Flexeras State of the Cloud har konsekvent visat att säkerhetsrelaterade incidenter är bland de dyraste oplanerade molnkostnaderna. En ransomware-attack som krypterar era produktionsdata kostar inte bara lösensumman – den kostar driftstopp, kundtapp och regulatoriska sanktioner. Ett penetrationstest som identifierar attackvektorn innan den utnyttjas ger mätbar avkastning.

Cloud FinOps

Vanliga frågor

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

Priset varierar kraftigt beroende på scope. En avgränsad webbapplikationstest kan kosta 50 000–120 000 SEK, medan ett fullskaligt red team-engagemang med fysisk åtkomst och social engineering hamnar på 250 000–600 000 SEK. Avgörande faktorer är antal IP-adresser, applikationer, testdjup och om NIS2-specifik rapportering krävs.

Hur ofta bör vi genomföra penetrationstest?

Minst årligen, men i praktiken efter varje större förändring: ny applikation, infrastrukturmigrering, organisationsförändring eller ny integration. NIS2 kräver att tester speglar aktuell hotbild, vilket innebär att statiska årsintervall sällan räcker för verksamheter med snabb utvecklingstakt.

Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?

Sårbarhetsskanning är automatiserad och identifierar kända brister mot en databas (CVE:er). Penetrationstest innebär att en säkerhetsexpert manuellt försöker kedja ihop sårbarheter och eskalera åtkomst – precis som en riktig angripare. Skanningen hittar dörrar; penetrationstestet visar vad som händer när någon öppnar dem.

Vilka certifieringar bör en penetrationstestleverantör ha?

Leta efter OSCP, CREST-ackreditering eller GPEN hos enskilda testare. På företagsnivå är ISO/IEC 27001-certifiering och CREST-medlemskap starka signaler. Undvik leverantörer som inte kan visa namngivna certifieringar hos de som faktiskt utför testerna.

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

Nej. NIS2-direktivet talar om riskbaserade säkerhetsåtgärder och incidenthanteringsförmåga, vilket kräver att ni kan visa att ni testat mot realistiska hotscenarier. Enbart automatiserad skanning visar inte att ni förstår er faktiska riskexponering. Kombinationen automatiserad skanning plus manuellt penetrationstest är miniminivån.