Hvordan kan utviklere introdusere mindre sårbarheter?
Tenker vi tilbake til min tidligere artikkel om fuzzing, så skjønner man raskt at input-validering er avgjørende for god sikkerhet i applikasjonen man skriver.
Her er noen tips og tanker rundt hvordan vi kan lage tryggere applikasjoner og ta lærdom og hjelp ut av DevSecOps.
Vær defensiv
Utviklere må være defensive! Defensive utviklere lager tryggere kildekode.
Dersom du skal sikre input-feltet i en applikasjon, bør ikke vurderingen være hvilke tegn som skal blokkes. Men heller hvilke tegn som skal tillates. Dessverre er det mange som vegrer seg å gå for alternativet om å kun tillate et utvalgt antall tegn, i stor grad på grunn av feilsituasjonene som kan oppstå. Med andre ord: "block-lists" mot "allow-lists".
Et eksempel: Applikasjonen forventer at brukeren skal skrive inn navnet sitt. Et defensivt utgangspunkt er å kun tillate alfanumeriske verdier (regex: [a-zA-Z0-9]). Da tillater man jo vanlige navn som "Harald 5 av Norge", men nei, vi har jo glemt å tillate mellomrom, samt mange navn inneholder apostrofer eller tegn som ikke er i det norske alfabetet; hva da med navnet "Ørnulf"?
Skjulte prompter på nettsider gjør chatbotter til utspekulerte svindlere
Må være raske på ballen
Målet er at utviklere tar i bruk DevOps-konseptet og raskt være på ballen for å fikse problemene i det de oppstår. Dette skjer gjennom aktiv overvåkning og patching av applikasjonene. Å være defensiv forårsaker gjerne flere potensielle feilsituasjoner, men samtidig færre sikkerhetssårbarheter.
Dette krever at utviklere er raskere på ballen på å identifisere feilene og ta tak i feilene, sånn at det ikke går for mye utover brukeropplevelsen. Dessverre er det allerede her mange allerede taper: Det er et så stort fokus på oppetid, brukeropplevelsen og minst mulig feilsituasjoner at man heller tar sjangser med sikkerheten...
Heldigvis har vi mange ferdigskrevet biblioteker som gjør det mye lettere å enkelt legge på beskyttelse. Utviklere bør ha kjennskap til slike biblioteker og sikre at de er implementert på tvers av applikasjonene. Personlig har jeg god erfaring med biblioteker som AJV (Another Json Validator).
- Gi sikkerhetsoppgavene til sikkerhetsutviklere!
Må kontinuerlig overvåke
Det må sies at DevOps støtter veldig fint opp under sikkerhetsovervåkning. Når disse fagfeltene smeltes sammen kalles det ofte DevSecOps. Ved kontinuerlig utvikling og releases blir det også et behov for kontinuerlig overvåkning, noe sikkerhet kan dra stor nytte utav.
Utviklere har etter min erfaring vært flinke til å dra informasjon og statistikk fra applikasjonene ut i grafer, for eksempel via Grafana. Dette med formålet å få frem når applikasjoner oppfører seg unormalt, som ved at en oppdatering har forårsaket bugs eller annen moro.
Dette kan hjelpe på sikkerhet på mange måter, for eksempel om en utvikler plutselig ser et stor sprik i grafene som viser HTTP 500-feilmeldinger (feil på serverside) i applikasjonen sin? Ja, da er kanskje en hacker på besøk. Når hackere leter etter sårbarheter vil de typisk fremprovosere et stort antall HTTP 500- feilmeldinger mens sårbarheten blir utnyttet.
Nå forteller LastPass om hvordan hackerne klarte å bryte seg inn
Kan ta utviklingen til nye høyder
Konvensjonell sikkerhetsovervåkning har ofte fokusert på logger og korrelasjon mellom disse for å peke på ondsinnede hendelser. Dette er krevende: Mange leverandører av SIEM (Security Information Event Management) ender opp med signaturer rundt hva ondsinnet betyr, og så lenge en angriper klarer å unngå signaturene, så flyr de under radaren.
En bedre fremgangsmåte er å sikre en forståelse av hva normal drift er, og så peke på avvik fra normalen. UEBA (User and Entity Behavioral Analytics) prøver å hjelpe her, men sliter ofte med mye falske positiver enn så lenge. Det fine med en fremoverlent DevOps organisasjon er at man ofte får en kjempegod windikator når unormale hendelser skjer.
DevOps setter opp skjermer med grafer og oversikter, med terskelverdier som automatisk varsler ved avvik. Dette identifiserer avvik fra normalen og tillater oss å reagere og undersøke hendelsen: kanskje det er en hacker på ferde.
Dette kan betegnes som DevSecOps og er noe som virkelig kan ta både utvikling-, sikkerhet- og drifts-organisasjonen til nye høyder.