# Hva er sårbarhetsskanning, og hvordan gjør dere det riktig

> En sårbarhetsskanning finner kjente sikkerhetshull i systemene dere peker den mot. Her er hva den ser, hva den ikke ser, og hvordan dere prioriterer.

Source: https://fmcybersecurity.com/insights/exposure/hva-er-sarbarhetsskanning/
Locale: Norwegian (nb-NO)
Other locale: https://fmcybersecurity.com/en/insights/exposure/what-vulnerability-scanning-is/

## Metadata

- Date: 2026-07-29
- Author: anders-helgesplass
- Topic: exposure
- Format: guide
- Partner: tenable

En sårbarhetsskanning forteller hvilke kjente sikkerhetshull som ligger i systemene dere peker den mot. Her er hvordan dere kjører den slik at dere sitter igjen med en arbeidsliste og ikke en PDF.

Jeg kjører Tenable for kundene til FM CyberSecurity, og de samme tre feilene går igjen i nesten hver eneste førstegangsskanning: ingen innlogging, ingenting utenfor brannmuren, og en rapport sortert etter alvorlighetsgrad. Alle tre lar seg rette på en ettermiddag.

## 1. Hva en sårbarhetsskanning finner, og hva den aldri ser

En sårbarhetsskanning sammenlikner programvaren på systemene deres mot en database over kjente feil, og lister opp treffene. Databasen er hele poenget. [Nessus](/insights/exposure/hva-er-nessus/), motoren under alle Tenable-produktene, får nye plugins fra Tenable hver dag.

Skanningen er god på manglende sikkerhetsoppdateringer, programvare som har gått ut på dato, svak konfigurasjon, standardpassord og tjenester som lytter på porter ingen husker at de åpnet. Nettopp disse sikkerhetshullene blir utnyttet i stor skala, for en angriper finner dem uten å vite noe som helst om virksomheten deres.

Skanningen ser derimot ikke en logikkfeil i applikasjonen deres egne utviklere har skrevet. Den ser ikke en angriper som allerede er inne og bruker gyldige brukerkontoer. Den sier ingenting om hvorvidt en sårbar server i det hele tatt er tilgjengelig fra et sted som betyr noe. Og den kan ikke rapportere en feil som ennå ikke har fått en signatur.

Skriv ned begge listene før dere kjøper noe. Halvparten av skuffelsen over skanning kommer av at folk forventer at den skal dekke liste nummer to.

## 2. Gi skanneren innlogging, ellers får dere en pyntet rapport

Uten innlogging ser skanneren systemene deres slik en fremmed på nettverket ser dem, og det synet er tynnere enn de fleste tror. Tenable sier det rett ut i egen dokumentasjon: en skanning uten brukerkonto klarer ikke å avdekke lokale svakheter på maskinen, og deler av det den rapporterer bygger på banner-informasjon som "may be inconclusive or incorrect" ([Tenable om credentialed checks](https://docs.tenable.com/nessus/Content/NessusCredentialedChecks.htm)).

Banner-lesing er kjernen i problemet. Skanneren spør tjenesten hvilken versjon den er, og tror på svaret. Linux-distribusjoner legger inn sikkerhetsfikser uten å endre versjonsstrengen, så en ferdig oppdatert server kan se sårbar ut. Samtidig ligger et sårbart bibliotek på disk uten å annonsere noe som helst, og da ser serveren ren ut.

Derfor blir resultatet uten innlogging for pent. Mesteparten av flaten, altså installerte pakker, registerinnhold, lokale rettighetsproblemer og manglende tredjepartsoppdateringer, er ikke synlig fra nettverket i det hele tatt.

Sett opp en egen skannekonto: en domenekonto med lesetilgang for Windows, en SSH-nøkkel med sudo for Linux. Kjør så samme omfang på nytt med innlogging, og sammenlikn de to tallene. I gjennomgangene jeg kjører, er listen med innlogging alltid den lengste, som regel med god margin.

## 3. Ekstern sårbarhetsskanning viser det angriperen ser først

Ekstern sårbarhetsskanning betyr at dere skanner alt deres som svarer fra internett, utenfra og inn. Webservere, VPN-portaler, e-postservere, en brannmurkonsoll noen glemte å stenge, et testmiljø på en sky-IP fra 2023.

Dette er åpningsbildet angriperen har. De starter ikke inne i nettverket deres, de starter med det som svarer på en offentlig adresse. Tenable kjører denne typen skanning fra egne skyskannere som selskapet vedlikeholder selv, så dere slipper å sette opp noe i eget serverrom ([Tenable cloud sensors](https://docs.tenable.com/vulnerability-management/Content/Settings/Sensors/CloudSensors.htm)).

En intern skanning svarer på noe annet: hvis noen først kommer seg inn, hvor langt kommer de da. Begge deler trengs, og de finner ulike ting. Systemer mot internett er gjerne godt oppdatert og dårlig konfigurert. Interne systemer er ofte motsatt.

Fella i ekstern sårbarhetsskanning heter oversikt. Dere kan ikke skanne en IP-adresse dere ikke vet at dere eier, og det er de glemte systemene som svir. Start med å hente ut alle offentlige IP-serier og alle DNS-soner selskapet kontrollerer, og skann hele bunken, også det ingen vil vedkjenne seg.

## 4. Skann hver uke, ikke hvert kvartal

En kvartalsvis skanning gir et kvartalsstort etterslep, og køen er for lang til å jobbe med allerede fra første dag. Kvartalsvis skanning dekker et compliance-krav og fungerer dårlig som sikkerhetsrytme. Tenable skriver kravet rett ut i sin egen PCI-veiledning: "PCI Requirement 11.3.1 makes vulnerability scanning mandatory at least once every three months, and recommends more frequent scanning depending on network complexity" ([Tenable om PCI DSS](https://docs.tenable.com/cyber-exposure-studies/pci-dss/Content/Overview.htm)).

Regn på det. Et kvartal rommer tre runder med Microsoft-oppdateringer, pluss alle andre leverandørvarsler som kom i løpet av nitti dager. Alt sammen lander i samme rapport. Ingen jobber seg gjennom en liste av den størrelsen, så den blir barbert ned til "bare kritiske", og resten blir aldri rørt. Neste kvartal skjer det samme oppå det som ble liggende.

Ukentlig skanning gir dere endringen siden sist, ikke hele haugen på nytt. Ti eller tjue nye funn i uka er en oppgaveliste. To tusen er et arkivproblem.

Sett det opp slik: intern skanning med innlogging hver uke, ekstern skanning hver uke, og en kontrollskanning av samme omfang innen en uke etter hvert oppdateringsvindu. Det siste punktet betyr mer enn folk tror, for "vi har oppdatert" og "skanningen er ren" er to forskjellige påstander.

## 5. Sorter etter utnyttelse, ikke etter alvorlighetsgrad

CVSS forteller hvor ille en feil ville vært hvis noen utnyttet den. Den sier ingenting om hvorvidt noen kommer til å gjøre det. FIRST, som eier standarden, skriver det inn i spesifikasjonen for CVSS 4.0: brukerne bør supplere basismålene med trussel- og miljøverdier "specific to their use of the vulnerable system" før tallet brukes som risikoinngang ([CVSS 4.0-spesifikasjonen](https://www.first.org/cvss/v4.0/specification-document)).

To offentlige kilder tetter det hullet, og begge er gratis.

EPSS, også fra FIRST, gir hver CVE en daglig sannsynlighet for å bli utnyttet i praksis de neste 30 dagene. FAQ-en setter grunnraten i perspektiv: i et hvilket som helst 30-dagersvindu ser EPSS utnyttelsesaktivitet på omtrent 2,5 til 3 prosent av publiserte CVE-er ([EPSS FAQ](https://www.first.org/epss/faq)). De aller fleste sårbarheter blir aldri utnyttet av noen.

Katalogen Known Exploited Vulnerabilities fra CISA er den bekreftede listen: 1662 CVE-er i katalogversjon 2026.08.07 ([CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)). FIRST oppgir at KEV dekker rundt 0,5 prosent av alle publiserte CVE-er.

Et forbehold hører med. Ikke gang EPSS med CVSS for å lage ett samletall. FIRST skriver rett ut at det aldri er en god idé, for de to måler ulike ting.

CISAs egen retningslinje BOD 26-04 setter rekkefølgen amerikanske føderale etater må følge, og modellen holder mål også utenfor USA. Tre spørsmål: er systemet tilgjengelig fra internett, står CVE-en på KEV, og kan angriperen automatisere utnyttelsen. Svarene styrer frister på tre, fjorten eller seksti dager ([BOD 26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)).

Køen deres, i rekkefølge: KEV-funn på systemer mot internett, deretter høy EPSS på de samme systemene, så kritiske og høye CVSS-funn internt, og resten på en fast oppdateringssyklus.

## 6. Slik blir skanning til sårbarhetshåndtering

Skanning produserer funn. Sårbarhetshåndtering lukker dem, og lukkingen er den delen ingen verktøy gjør for dere.

Et program legger til fem ting skanningen ikke dekker: en oversikt over systemer, slik at dere vet hva som burde vært skannet og oppdager når noe faller ut; en navngitt ansvarlig per system, slik at funnene har et sted å gå; en frist per prioritetsnivå, avtalt med virksomheten og ikke funnet på av IT; en avviksprosess med utløpsdato, slik at akseptert risiko blir vurdert på nytt i stedet for glemt; og en kontrollskanning som beviser at rettingen traff.

Her kommer også plattformspørsmålet inn. [Tenable One Vulnerability Management](/insights/exposure/nessus-vs-tenable-vm-vs-tenable-one/), tidligere kalt Tenable Vulnerability Management, holder på historikken, rollene og trendlinjen som en frittstående skanner ikke tar vare på. Er dere usikre på begrepene, har vi skrevet om [hva som skiller exposure management fra sårbarhetshåndtering](/insights/exposure/exposure-og-sarbarhetshandtering/).

NSM har med å oppdage og fjerne kjente sårbarheter som et av grunnprinsippene for IKT-sikkerhet (prinsipp 3.1), og norske revisorer spør hvordan dere gjør det ([NSMs grunnprinsipper](https://nsm.no/regelverk-og-hjelp/grunnprinsipper/grunnprinsipper-for-ikt-sikkerhet)). En skannerapport svarer på halve spørsmålet. Sløyfa svarer på resten.

## Neste steg

Kjør en intern skanning med innlogging og en ekstern sårbarhetsskanning av alle offentlige IP-adresser dere eier, og legg de to resultatlistene ved siden av hverandre. Den sammenlikningen avgjør som regel de neste seks månedene med arbeid.

Anders Helgesplass kjører Tenable hos FM CyberSecurity. Ta direkte kontakt gjennom [praksisen vår for sårbarhetshåndtering](/services/vulnerability-management/) hvis dere vil ha en ekstra vurdering av skanneresultatet, eller se hvordan vi kjører [kontinuerlig sårbarhetshåndtering](/services/exposure-management/) som en tjeneste vi tar oss av. Vi setter opp plattformen, brukerkontoene og tuningen selv, så rådet kommer fra dem som ville kjørt den. FM CyberSecurity er sertifisert partner på [Tenable](/partners/tenable/) i Norge.

## FAQ

### Hvor ofte bør vi kjøre sårbarhetsskanning?

Ukentlig, både internt og eksternt, med en kontrollskanning etter hvert oppdateringsvindu. Kvartalsvis møter gulvet i PCI DSS og lite annet: tre måneder med leverandørvarsler kommer i samme rapport, og etterslepet vokser fortere enn teamet klarer å ta unna. Er ukentlig urealistisk nå, start med ukentlig ekstern sårbarhetsskanning og månedlig intern skanning med innlogging, og stram inn derfra.

### Trenger vi ekstern sårbarhetsskanning når vi allerede skanner internt?

Ja, for de svarer på hver sin ting. En intern skanning forutsetter at angriperen allerede er inne. En ekstern sårbarhetsskanning viser hva angriperen ser før de kommer inn, altså den flaten de prøver seg på først. Ekstern skanning fanger dessuten opp systemer som har falt ut av oversikten: et gammelt subdomene, en testmaskin på en sky-IP, en administrasjonsside som skulle vært midlertidig.

### Kan skanning ødelegge noe?

Sjelden, og sjeldnere med innlogging enn uten. Skanning med brukerkonto leser stort sett lokal tilstand og er mildere enn å banke på porter utenfra. Gammelt eller skjørt utstyr, enkelte skrivere, noe industriutstyr og eldre nettverksbokser, kan reagere dårlig på aggressiv portskanning. Dem tar dere med en egen skanneprofil som utelater de risikable plugin-familiene, og et vedlikeholdsvindu på første kjøring.

### Førstegangsskanningen ga tusenvis av funn. Hvor begynner vi?

Sorter etter utnyttelse, ikke etter alvorlighetsgrad. Ta først alt som står på KEV-listen til CISA og ligger på et system mot internett. Deretter høy EPSS på de samme systemene. Så kritiske og høye CVSS-funn internt. Grupper resten etter rettingen i stedet for etter funnet: en operativsystemoppdatering lukker gjerne flere hundre rader samtidig, så tell oppdateringer i stedet for CVE-er, da ser jobben ut som det den er.

### Er sårbarhetsskanning det samme som en pentest?

Nei. En skanning er automatisk, dekker alt dere peker den mot, og rapporterer kjente sikkerhetshull. En pentest handler om å koble funn sammen til en fungerende vei inn, altså hvilke svakheter som betyr noe i kombinasjon. Skanning er den ukentlige hygienen. Pentest er den jevnlige kontrollen av om hygienen holder. De fleste trenger begge deler, og skanningen bør komme først, for det er lite poeng i å betale noen for å finne en manglende sikkerhetsoppdatering dere kunne funnet selv.

---

For the full documentation index, see https://fmcybersecurity.com/llms.txt
For the complete corpus as a single document, see https://fmcybersecurity.com/llms-full.txt