Satte krisestab og stengte ned i fire døgn da Log4j-hullet ble kjent

Varsellampene begynte å blinke verden over da en tidligere ukjent sårbarhet i det Java-baserte biblioteket Apache Log4j ble kjent to uker før jul.

Brønnøysundregistrene (Brreg) er kanskje den virksomheten i Norge som tok de mest drastiske skrittene.

Alt tyder på at det var en klok beslutning å stenge dørene i flere dager, som du kan lese om i dette intervjuet.

Krisestab

Etaten mottar en jevn strøm av informasjon og varsler om mulige cybertrusler som deltaker i VDI-samarbeidet (Varslingssystem for digital infrastruktur) i regi av Nasjonal sikkerhetsmyndighet (NSM).

Det er fredag 10. desember og snart helg når Brønnøysundregistrene blir varslet av NSM om en sårbarhet i et Java-knyttet bibliotek.

– Da jeg fikk se oppsummeringen fra kollegene mine, tenkte jeg først at det var en rutinemessig oppdatering. Alvoret gikk først opp for meg etter flere samtaler med fagsiden, forteller IT-direktør Kjell-Arne Strøm Hansen.

Likevel gikk det maks en time, anslår han, før de satte krisestab for IT-avdelingen ved 15-16-tiden. Ti minutter senere konkluderte de med at situasjonen var så alvorlig at det utgjorde en mulig krise for Brønnøysundregistrene.

– Det innebærer at vi setter både strategisk og operativ krisestab, tilføyer kommunikasjonsdirektør Kristine Aasen.

Arbeidsdagen er nesten over da beredskapsplanene iverksettes. En stab på koronahjemmekontor var ingen direkte ulempe, mener Aasen, som viser til at troppene da raskt lot seg samle til videomøter på Teams.

På det mest hektisk er nesten 50 ansatte i full aktivitet med å avdekke, analysere og sikre løsningene mot en overhengende trussel. De jobber fredag kveld, hele lørdagen, søndag kveld og fortsetter igjen mandag, inkludert mer kveldsarbeid.

Valgte å stenge døra

Hva gjør vi nå? IT-direktøren husker tilbake til fredagen, to uker før jul. Etter at han som IT-leder hadde presentert situasjonen, måtte han gi råd om veien videre.

– Når du sitter der, kjenner du på ansvaret ved å ta en sånn beslutning. Spesielt når vi ikke har noen å rådføre oss med. Sånn sett valgte vi å følge rådene og risikoprofilen fra NSM til punkt og prikke, sier Strøm Hansen.

Kort fortalt: De måtte identifisere hvilke tjenester som var berørt. Så valgte de å skalke lukene.

– Vi anbefalte å stenge inngangsdøra helt. Vi tok aldri ned noen tjenester, men sørget for å stenge tilgangen gjennom brannmuren.

Nedstengningen ble opplevd litt ulikt avhengig av hvem du spør. Publikum ble i en kort periode servert en 404-feilmelding i nettleseren, deretter en mer beskrivende melding om at nettjenestene er utilgjengelige.

Altinn valgte til sammenligning å deaktivere sin søkefunksjon før innlogging som følge av den samme sårbarheten.

Nede i over fire døgn

Brønnøysundregistrene har trolig ikke hatt lengre nedetid for publikum enn da da måtte hanskes med Log4j-komponenten forrige måned, i hvert fall ikke i nyere tid.

– Det ble over fire døgn nedetid, medgir Strøm Hansen. Så vidt han vet er det rekord.

Nærmest og med en lignende alvorlighetsgrad må være tidsavsbruddet da Altinn-portalen sviktet i 2012 og eksponerte personopplysningene til «Kenneth». Altinn var en del av Brønnøysundregistrene den gangen, men siden (1.1.2020) er rapporteringsportalen overført til Digitaliseringsdirektoratet.

Utbredelsen av Log4j i systemene til Brønnøysundregistrene var betydelig. IT-direktøren forteller at det tok sin tid å analysere, vurdere, teste og rulle ut nødvendige endringer.

Apache Log4j ble raskt tilgodesett med oppdateringer, men så ble det oppdaget feil også i oppdateringene. I flere runder har det vært avslørt nye sårbarheter, om enn ikke fullt så kritiske som den første. Det betyr uansett at mange virksomheter har utført flere oppdateringer.

– Måtte dere gjøre jobben flere ganger?

– Vi fant en måte å omgå problemstillingen på. Da vi patchet opp våre systemer, endret vi også på kode, sier Strøm Hansen, som av hensyn til sikkerheten ikke ønsker å gå nærmere inn på detaljene.

Brreg var i tillegg avhengig av at tredjepart utførte nødvendige oppdateringer, herunder infrastrukturleverandører de benytter seg av som også var berørt av svakhetene, blant annet Oracle.

Angrep seg selv

Hvilken risiko løp Brønnøysundregistrene? Hvor stor var sannsynligheten for at deres nettverk og tjenester kunne bli hacket?

– Vi kjørte en egen «red team»-øvelse (penetrasjonstest, red.anm.) bak brannmuren for å se om vi klarte å utnytte sårbarhetene selv. Og det klarte vi. Her var det rikelig med muligheter til å utnytte sårbarhetene og kompromittere våre systemer og vår infrastruktur, innrømmer IT-direktør Kjell-Arne Strøm Hansen.

Erkjennelsen kan sammenlignes med at de fant en eller flere vidåpne dører. Uten tiltak ville risikoen for alvorlige angrep mot kritisk infrastruktur i Norge vært overhengende.

– Vi baserer oss i veldig stor grad på tillit. Det er en tillit til data vi avleverer og tjenestene våre som vi er helt avhengig av. I verste fall kunne vi blitt angrepet, for eksempel med utpressingsvare. Da ville vi vært nede lenge, sier Hansen.

Svært mange forsøk på utnyttelse

Log4Shell er ekstremt alvorlig. Direktøren for USAs føderale sikkerhetsorgan Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, uttalte nylig at hun ikke har sett en mer kritisk sårbarhet i sin flere tiår lange karriere.

Tross millioner av forsøk er amerikanske myndigheter ikke kjent med noen store Log4j-baserte innbrudd så langt. Bildet deles av norske kolleger, uten at risikoen nødvendigvis er noe mindre av den grunn.

– Vi har ikke sett de store konsekvensene av Log4j så langt i Norge. Men vi har sett svært mange utnyttelsesforsøk, i alle sektorer. Internasjonalt er det rapportert om mange tilfeller av kompromitteringer på grunn av Log4Shell-utnyttelse.

Det sier avdelingsdirektør Bente Hoff i Nasjonalt cybersikkerhetssenter i NSM, som fortsetter:

– Siden det fortsatt pågår mange forsøk på å utnytte sårbarheten, er risikonivået for norske virksomheter fortsatt høyt. At vi ikke har sett de store konsekvensene så langt, kan bety at norske virksomheter har tatt risikoen på alvor og fått på plass beskyttelsestiltak. Slik sett kan risikoen være noe redusert.

– Samtidig vet vi at kompromitteringer ofte skjer eller blir oppdaget lenge etter at sårbarheten ble kjent. Vi forventer derfor at det vil komme hendelser der denne sårbarheten er blitt utnyttet, sier Hoff.

Samtidig er Log4J bare én sårbar komponent. For norske virksomheter vil det fortsatt være avgjørende å fokusere på langsiktig, helhetlig og kontinuerlig sikkerhetsarbeid, understreker avdelingsdirektøren.

NSM har etablert en egen samleside med viktig informasjon knyttet til Apache Log4j-sårbarheten.

Ensomt uten IT-partnere

Brønnøysundregistrene har en sourcing-modell som innebærer at de drifter og forvalter systemene sine, inkludert kritisk infrastruktur, helt selv.

I en krisesituasjon som den de opplevde, blir savnet etter noen å rådføre seg med, desto mer påtakelig.

NSM som overordnet sikkerhetsmyndighet kan være en partner å sparre mot, men etatens IT-direktør skulle gjerne sett at det eksisterte også en annen type arena. Han etterlyser rett og slett en egen CERT (computer emergency response team) – eller brannkorps ved digitale hendelser, om du vil – for offentlige etater.

– Det offentlig sektor mangler, er en offentlig CERT. Både vi og mange andre kunne hatt stor nytte av det i en sånn situasjon, for uten står vi i utgangspunktet ganske alene og ensomme, konstaterer Kjell-Arne Strøm Hansen.

For øvrig er de for tiden midt oppe i en prosess for anskaffelse av SOC-tjenester (security operations centre), det vil si innleie av en operativ IKT-sikkerhetsfunksjon.