- De fleste sikkerhetshullene jeg finner, kunne vært unngått med små grep

- De fleste sikkerhetshull jeg finner, kunne vært unngått med små grep i utviklerhverdagen, sier Stian, Technical Team Lead for Cyber Defense Engineering, en avdeling under SecOps og Application Security Engineer i Storebrand.

Her forteller Stian om arbeidsdagen sin og hvordan han jobber for å beskytte digitale applikasjoner og er tett på utviklere for å sikre at de koder sikkert.

Har Security rollen endret seg for deg de siste årene? Hvordan?

Ja, det har den. Da jeg startet som deltidsansatt i Storebrand i 2022, jobbet jeg med å håndtere hendelser, det vil si at jeg jobbet med reaktiv sikkerhet. Jeg fikk jobbe med svært dyktige sikkerhetsfolk som hadde flere års erfaring, så det var veldig lærerikt. Det var også en fin overgang fra skolebenken til den virkelige verden.

I fritiden utforsket jeg sikkerhetstesting på applikasjonsnivå, noe jeg viste lederen min. Dette førte til at jeg fikk tilbud om jobb som «Application Security Engineer». Det betød nye arbeidsoppgaver og jeg flyttet fokus fra reaktiv sikkerhet til proaktiv sikkerhet. Da ble målet å sikre applikasjoner ved å jobbe tett med utviklere. Jobben endret seg fra å rydde opp etter angrep til å forhindre at de skjer.

Hvor tett jobber du med utviklere til daglig?

Det varierer svært fra uke til uke, men generelt så har jeg kontakt med våre Security Champions daglig og andre utviklere hver uke. Mye av arbeidet ligger i planlegging og prosesser. Jeg er ofte med som sikkerhetsrådgiver og kan blant annet tilby både trening og testing. Vi prøver å komme inn før designvalg er låst, ikke etter at løsningen er ferdig bygget.

Hva er ditt viktigste mål når det gjelder sikker koding?

Sikker koding er vanskelig, fordi utviklere har mange ting de skal tenke på. Det viktigste målet er at utviklere skal forstå hvorfor sikker kode er viktig. Hvorfor er det krise om noen klarer å hente en fil fra systemet applikasjonen kjøre på? Hvorfor er det viktig å fikse sårbarheten i en Cross Site Scripting? Hvorfor er det viktig at en nøkkel ikke lekker i en server respons?

Noen av punktene er selvforklarende og raske å fikse. Andre sårbarheter er mer komplekse, og det er ikke alltid så enkelt for utviklere å forstå den virkelige risikoen den bærer. Det er derfor viktig å lage tydelige «Proof of concepts». Det gjør vi ved å visualisere hvordan en trusselaktør kan misbruke en sårbarhet slik at den skader våre systemer eller lurer kundene.

Hva er det som oftest gjør sikker koding krevende?

Det kan være komplekst å se sårbarheter. Problemet er ikke at utviklere er likegyldige til sikkerhet, men at konsekvensene ofte er usynlige.

Det kan hende at utviklerne bruker et rammeverk som er svært sikkert og derfor er mer avslappet rundt inputvalidering. Men, plutselig blir teksten i applikasjonen sendt videre til en annen applikasjon der den detonerer. Det er ikke alltid at den som utvikler den første applikasjonen, vet dette. Et sikkert rammeverk beskytter deg bare så lenge dataene blir innenfor rammene.

Sikkerhet er ofte en balanse. Du kan bruke mye tid på å gjøre en applikasjon svært sikker, men det er ikke alltid det er nok tid. Da hender det at det blir tatt noen snarveier som kan åpne sikkerhetshull. Det krever også mye kunnskap å kjenne til disse sårbarhetene, så det er fullt mulig at en utvikler ikke er klar over alle fallgruvene som finnes.

Hvordan jobber dere med opplæring i praksis? Hva gir mest effekt?

Vi har årlig kursing med utviklere der vi går igjennom kjente saker som for eksempel «supply chain-angrep». Dette gjør vi for å skape bevissthet rundt sårbarheter vi har hatt, og som har blitt utnyttet av sikkerhetsforskere i vårt «bug bounty-program». Her viser vi hvordan vi jobber med trussel-modellering for å blant annet identifisere gap i sikkerheten.

En ting er å forklare alt dette, men det er noe annet å kunne få hands-on opplevelser. Når utviklere selv utnytter en sårbarhet, forstår de plutselig hvorfor den er alvorlig. Vi lager derfor «Capture the flag-arrangementer» med disse sårbarhetene, og på den måten lærer utviklerne hvordan en sikkerhetsforsker finner sårbarheter, utnytter dem og hvilke skader de kan føre til.

Hvordan opplever utviklerne å forholde seg til sikkerhet og rutiner knyttet til dette? Må de ofte inngå kompromisser?

Dette er individuelt for utviklere. Noen tenker sikkerhet fra start, mens andre ikke har fått opplæring rundt dette. Jeg opplever at mange er svært positive til å bli utfordret med nye problemstillinger, selv om det ofte blir litt ekstra arbeid. Noen ganger kommer vi borti utfordringer der sikkerhet konkurrerer med effektivitet og det operasjonelle, da må vi finne kompromisser som gjør løsninger så sikker og funksjonell som mulig. Den raskeste løsningen i dag kan være den dyreste om seks måneder.

I disse tilfellene er det fint å kunne sparre med andre sikkerhetseksperter. I vårt sikkerhetsteam har vi kollegaer som også har bakgrunn som utviklere og er flinke til å finne sikre løsninger, selv der det virker nærmest umulig. Min bakgrunn er mer knyttet til angreps- og risikoidentifisering, så jeg er flinkere til å finne ut hvordan en løsning kan bli misbrukt. Teamet har derfor ofte samarbeid og diskusjoner for å komme frem til solide løsninger.

Har du tre konkrete råd for sikrere kode i hverdagen?

1. Bli godt kjent med OWASP Top 10 rammeverket. Det er verdt å sjekke ut deres Cheat sheet.

2. Ha gode kode skanne verktøy som kan hjelpe å identifisere om du har lekket hemmeligheter (Tokens, connection strings etc.) i kode ved et uhell eller har kjente sårbarheter.

3. Code review er svært viktig av mange grunner. Om du setter opp skannerverktøy for koding riktig, kan det fange opp om du har sårbarheter. Dette er også en fin måte å identifisere om det er en trusselaktør som prøver å lure ond eller sårbar kode inn i applikasjonen.

Bonus: Trusselmodellering er et fint verktøy for å kartlegge og forbedre sikkerheten rundt applikasjoner. Om koden din har en ukjent sårbarhet, men du har en bra infrastruktur-design rundt, kan det gjøre et mulig skadeomfang mindre.