Processens fem steg – från identifiering till verifiering

En effektiv sårbarhetshanteringsprocess är cyklisk, inte linjär. Vi arbetar med en femstegsmodell som bygger på NIST Cybersecurity Framework och är anpassad för organisationer som kör hybridmiljöer med arbetsbelastningar fördelade mellan on-prem och publika moln.

1. Inventering – vet vad ni har

Ni kan inte skydda det ni inte känner till. En komplett och automatiskt uppdaterad inventering av alla tillgångar – servrar, containrar, API:er, SaaS-integrationer, tredjepartsbibliotek – är det absolut grundläggande steget. I molnmiljöer där resurser skapas och förstörs dynamiskt kräver detta integration med AWS Config, Azure Resource Graph eller motsvarande, samt en Software Bill of Materials (SBOM) för era applikationer.

Från Opsios driftsperspektiv: den vanligaste orsaken till att kritiska sårbarheter missas är inte bristfälliga skanningsverktyg – det är att tillgångsinventeringen är ofullständig. Skuggsystem och bortglömda testmiljöer är angriparens bästa vän.

2. Identifiering – hitta sårbarheterna

Sårbarhetsskanning sker i flera lager:

• Infrastrukturskanning – nätverks- och OS-nivå (exempelvis Qualys, Tenable, AWS Inspector)
• Applikationsskanning – SAST/DAST i CI/CD-pipelines
• Beroendeanalys – SCA-verktyg (Software Composition Analysis) som identifierar kända sårbarheter i tredjepartsbibliotek
• Molnkonfiguration – CSPM-verktyg (Cloud Security Posture Management) som upptäcker felkonfigurationer

Varje identifierad sårbarhet kopplas till en CVE-identifierare (Common Vulnerabilities and Exposures) som ger spårbarhet och möjliggör korsreferens mot hotintelligens.

3. Bedömning och prioritering – den viktigaste och svåraste delen

Här faller de flesta organisationer. Att ha en lista med tusentals CVE:er är inte detsamma som att veta vad ni ska åtgärda först. CVSS (Common Vulnerability Scoring System) ger en standardiserad teknisk allvarlighetsgrad, men den saknar er specifika kontext.

Vi rekommenderar en prioriteringsmodell som väger in tre dimensioner:

En sårbarhet med CVSS 9.8 i ett isolerat testsystem utan känslig data är lägre prioritet än en CVSS 7.5 i en internet-exponerad API som hanterar personuppgifter. Det låter självklart, men utan en strukturerad modell hamnar teamet i "patch everything now"-läge, vilket i praktiken innebär att inget prioriteras.

4. Åtgärd – mer än bara patching

Åtgärd är inte synonymt med att installera en patch. Beroende på kontext kan åtgärden vara:

• Patchning – den vanligaste och mest direkta åtgärden
• Konfigurationsändring – stänga en öppen port, ändra IAM-policy, aktivera kryptering
• Kompenserande kontroll – WAF-regel, nätverkssegmentering eller IPS-signatur som temporär skyddsåtgärd
• Accept – dokumenterat riskacceptansbeslut med tidsbegränsning och ansvarig beslutsfattare
• Avveckling – ta bort systemet eller beroendet helt

Vi sätter tydliga SLA:er baserade på allvarlighetsgrad:

5. Verifiering och rapportering – stäng loopen

Efter åtgärd verifierar vi att sårbarheten faktiskt är eliminerad genom omskanning. Det låter trivialt, men vi ser regelbundet att patcher installeras utan att tjänsten startas om, eller att konfigurationsändringar överskrivs av IaC-pipelines som inte uppdaterats. Verifiering är inte ett nice-to-have – det är det steg som gör skillnaden mellan "vi tror att vi är säkra" och "vi vet att vi är säkra".

Rapportering kopplar processen tillbaka till ledningsnivå med KPI:er som:

• Mean Time to Remediate (MTTR) per allvarlighetsgrad
• Andel tillgångar med fullständig skanningstäckning
• Antal kritiska sårbarheter äldre än SLA
• Trend över tid – blir ni bättre eller sämre?

Ramverk och standarder som styr arbetet

Sårbarhetshantering existerar inte i ett vakuum. Ramverken ger struktur och gemensamt språk:

Enligt NIST CSF 2.0 är "Identify" och "Protect" de funktioner som direkt adresserar sårbarhetshantering, medan "Detect" och "Respond" hanterar konsekvenserna när processen brister.

NIS2 och den svenska kontexten

NIS2-direktivet, som implementeras i svensk lagstiftning genom den kommande cybersäkerhetslagen, skärper kraven avsevärt jämfört med det tidigare NIS-direktivet. För sårbarhetshantering innebär det bland annat:

• Skyldighet att ha dokumenterade processer för att identifiera och hantera sårbarheter i nätverk och informationssystem
• Incidentrapportering inom 24 timmar vid betydande incidenter – vilket kräver att ni redan har kartlagt era sårbarheter och vet var riskerna finns
• Ledningsansvar – ledningen kan hållas personligt ansvarig för bristande cybersäkerhetsåtgärder
• Leveranskedjesäkerhet – ni ansvarar inte bara för era egna system utan även för att hantera risker i leverantörsrelationer

Myndigheten för samhällsskydd och beredskap (MSB) är tillsynsmyndighet, och Integritetsskyddsmyndigheten (IMY) övervakar GDPR-aspekterna. Organisationer som redan har en mogen sårbarhetshanteringsprocess har ett betydande försprång i NIS2-efterlevnad.

Molnsäkerhet och NIS2-efterlevnad

Sårbarhetshantering i molnmiljöer – specifika utmaningar

Molnmiljöer adderar komplexitet som traditionella processer inte adresserar:

Dynamisk infrastruktur – containrar och serverlösa funktioner lever i minuter eller sekunder. Skanning måste ske vid byggtid i CI/CD-pipelinen, inte bara i drift. En sårbarhetsskanning som körs veckovis mot en Kubernetes-kluster missar potentiellt hundratals containrar som skapats och förstörts mellan skanningarna.

Delat ansvarsmodell – i AWS, Azure och GCP ansvarar leverantören för säkerheten av molnet, men ni ansvarar för säkerheten i molnet. Det innebär att OS-patching på EC2-instanser, IAM-konfiguration och applikationssäkerhet är ert ansvar. Vi ser regelbundet att organisationer förutsätter att "molnleverantören sköter det".

Konfigurationssårbarheter – i molnet är felkonfigurationer minst lika farliga som kodbaserade sårbarheter. En öppen S3-bucket eller en alltför generös IAM-roll är i praktiken en sårbarhet, även om den inte har ett CVE-nummer.

Multi-moln och hybridmiljöer – när arbetsbelastningar är fördelade över flera molnplattformar och on-prem-system krävs ett enhetligt sätt att inventera, skanna och prioritera. Verktyg som fungerar utmärkt i AWS kanske inte täcker Azure – och vice versa.

Managerade molntjänster

Vad Opsio gör annorlunda

Från vårt 24/7 SOC/NOC hanterar vi sårbarhetshantering som en integrerad del av driften – inte som ett separat säkerhetsprojekt som körs kvartalsvis. Konkret innebär det:

Kontinuerlig skanning integrerad i drift – vi kopplar sårbarhetsskanning direkt till era CI/CD-pipelines och molnmiljöer, med automatiserade gates som stoppar deploys med kritiska sårbarheter.

Prioritering baserad på verklig hotkontext – vi kombinerar CVSS med EPSS-data, CISA:s KEV-katalog och insikter från vår egen SOC-verksamhet för att ge er en prioriteringslista som reflekterar faktisk risk, inte teoretisk allvarlighetsgrad.

Åtgärdsdriven rapportering – varje rapport innehåller konkreta åtgärdsrekommendationer med tydligt ägarskap och SLA. Vi mäter MTTR och rapporterar trender till er ledning.

NIS2-redo dokumentation – vi levererar den dokumentation som NIS2 kräver: processbeskrivningar, riskanalyser, incidenthanteringsplaner och revisionsunderlag.

Managerad DevOps

Vanliga frågor

Vad är skillnaden mellan sårbarhetshantering och penetrationstest?

Sårbarhetshantering är en kontinuerlig process som systematiskt identifierar, prioriterar och åtgärdar kända svagheter i hela IT-miljön. Penetrationstest är en punktinsats där en testare simulerar en angripares beteende mot specifika system. Penetrationstest kompletterar sårbarhetshantering men ersätter den inte – ni behöver båda för en fullständig säkerhetsbild.

Hur ofta bör vi genomföra sårbarhetsskanningar?

Minst veckovis för produktionsmiljöer, men helst integrerat i CI/CD-pipelinen så att varje kodändring skannas automatiskt. Kritiska internet-exponerade system bör skannas dagligen. NIS2 kräver att organisationer har en dokumenterad frekvens anpassad efter riskprofil.

Räcker det att patcha alla kritiska CVSS-sårbarheter?

Nej. CVSS mäter teknisk allvarlighetsgrad men saknar er specifika kontext. En CVSS 9.8-sårbarhet i ett isolerat testsystem är lägre prioritet än en CVSS 7.5 i en internet-exponerad produktionstjänst som hanterar kunddata. Affärskontext och exploaterbarhet måste alltid vägas in.

Vilka krav ställer NIS2 på sårbarhetshantering?

NIS2-direktivet kräver att väsentliga och viktiga entiteter har dokumenterade processer för att identifiera och hantera sårbarheter, rapportera incidenter inom 24 timmar och genomföra regelbundna riskanalyser. Sverige implementerar detta genom den kommande cybersäkerhetslagen, med MSB som tillsynsmyndighet.

Hur lång tid bör det ta att åtgärda en kritisk sårbarhet?

Branschpraxis för aktivt exploaterade kritiska sårbarheter är 24–72 timmar. För kritiska sårbarheter utan känd exploit rekommenderar vi max 14 dagar. Organisationer utan strukturerad process behöver ofta veckor eller månader – det är precis den risken en mogen process eliminerar.

For hands-on delivery in India, see zero-downtime konsult consulting.