Reaktive tall er de enkleste å måle; hvor mange spam-eposter har vi blokkert, hvor mange vanilla angrep har brannmuren eller IPSen forhindret, hvor mange merkelige hendelser har IDSen varslet om. Alle hendelser må loggføres, og de må markeres om de var falske positiver eller ikke. Mange klassifiserer de forskjellige sikkerhetsområdene og legger ansvaret for implementeringen til autonome team. Lokal infrastruktur, driftsleverandører (det være sky eller on-prem), endepunkter (laptoper, BYOD), hyllevare produkter, applikasjonsutvikling og forvaltning. Uansett hvordan du kategoriserer dette, så leder alle veier til Rom.
Som min tidligere kollega Arne Asphjell alltid sa «Du får hva du måler», og hvis ingen måler sikkerhet så får du svært lite, og hvis ingen har noen incentiver for å levere på sikkerhet, så er det kanskje fordi de ikke blir målt på det. Hvorfor skjer dette? Jeg arbeider primært mot offentlig sektor og møter sjelden noen som har klare sikkerhetskrav i sine rollebeskrivelser. Det finnes abstrakte strategier om hva som skal gjøres, men sjelden konkret hvordan dette skal implementeres, monitoreres og vurderes.
Det finnes mange forskjellige typer sikkerhetskontroller som man igjen kan dele inn i forskjellige kategorier. Vi har sikkerhetskontroller gruppert etter tid:
- Preventive kontroller
- Oppdagende kontroller
- Korrigerende kontroller
Sikkerhetskontroller innenfor de tre forskjellige tidsrommene deles deretter opp i forskjellige områder som:
- Fysiske kontroller
- Prosess kontroller
- Tekniske kontroller
- Juridiske kontroller
Sikkerhetskontroller innen disse områdene og tidsrommene er tiltak som implementeres for å håndtere risikoer som deles opp i de klassiske Konfidensialitet, Integritet og Tilgjengelighet.
For å kontrollere og styre dette trenger man et ISMS (Informasjonssikkerhet Forvaltningssystem) og en rekke roller. Bøker på hundrevis av sider er skrevet om dette, så vi skal fokusere spesifikt på ett området innen Preventive kontroller: Hvordan måle sikkerheten på programvareutvikling i vår smidige hverdag?
1. Secure Software Development Lifecycle
Uansett hva slags applikasjon du utvikler, uansett hvor applikasjonen skal kjøre og uansett hva slags data den behandler eller brukere den skal ha, så legg deg til vane (forresten, gjør det til et krav i virksomheten din) at utviklerteamene benytter Secure Software Development Lifecycle. Det finnes sertifiseringsløp på CSSLP og det finnes mange åpne standarder du kan finne på internett (Microsoft sin SDL finnes i både tradisjonell fossefall oppskrift og som smidig).
Å kreve at alle dine team kjører en form for sikker utviklingsmetodikk med klare krav til sikkerhetskontroller som skal implementeres basert på hva som utvikles, med tydelig roller og ansvarsbeskrivelser, er sannsynligvis det beste og mest effektive du kan gjøre.
Dette vil bare fungere hvis virksomheten gjør det til en del av sin strategi og bevilger penger og tid til opplæring og trening. Som den legendariske basketballtreneren John Wooden sa «If you don’t have time to do it right, when will you have time to do it over». Det blir aldri billigere å implementere sikkerheten enn i dag.
Legg også detaljerte krav til leverandører og underleverandører om forventningene til sikkerhetskontroller. Det er viktig at ressurser og penger blir øremerket med tid og sum for implementering av dette.
Da det kommer til å måle metrikker på sikkerhet kan man dele det opp i to typer.
- Bevissthet og kompetanse
- Tekniske
Det å kjøre Secure Development Lifecycle drar sikkerhet inn som en del av den daglige driften og blir en del av kulturen. Man kan enten kjøre offentlige sertifiseringsløp for å måle kvaliteten, eller utvikle sine egne interne tester/sertifiseringer som ansatte må bestå.
Vil du jobbe med sikkerhet i twoday? Vi søker sikkerhetskonsulent! Les mer om stillingen her.
2. Sikkerhetstester
Enhetstester er i dag standard hos utviklerteam og testdekning regnes ofte ut etter antall kodelinjer. Personlig synes jeg det er litt feil å si at man har 80% test dekning fordi man tester rundt 80% av kodelinjene. En applikasjon befinner seg i så mange forskjellige states og er påvirket av alt omliggende og forvaltning at du er sannsynligvis aldri er i nærheten av faktisk 80% på en kjørende applikasjon. Allikevel er enhetstester for sikkerhet første kontroll du kan implementere og det som oppdages her er billigst å fikse. Så legg til vanen å ha abuser-stories og abuse cases på kode som omhandler autentisering, autorisering, session management, nøkkelhåndtering, kommunikasjon med andre applikasjoner, databehandling (input og output), database spørringer, datalagring, m.m.
Når en utvikler er ferdig med koden sin, QA er kjørt og den sjekkes inn så skal den testes. Hvis dette er kode som omhandler noe fra trusselmodellering, og risiko- og sårbarhetsanalysen, så skal de utføres manuelle sikkerhetstester på denne funksjonaliteten før den går til produksjon.
All kode som bygges og deployes går igjennom en bygg pipeline som verifiserer kodekvalitet (statiske scannere). Her bør man også benytte sikkerhetsscannere som Burp Enterprise, ZAP eller AppScan (for å nevne noen) som kan oppdage kjente brister automatisk.
3. Bug Bounty Program
Som nevnt så vil utviklerne alltid introdusere bugs, men har man en godt innarbeidet Secure Development Lifecycle og god dekning på sikkerhetstester vil man kunne avdekke disse feilene raskt. Loggføring på hvor ofte man oppdager nye bugs er viktig.
Det vil alltid være bugs som enhetstestene, statiske kodeanalyse verktøy, manuelle tester eller penetrasjonstester ikke klarer å finne grunnet at man alltid har for lite tid. Derfor kan det ha stor positiv effekt om man tar i bruk bug bounty programmer. Da vil hackere sitte å lete etter feil i applikasjonen din gratis, i håp om å avdekke feil de kan dokumentere og så få betalt for.
Hvor mange feil finner de? Hva er kritikaliteten på feilene? Hvilke utvikler team har flest feil?
4. Time-To-Fix
Noter tiden virksomheten bruker på å fikse programvarefeil fra de blir oppdaget til de er fikset og produksjonssatt. Det vil alltid bli introdusert bugs. Du vil aldri komme unna dette, men hvor raskt du klarer å finne de og fikse de er en sterk indikator på sikkerhets kvaliteten i applikasjonen. Har du flere utviklerteam kan dette vise hvilke teams som trenger mer trening, fler folk eller belyse andre utfordringer de har.
5. Sårbarhetshåndtering
I dag benyttes mye kode som man ikke har utviklet selv. Rammeverk og biblioteker både på applikasjonsnivå, mellomvarenivå, men også på infrastrukturnivå hentes fra internett og legges til å jobbe sammen med dine mest sensitive data. All denne koden har også sårbarheter i dag og nye som blir oppdaget i morgen. Noen må følge med på dette, og hele tiden vurdere hvordan dette endrer risikobilde. Dette vil kunne gi gode indikatorer på hvor god sikkerheten faktisk er i tredjepartskode, og om man må oppgradere eller i verste fall finne alternativer fordi det man valgte viser seg å være for dårlig.
Noen på hvert utviklerteam må ha ansvar for å følge med på sikkerhetshull relatert til tredjepartskode og loggføre dette. Man bør sette en smerteterskel for antall sårbarheter man kan akseptere. Dette vil hjelpe andre utviklerteam med valg av teknologi når de skal starte opp.
Les hvordan twoday jobber for å ivareta sikkerhet og personvern hos Helsedirektoratet.