# Hvorfor vi valgte Tenable for sårbarhetshåndtering

> Vi standardiserte på Tenable fordi styret kjøper ett risikobilde knyttet til kontraktene, ikke nok en CVE-liste ingen rekker å lese.

Source: https://fmcybersecurity.com/insights/exposure/hvorfor-vi-valgte-tenable/
Locale: Norwegian (nb-NO)
Other locale: https://fmcybersecurity.com/en/insights/exposure/why-we-picked-tenable-for-exposure-management/

## Metadata

- Date: 2026-04-28
- Author: anders-helgesplass
- Topic: exposure
- Format: article
- Partner: tenable

Vi standardiserte på [Tenable](/partners/tenable/) fordi styret er den reelle kjøperen av sårbarhetsarbeidet, og styret trenger ett kart over forretningsrisikoen, ikke en liste med CVE-er. Det er hele grunnen. Resten av teksten forklarer hvordan jeg kom dit fra kontraktssiden av bordet.

På tvers av compliance- og risikooppdragene jeg har rådgitt i år, lyder spørsmålet som lander i styret aldri "hvor mange sårbarheter har dere". Det lyder "hvilke av dem kan ramme kontrakten dere nettopp signerte". I et sammensatt oppdrag med et norsk SaaS-foretak som jaget en ISO 27001-sertifisering for å låse opp et enterprise-anbud, leverte det tekniske teamet en skannerapport på 9 000 linjer til revisjonsutvalget. Styret leste tre sider og stilte det åpenbare spørsmålet: Hvilke av disse treffer kundedataene vi lovet å beskytte i kontrakten? Ingen hadde svaret. Skanneren hadde ikke fått det spørsmålet.

Det gapet skal eksponeringshåndtering lukke, altså sårbarhetshåndtering med utnyttbarhet på toppen. Det forklarer også hvorfor et rent CVE-listeverktøy sluttet å holde.

![Tenable-logo og Exposure Management, FM CyberSecurity](../../../assets/news/why-we-picked-tenable-for-exposure-management-inline.png)

## Hva folk griper etter først

Når en norsk små- eller mellomstor virksomhet bestemmer seg for å ta sårbarhetsarbeid på alvor, går første trekk som regel ut på å kjøpe en skanner og kjøre den månedlig. Sett opp [Nessus](/insights/exposure/hva-er-nessus/) på nettverket, planlegg en skanning, arkiver rapporten. Logikken virker fornuftig. Revisor ba om sårbarhetsskanning, og nå har dere sårbarhetsskanning.

Gapet ligger ikke i skanneren. Nessus gjør det som står på pakken. Gapet ligger i at en skanner alene produserer en flat liste med funn, sortert etter Common Vulnerability Scoring System (CVSS), uten oversikt over hvilke av funnene som sitter på systemene som bærer kontraktsforpliktelsene deres. CVSS måler teknisk alvorlighet abstrakt. Skanneren vet ikke hvilken server som kjører lønnssystemet dere lovet største kunde 99,9 prosent oppetid på.

Det ærlige spørsmålet er altså ikke "hvilken skanner". Det er "hvem gjør denne listen om til en beslutning styret kan handle på, og opp mot hvilke kontrakter". Kjøper dere en skanner uten å svare på det, ender dere opp med et pent revisjonsfunn og en misfornøyd økonomidirektør den dagen noe går galt på et system ingen hadde prioritert.

## Hvorfor plattformen forsvarer valget

Tenable forsvarer valget på to ting jeg ser fra kjøpersiden av bordet: skanneren under, og plattformen rundt.

Skanneren er Nessus, og den delen er sjelden verdt å krangle om. Nessus har vært den fungerende skanneren i norske sikkerhetsteam i to tiår. Revisorene kjenner den igjen, penetrasjonstesterne bruker den, og de fleste andre sårbarhetsverktøy ender opp med å måle seg mot den. Gjeldende SKU-er er Nessus Essentials, Nessus Professional og Nessus Expert ([per Tenables lisensieringsguide](https://docs.tenable.com/quick-reference/licensing-guide/Content/tenable-nessus-licensing.htm)). Det fundamentet er solid, men det er ikke der differensieringen ligger.

Differensieringen ligger i det som omslutter skanneren. Tenables paraplyplattform, [Tenable One](https://www.tenable.com/products/tenable-one), samler sårbarhetsfunn, webapplikasjonsfunn, skyfeilkonfigurasjoner, identitetseksponering, angrepsoverflatefunn og data fra operasjonell teknologi i ett risikobilde. Tenable endret navn på Tenable.io til Tenable Vulnerability Management i 2023 som del av overgangen til beskrivende produktnavn, og Tenable Vulnerability Management er modulen som ligger inne i Tenable One ([Tenable, 2023](https://www.tenable.com/blog/tenable-product-name-changes-and-the-evolution-of-the-tenable-brand)). Poenget med paraplyen er ikke teknologien. Poenget er at styret får ett kart.

Jeg har skrevet om hvordan Nessus, Tenable Vulnerability Management og Tenable One henger sammen i [sammenligningen vår av de tre](/insights/exposure/nessus-vs-tenable-vm-vs-tenable-one/). Kortversjonen: Nessus er skanneren, Tenable Vulnerability Management er det skybaserte sårbarhetsprogrammet, og Tenable One legger perspektivene på webapp, sky, identitetseksponering og angrepsoverflate oppå.

Identitetseksponeringsmodulen er verdt å være presis om. Den kartlegger risiko i konfigurasjonen av Active Directory og Entra ID, altså overprivilegerte kontoer, svake passordpolicyer og feilkonfigurerte tillitsrelasjoner. Det handler om eksponeringssynlighet på identitet, ikke om identitetshåndtering. FM CyberSecuritys identitetspraksis kjører på CyberArk for privilegert tilgang. Tenable Identity Exposure forteller hvor eksponeringen sitter. CyberArk er hvordan dere kontrollerer den. Annet problem, annet verktøy.

## Hva FM CyberSecurity gjør

FM CyberSecurity drifter Tenable ende-til-ende for foretakene vi jobber med. Vi videreselger det ikke. Vi står for utrullingen, finjusteringen av skannepolicyene, merkingen som knytter funn til forretningssystemer, og styrerapporteringen som gjør plattformens utdata om til en kvartalsvis risikosamtale.

Den lite glamorøse delen er merkingen. I et sammensatt oppdrag innen [sårbarhetshåndtering](/services/assessments/) dette kvartalet returnerte første skanning rundt 4 200 funn på tvers av et estate på 250 enheter. Sortering på CVSS Critical og High tok det ned til 380. Da vi merket enhetene opp mot de fire kritiske forretningssystemene som var navngitt i foretakets største kundekontrakt, satt vi igjen med 41 funn på kontraktsbærende infrastruktur. Det var tallet revisjonsutvalget handlet på. De andre 4 159 ligger fortsatt i plattformen, blir fortsatt jobbet gjennom, men det er ikke det styret leser.

Den andre halvdelen er rapporten. Hvert kvartal får foretakene vi kjører Tenable for, et kort dokument som navngir eksponeringstrenden på kontraktskritiske systemer, ny eksponering på systemer som kom i drift det kvartalet, og hvert punkt som krysser en terskel styret har avtalt å eskalere på. Ikke 9 000 linjer. Tolv sider, ofte færre. Styret rekker å lese det på vei inn i møtet.

## Hva dette betyr for dere

Sitter dere som sikkerhetsansvarlig eller daglig leder i en norsk små- eller mellomstor virksomhet, blir konklusjonen smal. Beslutningen står ikke om "skal vi kjøre sårbarhetsskanninger". Den står om "hvem i rommet gjør skannerens utdata om til ett risikokart som styret, revisor og største kunde leser likt".

Tenable oppdager og prioriterer eksponering på tvers av endepunkter, webapplikasjoner, skyarbeidslaster, identitetsflater og angrepsoverflater, Tenable One presenterer det som ett risikokart, og FM CyberSecurity merker enhetene, finjusterer skanningene og skriver styrenotatet. Derfor valgte vi det. Vi ber ikke styret om å lese en CVE-liste.

Hvis dette treffer:

- Les [hva Nessus er i Tenable-porteføljen](/insights/exposure/hva-er-nessus/) for skanner-perspektivet bak plattformen.
- Send dette videre til økonomidirektøren eller compliance-ansvarlig, altså de som allerede kjenner kontraktspresset, men kanskje ikke ser hva skanneren produserer.
- Ta direkte kontakt med Anders for en samtale på 30 minutter om sårbarhetsprogrammet deres, og hvor gapet mellom skannerens utdata og styrebeslutningen sitter i dag.

---

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
