Det å passe på sikkerheten til et system etter at det har vært satt i drift, har tradisjonelt vært sett på som en (ja, nettopp) driftsoppgave som “de på IT” tar seg av.
Et vellykket programvaresikkerhetsinitiativ må imidlertid også omfatte sikkerhetsoperasjoner eller nettverkssikkerhet, for å sørge for full tilbakekopling til utviklerne.
Når man lager programvare må man også tenke på at hendelser kan oppstå, og ta høyde for at disse må håndteres, f.eks. ved å bygge inn funksjonalitet for logging og revisjonsspor. På den annen side må de som skal håndtere hendelser forstå hvordan programvaren oppfører seg.
Tradisjonelt finnes det vanntette skott mellom utvikling og drift, og følgelig ingen kobling mellom programvaresikkerhet og nettverkssikkerhet. Imidlertid finnes det gode argumenter for å etablere tettere kommunikasjonslinjer mellom de to leirene. Det vil forbedre den generelle sikkerhetsholdningen, og bidrar til bedre kunnskap om applikasjonen som er utviklet. Det vil også legge til rette for å inkludere grunnleggende nettverkssikkerhet på et tidlig tidspunkt, og vil knytte sikkerhetsaktiviteter tilbake til utviklingen på en slik måte at det ivaretar sporbarhet. Sist, men ikke minst, vil det sørge for at utviklingen kan skreddersys til eksisterende sikkerhetsretningslinjer i virksomheten.
Hendelseshåndtering
Hendelseshåndtering er det vi må gjøre når noe går galt – og ofte er det ondsinnede krefter bak. Tradisjonelt er dette noe IT-drift tar seg av, men når systemer man har utviklet selv er involvert, er det flere ting man bør involvere utviklerne i.
Man må eksplisitt definere hvem som skal være ned, og sørge for at fasiliteter er tilgjengelige. Man må kunne hente ut den versjonen som er rullet ut, og kunne følge krav/misbrukstilfeller til rett sted i koden. Her er det ekstra verdifullt hvis man har tilgang til resultater fra tester, sikkerhetstesting og penetrasjonstesting.
Hendelseshåndteringsplan
Man må utvikle en hendelseshåndteringplan som er spesifikk for applikasjonen som er utviklet. En vesentlig komponent er å ha en vaktliste med utviklere som kan kontaktes ved en hendelse. Man må også ha oversikt over hvor de forskjellige versjonene av koden finnes, og ha sentralisert tilgang til vesentlige artefakter fra utviklingsprosessen; inkludert arkitekturdokumenter, resultater fra risikoanalyser, sikkerhetsretningslinjer for virksomheten, trusselmodell, etc. Det må også finnes en rapporteringsmekanisme som kan sikre at informasjonen som er avdekket som en del av hendelseshåndteringen finner veien tilbake til de ansvarlige utviklerne. Det kan også være nødvendig å definere en prosess for håndtering av de forskjellige formene for “bevis” som samles inn i forbindelse med en hendelse, det omfatter hvor man skal lete etter informasjon (loggfiler, monitoreringsapplikasjoner, revisjonslogger), og eventuelt opprettelse av spesielle analysemiljøer for nærmere studering av artefakter. Det er verdt å nevne her at f.eks. i USA er det svært strenge regler for hva som kan brukes som bevis i en eventuell senere rettsak, slik at man i litteraturen ofte finner mange detaljer rundt hvordan man må behandle bevis, hvordan de kan lagres, hvem som kan ha tilgang, etc. I Norge er det imidlertid fri bevisførsel, noe som betyr at hva som helst kan føres som bevis, og det er opp til retten å avgjøre hva som skal tas hensyn til i hvert enkelt tilfelle.
Dev + Ops = DevOps
Kjernen i begrepet DevOps har vært uttrykt slik: “Lager du det – så drifter du det”. Ettersom absolutt sikkerhet ikke er mulig å oppnå, må DevOps også omfatter hendelseshåndtering. Vi stilte oss spørsmålet “hvilke programvaresikkerhetsaktiviteter i BSIMM støtter opp om hendelseshåndtering i DevOps“? Basert på de fem fasene i ISO/IEC 27035, har vi identifisert de forskjellige aktivitetene i BSIMM (versjon 8) som vi mener er relevante for hendelseshåndtering, og plassert dem i den korresponderende fasen i tabellen under (aktiviteter i parantes er i utgangspunktet plassert i en annen fase, men er også relevant der parantesen står).
| Plan | Detect | Assess | Respond | Learn |
| SM2.3 | SE1.1 | (SM2.3) | CMVM2.1 | CMVM1.2 |
| CP2.1 | SE3.3 | (CP2.1) | (SM2.3) | AM2.7 |
| T3.5 | (T3.5) | (T3.5) | ||
| SR3.1 | (SR3.1) | |||
| CMVM1.1 | (CMVM1.1) | |||
| CMVM2.3 | (CMVM2.3) | |||
| CMVM3.3 |
Vi tok utgangspunktet i data om de 109 (primært amerikanske) virksomhetene i BSIMM8-rapporten, samt de 20 offentlige virksomhetene vi studerte på vegne av Difi i 2015, i tillegg til data fra 6 norske utviklerbedrifter som vi hjalp med “veiledet selvevaluering”. Selv om vi sammenligner oss med resultatene i BSIMM-rapporten, så er det viktig å ta med noen forbehold: Vi har resultater fra vesentlig færre virksomheter (26 mot 109), vi har ventelig brukt en mindre dyptpløyende tilnærming enn Synopsys, og vår definisjon av hva som er en “godkjent” aktivitet er sannsynligvis annerledes enn Synopsys’.
Vi fant noen avvik mellom “våre” virksomheter og deltakerne i BSIMM8-studien. “CP2.1 Identifiser personvernrelaterte data” var betydelig mer populær i de norske virksomhetene, noe som kanskje er naturlig gitt norsk og europeisk fokus på personvern (for ikke å nevne GDPR). “T3.5 Etabler SSG kontortid ” gjøres av ~30% av de norske utviklerbedriftene, som er mer enn dobbelt så stor andel som hos BSIMM8 eller de 20 offentlige virksomhetene. “SR3.1 Kontroller risiko fra åpen kildekode” ble gjort av ~40% av de 20 offentlige virksomhetene, som er mer enn dobbelt så mye som hos de to andre. “CMVM3.3 Simulér programvarekriser” gjøres av overraskende få av BSIMM8-virksomhetene, noe som også er tilfelle for “SE3.3 Anvend overvåking av applikasjonsoppførsel og diagnostikk”. Rundt halvparten av de norske virksomhetene gjør “AM2.7 Etabler et internt forum for å diskutere angrep”, mot under 10% for BSIMM8 – kan vi tilskrive dette norsk åpenhet og flat organisasjonsstruktur?
Avslutningsvis kan vi gjenta at hendelseshåndtering må være en integrert del av Dev(Sec)Ops. Det er bra å undervise utviklere om sikkerhet, men å involvere utviklere i hendelseshåndtering er kanskje enda bedre – læringseffekten av å kjenne sikkerhetsproblemer på kroppen er uvurderlig. Hvis du er interessert i flere detaljer, kan du lese hele artikkelen her.