FEM SIKKERHETSRÅD VED APPLIKASJONSUTVIKLING

– Sikkerhet som integrert del av utviklingsprosesser er ingen bremsekloss.  Det er derimot all grunn til å frykte full brems dersom kode blir sluppet uten at sikkerheten er på plass, i beste fall av CISO (Chief Information Security Officer) og i verste fall av hackere, sier Esten Hoel, Senior Vice President for kvalitet og sikkerhet i Basefarm.

Hoel og Basefarm mottar mye kode direkte fra kundene eller utviklingsmiljøene deres, som Basefarm deretter skal ta drifts- og sikkerhetsansvaret for. – Du ser lett forskjell på gode og mindre gode sikkerhetskulturer, sier han.

– Folk trenger råd.

Og det får de. Gjennom årenes løp har Basefarm utviklet en beste praksis-oversikt til utviklermiljøer med råd om hva de konkret bør tenke på ved applikasjonsutvikling. Ut fra denne godbiten av en sjekkliste har Hoel formulert fem overordnede råd.

1. GI UTVIKLINGSTEAMET SIKKERHETSKOMPETANSE OG SIKKERHETSMÅL

– Sikker utvikling må utviklerne stå for, sier Hoel.

Da må de nødvendigvis både ha klare mål for sikkerheten og tilstrekkelig kompetanse til å nå disse. Sikkerhetsfolk kan komme inn i teamet, men Hoel mener at det beste er å bygge kompetansen selv og ha åpne dører mellom utviklingsmiljøet og sikkerhetsfolkene i selskapet.

– Utviklere har mål for produksjon og funksjonalitet. Sikkerhet må komme som et tredje mål. Mye følger av klare mål. Dersom ledelsen har sikre applikasjoner som mål, må utviklerne nødvendigvis få tildelt ressurser og tid, slik at de kan målet. Det blir en dårlig deal å skulle nå et mål uten å ha forutsetninger for å klare det, sier han.

Hoel slår fast at de fleste nå har tatt i bruk DevOps på en eller annen måte. Også sikkerhetsmessig er DevOps-basert utvikling å foretrekke fremfor den gamle fossefallsmetoden med full produksjonssetting først når hele applikasjonen var ferdig.

– Også da kunne du teste sikkerheten underveis, men sannhetens øyeblikk kom først ved endelig lansering og kunne være brutal. Med DevOps kan du ha sikkerhetsmål i hver iterasjon. Ved å teste fortløpende bygger du sikre applikasjoner.

Kvalitets- og sikkerhetssjefen mener at det gir liten mening å teste ny kode isolert. Kode innvirker på annen kode og må derfor testes som en del av hovedapplikasjonen.

– Når skal du gjøre det? Om natten eller i helgen? spør han.

En mulig løsning er å klone hele produksjonsmiljøet. Ikke totalmiljøet, men faktisk store deler av deler av det. Basefarm har for eksempel investert mye i å beskrive og strukturere infrastrukturmiljøer og kan dermed klone hele produksjonsmiljøer på noen minutter (og for øvrig lage test- og demonstrasjonsmiljøer i en fei).

– Da kan du teste og erstatte originalen med klonen, eller gjenta feilrettingene fra testmiljøet i produksjonsmiljøet, sier Hoel. Han understreker at denne typen testing gjelder de virkelig store anledningene, som oppdatering av kjernesystemer og samfunnskritisk infrastruktur.

– I DevOps skjer oppdateringer gjerne flere ganger om dagen. Da må testene nødvendigvis være automatisert. Akkurat som når du utvider med nye funksjoner, må testskriptet videreutvikles med nye elementer for både brukerfunksjonalitet og sikkerhet.

2. SETT STRENGESTE NIVÅ SOM «DEFAULT»

– Sett strengeste sikkerhetsnivå i applikasjonen som standard, anbefaler Hoel.

– Det er bedre at brukerne selv slakker på sikkerheten fremfor å få utlevert et sikkerhetsnivå som de opplever som slapt.

Han tar treningsapplikasjonen Strava som eksempel. Her kan brukerne velge om turene deres skal være åpne for alle, noen eller bare dem selv.

– Utviklerne bør angi «bare dem selv» som standard.

3. TEST SIKKERHETEN GJENNOM HELE LIVSSYKLUSEN

– Si at du har en strålende idé, konseptutvikler og koder opp denne, og leverer den til implementering, hvor koden blir stoppet av CISO. Det blir slowdown eller kanskje full stopp. Spørsmålet blir om ideen sikkerhetsmessig var dømt til å feile helt fra begynnelsen, sier Hoel.

Noen vil kanskje argumentere med at sikkerhetsfolk og -kultur dreper kreativitet og ideer allerede under unnfangelsen. Hoel ser det ikke slik.

– Det handler sjelden om å forkaste. Det handler om å justere idé og konsept for å sikre realisering. Alle er tjent med dette, ikke minst virksomhetens ledelse, som ønsker kostnadseffektiv innovasjon for å sikre ønsket utbytte av investeringen.

4. GJØR SIKKERHETSTESTING LIKE SELVSAGT SOM FUNKSJONSTESTING

– Sikkerhetstester er like nødvendige som funksjonstester, og du må ha kompetanse på å tolke resultatene fra testverktøyene, sier Hoel.

Skyplattformer som AWS og Microsoft Azure slipper nye verktøy kontinuerlig. For å få utbytte av verktøyene, må du kunne ta dem i bruk og forstå tilbakemeldingene verktøyene gir deg. Basefarm bruker slike verktøy selv og har i tillegg fått stor sans for partneren Detectifys analysebatteri for over 1000 sårbarheter i webapplikasjoner og databaser.

– Mange verktøy tester infrastruktur, plattform og nettverk. Detectify skiller seg fra dette ved å teste kode i applikasjonen. Vi opplever dessuten at det går kort tid fra en ny sårbarhet blir oppdaget til den blir bygd inn i testbatteriet. Detectify er også gode til å filtrere ut falske positiver i forhold til andre verktøy. Det er jo lett å sette alt i en oransje kategori og overlate vurderingen til brukeren av testverktøyet.

– Da er man på en måte like langt, sier Hoel.

Også fra Detectify-rapporter vil kunder på PaaS og IaaS få tilbakemeldinger på elementer som ligger utenfor deres egen kontroll.

– Fint å bruke overfor hosting-leverandøren sin.

Basefarm leverer Detectify som «unmanaged» og «managed». Det innebærer at kundene enten kan bruke verktøyet og fortolke resultatene selv, eller overlate dette til Basefarm. Basefarm kan også tette sikkerhetshull knyttet til driftsplattform og melde tilbake til tredjepart. – Da blir vi et kompetansesubstitutt for kundens utviklingsmiljø!

5. TEST ALT, IKKE BARE EGEN KODE

– Programvareutvikling innebærer ofte 20 prosent egenkoding og 80 prosent fra åpne kildekodemiljøer. Test også koden du laster ned og bruker i applikasjonene! Basefarm har selv erfart flere slike sikkerhetsproblemer ved bruk av åpen kildekode, sier Hoel.

OM ESTEN HOEL

Esten Hoel er leder for kvalitet og sikkerhet i Basefarm. Han har lang erfaring med IT, telekom, prosjektledelse, prosessledelse og sikkerhet. Han har sittet på begge sider av bordet, både som kunde og som leverandør.

De siste 13 årene har han jobbet for driftsleverandøren Basefarm, hvor han fikk et enkelt mandat: «Sett nerdene i system». Siden den gang har han erfart hvordan kravene fra markedet og kunder har endret seg i takt med digitalisering, tjenesteutsetting og nå multi-sourcing i hybride økosystemer av tjenesteytere.