KI gjør cyberangrep farligere. Responstiden må ned.

KI gjør cyberangrep farligere. Angriperne bruker KI til å utføre mer arbeid på kortere tid og angripe flere mål parallelt. Norske virksomheter må svare på denne utviklingen ved å kutte tiden fra et varsel kommer til beskyttelsen faktisk virker.

Responstiden må ned. Et dyktig sikkerhetsteam mister verdifull tid når det må vente på svar fra leverandøren, en leder som skal godkjenne nedetid, og neste vedlikeholdsvindu. Disse forsinkelsene er et ansvar for hele virksomheten, ikke bare sikkerhetsavdelingen.

Sikkerhetsoppdateringer må raskere i drift. Det er ikke nok alene. Ledelsen må også forberede virksomheten på tiden før en retting finnes: begrense den eksponerte tjenesten, blokkere den aktuelle angrepsveien og opprettholde viktige leveranser gjennom en godkjent reserveløsning. Kommer angriperen inn først, trenger bedriften tiltak som begrenser skaden, og en gjenopprettingsplan som er testet.

Min konklusjon er klar: Virksomheten må være rustet for raskere angrep. Fullmakter, tilganger og beskyttelsestiltak må være på plass før neste alvorlige sikkerhetshull blir kjent.

Raskere angrep er allerede dokumentert

I en studie publisert 8. juni 2026 testet Anthropic kjente Firefox-sårbarheter med offentlige feilrettinger og klargjorte testmiljøer. Selskapet rapporterer at Mythos Preview laget fungerende angrepskode for åtte av 18 feil, den første på under en time. Dette var leverandørens egen test av tidligere kjente feil i en frittstående JavaScript-motor. Forsøket omfattet verken en full nettleser eller en angrepskampanje på internett. De oppgitte tidene bygger på de raskeste vellykkede forsøkene. Studien viser hva modellen fikk til under disse forholdene. Den betyr ikke at virksomheter generelt har én time på seg til å avverge et angrep.

Det finnes også dokumentasjon utenfor laboratoriet. Anthropics rapport om misbruk fra september 2026 beskriver utvalgte kampanjer fra desember 2025 til august 2026 der innbrudd tok to til tre timer, og enkeltoperatører håndterte flere titalls ofre parallelt. Mennesker tok fortsatt viktige beslutninger. Rapporten bygger på saker leverandøren selv har undersøkt. Den er verken en representativ kartlegging eller en uavhengig måling av hvor mye KI bidro.

Det større bildet krever samme varsomhet. Google Threat Intelligence Groups analyse fra 30. september registrerte i gjennomsnitt 18 nylig offentliggjorte sårbarheter med observert utnyttelse per måned fra januar til august 2026, mot 10,5 i 2025. Analysen peker særlig på utnyttelse av kjente feil. Tallene gjelder antall sårbarheter, ikke antall angrep eller ofre. Resultatene påvirkes av hva forskerne oppdager, og når sårbarhetene offentliggjøres. Tallene fastslår ikke hvor mye av økningen KI forårsaket.

Funnene viser hvorfor virksomhetene må endre måten de planlegger beredskapen på. KI gjør deler av arbeidet fra oppdagelse til utnyttelse raskere og støtter angrep mot flere mål samtidig. At mennesker fortsatt deltar, gir ikke forsvarerne god tid til å reagere. Ledelsen må fjerne unødvendige forsinkelser nå, fremfor å vente på helautomatiske angrep.

Tre situasjoner som krever ulike svar

Ved et nulldagsangrep, ofte kalt et zero-day-angrep, utnytter angriperen et sikkerhetshull før en retting er tilgjengelig, gjerne før leverandøren kjenner til det. Begrepsbruken varierer. For virksomheten er spørsmålet enkelt: Har leverandøren en sikkerhetsoppdatering dere kan installere nå?

Ledelsen må forberede virksomheten på tre situasjoner:

En god oppdateringsrutine kan ikke installere en retting som ikke finnes. Før det første varselet avhenger beskyttelsen av hvordan systemene er bygd opp, og hvilke tilganger dere har gitt. Etter et varsel må ledelsen vurdere umiddelbare tiltak for å begrense eksponeringen. At oppdateringen mangler, er ingen grunn til å vente.

For Node.js-utgivelsene fra 21. oktober beskriver den egne oppdateringsguiden versjonsnumre og kontroller i produksjon. Denne saken handler om et større spørsmål: Hvordan skal bedriften beskytte en eksponert tjeneste og opprettholde driften mens en varig retting mangler eller ikke er ferdig innført?

Ett sikkerhetshull gir mål i mange virksomheter

Den samme sårbare programvarekomponenten finnes ofte hos mange virksomheter. En pålitelig angrepsmetode mot en utbredt konfigurasjon som er tilgjengelig fra internett, gir angriperen en oppskrift som kan gjenbrukes mot flere mål. KI reduserer deler av spesialistarbeidet med å forberede og gjennomføre gjentatte angrep. Konsekvensen er større press på hver eksponerte installasjon, også hos bedrifter som tidligere ville virket for små til å interessere en dyktig angriper.

Flere forhold må sammenfalle: Den sårbare koden må kunne nås, angrepet må virke på tvers av relevante versjoner, angriperen må finne mål og gjennomføre angrepet i stor skala, og beskyttelsen må svikte eller mangle. Å skanne en adresse, finne en sårbar versjon og stjele data er ulike resultater. Ett domene kan ha flere tjenester, og én tjeneste kan betjene mange domener. Antall nettsteder sier derfor lite om hvor mange faktiske innbrudd som har skjedd.

Automatisering i stor skala er dessuten eldre enn generativ KI. NISTs redegjørelse om WannaCry fra juni 2017 beskrev over 230 000 rammede datamaskiner i mer enn 150 land og automatisk spredning. Microsoft hadde publisert den aktuelle rettingen i mars, før angrepet i mai. Hendelsen viser potensialet i automatisert gjenbruk. Den dokumenterer ikke KI-drevet utnyttelse av nulldagssårbarheter.

Den strategiske endringen ligger i økonomien bak angrepene. Når arbeidet per mål blir mindre, blir også mindre gevinster verdt å forfølge. En norsk bedrift trenger ikke tiltrekke seg flere uker av en spesialists tid for å bli utsatt for et alvorlig innbrudd. Det holder å være ett eksponert mål i en operasjon som gjentas mot mange.

Derfor må masseangrep inn i beredskapsplanleggingen nå. Å hevde at KI vil bryte seg inn i millioner av tjenester innen et bestemt tidsrom, ville gått lenger enn dokumentasjonen gir grunnlag for. Å vente på et slikt antall ofre før virksomheten forbedrer responsen, ville være en alvorlig ledelsesfeil.

Respons på minutter krever beslutninger på forhånd

Flaskehalsen ligger ofte utenfor sikkerhetsteamet. Noen må finne den berørte tjenesten, nå personen med nødvendig tilgang, avgjøre hvilke avbrudd eller driftsforstyrrelser som er akseptable, få leverandøren til å gjøre en endring og kontrollere resultatet. Raskere analytikere hjelper lite hvis daglig leder fortsatt må godkjenne hvert akutte sikkerhetstiltak en fredag kveld.

Australske myndigheters veiledning fra 6. juli 2026 ber uttrykkelig ledere og styrer vurdere større aksept for korte avbrudd ved raske sikkerhetstiltak. Den anbefaler også automatiske tiltak som er avgrenset, godkjent på forhånd og kan reverseres. Målgruppen er myndigheter, kritisk infrastruktur og store virksomheter. Avveiningen er nyttig for norske bedrifter, men dette er utenlandsk veiledning, ikke et norsk lovkrav.

Ledelsen må på forhånd avklare hvilke tiltak beredskapsvakten har fullmakt til å gjennomføre uten ny godkjenning. Avhengig av tjenesten omfatter dette å stanse én integrasjon, begrense et offentlig tilgjengelig administrasjonsgrensesnitt eller sette en portal i en trygg vedlikeholdsmodus. Beskriv hva som utløser tiltaket, hvor langt fullmakten rekker, hvem som er ansvarlig, konsekvensene for kundene og vilkårene for å åpne igjen.

Ikke gi en generell instruks om å stenge alt. Et uprøvd tiltak kan stoppe produksjon, skape fare eller hindre ansatte i å betjene kunder. Riktig handling avhenger av tjenesten og må forberedes sammen med de driftsansvarlige. Når det er vanskelig å stanse en tjeneste på en trygg måte, blir det enda viktigere å begrense tilgangen fra internett og skille systemene bedre på forhånd.

Hvis en viktig tjeneste er i drift hele døgnet, må også beslutningsveien ved akutte varsler fungere utenfor kontortiden. For et lite AS er en tydelig avtale med den eksisterende leverandøren og en kontaktperson i bedriften med nødvendig fullmakt et naturlig utgangspunkt. Bedriften trenger ikke bygge sitt eget sikkerhetsoperasjonssenter. Den må vite hva som skjer når den vanlige kontakten ikke er tilgjengelig.

Tiden før sikkerhetsoppdateringen finnes

Tenk deg et hypotetisk norsk rådgivningsselskap med en portal for fortrolige kundedokumenter. Fredag ettermiddag varsler leverandøren om en alvorlig feil i portalprogramvaren. Ingen sikkerhetsoppdatering er tilgjengelig. Leverandøren kan foreløpig ikke avgjøre om selskapets konfigurasjon gjør feilen mulig å utnytte.

Før varselet kommer, må ledelsen avklare om ekstern tilgang til portalen lar seg stanse på en trygg måte, og forberede en godkjent reserveløsning for nødvendige dokumenter. Bestem hvilke integrasjoner som må stanses midlertidig, hva kundene skal få beskjed om, og hvem som har fullmakt til å handle. Alternativet må ivareta fortrolighet og sporbarhet. Å flytte dokumentene til vanlig e-post uten godkjenning er ikke automatisk en trygg reserveløsning.

Det tekniske teamet må vurdere hvilke midlertidige tiltak som faktisk kan blokkere angrepsveien. En regel i en webapplikasjonsbrannmur kan blokkere noen ondsinnede forespørsler, men slippe gjennom andre. En tilgangskontroll kan redusere eksponeringen for én feil og ha liten effekt mot en annen som kan utløses før innlogging. Avklar hva tiltaket beskytter mot, og kontroller at det virker.

Dette er en hypotetisk beslutningsøvelse, ikke en påstand om at portaler alltid må stenges. Målet er å synliggjøre valget før varselet kommer: Hvor stort avbrudd vil bedriften akseptere for å redusere en usikker, men alvorlig risiko?

Ved tegn til innbrudd må arbeidet med sårbarheten og hendelseshåndteringen gå parallelt. NSMs sjekkliste, oppdatert 19. oktober 2026, anbefaler å isolere berørte systemer uten å slå av enhetene, iverksette forberedte planer og skaffe ekspertbistand. En oppdatering alene gjør ikke stjålne innloggingsopplysninger ubrukelige, fjerner ikke nødvendigvis angriperens etablerte tilgang og henter ikke tilbake data som er stjålet. Følg hendelsesteamets plan for å sikre spor og åpne tjenestene igjen.

Begrens skaden hvis angriperen kommer inn

Beredskapen må tåle at en angriper får tilgang til én tjeneste. Bedriften må begrense hva angriperen får ut av denne tilgangen, også mens årsaken til innbruddet fortsatt undersøkes.

En dokumentportal trenger ikke rettigheter til å administrere bedriftens brukerkontoer, lese kundedatabaser som portalen ikke trenger tilgang til eller endre sikkerhetskopier. Slike rettigheter på portalens tekniske konto gjør ett innbrudd unødvendig skadelig. Fjern tilganger som ikke trengs, og skill kontoer og tjenester. Kontroller at portalen fortsatt løser oppgavene sine med de begrensede tilgangene.

Be teamet demonstrere grensene i en godkjent øvelse. Kan tjenesten nå systemer den ikke trenger? Kan kontoen endre kopiene dere skal gjenopprette fra? Vil sikkerhetslogger fortsatt være tilgjengelige hvis tjenesten blir kompromittert? Test også at kundene fortsatt kan bruke tjenesten som de skal etter at tilgangene er strammet inn. Da oppdager dere om sikkerhetstiltaket har ødelagt viktig funksjonalitet.

Gjenopprettingen må omfatte hele tjenesten, inkludert brukerkontoer, tilganger og integrasjoner. Dataene må være til å stole på. En sikkerhetskopi som aldri har vært brukt i en vellykket gjenopprettingstest, etterlater stor usikkerhet. Avklar hvilket arbeid som kan fortsette manuelt, og hvordan det skal avstemmes når normal drift kommer tilbake.

Tiltakene begrenser skaden fra en kompromittert tjeneste. De er ingen garanti mot alle ukjente feil. De bygger motstandsdyktighet i hele systemet, fremfor å basere beskyttelsen på håpet om at én eksponert applikasjon alltid er sikker.

Bruk KI til å gjøre sikkerhetsarbeidet raskere

Begynn med avgrensede oppgaver: sammenhold et leverandørvarsel med systemoversikten, få forslag til en konfigurasjonsendring, lag tester som avdekker om en endring ødelegger eksisterende funksjonalitet, og organiser dokumentasjon fra hendelser. Krev målbare tidsbesparelser og resultater teamet klarer å kontrollere.

I sin redegjørelse 21. oktober for arbeidet med PHP-sårbarhetene sier OpenAI at KI-støttet oppdagelse ga vedlikeholdere og leverandører tid til å samordne rettinger og beskyttelse før offentliggjøring. Så langt selskapet kjenner til, fant forsvarerne feilene før angriperne. Dette er leverandørens fremstilling, ikke dokumentasjon på at alle systemer var beskyttet. Eksempelet viser verdien av et forsprang fra KI-støttet oppdagelse. Det er en grunn til å investere i dokumentert nyttig KI-bruk på forsvarssiden, sammen med raskere respons.

Mål deres eget resultat. Fant verktøyet de berørte tjenestene korrekt? Besto endringsforslaget testene? Ble det kontrollert uavhengig at endringen virket i produksjon? Avgrens verktøyets fullmakter ut fra hvor pålitelig det har vist seg å være, og hva en feil kan føre til. At verktøyet har gjennomført endringen, er ikke bevis på at beskyttelsen virker. Kontroller resultatet i produksjon.

NSMs etablerte råd er raske, sentralt styrte og mest mulig automatiske sikkerhetsoppdateringer. De fem tiltakene retter seg hovedsakelig mot brukernes enheter. Sørg for pålitelige rutineoppdateringer og styrk hasteprosessen for eksponerte tjenester. Vanlige oppdateringer skal ikke trenge et nytt godkjenningsmøte hver gang.

Mål tiden frem til beskyttelsen virker

Et løfte om å svare på en henvendelse innen én time kan bare bety at noen bekrefter mottak. Ledelsen må skille dette fra en endring som faktisk reduserer risikoen.

Et troverdig varsel om aktiv utnyttelse mot en eksponert tjeneste må utløse hasteprosessen umiddelbart. Utpek en ansvarlig og vurder beskyttelsestiltaket uten å vente på neste vedlikeholdsmøte. Responsen må starte i løpet av minutter. Hvor raskt en trygg retting er på plass, avhenger av tjenesten og løsningen som finnes. Nettopp derfor må midlertidige beskyttelsestiltak være forberedt.

For hvert alvorlig varsel må dere registrere når det ble mottatt, når berørte tjenester var identifisert, når beskyttelsestiltaket var på plass og fungerte, og når den varige rettingen var kontrollert. Vis hvilke systemer som fortsatt er eksponert, også dem som faller utenfor hovedleverandørens avtale. Et godt gjennomsnitt kan skjule den ene internetteksponerte tjenesten som ingen har ansvar for.

Avtal tidsmål for hver tjeneste ut fra konsekvensene for virksomheten, hvor eksponert tjenesten er, og hvilke tiltak dere kan bruke. Test om dere når målene i en øvelse der oppdateringen mangler, leverandørkontakten er utilgjengelig og utrullingen mislykkes. Ingen offentlig statistikk gir en trygg, universell tidsfrist for alle systemer. Hvis dere bruker timer bare på å finne den ansvarlige, har dere et konkret problem å løse, uansett hvor raskt et fremtidig angrep kan gå.

Styret må ta stilling til hva virksomheten er forberedt på å tåle

Ledelsen må legge frem et konkret forslag: Hvilke viktige tjenester trenger raskere respons? Hvilke midlertidige avbrudd ønsker den fullmakt til å akseptere? Hvor er leverandøravtalene utilstrekkelige, og hvilke investeringer vil redusere de lengste forsinkelsene? Styret må undersøke om risikoen er akseptabel, om ressursene er tilstrekkelige, og om det er dokumentert at ordningen virker. Det skal ikke velge brannmurregler eller godkjenne hver oppdatering.

Britiske NCSCs vurdering frem mot 2027 advarte allerede i 2025 om at KI ville korte ned tiden til utnyttelse og styrke dyktige aktørers evne til å finne og utnytte nulldagssårbarheter. NCSC ventet fortsatt menneskelig deltakelse i avanserte angrep og vurderte helautomatisk gjennomføring fra start til slutt som lite sannsynlig frem mot 2027. Det var en prognose, ikke en øvre grense for hva KI vil mestre. At en angriper fortsatt sitter bak tastaturet, gir ikke virksomheten tid til en langsom godkjenningsprosess. Ledelsen må planlegge ut fra hastigheten i observerte angrep og oppdatere planene etter hvert som verktøyene blir kraftigere.

Ta utgangspunkt i én viktig tjeneste som er tilgjengelig fra internett, på neste ledermøte. Spør: Hvis leverandøren varsler om en alvorlig feil i kveld og ikke har noen oppdatering, hvem kan redusere eksponeringen, hva kan de gjøre, og hvordan vet vi at det virket? Bruk guiden til styrets cyberrapport til å dokumentere den uavklarte risikoen for virksomheten, og guiden til daglig leders beslutninger under en hendelse ved mistanke om innbrudd.

KI gjør cyberangrep farligere. Svaret er å få sikkerhetsoppdateringer raskere i drift, kontrollere at de virker og være forberedt på å begrense eksponeringen før en retting finnes. Gi teamet tydelige fullmakter, øv på beskyttelsestiltakene og mål tiden frem til de virker. Rask respons er et krav til driften, ikke en oppgave som skal utsettes til neste hendelse.

Kildene er kontrollert 23. oktober 2026. Bedriften med dokumentportalen er hypotetisk. Masseangrep omtales som en mulighet under bestemte forutsetninger, ikke som en prognose for antall ofre eller et bestemt tidspunkt. Ledelsesrådene og forslagene til måling er forfatterens vurderinger. Illustrasjonen er KI-generert.