Iso27001 2022 revision

.github/workflows/tests.yaml

@@ -14,9 +14,9 @@ jobs:
         uses: actions/checkout@main
 
       - name: "Setup node"
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4
         with:
-          node-version: 18
+          node-version: 20
           cache: npm
 
       - name: Install dependencies and build website

.gitignore

@@ -4,6 +4,9 @@
 # Production
 /build
 
+# Old stuff
+/docs/Old
+
 # Generated files
 .docusaurus
 .cache-loader

docs/01_planlegge/01_ansvarsfordeling.md

@@ -0,0 +1,38 @@
+---
+sidebar_position: 1
+---
+
+# Ansvarsfordeling
+:::tip Kort oppsummert
+Manglende klarhet i vårt og andres ansvar kan få enorme konsekvenser for et prosjekt, så dette må gås opp i forkant. Det er spesielt viktig dersom andre selskaper enn oss og kunden er involvert, da oppgaver og roller har lett for å falle mellom stoler fordi alle tror at "noen andre" tar seg av det.
+:::
+
+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](https://wiki.bouvet.no/display/BLS/SOA+-+ISO27001%3A2022) 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. 
+
+## Drift og forvaltning av løsning - 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? 
+
+:::important 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.
+:::
+
+# Veien videre
+* [Bouvet: Statement of Applicability](https://wiki.bouvet.no/display/BLS/SOA+-+ISO27001%3A2022) (intern lenke)

docs/01_planlegge/02_data_og_klassifisering.md

@@ -0,0 +1,47 @@
+---
+sidebar_position: 2
+---
+
+# Data og klassifisering
+:::tip Kort oppsummert
+De fleste organisasjoner opererer med ulike klassifikasjonsnivå på både data og systemer, der klassifiseringen stiller krav til 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, og skiller typisk i disse eller liknende 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 må gås opp 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"](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/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 <u>må</u> 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. 
+
+# Veien videre
+* [Datatilsynet: Innebygd personvern](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/programvareutvikling-med-innebygd-personvern/)
+* [NSM: Kartlegg enheter og programvare](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnprinsipper-for-ikt-sikkerhet/identifisere-og-kartlegge/kartlegg-enheter-og-programvare/)

docs/01_planlegge/03_business_continuity.md

@@ -0,0 +1,92 @@
+---
+sidebar_position: 3
+---
+
+# Business Continuity
+:::tip Kort oppsummert
+Dersom en katastrofal hendelse oppstår må vi vite 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 akseptabelt tap av data.
+:::
+
+_Business Continuity Planning_ er _ikke_ er IT-teknisk fag. 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 av 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 med kunden som regulerer oppetid, tilgjengelighet og liknende, eller har kunden implisitte forventninger til dette? 
+
+Dette må gås opp slik at en er klar over hvilke konsekvenser 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 gå opp 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. 
+
+:::caution 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.
+
+* Fysisk infrastruktur (brann, flom, jordskjelv, etc.)
+  * Har vi servere et annet sted vi kan benytte?
+  * Kan vi flytte til et alternativt datasenter?
+* Virtuell infrastruktur
+  * 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.
+
+# Veien videre
+* [Wikipedia: Disaster Recovery](https://en.wikipedia.org/wiki/IT_disaster_recovery)