Sårbarhetsskanning är en automatiserad undersökning som hittar kända sårbarheter och felkonfigurationer i system, kod eller molnmiljöer. Resultatet behöver verifieras, prioriteras och följas av åtgärder; en skanning i sig tar inte bort riskerna.
Här går vi igenom metoderna och hur ni tar ett fynd från skanningsrapport till verifierad rättning. Ni får också ett exempel på prioritering när teknisk allvarlighet och verksamhetens risker pekar åt olika håll.
Vad är sårbarhetsskanning?
Det är en automatisk kontroll av era system. Syftet är enkelt: hitta svagheter innan de utnyttjas.
Varje dag upptäcks nya fel (CVE:er). Det kan vara en bugg i Windows eller ett hål i Apache. För vissa sårbarheter finns attackkod redan när felet offentliggörs. För andra saknas kända angrepp. Bedöm hur utsatta era system är och om sårbarheten utnyttjas aktivt.
En skanner letar efter dessa kända fel. Den kan också hitta felkonfigurationer, som ett lösenord som är "admin123". Detta ger er en chans att täppa till hålen i tid.
Det finns olika typer av skanning:
- Nätverksskanning: Letar efter öppna portar och osäkra tjänster. Exempel: Port 3389 (RDP) är öppen mot internet.
- Webbapplikationsskanning (DAST): Testar webbsidor för fel som SQL-injection eller XSS. Exempel: Ett inloggningsformulär som saknar skydd mot kodinjektion.
- Kodskanning (SAST): Analyserar källkoden under utveckling. Exempel: Hårdkodade lösenord i en konfigurationsfil.
- Molnskanning: Granskar molnmiljöer (AWS, Azure). Exempel: En S3-bucket med känsliga filer som är publikt läsbar.
Så fungerar det i praktiken
En skanner fungerar som en digital besiktningsman. Den har en enorm databas med kända fel och testar era system mot denna.
Processen ser oftast ut så här:
- Upptäck: Skannern kartlägger vad som finns på nätverket (servrar, skrivare, laptops).
- Skanna: Den skickar förfrågningar till enheterna för att se versionsnummer och svar. Exempel: "Är du Apache version 2.4.49?"
- Analys: Den matchar svaren mot sin databas av sårbarheter.
- Rapportering: Ni får en lista på vad som måste fixas.
Så verifierar ni falska positiva resultat
Ett falskt positivt resultat betyder att skannern rapporterar en sårbarhet som inte finns, exempelvis för att den tolkar ett versionsnummer fel trots att säkerhetsfixen har bakporterats.
En verklig sårbarhet bakom en brandvägg är däremot inte ett falskt positivt resultat. Brandväggen kan minska exponeringen; ni behöver dokumentera skyddet och bedöma kvarstående risk.
Kontrollera vilken produkt och version fyndet gäller, vilken testmetod skannern använde och vad leverantörens säkerhetsmeddelande säger. Spara underlaget om ni avfärdar ett fynd. En notering som bara säger ”falskt larm” gör nästa granskning svår och kan dölja en verklig brist.
Autentiserad och oautentiserad skanning
En oautentiserad skanning visar vad verktyget kan se utan att logga in. En autentiserad skanning använder ett konto för att också undersöka exempelvis installerade paket och säkerhetsinställningar. Metoderna ger olika insyn: ett system som ser rent ut från utsidan kan fortfarande ha brister som upptäcks först vid inloggning. NIST:s vägledning om tekniska säkerhetstester beskriver skillnaden.
Bestäm omfattning, behörigheter och testfönster med systemägaren. Kontrollera att skanningskontot faktiskt fungerade; misslyckad inloggning är en lucka i täckningen. För känsliga driftmiljöer behöver ni även bedöma hur testerna kan påverka tillgängligheten.
Prioritera med CVSS och verksamhetens risker
CVSS beskriver en sårbarhets allvarlighet på en skala 0–10: låg 0,1–3,9, medel 4,0–6,9, hög 7,0–8,9 och kritisk 9,0–10,0.
Grundpoängen är inte hela er riskbedömning. Väg också in internetexponering, aktivt utnyttjande, berörd information och konsekvensen av avbrott. Se FIRST:s vägledning om allvarlighet och risk. Tilldela ansvarig, sätt ett åtgärdsdatum och skanna igen för att verifiera rättningen.
Exempel: Ni har två verifierade fynd. Det ena berör en intern testserver utan känsliga uppgifter, det andra en internetexponerad tjänst som används för att administrera produktionen. Om det andra fyndet dessutom utnyttjas aktivt kan det behöva hanteras först, även om testserverns grundpoäng är högre. Kontrollera aktivt utnyttjande i exempelvis CISA:s KEV-katalog och leverantörens säkerhetsmeddelanden. Avsaknad av en katalogpost bevisar inte att en sårbarhet är ofarlig.
Om en patch saknas kan ni behöva begränsa åtkomsten eller stänga den berörda funktionen tillfälligt. Dokumentera vad begränsningen skyddar mot, vem som ansvarar och när beslutet ska omprövas. För misstänkt intrång behöver ni även aktivera er incidenthantering.
Från skanningsfynd till verifierad rättning
För varje prioriterat fynd behöver ni kunna följa arbetet:
- Verifiera: Ange berörd tillgång, fynd eller CVE och underlaget som bekräftar bristen.
- Besluta: Dokumentera prioritet, ansvarig och åtgärdsdatum utifrån exponering och möjlig skada.
- Åtgärda: Registrera patch, konfigurationsändring eller tillfälligt skydd och eventuella undantag.
- Kontrollera: Skanna igen och testa att tjänsten fungerar. Markera fyndet som rättat först när kontrollen ger stöd för det.
Följ upp försenade åtgärder och system som inte kunde skannas. Antalet fynd kan minska för att en server saknas i skanningen, så jämför även täckningen mellan körningar.
Krav på sårbarhetshantering
- PCI DSS: En branschstandard för kortuppgiftssäkerhet, inte en allmän lag. Tillämpliga skanningskrav beror på er kortuppgiftsmiljö och valda validering. Krav 11.3 omfattar återkommande intern och extern skanning; kvartalsvisa externa skanningar utförs av en ASV. Kontrollera PCI SSC:s vägledning.
- NIS2: Verksamheter som omfattas ska hantera sårbarheter och utvärdera säkerhetsåtgärder enligt artikel 21. Direktivet föreskriver inte ett gemensamt skanningsintervall för alla.
- ISO 27001: Kontroll A.8.8 gäller hantering av tekniska sårbarheter. Bedöm hur kontrollen ska tillämpas inom ert ledningssystem och dokumentera arbetet.
- GDPR: Artikel 32 kräver säkerhet som är lämplig för risken med personuppgiftsbehandlingen. Skanning kan vara en del av skyddet, men är inte ensam ett bevis på efterlevnad.
Sammanfattning
Sårbarhetsskanning är inte en engångsinsats utan en löpande process. Den hjälper er att hitta kända fel, bedöma vilka som är viktigast och verifiera rättningar. Dokumenterade resultat kan stödja uppföljningen av säkerhetskrav, men bevisar inte ensamma efterlevnad. Kombinera regelbunden skanning med manuell tolkning och periodiska penetrationstester för bästa resultat.
Vanliga frågor
Vad skiljer skanning från penetrationstest?
Skanning söker brett efter kända svagheter med automatiserade tester. Ett penetrationstest undersöker hur svagheter kan utnyttjas och kombineras inom en avtalad omfattning. Metoderna kompletterar varandra; välj testdjup och intervall utifrån risker och krav.
Hur ofta ska vi skanna?
Bestäm intervallet utifrån exponering, förändringstakt och gällande krav. Internetexponerade system kan behöva tätare skanning; integrera kod- och beroendeskanning i byggflödet. Gör extra kontroller vid större ändringar eller larm om relevanta kritiska sårbarheter.
Räcker det med gratisverktyg?
Verktyg med öppen källkod kan räcka om de täcker miljön och ni kan tolka resultaten. Jämför täckning, uppdateringar, autentiserad skanning, rapportering och support. Ett betalverktyg ger inte automatiskt färre falska larm eller bättre skydd.
