5 sikkerhetsråd ved applikasjonsutvikling

26-02-2019

– Sikkerhet som integrert del av utviklingsprosesser blir 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 så 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 for hva de konkret må tenke på ved applikasjonsutvikling. Ut i fra denne godbiten av en sjekkliste har Hoel formet fem overordnede råd.

1: Gi utviklingsteamet sikkerhetskompetanse og -mål

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

Da må de nødvendigvis både ha klare mål for sikkerheten og kompetanse for å 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å avsatt ressurser og tid til å nå 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 du kunne 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 weekenden, 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 øvrige lage test- og demonstrasjonsmiljøer i en fei).

– Da kan du teste og erstatte originalen med klonen, eller gjenta fixene fra testmiljøet i produksjonsmiljøet, sier Hoel. Han understreker at denne type testing må bli ved de riktig store anledninger, som når du oppdaterer kjernesystemer og samfunnskritisk infrastruktur.

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

btn-top

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 sette default som «bare dem selv».

btn-top

3: Test sikkerhet gjennom hele livssyklusen

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

Noen vil kanskje argumentere for sikkerhetsfolk og -kultur vil drepe kreativitet og idéer allerede under unnfangelsen. Hoel ser det ikke slik.

– Det handler sjeldent 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.

btn-top

4: Gjør sikkerhetstesting like selvfølgelig som funksjonstesting

– Sikkerhetstester er like nødvendige som funksjonstester og du må ha kompetanse på å fortolke 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 sympati for partneren Detectify sitt 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 å maskere bort 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ø!

btn-top

5: Test alt og ikke bare egen kode

– Programvareutvikling innebærer ofte 20 prosent egen-koding 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.

btn-top

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 erfart 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». I årene siden 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

 

 

btn-top

Ønsker du mer informasjon?

Fyll ut feltene, en av våre spesialister vil kontakte deg fortløpende:

btn-top