Programvaresikkerhet handler om sikker funksjonalitet snarere enn sikkerhetsfunksjonalitet, dvs. å lage programvare slik at den oppfører seg som forventet også når den utsettes for angrep. Det finnes en lang rekke anbefalte aktiviteter som kan bidra til å nærme seg dette målet, men hvor skal man begynne? Etter fem års forskning på dette temaet har vi et forslag til ni steg som kan representere en slik begynnelse.
1. Definer hva som er “god nok” sikkerhet for deg
Hvis du er heldig, har du allerede noen eksplisitte krav som reflekterer et sikkerhetsbehov. Dersom du behandler personopplysninger, må du forholde deg til personopplysningsloven og GDPR som stiller krav til innebygget sikkerhet. Sannsynligvis har også dine kunder krav til sikkerhet – men de er ikke alltid klar over dem på forhånd! En måte å sette dette i system på er å ha et eget møte i begynnelsen av et utviklingsprosjekt hvor man konkretiserer forutsetninger og intensjoner for sikkerhet, og så gjenta møtet med faste mellomrom for prosjekter som går over tid. Vi kaller dette for sikkerhetsintensjonsmøter.
2. Studer og vurder dine eksisterende programvaresikkerhetsaktiviteter
De aller fleste virksomheter gjør allerede en god del programvaresikkerhetsaktiviteter, selv om de ikke nødvendigvis har en full oversikt eller har satt dem i system. Ved hjelp av Building Security In Maturity Model (http://bsimm.com) kan man gjøre en selvevaluering, og samtidig sammenligne seg selv med andre programvarevirksomheter. Det er ikke gitt at aktiviteter som gjøre av mange er egnet for alle virksomheter, men dersom en stor andel av virksomheter som man liker å sammenligne seg med gjør en aktivitet som du ikke gjør, er det i hvert fall grunnlag for å ta en vurdering på saken. OWASP har en konkurrerende modenhetsmodell (https://owasp.org/www-project-samm/) som kan være et alternativ – det handler mest om personlige preferanser.
3. Eksplisitt legg til programvaresikkerhetsaktiviteter i utviklingsprosessen
Alle har en programvareutviklingssyklus (SDL), også når den ikke er formalisert eller dokumentert. På samme måte burde alle ha en programvaresikkerhetsutviklingssyklus (SSDL), men vår erfaring er at dersom man ikke gjør programvaresikkerhetsaktivitetene eksplisitte, så har det lett for å bli nedprioritert eller glemt – dette gjelder spesielt når man driver med smidig utvikling. Ett alternativ er å se på Microsofts Security Development Lifecycle for smidig utvikling (SDL Agile), hvor man har delt programvaresikkerhetsaktivitetene i tre grupper: 1) Gjøres en gang per prosjekt, 2) Gjøres en gang per sprint, og 3) Et utvalg gjøres i hver sprint. De siste refereres til som “bøtte-aktiviteter”, som om man har en bøtte som man trekker fra i hver sprint; etter et antall sprinter skal man ha vært gjennom alle disse.
Det viktigste er imidlertid at du finner fram til en SSDL som passer for din virksomhet!
4. Tenk nytt rundt roller og ansvar for sikkerhet
Tradisjonelt har sikkerhet vært noe som “folka på IT-drift” har tatt seg av – men programvaresikkerhet er noe mer enn brannmurer og antivirus! Sikkerhet burde være hver utviklers ansvar, men det er lite sannsynlig at å ansette en sikkerhetsekspert til å løpe rundt å fortelle utviklerne hvor dumme de er vil føre til bedre programvaresikkerhet. Vi har mer tro på å sørge for at hver utviklergruppe har en sikkerhetsforkjemper som i utgangspunktet kanskje ikke er en sikkerhetsekspert, men som er over gjennomsnittet interessert i sikkerhet, og som kan prioriteres for kursing på programvaresikkerhet, både teknisk og prosess. Sikkerhetsforkjemperen kan bidra til tekniske aktiviteter for sikkerhet, trusselmodellering, og prioritering av programvaresikkerhetsaktiviteter; og kan hjelpe til med innføring av sikkerhetsstrategi for produktet. På denne måten kan man bidra til at utviklerne blir selvforsynt med sikkerhet, og man kan bygge videre på konseptet via samarbeid med andre på tvers av virksomheten. På denne måten kan man bygge opp et “sikkerhetslaug” hvor man deler kompetanse og erfaringer.
5. Lag ditt eget opplæringsprogram
W. Edwards Deming (han med sirkelen for kontinuerlig forbedring) skal ha uttalt: “Det er ikke nok å gjøre sitt beste; man er nødt til å vite hva man skal gjøre, og så gjøre sitt beste”. En virksomhet må sørge for at utviklerne har grunnleggende ferdigheter inne programvaresikkerhet; per i dag kan man ingen måte anta at dette er noe de har lært som en del av utdanningen. Det finnes mange forskjellige typer opplæring, fra tradisjonell instruktørledet via eLæring (nano-læring) til veiledning og mentoring. Det siste er spesielt gunstig å kombinere med sikkerhetsforkjempere, og man kan også ha større arrangementer hvor man en eller flere ganger i året kjører simuleringer og rollespill etterfulgt av gruppediskusjoner.
6. Finn måter som lar utviklerne begynne å tenke som en angriper
Hva er det verste som kan skje? Hvis utviklerne lærer seg å se applikasjonen fra en angripers synsvinkel, er de også nærmere å oppdage potensielle sårbarheter og sikkerhetsfeil i designet. Trusselmodellering er en strukturert måte å tilnærme seg dette; vi har funnet at det å skissere opp et dataflytdiagram for (deler av) applikasjonen, og deretter bruke sjekklister av angrepstyper slik som STRIDE er et lavterskel alternativ som de fleste kan gjøre med minimalt av opplæring. Spesifikke angrep kan detaljeres vha. misbrukseksempler og/eller angrepstrær – det siste er også svært gunstig når man senere skal spesifisere sikkerhetstester.
7. Identifisering og dokumentering av sikkerhetskrav
Selv om programvaresikkerhet handler om sikker funksjonalitet snarere enn sikkerhetsfunksjonalitet, kan man ikke ignorere at mye programvare også trenger det sistnevnte, og at man må ha en bevisst holdning til dokumentering av funksjonelle så vel som ikke-funksjonelle sikkerhetskrav. GDPR har også løftet fram behovet for innebygget personvern – dette er alltid en god ide, men dersom du skal behandle personopplysninger er det også et krav som du potensielt kan betale dyrt for å ignorere.
8. Introduser sikkerhetsverktøy i arbeidsflyten
Finn gode verktøy tilpasset din egen utviklingsmetodikk, og lær deg å bruke dem. Alle burde bruke verktøy for statisk analyse, og sørge for at disse er konfigurert for å se etter sikkerhetsproblemer. Automatiser så mye som mulig! I SoS-Agile har vi laget modulen JiraSec som leter gjennom Jira og automatisk flagger saker som kan ha med sikkerhet å gjøre.
9. Definer en systematisk tilnærming til sikkerhetstesting, penetrasjonstesting og sett pris på sikkerhetsfeil (bug bounty)
Alt for mange norske virksomheter utfører kun funksjonelle tester, og overlater sikkerhetstesting til “noen andre”. Sikkerhetstesting må inn som en del av det ordinære kvalitetssikringsarbeidet, og elementer fra penetrasjonstesting kunne også tas i bruk av egne utviklere/testere, i tillegg til mer tradisjonell penetrasjonstesting som utføres av eksterne eksperter i forbindelse med utrulling av et ferdig system. En periodisk øvelse hvor utviklere kappes om å angripe hhv. forsvare applikasjoner kan både være en sosial aktivitet og et reelt bidrag til bedre programvaresikkerhet. Virksomheten kan også vurdere å innføre et system for belønning av innrapporterte sikkerhetsfeil.
(Dette er en utvidet versjon av en kronikk vi publiserte i Computerworld Norge i oktober 2020)
Photo by Shamia Casiano from Pexels