Det viktigste vi kan gjøre før vi skriver en eneste kodelinje er å blie enige om ansvarsfordelingen mellom oss og kunden, samt klassifiseringen av løsning og data: Hvilke krav stiller kunden og hvilke krav kommer fra lovverk eller andre parter? Kompetanse innenfor applikasjonssikkerhet (AppSec) bør være på banen allerede i denne fasen for å sikre at en ivaretar krav og forventninger til sikkerhet.
Vi må også vite hva vi gjør ~~dersom~~når det oppstår en sikkerhetshendelse - hvilke krav står vi ovenfor, hva må til for at disaster recovery, backup og liknende skal lykkes, og hva vil konsekvensene av nedetid være for kunden?
1 - Ansvarsfordeling
Manglende klarhet i hvem som er ansvarlig for hva kan få store konsekvenser. Dette gjelder alle prosjekter, men er spesielt viktig dersom andre selskaper enn oss og kunden er involvert. Å ha en tydelig ansvarsfordeling med tilhørende varslingsrutiner og roller er avgjørende.
Bouvet gjennomfører utviklingsprosjekter på mange ulike måter, der vi tar mer eller mindre ansvar for prosjektledelse, planlegging, utviklingsfasen, kvalitetssikring og ikke minst drift og forvaltning av løsningen. Vi har også ulike innslag av eget, kundens og tredjepartsutstyr, både under utvikling og forvaltning av løsningen.
Uavhengig av hvordan prosjektet gjennomføres er det viktig at vi har kontroll på ansvarsfordelingen. Denne skal være regulert i avtalen med kunden, og vi må sikre at vi
Har kontroll på ansvar og rollefordeling
At vi har kontaktpunkt hos alle involverte parter
Kan følge opp avvik raskt slik at vi unngår misforståelser eller problemer senere i prosjektløpet
Drift og forvaltning av løsning
Bouvet
Dersom vi er ansvarlige for drift og forvaltning av løsning i vår infrastruktur, vil denne komme inn under vår sertifisering på ISO 27001 - Informasjonssikkerhet. Dette medfører at vi har et større helhetlig ansvar for sikkerheten rundt løsningen, og det er viktig at leveranseteamet er klar over dette.
Alle ressurser driftet av leveranseteamet må håndteres på linje med all annen infrastruktur, så teamet må ha rutiner for patching og vedlikehold eller sikre at dette blir håndtert. Sjekk gjerne med Intern-IT & Sikkerhet for å se hva de kan levere og dermed drifte på vegne av teamet for å forenkle forvaltningen.
Bouvets Statement of Applicability/Anvendelseserklæring (SOA) tar for seg ulike kontroller relatert til informasjonssikkerheten og hvordan vi skal forholde oss til disse. SOA kan finnes i det interne ledelsessystemet. Dersom vi tar på oss denne rollen vil din regionale kvalitetsleder kunne bistå med råd og veiledning for å sikre at alt ansvar er ivaretatt.
Kunde eller tredjepart
Dersom vi kun har ansvar for utvikling av løsningen, er det viktig at vi har gått opp grensesnittet mellom oss og organisasjonen som overtar og drifter løsningen videre:
Hvordan skal handover skje
Hvordan håndterer vi at nødvendig hardware og kapasitet er satt opp
Hvordan sikrer vi at behov for deployments, driftshendelser, feilrettinger og liknende kommuniseres til begge parter?
Tips
Dokumenter ansvarsfordeling og annen relevant informasjon i kildekodesystemet sammen med resten av det som produseres i prosjektet. Det øker synligheten og alle vet til enhver tid hvor informasjonen finnes.
De fleste organisasjoner opererer med ulike klassifikasjonsnivå på både data og systemer. Klassifiseringen gjøres ofte med bakgrunn i hvordan data brukes, hvor det lagres og hvem som kan aksessere disse. Dette er nøkkelkrav for ethvert utviklingsprosjekt og må avklares i forkant.
Klassifisering
De aller fleste organisasjoner har rutiner og prosesser for klassifisering av data, for eksempel i følgende nivå:
Åpent
Internt
Konfidensielt
Begrenset
Avhengig av denne klassifiseringen kan det foreligge ulike krav til sikring av data. Åpne data har typisk ingen begrensninger, mens data klassifisert som “begrenset” kan ha begrensninger som at en
har strenge krav til innsyn
kun kan behandle informasjonen i egne systemer
krever flerfaktor autentisering før aksess
har restriksjoner i forhold til bruk av skytjenester eller hvor data lagres
Dette avklares med kunde i oppstarten av prosjektet slik at en kan sikre nødvendig etterlevelse. Dersom kunden ikke har et forhold til dataklassifisering, bør en likevel kartlegge sensitiviteten til dataene som skal behandles for å sikre at vi innfører nødvendige tiltak.
Personvern
Dersom leveranseteamet skal behandle personsensitive opplysninger, er det viktig at teamet setter seg inn i kravene rundt dette. Datatilsynet har publisert en egen veileder for “Programvareutvikling med innebygd personvern” som gir nyttig innblikk i problemstillingen.
Viktige punkter en er nødt å være klar over er at
informasjon ikke skal lagres lenger enn hensikten med å samle den inn tilsier
enkelte typer informasjon ikke skal registreres under noen omstendighet
vi må ha et forhold til bruk av produksjonsdata i testsammenheng og restriksjoner på dette
brukere har “retten til å bli glemt” der personinformasjon kan kreves slettet
vi må forholde oss til personvern også i backupsammenhenger - vi trenger ikke nødvendigvis å slette enkeltpersoner fra backup, men vi må sikre at “retten til å bli glemt” ivaretas ved en restore.
Dersom vi behandler denne type informasjon på vegne av kunder skal de normalt kreve at vi signerer en databehandleravtale. Dersom dette ikke er på plass må det følges opp mot kundeansvarlig.
Data til bruk under utvikling og testing
Dersom en bruker data i forbindelse med utvikling og testing, er det viktig å ha et forhold til klassifisering og sensitivitet. Dev-miljøer har ofte et annet sikringsnivå enn produksjonsmiljøet, og dette gjør i praksis at vi ikke alltid kan bruke relle data til utvikling.
Teamet må sjekke behovet for anonymisering av dataene før disse brukes utenfor produksjonsmiljøet, slik at en ivaretar behovet for mengden data, fyllingsgrad og kvalitet samtidig som at en ikke risikerer at kundens data kommer på avveie.
Dette er spesielt viktig dersom utvikling skjer i Bouvets infrastruktur, men med produksjonsmiljø plassert hos kunden. I slike tilfeller er det viktig at Bouvet har dokumenterte rutiner som regulerer hvor og hvordan data oppbevares og brukes, og hvordan og når disse skal slettes. Dette må gås opp i samråd med kunde slik at det ikke er noe tvil rundt ansvar, plikter og risiko.
Dersom en katastrofal hendelse oppstår må vi vite hvem som skal kontaktes, og hvilke krav løsningen og leveranseteamet må forholde seg til. Dette går ikke bare på typiske krav relatert til tilgjengelighet men også hvor lang tid en kan bruke på gjenoppretting, hvordan dette skal gjøres og hva som er akseptabelt tap av data.
Business Continuity Planning er ikke utelukkende et IT-teknisk anliggende, men det er vårt ansvar som leverandører av et IT-system å minne kunden på at systemet kan bli utilgjengelig.
Svaret fra denne planleggingen vil være med å beskrive hvilke krav som stilles til løsningens robusthet og sikkerhetsnivå, og er avgjørende for å finne riktig balanse på kostnad og ytelse hos systemet.
Her er det viktig å ha et forhold til
Kritikaliteten av løsningen
Eventuelle workarounds dersom løsningen er utilgjengelig
Konsekvenser eller merarbeid som følge av utilgjengelighet eller når løsningen igjen blir tilgjengelig.
Kundens forventninger
Har vi definert en Service Level Agreement (SLA) med kunden som legger føringer på oppetid, tilgjengelighet og liknende, eller har kunden implisitte forventninger til dette?
Dette må avklares slik at en kjenner konsekvensene nedetid vil få. I mange prosjekter benyttes det skykomponenter der en ikke har kontroll over alle variabler selv. Derfor er det viktig å tidlig i prosjektet avklare de faktiske behovene med kunden. Vi kan sikre redundans på alle fronter dersom kunden ønsker det, men det koster da deretter.
Dersom en går opp dette i forkant er det lettere å henvise til dokumentasjon og avtaler når løsningen blir utilgjengelig for å unngå dårlig stemning.
Håndtering av hendelser
Alle kunder i Bouvet skal ha et definert kontaktpunkt for hendelser i Kunder (CRM). Dersom det er andre kontaktpunkter fra teamet inn mot kunde som sikkerhetssenter (SOC) eller liknende er det lurt å dokumentere dette også slik at en kan løse oppståtte hendelser så raskt som mulig.
Dersom en hendelse oppstår og kunde eller andre har behov for kontakt med teamet, er det vanlige at leveranseleder er det formelle kontaktpunktet i Bouvet-teamet.
Backup
Backup er viktig i alle prosjekter. Selv om vi i mange prosjekter ikke har noe ansvar for drift av infrastruktur, kildekodesystemer eller andre verktøy, bør vi gjøre oss kjent med rutiner og begrensninger på området.
Dersom vi har ansvar for drift har vi også ansvar for at backup gjennomføres. Vanlige begrep her er
Recovery Time Objective (RTO) - akseptabel tid for å oppnå normaltilstand etter svikt
Recovery Point Objective (RPO) - hva er akseptabelt datatap etter svikt (målt i tid)
Løsning for backup og recovery må designes ut ifra disse kravene, og vi må sikre at dette ivaretas. En må sammen med kunden ta stilling til
Hvor mye?
Hvilken data og systemer skal være underlagt backupregimet. Kan det differensieres?
Hvor ofte?
Skal vi ta backup 1 gang i uken, hver natt, eller hver time?
Hvor langt tilbake?
Hvor lenge skal vi lagre backupene?
En vanlig tilnærming til backup er å kjøre
Daglige backups - disse lagres i 30 dager
Ukentlige backups - disse lagres i 6 måneder
Månedtlige backups - disse lagres i 2 år
Det er også viktig å ha et forhold til hvor backupene lagres, slik at en kan være best mulig rigget mot katastrofale hendelser. Dette kan løses ved å ha offline og offsite backups, altså backups lagret på eksempelvis tape og oppbevart på en annen fysisk lokasjon enn øvrige backups.
Test!
Backup som ikke testes har ingen verdi - innfør rutiner for å teste at du kan restore fra backup!
Disaster recovery
Disaster Recovery i planleggingsfasen handler om å utvikle et planverk for hva som skal gjøres for å raskest mulig komme tilbake til normaltilstand. Det kan være nyttig å tenkte på dette som “actions on”, altså; “Hvis X inntreffer, så gjør vi Y”.
Gjenoppretting
Det vil ikke være nødvendig å gjenskape tjenestene i alle disaster hendelser. Ofte kan man slippe unna med mindre omfattende og manuell feilretting. Uavhengig av dette bør man uansett ha en plan for fullstendig gjennoppretting. Har man det kan man redde seg fra de fleste situasjoner.
Kan infrastruktur gjenskapes korrekt og raskt nok?
Dokumenter ressurser, avhengigheter, og operasjonelle prosedyrer
Her vil bruk av Infrastructure as Code (IaC) være et viktig bidrag
Data og databaser
Total / bulkgjennopretting: Hvordan gjenoppretter du store mengder data / hele volumer?
Enkeltfiler: Hvordan gjenoppretter du en enkelt fil?
Støttesystemer
Husk at støttesystemer kan spille en viktig rolle i det totale systmet. Disse må også kunne erstattes eller gjennopprettes ved hendelser
Eksempelvis: Git, CI-pipeline, logging og monitorering
Scenarier som kan diskuteres
Slettet tjeneste: Hvordan gjenoppretter du en tjeneste som har blitt slettet?
Korrupt tjeneste: Reparerer eller gjenoppretter man en VM eller andre tjenester med problemer?
Utilgjengelig tjeneste: Hva skjer om tjenestene blir utilgjengelige? Her trenger du definisjonen av hva som er midlertidig / kortvarig nedetid. Skal du deploye ny tjeneste, har du allerede en som kjører som hot-swap eller går det greit uten en periode?
Kompromittert sikkerhet: Hvordan håndterer du det når et passord har blitt lekket på noe vis?
Utgått passord: hvordan gjenopptar du driften hvis et passord eller sertifikat har utløpt? (Hint: prøv å unngå dette)
Kompromittert identitet / tjenestebruker: Hva gjør du hvis en managed identitet eller en tjenestebruker har blitt kompromittert?
Utilgjengelige passord: Hva gjør du hvis key vaulttjenesten i regionen du bruker går ned? Har du backup og failover i en annen region?
Malware: Hvordan gjenoppretter du systemet etter et cryptolockerangrep? Trenger du en delvis eller total gjenoppbygging av alle tjenester?
Konfidensialitetsbrudd: Hvordan håndterer du at noen har kommet seg inn i tjenesten(e) du drifter?
Kompromittert admin: Trenger du å planlegge for hva som skjer om eieren av subscription sletter hele Azure-subscriptionen din?
Kritisk sårbarhet: Hva skjer når noen oppdager en kritisk sårbarhet i din applikasjon? Det kan være lurt å ha protokoller klare for når du skal ta et valg om du stenger tjenesten ned.
Feilkonfigurasjon er en vanlig kilde til feil og sårbarheter, dette gjelder også for verktøy. Dersom mulig bør teamet standardisere på bruk av verktøy og utvidelser til disse, og sikre at alle har en mest mulig lik (og dokumentert) arbeidsprosess.
Alle utviklingsteam benytter ulike verktøy i utviklingsprosessen, og utvalget vil varierere fra team til team avhengig av personlige preferanser, teknologivalg, system og kundekrav og mye annet.
Et typisk team vil benytte seg av en eller annen form for
et system for versjonskontroll av koden, typisk git
et verktøy for CI/CD som kan utføre ulike oppgaver relatert til bygging, testing eller deployment
andre tjenester driftet eller konsumert av teamet, f.eks. meldingstjenester, filoverføringstjenester, generativ AI (copilots) eller liknende
Disse verktøyene kan ha stor betydning for sikkerhet og kvalitet i leveranser, så det er viktig at teamet har et forhold til hvordan disse settes opp.
IDE
Det er mulig å installere utvidelser på de fleste IDEs idag, som gir støtte for nye språk, formatering, linting, skytjenester og annet. Disse kan forbedre produktivitet og effektiviteten til teamet betraktelig, men vi må være obs på hva som installeres.
I likhet med alt annet som lastes ned og kjøres fra internett må vi ha et forhold til risiko, så det er viktig at vi er obs på hva vi laster ned, hvor det lastes ned fra og hvem som står bak for å unngå problemer.
Versjonskontroll
Versjonskontroll gir kjempekontroll over alle endringer, men det er viktig at vi bruker verktøyet på en god måte.
Mange baserer seg på løsninger som Azure DevOps, Github eller liknende som håndterer tilgangsstyring, reviews og en del andre funksjoner knyttet til konfidensialitet og integritet mot kildekoden.
Git har imidlertid også innebygd funksjonalitet for signering av commits, slik at hver enkelt commit kan spores til en person med en gitt nøkkel. Dette kan være et nyttig hjelpemiddel for å sikre integritet, og bør vurderes av teamet.
Branchingstrategi
En typisk tilnærming er å operere med en produksjonsbranch, ofte main eller master. Denne bør være beskyttet slik at alle endringer skjer i egne feature-branches som så merges inn via pull-request med dertilhørende review fra andre i teamet. Produksjonsbranchen blir så grunnlaget for alle deployments videre.
Det finnes andre og mer komplekse tilnærminger også, eksempelvis med separate branches samt tagging av versjoner. Denne er spesielt nyttig dersom en vedlikeholder flere ulike versjoner i ulike miljø, trenger mulighet for hotfixer eller liknende:
I dette eksempelet jobber alle utviklere i egne feature branches mot develop-branchen, som beskyttes mot direkte endringer. Denne deployes til dev-miljøet for å verifisere at alt fungerer som det skal.
Når teamet er fornøyed med tilstanden på develop, merges denne til test via en egen pipeline som håndterer tagging av versjonsnummer automatisk. Denne pipelinen kan kreve godkjenning for å kjøre, slik at det trengs en person for å starte den, og en annen for å godkjenne.
Test-branchen deployes til testmiljøet, og når kunden er fornøyd med det som er levert merges den til prod-branchen på samme måte som til test. For både test og prod bruker vi versjonsnummeret som en del av branchnavnet, slik at vi kan ha branchen Test/v1 og Test/v2, som korresponderer med Prod/v1 og Prod/v2.
Dersom det er behov for hotfixing mot prod kan dette eksempelvis gjøres mot den aktuelle prodbranchen slik at en får korrigert kritiske feil raskt, for så å ta hotfixen tilbake til dev.
pre-commit
Et tips er å bruke [pre-commit](https://pre-commit.com) til å kjøre alt av linting, formatering, og testing, for så å bruke den samme _pre-commit_ konfigurasjonen i CI/CD. Dette vil minimerer vedlikeholdet, gjøre det enkelt å teste lokalt, og fange opp problemer tidlig.
Vær obs på at flere av punktene under krever tilleggssoftware. Vi har per idag ingen felleslisenser for utviklere i Bouvet, dette må gås opp per prosjekt avhengig av behov og krav. Dersom teamet håndterer dette på egenhånd, vær obs på lisensbetingelser og hvordan verktøy fungerer. Noen verktøy sender eksempelvis kildekode til egne servere for analyse, dette er i utgangspunktet ikke tillatt med mindre det på forhånd er avklart med kunden.
Software compostion analysis (SCA)
Software composition analysis (SCA) kan settes opp automatisk som en del av CI/CD. Vi har mange avhengigheter til komponenter laget av andre, så det er viktig å ha oversikt over eksisterende og nyoppdagede sårbarheter i det vi lager.
Testing
Å kjøre tester i CI er lurt av flere grunner, men fra et sikkerhetsperspektiv er det enkelte tester som bør være med.
Test alle aktuelle endepunkter for 401/403 responser
Test kode som håndterer autorisasjon (hvem får gjøre hva). Her vil det være en fordel om all autorisasjonslogikk skjer på et sentralisert sted i kodebasen.
Statisk kodeanalyse (SAST) bør konfigueres til å kjøres automatisk som en del av CI/CD. Man kan vurdere om et bygg skal feile dersom den statiske kodeanalysen oppdager alvorlige svakheter med koden eller lav testdekning.
Secret scanning
Sjekking av hemmeligheter - passord, nøkler og annen sensitiv informasjon som ikke skal inn i kildekoden er et viktig verktøy som kan implementeres i versjonskontrollsystemet og i CI/CD. Noen verktøy har kun varsling ved funn, andre kan også ugyldiggjøre hemmelighetene i tjenestene de er ment for.
Generativ AI (copilots)
Det eksisterer mange slike generative AI-verktøy som utviklere kan benytte. Det er viktig at enhver bruk av slike verktøy avklares med kunden før de tas i bruk. Her har Bouvet gjort mye arbeid i evaluering av flere slike verktøy og har god støtte internt for å gjøre slike vurderinger om kunden skulle ha behov for det.
Et sikkerhetskontrollpunkt er et kontrollpunkt underveis i et prosjekt der en setter krav som må oppfylles før en går videre.
Avhengig av sikkerhetsnivået en leveranse ønsker å legge seg på, kan det være nødvendig å definere mekanismer for å vurdere sikkerheten på faste punkter i utviklingsløpet, såkalte sikkerhetskontrollpunkt.
Disse kan defineres mellom logiske faser i prosjektet, eksempelvis mellom design og utviklingsfasene, eller når en går fra utvikling til første release i produksjon. Andre og flere kontrollpunkter kan også defineres, helt avhengig av kravene leveranseteamet må forholde seg til.
IBM har i en studie fastslått at generelle svakheter i applikasjoner utviklet for det amerikanske forsvaret kostet langt mindre å utbedre jo tidligere de ble oppdaget.
Ved å ta i bruk sikkerhetskontrollpunkt er det ikke bare lettere å sikre etterlevelse av sikkerhet- og kvalitetskrav, men også lettere å sikre at en fanger opp svakheter tidlig. En vanlig praksis der slike kontrollpunkt benyttes er at det eksempelvis
skal foreligge et design av prosjektet før utviklingsløpet starter
at implementasjonen skal følge designet
og at en har verifisert at design og implementasjon faktisk matcher før en kan gå i produksjon
