Luksusfellen for utviklere er å ignorere sikkerhetsgjeld

Produktet du ikke bruker penger på lenger har likevel en skjult kostnad

De siste årene har antallet “oh shit”-store sikkerhetsfeil økt. Det er produkter som har millioner av installasjoner og finnes i alle bransjer, som Log4Shell, Spring4Shell, og Big-IP. Å utnytte feilene er dessverre relativt lett, og det har potensielt fatale konsekvenser. Vi må være rigget for å reagere raskere enn noen gang på disse hendelsene.

Teknisk gjeld påvirker to ting; hvor fort du kan utvikle ny funksjonalitet og hvor fort du kan rette feil. Den siste her er skummel da sikkerhetsproblemer dukker brått opp, og det er viktig å reagere raskt.

Hvis du må oppdatere mange andre avhengigheter, eller skrive deg vekk fra en teknologi som inneholder sårbarheter, krever det mye forarbeid slik at man ikke introduserer nye feil. En applikasjon som ligger urørt over lengre tid bygger opp en sikkerhetsgjeld, men i motsetning til Sentralbanken som prøver å være forutsigbare i rentehevingene sine, kan gjelden din akselerere fra lav til skyhøy over natten.

Som all gjeld opparbeider sikkerhetsgjeld seg over tid og svinger i hvor raskt den øker. Vi kan peke på sikkerhetsgjeld og definere det ved å gjøre noen observasjoner: hvis dine tjenester for eksempel benytter utdatert kode som inneholder kjente sikkerhetshull og sårbarheter, eller hvis den inneholder manglende fokus på beste-praksis innen sikkerhet, eller teamet lider av en svak sikkerhetskultur — da har man sikkerhetsgjeld!

Pakkebrønner som NPM og NuGet lar deg bygge programvare i et stadig høyere tempo med gjenbrukbare kodebiblioteker, men økende grad av avhengigheter til tredjeparter har en kostnad. Hva når rammeverk man bruker har avhengigheter til sårbar kode? Tredjepartsbiblioteker har blitt landminer hvor små sikkerhetsfeil har stort skadepotensiale. Her befinner det seg potensielt mye skjult sikkerhetsgjeld og verdikjedene våre må gjennomgås stadig grundigere med sikkerhetsbrillene på.

I kontrast til teknisk gjeld, er det rentenes uforutsigbarhet som skiller sikkerhetsgjeld fra teknisk gjeld.

Mye av grunnen til at risikoen øker har å gjøre med at terskelen for å finne og utnytte sårbarheter blir lavere etterhvert som sikkerhetsoppdateringer blir lansert og sårbarhetene de fikser blir offentliggjort. Det som tidligere krevde masse ressurser å oppdage og utnytte blir etterhvert lavthengende frukt via åpent tilgjengelige verktøy eller kildekode. Det tar som regel ikke veldig lang tid fra sårbarheter blir kjent til det finnes ferdige programmer man kan laste ned for å finne og utnytte dem. Sårbarheten som førte til dataangrepet på Stortinget i 2021 ble hyppig utnyttet globalt bare dager etter at Microsoft selv vaslet om problemet.

Dette gjør seg spesielt gjeldende når nulldagssårbarheter oppdages. I et kappløp mellom trusselaktørene og oss som forvalter tjenestene, er det å kunne agere raskt for å patche systemene våre stadig viktigere. Det kan fort bli vanskelig å gjøre i tide for applikasjoner som ikke aktivt forvaltes lenger. Hvis det ikke er noen utviklere som kan teknologien eller den tekniske riggen ikke fungerer lenger, mister man dyrebar tid i dette kappløpet. Så selv om en app ikke har noen kjente sårbarheter i dag, kan den ha et kritisk sikkerhetshull i morgen og da gjelder det å kunne agere raskt.

Manglende vedlikehold av en applikasjon utgjør også en risiko for andre applikasjoner og tjenester i nettverket ditt. Selv om den utdaterte applikasjonen isolert sett ikke inneholder noe viktig informasjon kan den brukes som en vei videre inn i nettverket. Det at tjenester ikke er direkte eksponert på internett kan derfor ofte gi en falsk trygghet.

Man kan nok enes om at å ikke betale renter på et lån er uansvarlig. Vi mener at å ikke betale rentene på ditt produkts sikkerhetsgjeld er like uansvarlig!

Sikkerhetsgjelden i produktet ditt øker over tid fordi nye sårbarheter oppdages hver dag. Ditt produkts verdikjede inneholder en rekke avhengigheter som også er eksponert for denne risikoen. Manglende vedlikehold øker også risikoen. Forskning har vist at nulldagssårbarheter tar i snitt 7 år fra de blir oppdaget, og utnyttet av en hacker, til de blir offentlig kjente og kan mitigeres med en programvareoppdatering. Dermed er det behov for årvåkenhet og å drive forebyggende sikkerhetsarbeid kontinuerlig, slik at man kan forhindre de som utnytter ikke-kjente sårbarheter som ditt produkt kanskje inneholder.

Vi mener derfor at sikkerhetsgjeld må få større fokus fremover!

Hvilke tjenester du vier oppmerksomheten din burde ikke utelukkende være styrt av ny funksjonalitet du skal levere. Gå jevnlig gjennom tjenesteporteføljen du har ansvar for og oppdater riskovurderingene dine. Oppgaver relatert til tjenester det er lenge siden noen har tatt i burde prioriteres høyere, da rentene på sikkerhetsgjelden her er størst.

Metrikker som indikerer hvor lenge siden det er siden forrige endring kan synliggjøre hvor skoen trykker.

Måten du kvitter deg med sikkerhetsgjelden raskere på er å la et produktteam selv organisere hvordan de ønsker å jobbe med vedlikehold og nyutvikling. Det blir en vektskål hvor målet er balanse enn at en dominerer for mye. Bærekraftig forvaltning av et produkt vil si at man kontinuerlig tar unna sikkerhetsgjeld, samtidig som man tar unna teknisk gjeld og øvrige oppgaver som medfølger av å ha ansvar for et produkt og dets funksjonalitet over tid.

“Kill your darlings” betyr at du skal ikke være redd for å kvitte deg med kode. Fordi det var vanskelig å skrive, tok mye tid og krefter eller fordi du løste et problem på en kul måte, betyr ikke at den har livets rett. Det er lett å tenke at en applikasjonen laget for lenge siden, som fortsatt tjener noen få kroner i året har verdi fordi man tilbyr kundene flere produkter.

Den skjulte kostnaden ved å sitte på sikkerhetsgjelden kan være stor. Ta avgjørelsen; kvitt deg med produktet eller gi den oppmerksomheten den krever.

Hold applikasjonsporteføljen oppdatert, og få oversikt over hva du trenger å vedlikeholde. Måten man får bukt med sikkerhetsgjelden på er på mange måter den samme måten som med teknisk gjeld, det er bare viktigere å betale den ned før renten plutselig vokser eksponentielt. Noen ganger er også løsningen å kvitte seg med hele appen, og dermed også gjelden den har.