Av Jan-Kåre Solbakken, Julian Ravn Thrap-Meyer og Sondre Halvorsen, NAV IT
NAV har mange flinke sikkerhetseksperter, men enda flere team som forvalter og videreutvikler et stort antall applikasjoner.
Hvordan jobber man med sikkerhet i en slik organisasjon?
Den klassiske oppskriften
Alt var enklere før, også IT-sikkerhet. Prosjektet skrev en detaljert kravliste, leverandøren skvisa inn implementasjonen i lett panikk den sista uka før hovedleveransen; underskrifter, penger og rapporter om testdekning ble utvekslet og så gikk alle fornøyde hjem.
Vi visste jo egentlig ikke hvor sikre vi faktisk var, men vi var i det minste compliant.
Hvis kravspek-en eller testavdelingen mot formodning skulle ha oversett noe så var vi jo uansett beskyttet av høye murer rundt de ulike delene av nettverket.
Denne tilnærmingen fungerer ikke like bra i en verden med sky, “zero trust” og autonome produktteam, som til sammen deployer endringer til produksjon et par hundre ganger om dagen. De tradisjonelle forsvarsmekanismene i nettverket må fortsatt være der, men hvordan bør teamene drive med sikkerhet i applikasjonslaget?
- Skal vi være best på digitalisering, må vi være best på sikkerhet
DevSec... HvaForNoe?
Løsningen er at sikkerhet blir en del av teamets ansvarsområde og jobbes med kontinuerlig på samme måte som alle andre tekniske og funksjonelle oppgaver. Denne måten å jobbe på omtales ofte som “DevSecOps” eller “shift left security”.
Det høres jo fint og flott ut, men hvordan gjør man det i praksis? Er dette bare å pålegge team enda flere oppgaver, i en skog av features som burde ha vært levert i går? Hvordan skal man sørge for at teamene har den nødvendige verktøykassen og kompetansen til å jobbe aktivt med sikkerhet i produktene sine?
Og ikke minst: hvordan kan vi legge til rette for at de skal synes det er gøy og noe de faktisk ønsker å drive med?
Den enkle delen (maskiner)
I NAV IT har vi valgt å angripe dette fra to vinkler.
Den ene er den tekniske.
Plattformen vår tilbyr støttetjenester som for eksempel WAF og “service mesh”. For å holde styr på avhengighetene i koden vår bruker vi Snyk. Vi har også utviklet biblioteker og verktøy som gjør det enklere for teamene å bruke OAuth og OIDC. “Det skal være lett å gjøre det rett”.
«Målet er å skape et community der folk kan lære og dele.»
Den vanskelige delen (mennesker)
Den andre vinkelen, som er vanskeligere enn den første, er å bygge sikkerhetskultur og få teamene til å prioritere sikkerhet i en travel hverdag.
I en organisasjon på NAVs størrelse (75 produktteam) vil det alltid være varierende sikkerhetskompetanse mellom team, og ulike mennesker nærmer seg problemet på ulike måter.
For å bøte på dette har vi startet et opplegg med “security champions”, inspirert av OWASP sin definisjon. Målet er å skape et community der folk kan lære og dele. En champion skal være det vi har kalt “teamets sikkerhetssamvittighet”, den som snakker sikkerhetens sak i det daglige arbeidet og sørger for at sikkerhet er et moment i avgjørelser som tas om teknologi og arkitektur.
“Champs’a” har ikke noe formelt ansvar for sikkerheten i produktene, det ansvaret hviler på teamet som helhet, sammen med de som eier teamets rammevilkår. Vi stiller ingen krav om forkunnskaper for å bli security champion, det holder at vedkommende har interesse. Nødvendig kompetanseheving gjør vi enten internt eller med eksterne kurs og foredragsholdere.
Security Champions v1
Det første forsøket på å stable på beina dette miljøet feilet.
Som i de fleste store organisasjoner, var ryggmargsrefleksen å starte med pålegg og forskrifter og tenke at resten ville gå av seg selv. “Alle team SKAL ha en security champion som skal gjøre sånn og sånn”.
Vi lærte fort at forskrifter er et lite effektivt virkemiddel for å bygge kultur, og at hvis ingen sørger for å drive initiativet framover og skape interesse så dør det hele sakte ut av seg selv. På toppen av dette dukka det opp en aldri så liten pandemi som sørget for at andre ting plutselig hasta mye mer.
- Open source var ikke problemet med Log4Shell
Security Champions v2
Nå som det verste Covid-kaoset har roa seg, er vi derfor i gang med en ny iterasjon. Denne gangen baserer vi oss på tillit og frivillighet.
Det skal være moro og givende å være security champion, og vi kommer til å jobbe aktivt med å holde oppe interessen. Vi i arrangørgruppa har tatt på oss å være pådrivere og ordne med det praktiske, som å arrangere samlinger og dra inn kurs og foredragsholdere basert på ønsker fra medlemmene.
I januar hadde vi Scott Helme på virtuelt besøk for å holde kurset “Hack Yourself First”, og vi fikk et lite innblikk fra Telenors Security Operations Center (SOC) om alt det skumle som rører seg der ute på internettet. Vi har også opprettet en playbook, som vi håper skal bli en slags kollektiv hukommelse, der så mange som mulig bidrar med innhold.
Kake og merch!
Og sist, men definitivt ikke minst: Vi har merch! Identitet er viktig, og designerne våre har laget en logo som pryder alt fra klistremerker, hoodies og sokker til digitale “badges” på ansattprofilene til folk.
Vi lar oss også inspirere av metodikken CDD (Cake-Driven Development), der feiring av selv den minste seier med kake er sentralt.
De som melder seg som Security Champions får en badge i Teamkatalogen.
Hva nå?
Så, kommer vi til å lykkes bedre denne gangen?
Vi er optimister. Stemningen på den nylig avholdte kickoff-en var god, det første kurset er gjennomført, og antall bidragsytere til playbooken har akkurat blitt tosifret. Nå avhenger dette av at vi klarer å stimulere til et aktivt miljø som snakker sammen og deler.
Ta gjerne kontakt hvis dere driver på med noe tilsvarende, det er alltid interessant å utveksle erfaringer. Ellers går det an å ta en titt på Sondres lyntale fra JavaZone og på playbook-en vår.
