Gjentakelse

Hvorfor én sjekk ikke holder

En sikkerhetstest er et fotografi, ikke en garanti. Den beskriver systemet slik det var den uken den ble kjørt, og den er verdt akkurat så mye som det bildet fortsatt ligner.

Argumentet for å se etter på nytt er ikke at testing er upålitelig. Det er at det som ble testet ikke står stille. Sertifikater går ut, subdomener dukker opp, folk slutter, og avhengigheter blir sårbare uten at noen har rørt en linje kode.

Glippen selger løpende overvåking, så dette er et salgsargument. Det står i klartekst nederst på siden, sammen med den gratis sjekken dere kan bruke til å etterprøve påstanden uten å betale oss noe.

Oppdatert 2026-08-16 · kildene kontrollert 2026-08-16 · skrevet av Erik Nilsen

Rapporten beskriver én dag

En rapport sier hva som ble funnet, i det som ble testet, i den perioden testen løp. Det er alt den kan si. En leverandør som antyder noe mer, selger en trygghet de ikke har dekning for.

Det er ingen svakhet ved metoden. Det er hva en test er. En revisor sier heller ikke at regnskapet kommer til å stemme neste år.

Verdien av rapporten faller derfor over tid, og den faller ikke jevnt. Den faller i sprang, hver gang noen endrer noe. Et system ingen har rørt på et år har en rapport som fortsatt stemmer ganske godt. Et system i aktiv utvikling har en rapport som begynner å bli historie etter et kvartal.

Datoen på en rapport er derfor mer opplysende enn konklusjonen i den. Det første en kjøper bør spørre om, er når testen ble kjørt og hva som er endret siden.

Utsiden flytter seg uten at noen rører den

Den delen av dere som er synlig fra internett endrer seg av seg selv, uten at noen har tatt en beslutning. Dette er de tre mekanismene som oftest gir et reelt funn ved neste gjennomgang.

Sertifikatet går ut fordi fornyingen sviktet stille. Et sertifikat fra Let's Encrypt varer i 90 dager, og de anbefaler selv å fornye hver 60. dag, nettopp fordi det skal være rom for at noe feiler. Når det feiler, feiler det uten lyd: jobben kjører, valideringen kommer ikke gjennom, og ingen merker noe før alt er nede. Det er full driftsstans uten at noen har angrepet dere.
Nye subdomener dukker opp uten at noen sier fra. Markedsavdelingen setter opp en kampanjeside, en utvikler ruller ut et testmiljø, en integrasjon får sitt eget navn. Hvert sertifikat som utstedes havner i offentlige logger, så adressene er kjent utenfor virksomheten før de er kjent inne i den.
DNS-poster lever lenger enn tjenesten de peker på. Et CNAME som peker på en skyressurs som er slettet, er en åpen dør: den som får registrert ressursen på nytt, overtar adressen. Navnet tilhører fortsatt dere, og alt som legges der ser ut som deres.

De to første fanges opp av en sjekk som kjøres jevnlig og sammenlignes med forrige gang. Den tredje krever i tillegg at noen faktisk rydder, og rekkefølgen er hele poenget: DNS-posten fjernes før tjenesten, aldri motsatt.

Koden står stille mens risikoen flytter seg

En avhengighet dere tok inn i fjor kan bli sårbar i morgen. Koden er den samme, testen var riktig da den ble kjørt, og risikobildet er likevel et annet.

Det som skjer er at noen offentliggjør en sårbarhet i et bibliotek dere bruker. Fra det øyeblikket er den kjent for alle, også for dem som leter etter systemer som ennå ikke har oppdatert. Tiden fra offentliggjøring til de første forsøkene er kort når sårbarheten er verdt å utnytte.

Dette er den eneste mekanismen på siden der ingenting hos dere har endret seg. Den er også den enkleste å håndtere, fordi den kan følges maskinelt: en oversikt over hva dere faktisk bruker, holdt opp mot de offentlige listene over kjente sårbarheter, sier hva som er blitt et problem siden sist.

De fleste slike varsler er uinteressante for akkurat dere. Et bibliotek kan ha en sårbarhet i en funksjon dere aldri kaller. Å skille de to fra hverandre krever at noen ser på det, og det er derfor et varsel ikke er det samme som et funn.

Innsiden endrer seg fordi noen gjør noe

Resten av endringene har en person bak seg. Ingen av dem er feil av noen. De er vanlig drift, og det er nettopp derfor de aldri blir meldt til den som testet.

Folk slutter, og tilgangen følger ikke alltid med ut. Kontoen i fagsystemet, den delte innloggingen til leverandørportalen, nøkkelen som lå i et skript. Sluttoppgjøret er ferdig lenge før tilgangene er det.
Noen lager en ny funksjon. Nye roller, nye endepunkter, nye steder der tilgangskontrollen kan bli feil på en måte ingen legger merke til. En rolle som skulle se sine egne data ser alles, og det oppdages ikke av folk som bruker systemet slik det er ment.
En leverandør endrer noe i et system dere er avhengige av, og sier ikke fra. En standardinnstilling flyttes, en integrasjon får flere rettigheter enn den hadde, en tjeneste dere trodde var lukket blir tilgjengelig for flere.
Et miljø settes opp for å prøve noe, og blir stående. En kopi av produksjonsdata uten innlogging foran er blant de vanligste alvorlige funnene som finnes, og den oppstår nesten alltid av en god grunn som gikk ut på dato.

Ingen av disse blir varslet til noen som testet i fjor. Det er ikke vond vilje. Det er at ingen tenker på en test mens de gjør jobben sin.

Hvor ofte det er verdt å se etter

Det finnes ikke ett riktig intervall som gjelder alle, og en leverandør som oppgir et tall har valgt det, ikke regnet det ut. Det som finnes er en brukbar regel: se etter så ofte som systemet endrer seg, og ikke oftere.

Endrer dere lite, og har ingen innlogging: én gjennomgang i året holder, med en gratis ekstern sjekk innimellom for å fange sertifikat og DNS.
Ruller dere ut endringer jevnlig i en applikasjon med brukere og roller: én test i året på helheten, og en ny gjennomgang av det som ble endret hver gang noe stort er endret.
Har dere gjort et stort skifte, som ny plattform, ny driftsleverandør eller sammenslåing av to virksomheter: test etter endringen, ikke etter kalenderen.
Kommer kravet utenfra, fra et anbud eller et sikkerhetsskjema fra en kunde, er det som regel kravteksten som setter frekvensen. Da gjelder den, uansett hva vi mener om saken.

Når én test i året er nok

Dette er avsnittet som mangler hos alle som selger overvåking, og det er det letteste å skrive, fordi det er sant.

Har dere en nettside som står stille, ingen innlogging, ingen personopplysninger ut over en kontaktadresse, og ingen endringer på månedsvis, trenger dere ikke løpende overvåking fra oss. Angrepsflaten er liten nok til at dere kan holde øye med den selv, og den gratis eksterne sjekken gjør nettopp det arbeidet.

Det samme gjelder om dere allerede har dekket det på andre måter: en driftsleverandør som følger med på sertifikater og DNS, en utviklingsprosess som varsler om sårbare avhengigheter, en fast rutine for hva som skjer med tilganger når noen slutter. Da kjøper dere ikke overvåking, dere kjøper en ny faktura for noe dere har.

Vi sier det heller nå enn å selge et abonnement dere sier opp om et halvår.

Det overvåking ikke kan se

En automatisk sjekk ser to ting: hva som er synlig fra utsiden, og hva som har endret seg siden sist. Det er nyttig, og det er alt den er.

Den finner ikke en ny autorisasjonsfeil i applikasjonen deres. At en bruker med én rolle kan hente ut data som tilhører en annen kunde, er ikke synlig utenfra, det står ikke i en DNS-post, og det avdekkes bare ved at noen logger inn og prøver. Det er en test, ikke en overvåking.

Den avgjør heller ikke om en endring er et problem. Den ser at noe er nytt. Om det nye subdomenet er en planlagt kampanjeside eller et testmiljø noen glemte, avgjøres av et menneske som vet hva dere driver med.

Overvåking erstatter altså ikke testing. Den korter ned tiden fra noe endrer seg til noen vet om det, og den holder oversikten over hva dere faktisk har. Det er verdt penger for noen, og ikke for alle.

En leverandør som selger overvåking som erstatning for testing, selger et varslingssystem og kaller det en sikkerhetsvurdering. Spør hva produktet gjør når svaret er at ingenting har endret seg.

Dette er et salgsargument, og det er likevel sant

Glippen selger løpende overvåking og en årsavtale. En side som argumenterer for at én test ikke holder, er skrevet av noen som tjener på at dere er enige. Les den med det i bakhodet.

Argumentet står seg uansett, og dere trenger ikke ta vårt ord for det. Den eksterne sjekken er gratis, den krever verken konto eller e-postadresse, og den leser DNS, e-postoppsett, sertifikat og svarhoder for ett domene.

Kjør den i dag, og skriv ned hva den sier. Kjør den igjen om tre måneder og se om noe er annerledes. Er svaret nei tre kvartaler på rad, har dere et godt argument mot å kjøpe overvåking av oss, og det har ikke kostet dere noe å skaffe det.

Er svaret ja, vet dere nå hvorfor vi mener det vi mener. Da er spørsmålet bare om dere vil følge med selv eller la noen andre gjøre det, og hva det siste koster står på tjenestesiden.

Uavklart

Det vi ikke vet sikkert

En side som argumenterer for at dere bør kjøpe noe oftere, bør være tydelig på hva den ikke kan belegge.

Hvor ofte det lønner seg å teste, vet vi ikke. Vi kjenner ikke til noe tallgrunnlag som fastslår et riktig intervall for en virksomhet av en gitt størrelse, og vi kommer ikke til å finne på ett. Rådene over er erfaring og skjønn, ikke måling.
Om et varsel blir lest, avgjør hele nytten, og det styrer ikke vi. Overvåking som sender e-post til en adresse ingen følger med på, er en utgift og ikke et tiltak. Det bør avklares før dere kjøper, ikke etterpå.
Vi kan ikke si hva en jevnlig sjekk ville fanget opp i en hendelse som allerede har skjedd. I ettertid ser sammenhengen alltid klarere ut enn den gjorde på forhånd, og den slags fortellinger skal ikke brukes som argument for å selge noe.
Grensen mellom at noe er endret og at noe er blitt verre, er en vurdering. Sjekkene ser endringen. Om den betyr noe, avgjøres fortsatt av et menneske, og det er en kostnad ingen kan automatisere bort.

Kilder

Hvor dette er hentet fra

Primærkilder, slik at dere kan kontrollere hvert punkt uten å spørre oss.

Videre

Les videre

Se også

Andre steder på nettstedet