Sårbarhetsanalyse: slik finner bedriften sikkerhetshullene

Geometrisk fremstilling av sikkerhetshull og analyse

En sårbarhetsanalyse er en gjennomgang av nettsiden, kildekoden, nettverket og skytjenestene deres. Målet er å finne svakhetene en angriper kan bruke, før noen faktisk gjør det. Analysen gir dere tre ting: en liste over hullene, en vurdering av hvor alvorlig hvert av dem er, og en plan for hva som rettes først. Under går vi gjennom hvordan dette gjøres i praksis, hva som skiller analysen fra en automatisk skanning, og hva en bedrift uten egen IT-avdeling bør avklare før den bestiller.

Clevo

Få sikkerhetshullene fulgt opp

Clevo identifiserer sikkerhetshull, forklarer funnene for ledelsen og bidrar direkte med konkrete tiltak for å forbedre bedriftens sikkerhet.

Se hvordan Clevo kan hjelpe

Kort oppsummert

En sårbarhetsskanning er et automatisk søk etter kjente svakheter. En sårbarhetsanalyse kombinerer flere verktøy med manuell vurdering og gir en prioritert tiltaksliste.
En nettside testes utenfra og innenfra: hva som er synlig på internett, hvordan innlogging og tilganger fungerer, og hvilke komponenter og avhengigheter koden bygger på.
Funnene rangeres etter teknisk alvorlighetsgrad (for eksempel CVSS) og etter hva de betyr for akkurat deres virksomhet.
Analysen er bare halve jobben. Hvert funn trenger en ansvarlig, en frist og en kontroll som bekrefter at hullet faktisk er tettet.
Skann jevnlig, og alltid før nye eller endrede systemer settes i drift.

Innholdsfortegnelse

Hva en sårbarhetsanalyse er, og hva den ikke er
Slik gjennomføres en sårbarhetsanalyse av en nettside
Sårbarheter i kildekoden
Nettverk, sky og interne systemer
Slik prioriteres funnene
Etter analysen: retting og kontroll
Hvor ofte bør dere skanne og analysere?
Før dere bestiller: dette bør avklares
Vårt syn: en analyse er bare verdt noe når hullene blir tettet
Få nettsiden og systemene testet
Ofte stilte spørsmål
Kilder

Hva en sårbarhetsanalyse er, og hva den ikke er

Søker du på ordet, får du mange treff om ROS-analyser, altså risiko- og sårbarhetsanalyser i planarbeid, beredskap og arrangementer. Det er beslektet, men noe annet. I IT-sikkerhet handler en sårbarhetsanalyse om de digitale systemene: hvor kan noen komme seg inn, hente ut data eller stanse driften?

Begrepene blandes ofte, så her er forskjellen kort forklart:

Metode	Hva den gjør	Hvordan	Hva dere sitter igjen med
Sårbarhetsskanning	Leter etter kjente svakheter i programvare og systemer	Automatiske verktøy	En lang liste med tekniske funn
Sårbarhetsanalyse	Kartlegger systemene, finner og vurderer svakheter	Flere verktøy kombinert med manuell gjennomgang	Prioriterte funn med konkrete tiltak
Penetrasjonstest	Prøver å utnytte svakhetene, slik en angriper ville gjort	Planlagt, manuelt angrep innenfor avtalte rammer	Bevis på hva som faktisk lar seg utnytte
ROS-analyse	Vurderer uønskede hendelser, sannsynlighet og konsekvens	Workshop og systematisk vurdering	Risikobilde og tiltaksplan for virksomheten

NVE beskriver i sin veileder sårbarhetsskanning som en automatisert prosess der et verktøy undersøker programvare, systemer eller komponenter for kjente svakheter en angriper kan utnytte. Det er et godt utgangspunkt, men et verktøy vet ikke hvilke data som er viktigst for dere, eller om et funn i praksis lar seg utnytte. Det er her analysen tilfører noe: noen som forstår både teknikken og virksomheten, ser på resultatene og sier hva som haster.

En penetrasjonstest går et steg lenger. Nasjonal sikkerhetsmyndighet beskriver inntrengingstesting som en planlagt og forhåndsbestilt operasjon som avdekker fysiske, logiske, tekniske, menneskelige og administrative sårbarheter. I praksis glir analysen og testen ofte over i hverandre. Mange bedrifter får mest igjen for en kombinasjon: bred kartlegging først, deretter dypere testing av det som betyr mest.

Slik gjennomføres en sårbarhetsanalyse av en nettside

Nettsiden og nettbutikken er det de fleste små og mellomstore bedrifter har mest eksponert mot internett. En grundig analyse følger som regel disse stegene:

Avgrensning. Hvilke domener, underdomener, innloggingsløsninger, API-er og tredjepartstjenester skal være med? Det skal være skriftlig avtalt hva som testes, når, og hvem som kan kontaktes hvis noe uventet skjer.
Kartlegging av angrepsflaten. Hva er synlig utenfra? Glemte testmiljøer, gamle innloggingssider, åpne administrasjonspaneler og utdaterte underdomener er blant de vanligste funnene.
Automatisk skanning. Verktøy leter etter kjente svakheter, utdaterte programtillegg, svak kryptering, manglende sikkerhetsheadere og feilkonfigurasjoner. NVE anbefaler å kombinere flere verktøy for å få et godt nok bilde, fordi ingen enkeltverktøy fanger alt.
Manuell testing. Her ser fagpersonen på logikken: kan en innlogget kunde se en annen kundes ordre ved å endre et tall i adressefeltet? Kan skjemaer misbrukes til å sende inn skadelig kode? Slike feil finner sjelden et verktøy alene.
Vurdering og prioritering. Hvert funn vurderes etter alvorlighetsgrad og etter hva det betyr for deres data og drift.
Rapport og tiltak. Ledelsen trenger en kort oppsummering. Utvikleren eller leverandøren trenger tekniske detaljer og en tydelig beskrivelse av hva som må gjøres.

Et nyttig rammeverk for den manuelle delen er OWASP Top 10:2025, oversikten over de mest kritiske sikkerhetsrisikoene i webapplikasjoner. Brudd på tilgangskontroll står øverst på listen, og feilkonfigurasjon kommer høyt. Det stemmer godt med hva man ofte finner på norske bedriftsnettsider: ikke avanserte angrep, men dører som står på gløtt.

Typiske funn på en bedriftsnettside

Publiseringsløsning eller programtillegg som ikke er oppdatert
Administrasjonssider som er åpne for hele internett uten totrinnsinnlogging
Kontaktskjemaer og søkefelt som ikke vasker inndata
Tilgangsfeil der én bruker kan se andres data
Feilmeldinger som avslører versjonsnumre og interne detaljer
Glemte sikkerhetskopier eller testfiler liggende på serveren

Vil dere ha nettsiden, appen eller systemene testet av folk som også retter det de finner, kan dere lese mer om vår sikkerhetstest av nettside og app.

Sårbarheter i kildekoden

Mye av risikoen ligger ikke i koden dere selv har skrevet, men i bibliotekene og pakkene den bygger på. En moderne nettside kan ha hundrevis av slike avhengigheter, og en svakhet i én av dem blir en svakhet hos dere.

Det finnes to hovedmåter å analysere kode på:

Statisk analyse (SAST) leser kildekoden og leter etter mønstre som gir sikkerhetshull, for eksempel uvasket inndata eller passord skrevet rett inn i koden.
Dynamisk analyse (DAST) tester den kjørende applikasjonen utenfra, slik en angriper ser den.

I tillegg kommer skanning av avhengigheter og containere. Et godt norsk eksempel er Digitaliseringsdirektoratets tekniske dokumentasjon for data.norge.no, som viser hvordan de bruker verktøy som Dependabot, pip-audit for Python, npm-audit for JavaScript og TypeScript, CodeQL via GitHub, et DAST-verktøy og Trivy for Docker-images. Poenget er ikke de konkrete navnene, men at flere lag av kontroll bygges inn i utviklingsløpet.

Automatikken fanger mye, men ikke logikkfeil. En manuell kodegjennomgang finner det verktøyene overser: feil i hvordan tilganger sjekkes, hvordan økter håndteres og hvordan data lagres. Bygger dere nytt, er det langt billigere å få sikkerheten riktig fra start enn å rette i ettertid. Det er tanken bak sikker utvikling og kodegjennomgang.

Nettverk, sky og interne systemer

Nettsiden er bare én dør. En sårbarhetstest av nettverket ser på resten av huset:

Eksterne tjenester: brannmur, VPN, fjernskrivebord og andre tjenester som svarer fra internett
Interne systemer: servere, skrivere, nettverksutstyr og maskiner som mangler oppdateringer
Sky og e-post: innstillinger i Microsoft 365 eller Google Workspace, delingsrettigheter, totrinnsinnlogging og beskyttelse mot falske avsendere
Brukere og tilganger: gamle kontoer etter ansatte som har sluttet, og administratorrettigheter som er gitt for bredt

For mange små bedrifter er skytjenestene og e-posten den største risikoen, fordi én overtatt konto gir tilgang til nesten alt. Det er derfor vi har en egen tjeneste for sikker sky og e-post.

Slik prioriteres funnene

En analyse kan gi alt fra en håndfull til flere hundre funn. Uten prioritering blir listen liggende. To verktøy brukes mye:

CVSS (Common Vulnerability Scoring System) gir hver sårbarhet en poengsum fra 0,0 til 10,0, basert på blant annet angrepsvei, kompleksitet, om det kreves brukerinteraksjon eller rettigheter, og konsekvens for konfidensialitet, integritet og tilgjengelighet. Som Red Hat påpeker i sin beskrivelse av sårbarhetshåndtering, måler grunnscoren teknisk alvorlighetsgrad, ikke risiko. En «kritisk» sårbarhet på en intern maskin uten sensitive data kan i praksis være mindre alvorlig enn en «middels» feil i nettbutikkens betalingsflyt.

OWASP Risk Rating Methodology er laget nettopp for å prioritere hva som skal rettes etter en test eller kodegjennomgang. Den går, som en studie fra DTU beskriver, gjennom stegene identifisere risiko, estimere sannsynlighet, estimere konsekvens, fastsette alvorlighetsgrad og beslutte hva som rettes.

I praksis stiller vi tre spørsmål til hvert funn:

Er det synlig fra internett?
Hvor lett er det å utnytte, og finnes det kjente angrepsverktøy?
Hva står på spill: kundedata, betalinger, drift eller omdømme?

Svaret avgjør rekkefølgen. Et lett utnyttbart hull på en internetteksponert tjeneste med persondata kommer alltid først.

Etter analysen: retting og kontroll

Her går mange prosjekter i stå. Rapporten er levert, alle er enige om at funnene er viktige, og så skjer lite. Universitetet i Oslo beskriver i sine retningslinjer at systemeier etter en risikovurdering skal sørge for en tiltaksplan som angir hva, hvem og når for alle risikoer som ligger over akseptabelt nivå. Den samme disiplinen fungerer for en bedrift med ti ansatte.

Rett, eller begrens skaden

Norsk helsenett anbefaler at sårbarheter lukkes ved oppdatering uansett hastegrad. Når det ikke går med en gang, kan dere fjerne tjenesten fra internett, legge den bak tilgangsstyring eller følge leverandørens anbefalte midlertidige tiltak. Det gir tid uten å la døren stå åpen.

Kontroller at hullet er tettet

At utvikleren sier «det er fikset», er ikke det samme som at sårbarheten er borte i miljøet som faktisk kjører. En ny test av hvert rettet funn bekrefter at svakheten er lukket, og at endringen ikke har skapt en ny feil. NSM anbefaler i sine grunnprinsipper for sikkerhetsstyring dessuten periodisk kontroll av at sikkerhetsarbeidet holder et forsvarlig nivå.

En god rapport gjør dette enkelt. Den bør inneholde:

navn på sårbarheten og når den ble funnet
hvilke systemer som er berørt
alvorlighetsgrad og begrunnelse
konkret tiltak og ansvarlig
frist, og dato for når funnet ble bekreftet rettet

Kan bedriften bli omfattet av NIS2, blir dokumentert sårbarhetshåndtering en del av det dere må ha orden på. Vi har skrevet om hva NIS2-kravene betyr i Norge og en praktisk plan for å forberede bedriften.

Hvor ofte bør dere skanne og analysere?

To råd går igjen hos norske myndigheter. NVE anbefaler at dere skanner før nye eller oppdaterte komponenter tas i bruk, og i tillegg jevnlig på systemer som er i drift. Norsk helsenett skanner kontinuerlig etter kjente sårbarheter og rapporterer kritiske og høye funn innen én uke, middels innen to uker og lave innen fire uker.

For en liten eller mellomstor bedrift blir et fornuftig mønster omtrent slik:

Hva	Når
Automatisk skanning av det som er synlig fra internett	Jevnlig og løpende
Skanning av nye eller endrede systemer	Før de settes i drift
Full sårbarhetsanalyse	Fast intervall, og etter store endringer
Penetrasjonstest	Ved lansering av viktige løsninger, og når risikoen øker
Kontroll av rettede funn	Etter hver utbedring

En sårbarhetsanalyse er et øyeblikksbilde. Nye sårbarheter publiseres hele tiden, så et system som var rent i vår, kan ha kjente hull i høst.

Før dere bestiller: dette bør avklares

Mangler dere egen IT-avdeling, avgjør forarbeidet hvor mye dere får igjen. NVE peker på at det å kombinere flere verktøy ofte gjør det nødvendig å hente inn ekstern kompetanse. Avklar dette før oppstart:

Hva er viktigst å beskytte? Kundedata, betalinger, bestillingssystem, e-post?
Hva har dere egentlig? Lag en liste over domener, nettsider, apper, skytjenester og leverandører. NSM anbefaler å kartlegge enheter og programvare som et grunnleggende første steg.
Hvem eier systemene? Er nettsiden levert av et byrå eller driftet av en leverandør, trengs ofte deres samtykke og kontaktperson.
Hvem retter funnene? Dette er spørsmålet flest glemmer. Hvis ingen hos dere kan rette, bør leverandøren av analysen kunne gjøre det.
Hvordan vil ledelsen ha resultatet? En kort oppsummering på norsk med tydelige prioriteringer er ofte mer verdt enn en teknisk rapport på 80 sider.

Er dere usikre på hvor dere skal begynne, har vi samlet råd om hvordan bedriften får riktig hjelp med cybersikkerhet.

Vårt syn: en analyse er bare verdt noe når hullene blir tettet

Vi har sett mange sårbarhetsrapporter som aldri førte til noe. De var tekniske, lange og skrevet for et sikkerhetsteam bedriften ikke hadde. Lederen forsto ikke hva som hastet, og utvikleren visste ikke hvor han skulle begynne.

Derfor jobber vi annerledes. Ledelsen får en kort oppsummering av hva vi fant, hva det betyr for virksomheten og hva som må gjøres først. Den tekniske detaljen ligger der for dem som trenger den, men beslutningen skal kunne tas på fem minutter.

Og vi stopper ikke ved rapporten. Vi er med og retter sikkerhetshullene selv, og vi kontrollerer etterpå at de faktisk er lukket. Du snakker direkte med fagpersonen som har gjort testen, uten selgere eller mellomledd. For en bedrift uten egen IT-avdeling er det forskjellen på å vite om et problem og å bli kvitt det.

Sejad

Få nettsiden og systemene testet

Vi tilbyr sikkerhetstester av nettsider, apper og systemer, gjennomgang av sky og e-post, kodegjennomgang og risikovurdering. Dere får funnene forklart på en måte ledelsen forstår, og hjelp til å rette dem.

Clevo

Vil dere starte enkelt, kan dere ta en gratis sjekk av e-posten. Er dere klare for en full gjennomgang, kan dere bestille en sikkerhetstest, så tar vi kontakt for å avklare omfanget.

Ofte stilte spørsmål

Hva er forskjellen på en sårbarhetsanalyse og en ROS-analyse?

En ROS-analyse vurderer uønskede hendelser bredt, med sannsynlighet og konsekvens, og brukes mye i planarbeid og beredskap. En sårbarhetsanalyse i IT-sikkerhet ser konkret på tekniske svakheter i nettsider, kode, nettverk og skytjenester. De utfyller hverandre: ROS-analysen sier hva som er viktigst å beskytte, og sårbarhetsanalysen finner hullene.

Holder det å kjøre et gratis skanneverktøy på nettsiden?

Et skanneverktøy finner kjente svakheter og er et nyttig første steg. Det finner sjelden logikkfeil, som at én kunde kan se en annen kundes data, og det sier ikke hva som haster for akkurat dere. En analyse med manuell vurdering gir prioriterte funn og tiltak.

Hvor lang tid tar en sårbarhetsanalyse?

Det avhenger av hvor mange systemer som er med. En avgrenset nettside går raskere enn et helt nettverk med skytjenester. Til sammenligning oppgir NSM at feltarbeidet i deres inntrengingstester vanligvis tar én til tre uker, og at større tester kan vare lenger.

Må vi ha egen IT-avdeling for å følge opp funnene?

Nei. Det viktigste er at noen har ansvaret for hvert tiltak og en frist. Har dere ikke folk som kan rette selv, kan vi gjøre utbedringen og kontrollere etterpå at hullene er lukket.

Hva gjør vi hvis noen varsler oss om et sikkerhetshull?

Ta varselet på alvor, bekreft at det er mottatt, og få funnet vurdert av en fagperson. Har dere en tydelig side for ansvarlig varsling, vet de som finner hull hvordan de skal melde fra. Se gjerne hvordan vi selv håndterer ansvarlig varsling.