Kultur som fremmer sikkerhet i alle ledd fra konseptutviklingen av produkter helt til ledelse av ansatte er å anse som god sikkerhetskultur. En kultur der spørsmål og nysgjerrighet står sentralt, og hvor det er helt greit og lov å gjøre feil. Gjennom denne artikkelen skal vi prøve å forklare hvorfor man bør strebe etter, og hvordan man kan bygge god sikkerhetskultur i en organisasjon.

Men, hvorfor trenger man sikkerhetskultur, når man heller kan fokusere på å bygge sikre systemer?

Først og fremst er det viktig å innse at mennesker er feilbare. Vi ønsker selvfølgelig ikke feil, men det er utopisk å tro at vi kan eliminere menneskelige feil. Derfor må mennesker være en del av en trusselmodell.

For å enkelt og effektivt beskrive hva god sikkerhetskultur er, og hvordan man kan jobbe for det, prøver vi i denne posten å ta dere gjennom et par scenarioer for de fleste utviklingsteam. Det er vanskelig å uttrykke kultur gjennom ren tekst og vi tror at scenarioene kan hjelpe å forstå bedre.

Scenario 1: Features først, sikkerhet til slutt

Du er tech lead på et prosjekt hvor det ikke er tid eller ressurser til å prioritere sikkerhet. Features er det eneste som betyr noe, og ledelsen tror at sikkerhet er noe man kan gjøre til slutt.

Hvordan får man sikkerhet inn som en del av utviklingsprosessen, og inn på dagsorden?

Først og fremst vil vi oppfordre deg til å løfte problemstillingen med teamet ditt. Opplever alle situasjonen lik som deg? Er løsningen egentlig tilstrekkelig sikret? Det kan være greit å snakke med flere før man går hardere til verks. Får man ikke løst det internt i teamet, anbefaler vi å starte en prosess hvor man har fokus på bevisstgjøring av hvordan sikkerhet bør implementeres som en del av den daglige prosessen.

Kontinuerlige leveranser — en feature er ikke ferdig før sikkerheten også er på plass. Altså inngår det i pakken av “en feature” i det å jobbe kontinuerlig. For eksempel kan man ikke prodsette et nytt API kontinuerlig uten at hvert endepunkt er tilstrekkelig sikret.

Allier deg — prat med de rundt deg, sammen er dere sterkere!

Å utsette er dyr “sikkerhetsgjeld” — kostnaden ved å legge fra seg en feature og ta den opp igjen er høy i seg selv. Det er også sannsynlig å anta at løsningen man implementerer i ettertid ikke vil være like god som når man utvikler selve featuren siden man ikke husker context og omfang like godt.

Opprett rutiner — for å teste systemene jevnlig, både av egne utviklere for eksempel med hack-yourself-first prinsippet eller ved ekstern pentesting. Ved en hendelse vil det også være nødvendig å koordinere med flere personer, og beste måten for å forberede seg på det er ved å ha gode beredskapsplaner og rutiner.

Security Champion —å ha en sikkerhetsutvikler eller Security Champion på teamet gir teamet en god forutsetning for å jobbe tverrfaglig og smidig med sikkerhet.

Scenario 2: Soveputer og falsk trygghet

Sikkerhet er høyt prioritert i organisasjonen. Det er en egen sikkerhetsavdeling som setter meget strenge retningslinjer. Spesielt for for eksempel klientmaskiner. Faktisk så streng at den føles som et hinder for utviklerne. Samtidig vet du at applikasjoner sender data ukryptert, man har fellesbrukere og man er ganske langt fra en zero-trust modell. Likevel har organisasjonen troen på at sikkerheten er ivaretatt.

Hvordan overkommer man slike soveputer, og falske tryggheter?

I første omgang bør hvert utviklingsteam iverksette en kartlegging av sikkerheten. Rent teknisk kan det være “sikkerhetsgjeld” som beskrevet over, og noen ganger kan det være utfordringer som er unikt for domene. Områdene med svakheter bør underbygges av resultater og objektiv informasjon. På applikasjonsnivå er det fint å gjennomføre penetrasjonstester som vanligvis vil avdekke en del av de vanligste feilene, og man sitter gjerne igjen med en fin oversikt over test og resultat.

“Hvor ønsker teamet å være om 3, 6, 12 måneder?” er en fin øvelse for å prioritere hvilket sikkerhetsarbeid som må gjøres for å nå målene man setter seg. For å komme dit må man også snakke om hvilke utfordringer dere har. Det at data går ukryptert i nettverket eller at passordet til databasen ikke har vært rotert på flere år burde ikke være en hemmelighet innad i teamet.

Etter denne kartleggingen kan det vært fint å ta med resultatene høyere opp i organisasjonen for å sikre at risikobildet matcher teamenes. Dere vil sannsynligvis raskt merke at ledelsen og teamene har ulik virkelighetsforståelse av sikkerheten. Det er helt ok — poenget er at nå begynner dere å prate sammen, og samarbeide!

Videre i det daglige anbefaler vi å fokusere på de lavthengende fruktene — kultur tar generelt lang tid å bygge.

Dra i gang lavterskel sikkerhetsforum, hold foredrag, inviter eksterne — men husk å ha fokus på objektiv kunnskapsdeling slik at ledelsen i mindre grad kan argumentere mot det som legges frem.

Scenario 3: Sikkerhet uten kompetanse

Ingen på teamet har noe særlig kompetanse på sikkerhet, og ledelsen har uttrykt ønske om å løfte sikkerheten i organisasjonen.

Hvordan motiverer man og skaper en kultur i teamet for å øke bevisstgjøring av sikkerhet?

Dette er en gylden anledning til å utfordre seg selv. Det er mange som unngår sikkerhetsoppgaver — det er ofte komplisert og feil kan få store konsekvenser. Ansvaret for å lage tilstrekkelig sikrede løsninger ligger i teamet og det er derfor fint at ledelsen ønsker å løfte sikkerheten. Så fremover bør dere som team sette av tid til kompetanseheving. Dette kan man gjøre gjennom felles workshops, forberede foredrag, eller ved å hente inn sikkerhetskompetanse for å komme i gang.

Et alternativ er å anbefale ledelsen å opprette et kompetanseteam. Det kan være et eget team som jobber aktivt med sikkerhet i organisasjonen, eller et team basert på security champions i ulike teams. Autonome team vil sjeldent ha all kompetanse som trengs for å løse alle oppgaver, så å bringe inn ekspertise ved behov blir en kunst å få til.

Allikevel er det gjennom praktisk erfaring man lærer mest, og best! Derfor er vår sterkeste oppfordring å høre med andre i selskapet hvilke sikkerhetstiltak dere kan iverksette og bruke mye tid på dette fremover. Det kan også være fin trening å la flere i teamet løse samme oppgave for å diskutere beste løsning, samt å lære av hverandre!

God kultur bygges ikke ovenifra og ned. Bygg sikkerhetskultur nedenfra opp, og se verdien i å utøve sikkerhet som en del av utviklingsløpet.