BrandStory er et annonseprodukt, produsert etter gjeldende retningslinjer.

Retningslinjer for BrandStory

BrandStory er en markedsføringskanal for annonsører. Tanken bak annonseformatet er at firmaer med komplekse budskap skal få anledning til å gå i dybden på sine temaer, og ha mulighet til å få direkte feedback fra en relevant målgruppe.

Annonsørene er velkomne til å dele innsikt fra forskning og utvikling, refleksjoner rundt sin rolle i samfunnet og tanker om ledelse.

Produktreklame er ikke tillatt i dette formatet. Annonsører kan heller ikke bruke BrandStory som en kanal for tilsvar på journalistikk som utøves på redaksjonelle flater.

Ønsker du at utviklerne dine skal lage sikre applikasjoner? Da må det være sammenheng mellom mål og ressursene de får for å nå målene. Det beste er å bygge sikkerhetskompetanse inn i utviklingsmiljøet.
Ønsker du at utviklerne dine skal lage sikre applikasjoner? Da må det være sammenheng mellom mål og ressursene de får for å nå målene. Det beste er å bygge sikkerhetskompetanse inn i utviklingsmiljøet. (Iryna Yuzhyna)
Innhold fra annonsør

5 sikkerhetsråd ved applikasjonsutvikling

Innovasjon og sikkerhet må gå hånd i hånd. De fleste har tilnærmet seg DevOps, men ikke alle har tatt skrittet fullt ut til DevSecOps. Her får du 5 råd på veien.

5 råd til utviklingsmiljøer

  1. Gi utviklingsteamet sikkerhetskompetanse og -mål
  2. Sett strengeste nivå som «default»
  3. Test sikkerhet gjennom hele livssyklusen
  4. Gjør sikkerhetstesting like selvfølgelig som funksjonstesting
  5. Test alt og ikke bare egen kode

– 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

– Ikke gi Chief Information Security Officer (CISO) god grunn til å stoppe koden før lansering. Tenk i stedet sikkerhet gjennom hele livssyklusen, bygg opp sikkerhetskompetanse i utviklingsmiljøet og test også sikkerhet ved hver iterasjon, sier Esten Hoel som er ansvarlig for sikkerhet og kvalitet i Basefarm.

– 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.

Basefarm er partner med Detectify som har et batteri på 1000+ tester for webapplikasjoner og databaser, er kjappe til å oppdatere for nye sårbarheter og gir få falske positive sammenlignet med andre verktøy.

– 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.

 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».

Esten Hoel

  • Senior Vice President kvalitet og sikkerhet, Basefarm
  • CISM og ITIL Expert sertifisert
  • Erfaring som senior prosjektleder, kvalitetssjef og teknologidirektør
  • Driftsleder for 24/7-operasjoner hos både Jernbaneverket og Eurowatch/TRI-MEX
  • Prosjektleder Norsk Philips AS
  • Ansvarlig for kommunikasjon og telematikk i NSB Gardermobanen
  • Tidtagning, resultatservice og TV-grafikk under OL på Lillehammer
  • Høyskolekandidat informatikk fra Hedmark Distriktshøgskole, Rena

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.

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ø!

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.