Uken før påske var travel for alle som jobber med informasjonssikkerhet. Heartbleed-sårbarheten i OpenSSL var unik i hvor bredt nedslagsfelt den hadde, hvor mange tjenester og brukere som ble berørt. Den var ikke unik som et eksempel på hva en enkel programmeringsfeil kan medføre. Det er en klar sammenheng her: programvare har sårbarheter, angripere utnytter disse sårbarhetene for å nå sine mål. Og, sårbarheter i programvare oppstår fordi utviklere gjør feil. Enten fordi de ikke vet bedre, eller rett og slett bare fordi alle gjør feil av og til.
I dette tilfellet har vi hørt fra utvikleren som var ansvarlig for kodebiten som inneholdt sårbarheten. OpenSSL er skrevet i C, et språk som gir mye frihet til utviklerne og derfor også stiller store krav. Koden som inneholdt Heartbleed-sårbarheten er skrevet av en erfaren utvikler som glemte å gjøre en sjekk av minnebruken, noe som tillater at det leses ut en større mengde informasjon fra minnet enn hva som var meningen. OpenSSL-teamet hadde gode rutiner, inkludert kvalitetskontroll før ny kode tas inn, men denne feilen ble ikke oppdaget i kvalitetskontrollen heller.
Nå som stormen har lagt seg, de fleste tjenester er oppdatert, passord er byttet der det var nødvendig og Internett atter er et relativt trygt sted å være, er det på tide å se nærmere på rotårsaken: hvordan kunne Heartbleed forekomme? Og hva kan vi gjøre for å redusere sannsynligheten for tilsvarende feil i fremtiden?
Det er lett å tenke at løsningen er enkel: vi må bare slutte å bruke disse utrygge programmeringsspråkene. Men, nei det er ikke så enkelt. Det er mulig å gjøre feil i alle programmeringsspråk. Bare ulike typer feil, som har ulike konsekvenser. Det handler mer om å ha kunnskap til å bruke språket riktig, og gode nok mekanismer til å fange opp feil.
Whitehat Security publiserte nylig en rapport der de har sett på sikkerhetsutfordringen i de vanligste programmeringsspråkene brukt i webapplikasjoner. De tre mest brukte språkene er .Net (28 %), Java (25 %) og ASP (16 %). Ifølge rapporten fra Whitehat Security er det ingen vesentlig forskjell mellom disse i antall sårbarheter. De har alle i snitt 11 sårbarheter per «slot» (en «slot» definerer de som grensene til en webapplikasjon). Tallene var vesentlig lavere for bla Perl og ColdFusion. Rapporten er anbefalt lesning for de som måtte være interessert i mer detaljer.
Poenget her er at selv disse «moderne» språkene ikke er feilfrie eller 100 prosent trygge. De må fortsatt brukes riktig for at man skal unngå å lage applikasjoner som har sårbarheter.
Ulike programmeringsspråk har ulike fordeler og ulemper. Hva man velger å bruke er som regel en sammensatt beslutning, som ofte inkludere hensyn til hva utviklerteamet er kjent med og hva slags type applikasjon man skal lage. Altfor sjelden er dessverre sikkerhet en del av denne beslutningen.
Høsten 2011 gjorde en student ved NTNU, Pål Thomassen, en undersøkelse for å se på sikkerhet i praksis hos programvareindustrien i Norge. Poenget var å sammenligne hva lærebøkene og teorien sier man skal gjøre, men hva som i realiteten gjøres i industrien. Resultatet var varierende, men den ene tingen alle hadde til felles var at de hadde planer for håndtering av bugs og utrulling av nødvendige sikkerhetsoppdateringer etter produksjonssetting. Det er jo mildt sagt et nedslående resultat, og det er ingen grunn til å tro at situasjonen er endret siden da. Det dette egentlig betyr er: vi vet vi vil gjøre feil, og når vi gjør feil har vi en plan for å håndtere det. Og det peker tydelig på at sikkerhet i stor grad fortsatt er en reaktiv, og dessverre ikke proaktiv, prosess.
Statistikk fra NVD, CVE og siste Symantec Internet Security Threat Report viser at antall sårbarheter oppdaget per år de siste 10 årene er rimelig jevnt. Tallet er stabilt på omkring 5000 nye sårbarheter per år. Fokus på sikkerhet har økt i disse årene, men sårbarhetene blir ikke færre. For at det skal skje, må sikkerhet få et større fokus i systemutviklingsprosjekter enn det har i dag. Det må bli en del av prosjektet hele veien. Fra et bevisst valg av programmeringsspråk, til opplæring av utviklere og ikke minst må det testes og kvalitetssikres gjennomgående med fokus på sikkerhet. Vi trenger å bli bedre på å unngå å gjøre slike feil til å begynne med, og bedre på å fange de opp og luke de ut før kode settes i produksjon.
Teamet som utviklet OpenSSL gjorde mye av dette. Allikevel snek denne feilen seg inn i koden. Det viser oss at det ikke finnes noen garantier for å unngå feil. Akkurat som alle vet at 100 prosent sikkerhet i de fleste tilfeller er umulig å oppnå. Men, det er helt sikkert at vi kan gjøre mye mer enn det vi gjør i dag. Og løsningen begynner og slutter med kunnskap. Bare når vi kjenner til de mulige fellene, kan vi unngå å gå i dem.
_logo.svg.png){kind=logo}
Delta i debatten
Informasjon om debattinnlegg og kronikker i digi.no
Alle innlegg må sendes til redaksjon@digi.no. Husk å legge ved et portrettbilde. Vi forbeholder oss retten til å redigere innsendt materiale.
