<img height="1" width="1" src="https://www.facebook.com/tr?id=1272750026111903&amp;ev=PageView &amp;noscript=1">

IT-sikkerhet i utviklingsprosjekter - en kort guide

Knut Nymoen

Knut Nymoen | 02. oktober 2018

Er du ansvarlig i et IT utviklingsprosjekt - og trenger oversikt over hva du må gjøre av sikkerhetsaktiviteter? Da er denne guiden for deg!

Informasjonssikkerhet er et enormt område og det aller meste av informasjon, sertifiseringer og opplæring er for linjeenheter, eksperter og ansatte. Relativt lite er gjort for å hjelpe prosjektene, så vi i Systek har laget vår egen prosjektguide som vi gjerne vil dele med deg! Den kan brukes både i smidige og vannfalls-prosjekter. Vi går her gjennom 4 steg du må gjennom som prosjektleder eller teknisk ansvarlig. 

Først et par definisjoner:

  • Med tjenesten mener vi funksjonene og tilhørende data. 
  • Med løsningen mener vi implementeringen av tjenesten. Dvs. brannmurer, lastbalanserere, servere, programvare etc.

Steg 1: Før prosjektet begynner for fullt

Du bør kartlegge en del områder før prosjektet starter med full hastighet. Disse oppgavene utføres som regel i forstudie/konseptfase.

Først må du få tak i (og vurdere) reglene, policies og rutinene bedriften har og som vil påvirke ditt prosjekt.

  • Vurdering av selve tjenesten. Har bedriften regler for verdivurdering av data i tjenesten, risikovurderinger etc?
  • Prosjekt / løsningsrettet: Dette kan være policy for skytjenester, sikkerhetsregler for interne tjenester (f.eks. transportkryptering internt), regler for kode som lages (scanning, gjennomganger) etc.
  • Driftsrutiner - hva trenger du av logging, overvåkning o.l.?
  • Godkjenningsrutiner og forum du må gjennom - hvordan får du godkjent risikovurderinger, designspesifikasjon etc?
  • Hva kreves av sikkerhetstesting?

Snakk med en sikkerhetsarkitekt tidlig for å få en vurdering av størrelsen og kompleksiteten av prosjektet, og for å få oversikt over hvem som skal godkjenne og vurdere løsningen. Skal du lage et tillegg til en eksisterende intern tjeneste, eller skal du lage en helt ny skyløsning med store mengder sensitive data? En kompliserende faktor er sikkerhetkrav som kommer midt i prosjektløpet - hvis du snakker med sikkerhetarkitekten jevnlig kan du få bedre oversikt om ditt prosjekt blir truffet.

Den siste større aktiviteten i denne fasen er å vurdere både prosjekt og linjeorganisasjonen. Hvem trenger du å få inn i prosjektet og hvem bør du ha kontakt med i linja? Hva er modenheten/opplæringsbehov på disse? Kan du få tak i sikkerhetseksperter på kort varsel? Vet du hvem som er ansvarlige for lastbalanserere og brannmurer og og vet du om disse kan gi deg gode råd? Trenger du opplæringsprogram for utviklerne eller vet du at du får tak i noen som er gode på sikker koding? Hvis du gjør en god jobb her så slipper du å få tak i en krypteringsekspert to uker før driftsetting for å bytte ut kryptoalgoritmen!

Steg 2: Krav, analyse og planlegging

I denne fasen må du få oversikt over krav og løsninger for tjenesten, dele opp i oppgaver (sprinter hvis du bruker Scrum) og få på plass utviklingsmetodikk for sikker utvikling av vanlig kode.

En hovedoppgave er å få utarbeidet og godkjent verdivurderinger og risikoanalyser for selve tjenesten. Dette drar med seg at du må gjøre en grov design av tjenesten: Hva skal tjenesten gjøre? Hvilke data skal lagres hvor? Hvor sensitive er dataene? Her er det viktig å være streng fra starten av og fjerne alt som er "kjekt å ha": Trenger du virkelig personnummeret i ERP-systemet?

Det er en trippel bonus her:

  • Fjerner du sensitive data blir det enklere både å få godkjent, utviklet og driftet tjenesten!


Deretter må det lages mer detaljerte sikkerhetskrav og løsningsforslag for tjenesten, og dette må analyseres for å se hvordan policyene og reglene til bedriften kan oppfylles. Temaene vil variere med tjenesten som skal lages, her er de viktigste:

  • Kommunikasjon: Hvordan håndterer du innkommende forbindelser - evt klarer du å ha bare utgående forbindelser? Trenger du tidsstyring på meldingsoverføringene (slik at meldingene blir ugyldige etter kort tid) og hvilken mekanisme skal du bruke for dette?
  • Lagring: Trenger dataene å beskyttes under mellomlagring? 
  • SSO: Hvilke mekanismer bruker du for federering og SSO? 
  • Ekstern testing - skal tjenesten testes eksternt? 
  • Plattformer -trenger prosjektet å forholde seg til oppsett, patching og herding? 
  • Infrastruktur-bestillinger: Hva skal bestilles av brannmurforbindelser, sertifikater og annet oppsett?
  • Logging: Hva skal logges? Og hvordan sikrer vi oss at passord og tokens ikke blir logget? 
  • Beskyttelse av sertifikater og passord - hvordan lagres disse sikkert?

Du må ikke spikre alle løsningene her, men du må være sikker på at kravene kan oppfylles.

Sprinter

Videre må du dele opp i oppgaver / sprinter, og sikkerhetkravene/oppgavene tas med i backloggen- sammen med de andre kravene. Her er det lett å gå i en fallgruve - det vil være egne sikkerhetskrav, og da må ikke sikkerhetkravene legges for sent i prosjektløpet.

Det er naturlig å prioritere viktig funksjonalitet først, men tas all sikkerhet på slutten er du nesten garantert problemer.

Mye skyldes at testing av sikkerhetskrav som regel er mer komplekse å teste enn funksjonelle krav - og dette må du ta hensyn til i planleggingen. Og du må selvsagt planlegge slik at når tjenesten går i produksjon så er sikkerheten riktig i forhold til det du deployer -et Minimum Viable Product må også inneholde nødvendig sikkerhet.

Til slutt må det på plass utviklingsmetodikk for sikker koding av ordinær kode. Her gjelder det å finne en bra kombinasjon av gode kodingsregler, kodegjennomganger, statiske verktøy for kodeanalyse, og dynamiske verktøy/ testverktøy for å få koden så god som mulig. OWASP har mye materiale for dette.

Steg 3: Utviklingsløpet

I utviklingsløpet må du utvikle og teste de enkelte sikkerhetsløsningene, samt at ordinær kode må utvikles i henhold til de rutinene som er definert for sikker koding.

Vi anbefaler at du har en teststrategi hvor du legger på fler og fler av sikkerhetsmekanismene og ikke tester de isolert. La oss si at du i sprint 2 legger på kryptering fra A->B, og i sprint 3 legger på kryptering fra B->C. Da anbefaler vi at du tester kjeden A->B->C og ikke bare B->C. Med en slik strategi så vil du teste mer og mer av sikkerhetskjeden, og ikke bare isolerte steg. Da vil du bedre se om sikkerhetsmekanismene henger sammen og gir deg tilstrekkelig beskyttelse hele veien.

Steg 4: Test og driftssetting

Før du driftsetter bør du ta en siste verifikasjon av at alle sikkerhetsløsningene henger sammen og at alt er komplett.

Du må også sikre deg at du får bestilt og lagt inn det du trenger av passord og sertifikater som er unike for produksjonsmiljøet. Du har som regel kontroll på din egen applikasjonsserver - men hva med lastbalanserere, containere, databaser etc? Disse har du mindre kontroll over og du bør ta en ekstra sjekk at disse faktisk har lagt inn riktig sertifikat og passord.

Og etter at du har driftssatt: Sjekk at alt er slått på! Alle vil sjekke at HTTPS på selve web-siten er slått på - men hva med overføringen av loggfiler til loggeserveren?

Andre kilder

Det er som nevnt lite informasjon rettet mot prosjekter. Men vil man grave litt dypere finnes det en håndbok her: http://www.n4s.fi/2014magazine/article2/assets/guidebook_handbook.pdf

I tillegg har Microsoft en modell som er rettet mer mot .Net utvikling: https://www.microsoft.com/en-us/SDL/discover/sdlagile.aspx. Denne mangler litt på de første stegene, men dekker mer på selve utviklingsdelen.

Lykke til - og kontakt gjerne oss i Systek for mer informasjon!

 

Ønsker du nye utfordringer? Se våre ledige stillinger

Del på sosiale medier: