I skrivende stund arbeider virksomheter verden over med hendelseshåndtering. Årsaken er sårbarheter i en perifer open source komponent kalt Apache Log4j 2, som er et bibliotek for logging i Java-baserte applikasjoner. Kort fortalt gjør sårbarheten det mulig for en angriper å fjernkjøre kode. Sårbarheten har blitt gitt en CVSS-score på 10.0 (kritisk), som er den høyeste klassifiseringen en sårbarhet kan oppnå i CVSS-systemet.
Underholdningstjenester som iCloud, Steam og Minecraft inneholder alle sårbarheten, men også sentrale systemer i offentlig forvaltning slik som Altinn og Brønnøysundregistrene, er berørt. Sistnevnte tok av preventive hensyn ned enkelte av sine publikumstjenester i helgen. Sårbarheter i tjenester som er direkte eksponert mot internett, kan enkelt utnyttes av en angriper. NCSC har allerede meldt om at de har observert omfattende utnyttelsesforsøk i Norge gjennom deres varslingssystem for digital infrastruktur (VDI).
En perifer enkeltkomponent
Log4j kan beskrives som en perifer enkeltkomponent. Den er utviklet av et fåtall personer på fritiden og distribueres som open source. Det er i utgangspunktet en god ting at koden er åpent tilgjengelig for alle, slik at koden er tilgjengelig for gransking av flere. Utfordringen er at 1) sårbarheten har ikke blitt avdekket til tross for at Log4j er open source og 2) svært mange utbredte tjenester og produkter fra Apache, Cisco, VMWare og Elastic, benytter Log4j.
Dette er tjenester som ofte blir benyttet av virksomheter (til forskjell fra enkeltpersoner) og derfor blir konsekvensene ved at en slik sårbarhet eksisterer i et viktig informasjonssystem, vesentlig større for samfunnet som helhet. De fleste klarer seg fint uten Steam og Minecraft noen dager eller uker, men det samme kan ikke sies om sentrale samfunnsviktige tjenester.
Den aktuelle sårbarheten i Log4j biblioteket var før den 9. desember ukjent for alle i Norge. Log4j var i seg selv med stor sannsynlighet også ukjent for de fleste som ikke utvikler i Java. Det er et betimelig spørsmål hvorvidt virksomheter som benytter de aktuelle Apache, Cisco, VMWare og Elastic produktene, er kjent med at de benytter komponenter som utvikles av enkeltpersoner, ubetalt på fritiden. Og hvorvidt de har akseptert den risiko som dette innebærer. Spesielt ettersom Log4j nå har blitt en global informasjonssikkerhetsrisiko.
Verdi- og leverandørkjeder
Problemstillingen som dermed må adresseres knytter seg til våre verdi- og leverandørkjeder. Når samfunnsviktige tjenester benytter applikasjoner som inneholder åpent tilgjengelig kildekode, utviklet på fritiden av enkeltpersoner med varierende grad av kvalitetssikring og tilnærmet ingen finansiering, så er sannsynligheten stor for at modellen vi snakker om ikke er bærekraftig på lengre sikt. Sårbarheten som introduseres med Log4j kan med andre ord leses som et symptom på et strukturproblem, men håndteres ofte som enkelthendelser.
IT-industrien er ung i alder, enorm i omfang og kompleks i sammensetning. Veien fra gutterommet til å drifte banker, kraftsystemer og offentlig forvaltning, har vært kort. Industrier som er avgjørende for samfunnet og som potensielt kan generere høy risiko er ofte strengere regulert og standardisert. Du ville ikke kjørt en bil der produsenten ikke kunne garantere for at setebeltene var korrekt montert og at de faktisk fungerte ved en kollisjon?
Når IT-systemer som er viktige for staten og samfunnet som helhet benytter komponenter som i liten grad kvalitetssikres gjennom standardiserte prosedyrer, slik som eksempelet er med Log4j, så vil vi jevnlig bli eksponert for risiko i våre leverandørkjeder. I dette tilfellet er det en gladhistorie at den kritiske sårbarheten kun ser ut til å ha blitt utnyttet én uke, fra 1. desember, før den ble avdekket og offentliggjort den 9. desember. Ved offentliggjøring av sårbarheter går antallet utnyttelsesforsøk drastisk opp, og de neste ukene blir avgjørende.
Kvalitetssikring
Når hendelseshåndteringen snart er over og støyen har lagt seg, bør vi benytte anledningen til å lære av situasjonen. Hvordan kvalitetssikrer vi komponenter som benyttes i våre digitale verdikjeder, slik at vi har tilstrekkelig kontroll over faktorer som potensielt kan generere risiko? Dersom vi tenker at open source som konsept er det best egnede som IT-industrien har kommet opp med for å avdekke svakheter i kode, bør det etableres finansierings- eller kvalitetssikringsmekanismer som adresserer svakheter ved dagens modell? Eller skal vi fortsette å basere digitaliseringen av samfunnet vårt på enkelte ildsjelers frivillighet?
På grunn av dagens digitaliseringstakt og utviklingen i det digitale trusselbildet, er det ikke gitt at dagens modell for håndtering av risiko i tilknytning til verdi- og leverandørkjeder skalérer. Det vil på sikt føre til et enda større behov for reaktiv hendelseshåndtering. Det er ofte først når en konkret hendelse inntreffer at vi alle blir oppmerksomme på risiko, men risikoen har ligget der latent hele tiden, uten at hendelsen har manifestert seg.
Dersom årsaken til hendelsen er et strukturproblem fremfor en enkelthendelse, bør vi også ramme inn problemstillingen på den måten. Ellers vil vi i fremtiden få svært mange enkelthendelser å håndtere. Da vil vi alle bli veldig opptatt, men samtidig mindre produktive.
PS: Dette må ikke leses som kritikk av open source som konsept, personer og virksomheter som benytter Log4j eller utviklerne bak. Dette er et innspill for å forbedre strukturene våre.
Ny rapport: KI-assistenter gjør ikke (alle) utviklere mer effektive
