# Slik kjører vi første sårbarhetsanalyse i Tenable One > To uker, dag for dag, fra avgrensningssamtale til forsvarlig baseline i Tenable One hos en ny norsk SMB-kunde. Source: https://fmcybersecurity.com/insights/exposure/forste-sarbarhetsanalyse-i-tenable-one/ Locale: Norwegian (nb-NO) Other locale: https://fmcybersecurity.com/en/insights/exposure/first-vulnerability-assessment-in-tenable-one/ ## Metadata - Date: 2026-05-26 - Author: anders-helgesplass - Topic: exposure - Format: guide - Partner: tenable Her er det to-ukers oppdraget FM CyberSecurity kjører på [Tenable One](/partners/tenable/) når en ny norsk SMB-kunde skal gjennom førstegangsskanningen sin, dag for dag. Poenget med første skann er en forsvarlig baseline, ikke en lang PDF. ![Tenable-logo og First Assessment, FM CyberSecurity](../../../assets/news/first-vulnerability-assessment-in-tenable-one-inline.png) ## 1. Avgrensningssamtale, dag 1 Vi starter med et tretti minutters møte for å bli enige om hva som skal skannes. Første spørsmål er hvilke systemer som bærer kontraktsforpliktelser: e-postplattformen, filområdene, kundewebappen, skyworkloadene, Active Directory. Disse er omfattet av oppdraget. Laben med den gamle printserveren i kroken faller utenfor, så fremt ingen fortsatt kan logge inn på den. Ut av møtet kommer dere med en én-siders avgrensning: interne IP-rekker, offentlige domener, sky-kontoer, AD-skoger, og en navngitt kontakt hos dere som kan svare på spørsmål mens skannet pågår. ## 2. Asset-oppdagelse, dag 2 til 3 De fleste SMB-er vi jobber med, klarer ikke å liste opp eiendelene sine uten et oppdagelsessveip. Derfor kjører vi en lett oppdagelsesrunde først, slik at selve skannet ikke bommer på noe åpenbart. På interne rekker henter vi fra DHCP, fra AD, og et lett ping-sveip. På utsiden henter vi det angripere ser: sertifikatlogger, DNS, og de offentlige IP-ene leverandøren har tildelt dere. Resultatet blir en arbeidsliste over eiendeler med ansvarlige. Klarer dere ikke å peke ut en ansvarlig for et system, blir nettopp det systemet det første funnet, før noe skanneverktøy starter. ## 3. Oppsett av Tenable One-tenant, dag 3 Vi etablerer [Tenable One](/partners/tenable/)-tenanten under FM CyberSecuritys partnerkonto og legger til de navngitte brukerne deres med riktige roller. Intern skanning kjører gjennom én eller to Tenable Nessus-skannere som vi setter opp i nettet deres (virtuell appliance eller container). Ekstern skanning kjører fra Tenables sky. Sky-workloads kobles inn via native koblinger mot AWS, Azure eller Google Cloud, kun lesetilgang i denne fasen. Er Active Directory omfattet, installerer vi Tenable Identity Exposure-kollektoren mot en lesetilgang-konto på en domenekontroller. Identity Exposure synliggjør konfigurasjonsrisiko i AD, men er ikke et identitetshåndteringsverktøy. Kjører dere allerede CyberArk på toppen, utfyller de to hverandre. ## 4. Førstegangsskann, dag 4 til 7 Vi setter i gang fire skann parallelt, dimensjonert til avgrensningen deres: - Internt autentisert sårbarhetsskann mot IP-rekkene i avgrensningen, med en skannekonto som har minst mulig rettigheter. - Eksternt uautentisert skann mot offentlige IP-er og domener. - Webapplikasjonsskann mot de kundevendte appene dere har navngitt. - Cloud Security og Identity Exposure kjører kontinuerlig så snart de er tilkoblet, slik at første avlesning lander samme uke. Autentiserte skann er det som teller. Et uautentisert skann finner versjonsbanneret. Et autentisert skann finner Windows-patchen som mangler bak det. Forskjellen i signal mot støy mellom de to avgjør om første rapport blir brukbar. ## 5. Støy-passet, dag 8 Råutdata er høyt. Et førstegangsskann mot et reelt nett produserer tusenvis av funn, og de fleste skal dere ikke rette først. Derfor kjører vi et støy-pass før noen ser dataene: - Slå sammen duplikate funn på tvers av skannere. - Merk kjente interne verktøy (jumphost, overvåkingsagenter, backup-appliancen) slik at forventet oppførsel ikke leses som risiko. - Demp funn som allerede er motvirket av en kompenserende kontroll vi kan verifisere. - Marker alt som trenger leverandørunntak, med begrunnelse skriftlig. Da står den reelle listen igjen. ## 6. Bedriftskontekst-merking, dag 9 En CVSS-score vet ikke hvilken av serverne deres som kjører lønn. Derfor merker vi hver eiendel mot de kontraktsbærende systemene fra steg 1: lønn, kundedata, e-handelsstacken, HR-systemet. Tenable One bruker disse merkene til å løfte funn som treffer disse systemene, over resten. Resultatet blir en prioritert visning: kritiske funn på kontraktsbærende systemer øverst, deretter utnyttbare funn på støttesystemer, så alt annet. Styret leser første kutt. Operatørene jobber med det andre. ## 7. Funnsgjennomgang, dag 10 En arbeidsøkt på halvannen time med IT-lederen deres og én forretningsansvarlig per kritisk system. Vi går gjennom toppfunnene, blir enige om hva som er reelt, hva som trenger leverandørunntak, og hva som må rettes. Der dere og vi er uenige om alvorlighet, markerer vi det og kommer tilbake til det. To leveranser kommer ut av møtet: en liste over tiltak med navngitte ansvarlige og målfrister, og en kort liste over kompenserende kontroller vi godtar mens en rettelse pågår. ## 8. Overleveringsdokument, dag 11 til 12 Dere får en skriftlig overlevering. Den er kort med vilje: - Avgrensning, hva som ble skannet og hva som ikke ble det. - Eiendelsoversikt med ansvarlige og forretningsmerker. - Toppfunn etter forretningsvirkning, med ansvarlige og frister for retting. - Unntak og kompenserende kontroller, med begrunnelse skriftlig. - Tenant-konfigurasjonen vi etterlater i drift: skannere, koblinger, skannevinduer, brukerroller. - Første baseline med målepunkter: antall kritiske og høye funn totalt, gjennomsnittsalder, andel eiendeler med ansvarlig. Overleveringen leser revisoren, og styret spør om den neste kvartal. ## 9. Hva endrer seg fra første skann til løpende program Første skann er en engangshandling. Det løpende programmet som følger, er det ikke. Vi går over til ukentlige interne skann, daglige eksterne og sky-avlesninger, og månedlig funnsgjennomgang. Baseline fra steg 8 blir trendlinjen. For hvordan vi kjører det løpende programmet, se [hvordan vi kjører sårbarhetsprogrammet i Tenable One](/insights/exposure/sarbarhetsprogrammet-i-tenable-one/). For selve plattformvalget, se [hvorfor vi valgte Tenable for eksponeringshåndtering](/insights/exposure/hvorfor-vi-valgte-tenable/) og sammenligningen [Nessus mot Tenable Vulnerability Management mot Tenable One](/insights/exposure/nessus-vs-tenable-vm-vs-tenable-one/). ## Neste steg Ta direkte kontakt med Anders i [FM CyberSecuritys assessments-praksis](/services/assessments/) for en avgrenset første sårbarhetsanalyse i Tenable One. Vi kommer tilbake med en skriftlig avgrensning, en tenant-konfigurasjon, og en forsvarlig baseline dere kan legge fram for revisor eller styre. ## FAQ ### Hvor mye tilgang trenger dere fra oss for å kjøre første skann? For intern skanning trenger vi en skannekonto med minst mulig rettigheter på Windows- og Linux-eiendelene, og en rute fra en Nessus-skanner inn til IP-rekkene i avgrensningen. For ekstern skanning trenger vi de offentlige IP-rekkene og domenene deres, ingen tilgang utover det. For sky trenger vi en lesetilgang-rolle i hvert abonnement eller prosjekt. For Active Directory trenger vi en lesetilgang-konto på en domenekontroller. Vi dokumenterer hver tilgang vi bruker, med en utløpsdato, og fjerner den når oppdraget er ferdig hvis dere ber om det. ### Hvor lang tid tar første skann, ende til ende? To uker fra avgrensningssamtalen til overleveringen, for en typisk norsk SMB med ett eller to lokasjoner, én sky-tenant og én AD-skog. Dag 1 er avgrensningssamtalen, dag 2 til 3 er oppdagelse og tenant-oppsett, dag 4 til 7 er skannene, dag 8 til 10 er støy-passet og gjennomgangsmøtet, dag 11 til 12 er overleveringen. Større eller fler-enhetlige avgrensninger legger på en uke. ### Hva sitter vi igjen med på slutten? En aktiv Tenable One-tenant konfigurert til miljøet deres, en eiendelsoversikt med ansvarlige og forretningsmerker, en prioritert tiltaksliste med navngitte ansvarlige og frister, en skriftlig oversikt over unntak og kompenserende kontroller, og en baseline med målepunkter dere kan vise styret og revisoren deres. ### Kan dere kjøre dette uten IT-nedetid? Ja. Autentiserte sårbarhetsskann mot moderne Windows- og Linux-systemer er leseoperasjoner, og forårsaker ikke utfall på frisk infrastruktur. Vi planlegger skann i avtalte vinduer, struper skannehastigheten for å skåne lavkapasitetsutstyr, og pauser hvis overvåkingen deres reagerer. Webapp-skann mot et produksjonsmiljø er stedet der vi legger planen rundt et stagemiljø eller et lavtrafikkvindu, etter avtale. ### Skanner dere identitetssystemene våre i første analyse? Er Active Directory omfattet av avgrensningen, så ja, gjennom Tenable Identity Exposure. Det synliggjør konfigurasjonsrisiko i AD: gamle admin-kontoer, svake Kerberos-innstillinger, risikable delegeringer, og tillitsstier. Verktøyet oppdager AD-risiko, men er ikke et identitetshåndteringsverktøy. Kjører dere allerede CyberArk, utfyller Identity Exposure det, og dere håndterer privilegert tilgang gjennom CyberArk. Gjør dere ikke det, er funnene et nyttig innspill til PAM-samtalen. --- --- 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