Programvaresikkerhet er nødvendig for all programvare! Imidlertid må vi innse at sannsynligheten er liten for at alle utviklere skal hive seg på alle de 113 aktivitetene i BSIMM på en gang. Hvor kan man da begynne? Gary McGraw lanserte for over 10 år siden en samling med god praksis for programvaresikkerhet som kanskje kan være et godt utgangspunkt.
Trykkpunktene er illustrert i figuren over, fra venstre mot høyre, fordelt på fasene i en tradisjonell vannfallsmetodikk. McGraw har senere laget dette om til en liste prioritert etter grad av effektivitet:
- Kodegjennomgang
- Arkitekturanalyse
- Penetreringtesting
- Risikobasert sikkerhetstesting
- Misbrukstilfeller
- Sikkerhetskrav
- Sikkerhetsdrift
De første 4 har vi allerede skrevet om i tidligere blogger (se linker i listen), men vi kan her bruke litt tid på de siste 3.
Misbrukstilfeller
Jeg skal være den første til å innrømme at dette ikke er noen god oversettelse av “abuse cases” (eller “misuse cases”), men jeg er mottagelig for andre forslag.
Misbrukstilfeller er en teknikk som brukes i kravfasen for å identifisere sikkerhetskrav. Man tar utgangspunkt i UML Use Cases, og utvider disse med handlinger utført av en angriper. I sin ytterste konsekvens snakker vi her om å tegne diagrammer som vist under:
Imidlertid må vi innse at de færreste utviklere setter seg ned og tegner slike diagrammer i dag, så derfor er det mer nyttig å tenke på den bakenforliggende hensikten, nemlig å tenke som en angriper. Hvordan kan noen misbruke denne funksjonaliteten? Hva kan en angriper gjøre? Hva kan vi i så fall gjøre for å hindre angriperen?
Sikkerhetskrav
Det er ganske åpenbart at funksjonelle sikkerhetskrav er viktige; hvis vi skal begrense tilgang til informasjon trenger vi autentisering, hvis vi er bekymret for avlytting må vi ha kryptering, og hvis vi er opptatt av hva som har skjedd trenger vi logging. Like viktig er imidlertid de ikke-funksjonelle sikkerhetskravene; hvor sterk kryptering trenger vi, hvordan håndterer vi personvern, hvem skal ha tilgang til hva, etc. Mange sikkerhetskrav vil åpenbare seg som et resultat av arbeidet med misbrukstilfeller.
Vi starter gjerne arbeidet med sikkerhetskrav ved å se på hvilke aktiva (assets) som finnes i systemet. Når du vet hva du har som du må beskytte, er du ett skritt nærmere å vite hva du må gjøre for å oppnå dette.
Sikkerhetsdrift
Dette er spesielt aktuelt for de som drifter programvare som de har utviklet selv – ved å overvåke input til applikasjoner, og mate feil som oppdages i driften tilbake til utviklerne, kan sikkerhetshull lappes raskt. Hvis man driver etter DevOps-filosofien, er det enten de samme som har utviklet et system som står for driften av det, eller så er det velsmurte kommunikasjonslinjer mellom utviklere og driftere.
I BSIMM er det spesielt områdene Programvaremiljø og Konfigurasjonsstyring som har relevante aktiviteter relatert til sikkerhetsdrift; vi nevner i fleng:
- SE1.1: Overvåk input til applikasjonene
- SE3.3: Anvend overvåking av applikasjonsoppførsel og diagnostikk
- CMVM1.1: Opprett eller opprett kontakt med hendelseshåndtering
- CMVM1.2: Identifiser programvarefeil som oppdages ved overvåkning av driften, og mat disse tilbake til utviklingsavdelingen
- CMVM2.1: Ha et system for å gjøre hurtige krise-endringer i koden når en applikasjon er under angrep
Konklusjon
Ingen blir ekspert i programvaresikkerhet over natta, men hvis man starter i rett ende kan man raskt oppnå en vesentlig forbedring. Det viktigste er å begynne!
Illustrasjon av Misuse Case Diagram ved Marcel Douwe Dekker, CC BY-SA 3.0