Sikkerhet i utviklingsfart

Et større fokus på sikkerhet i utvikling har vært en positiv og etterlengtet trend over de siste årene. Mens verdiskapning øker gjennom Smidig praksis og etablering av DevOps-kultur i mange organisasjoner, kan det ofte være utfordrende å bygge sikkerhet inn.

Jeg har jobbet med sikkerhet gjennom hele karrieren min og har sett hvordan vi med “sikkerhetshatten” på, med beste intensjoner, ikke alltid har kommet med de beste løsningene for å hjelpe utviklere. Dette har gjerne resultert i innføring av tunge reglement som vi forventer at alle leser, tidkrevende sikkerhetsrutiner som skaper usikre tidsrammer, og eksperter som kan mye om sikkerhet men veldig lite om utvikling. Slikt kunne tolereres før, men nå er det på tide at sikkerhet blir en naturlig del av verdiskapningen.

Det er mye som kan gjøres for å bygge sikkerhet inn i utvikling (siste versjon av BSIMM inneholder f.eks. 119 forskjellige sikkerhetsaktiviteter knyttet til utvikling) og det er mange forskjellige innfallsvinkler. Her er tre råd for å lykkes med å modne din sikkerhetspraksis:

1 – Sikkerhet må være en del av kulturen

Sikkerhetsfolk kan ikke gjemme seg bort og være “temmelig hemmelig” når det kommer til området de jobber med. Det vil i hvert fall ikke hjelpe produkteiere, arkitekter, utviklere og andre som leverer nye spennende løsninger å bli smartere på sikkerhet. Enkelte sikkerhetstema kan være sensitive, selvklart. Men skal man forebygge mot trusler, så må de som skal bygge løsningene være informert og ha tilgang til riktig kompetanse.

Bygg en kultur hvor alle har tilgang til noen med sikkerhetskompetanse som kan hjelpe. Ha en “åpen dør” slik at nysgjerrige får svar på sikkerhetsspørsmål de er usikre på, og vær imøtekommende. En kan lære mye fra å feile, dermed er det viktig at folk tør å si ifra. Noen bedrifter arrangerer såkalte “bug parades” hvor team deler feil de oppdaget, og snakker om hvordan det ble løst og hvordan de har lagt tilrette for at samme feil ikke skjer igjen. Her handler det ikke om å kjefte, men om å gjøre det bedre for alle.

Flere bedrifter og organisasjoner har etablert “security champion” programmer, hvor de rekrutterer noen innenfor utvikling til å bli en slags flaggbærer for sikkerhet i tverrfaglige team. Denne personen er en produktiv del av verdiskapningen, samtidig som de er en rådgiver. På denne måten slipper sikkerhetsavdelingen skaleringsutfordringen ved å løse mange problemer for mange forskjellige team. Det skal også sies at utviklere med sikkerhetsinteresse er, i min erfaring, ofte mye bedre egnet enn sikkerhetsfolk uten utviklingsbakgrunn til å løse sikkerhetsutfordringer i applikasjonsutvikling.

2 – Sikkerhetsrutiner må tjene utviklingsrutiner, ikke motsatt

Sikkerhet er opptatt av å redusere risiko, og en veldig “enkel” måte å oppnå det er å si at ingenting kan gå ut døren inntil sikkerhetsfolkene har sagt at det er greit. Sikkerhetsaktiviteter som prøver å oppdage mulige svakheter og risikoer er utrolig verdifulle, og bør absolutt gjennomføres. Da er det viktig at de er koordinert med alt annet som skal gjøres i løpet av utviklingsløpet.

Engasjer sikkerhet tidlig med utvikling og ha en åpen dialog om hva som kan være relevant og nyttig for sikkerhetsteamet å bidra med. Ikke alle endringer krever en full sikkerhetsgjennomgang, og med bedre innsyn er det lettere å kunne prioritere når og hvordan en sikkerhetsaktivitet bør gjennomføres.

Justér hyppigheten og metodikken for sikkerhetsaktiviteter slik at de passer bedre inn i andre aktiviteter. Trusselmodellering – en gjennomgang av arkitekturen for å finne potensielle svakheter, kan være en 2-timers workshop i stedet for en flere-ukers prosess. Statisk analyse – en automatisk gjennomgang av kildekode for å finne svakheter, kan automatiseres og konfigureres til å passe sammen med andre “pre-deployment” aktiviteter som funksjonelle tester og lignende. Penetrasjonstesting – hvor noen prøver å finne svakheter ved å simulere et hacker-angrep, kan være en aktivitet som utføres på jevnlig basis parallelt med andre aktiviteter fremfor hver gang løsningen skal oppdateres.

Her må risiko balanseres. Det bør settes større fokus på aktiviteter som hjelper utviklere å bygge en sikrere løsning fra begynnelsen, fremfor aktiviteter som finner svakheter sent i prosessen.

3 – Automatisering er ikke alltid løsningen, men det kan hjelpe

Som nevnt tidligere kan enkelte sikkerhetsaktiviteter automatiseres akkurat som andre utviklingsaktiviteter. De fleste løsninger som bygges nå benytter seg av “continuous delivery” verktøy. Disse kan automatisere hele prosessen etter en utvikler oppdaterer kildekoden og frem til den oppdaterte funksjonaliteten blir tilgjengelig for brukerne. (Se min tidligere artikkel om diverse sikkerhetsverktøy som kan automatiseres og hjelpe som del av denne prosessen).

Enkelte sikkerhetsbeslutninger kan også automatiseres, spesielt med tanke på “go live” beslutninger basert på sikkerhetskriterier. I gamle dager (fortsatt vanlig praksis hos en del organisasjoner) var det vanlig med et møte hvor et “Change Advisory Board” gikk gjennom og godkjente hvilke endringer som kunne gjøres i driftsystemer i løpet av neste “Change Window”. I et slikt møte kunne en representant fra sikkerhetsteamet gjerne si at en løsning ikke fikk gå i produksjon på grunn av en utenforstående risiko, eller at en viktig sikkerhetsaktivitet ikke hadde blitt gjennomført.

Dersom et produktteam på forhånd vet hvilke sikkerhetskriterier de må oppfylle, er det mulig at en god del av aktivitetene som må gjennomføres kan automatiseres. Hvis aktivitetene er automatiserte er det mulig at beslutningen om “go live” kan automatiseres også. Det kreves en del arbeid for å få noe sånt på plass, spesielt når enkelte aktiviteter fortsatt er manuelle (f.eks. trusselmodellering). Slike “gates” kan automatiseres som del av en “continuous delivery pipeline”, og kommersielle løsninger er også i utvikling for å gjøre det lettere å definere, automatisere og rapportere på sikkerhetskriterier og beslutninger, som f.eks. det norske firmaet ComplianceDB.

Som sagt, ikke alt kan automatiseres. Men om vi lar automatikken ta hånd om de mer trivielle oppgavene, kan vi benytte kompetansen og erfaringen innen sikkerhet og utvikling til de mye mer interessante og utfordrende oppgavene!

Jeg håper du synes disse rådene er nyttige. Skulle din bedrift ha utfordringer med å bygge sikkerhet inn i utvikling må dere gjerne ta kontakt med meg direkte.