Legger til resten av innholdet. Alt skal mer eller mindre være på pla…

…ss, minus introartikler

docs/01_planlegge/05_sikkerhetsgater.md

@@ -0,0 +1,28 @@
+---
+sidebar_position: 6
+title: Sikkerhetskontrollpunkt 
+---
+
+# Sikkerhetskontrollpunkt
+:::tip Kort oppsummert
+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](./ibm_relative_cost2.png)
+
+IBM har [i en studie](https://www.researchgate.net/figure/IBM-System-Science-Institute-Relative-Cost-of-Fixing-Defects_fig1_255965523) 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](../02_designe/02_systemskisser.md) 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
+
+
+# Veien videre
+* [Dawson, Maurice, et al. "Integrating software assurance into the software development life cycle (SDLC)." Journal of Information Systems Technology and Planning 3.6 (2010): 49-53.](https://d1wqtxts1xzle7.cloudfront.net/43105461/fulltext_stamped-libre.pdf?1456510133=&response-content-disposition=inline%3B+filename%3DIntegrating_Software_Assurance_into_the.pdf&Expires=1719440984&Signature=eH8UCTexOuHmFfCL~FAtaw4tuESm5nRoKrrlOAt~UqP2Od6V7lis-gvCNcmZtLIJYpAQ1LaznsUPbUDIk39imYfEqHeqk9JpODsYN5T4aF32VM6-RhkhIBYRDHLQ5VN72v7~tnsTzsEg6dR-iHjCNAVGD296zsXmyEaOUv3lzNMihjxUNwxziirGJHNm8b3Nw4yLQzydjkqZ192rplx45I61vtwP7WZBR~JzJVVL-tZ9-HBbJdeujgvibekFspH5DttxpvV9kR2vmn7Z5OkUWQWAyuOGl~ORwpF5x96mrD5SE3Of2ftgSDT4iscXa-R3ej4gPeAgnSnGAAiAp4BcLA__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA)
+* [RedHat: Security in the software development lifecycle](https://www.redhat.com/en/topics/security/software-development-lifecycle-security)
+* [Implementing Smart Security Gates in Modern Software Development](https://blog.secodis.com/2023/11/24/how-security-gates-can-work-efficiently-even-with-devops/)

docs/03_utvikle/04_sikkerhetspraksiser.md

@@ -21,11 +21,13 @@ Det finnes mange ulike typer sårbarheter og svakheter vi må forholde oss til n
 9. Security Logging and Monitoring Failures
 10. Server-Side Request Forgery
 
-
 Dersom teamet ikke har noen prosesser rundt sikker utvikling, vil dette være en god start. For team med større modenhet innenfor applikasjonssikkerhet vil andre sjekklister, som Application Security Verification Standard - også fra OWASP være et videre alternativ. Denne er delt opp i tre ulike nivå, der nivå 1 dekker hovedpunktene, mens level 3 går mye mer i dybden og krever mer kompetanse og støtteverktøy. 
 
+OWASP publiserer mye annet i tillegg, både andre Top 10-lister i tillegg til det de kaller ["_Cheatsheets_"](https://cheatsheetseries.owasp.org/); detaljert informasjon om spesifikke sikkerhetsrelaterte tema. 
+
 # Veien videre
 * [OWASP Top 10 (2021)](https://owasp.org/www-project-developer-guide/draft/training_education/owasp_top_ten/)
 * [OWASP Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
 * [The 18 CIS Critical Security Controls](https://www.cisecurity.org/controls/cis-controls-list)
-* [CISA - Secure by design](https://www.cisa.gov/securebydesign)
+* [CISA - Secure by design](https://www.cisa.gov/securebydesign)
+* [OWASP: Cheatsheets](https://cheatsheetseries.owasp.org/)

docs/03_utvikle/05_software_supply_chain.md

@@ -26,6 +26,9 @@ Det finnes flere sikkerhetsrisikoer knyttet til tredjepartspakker, men dessverre
 
 Uavhengig av om noe er ment som malware eller protestware er konsekvensene alvorlige, og alle utviklingsprosjekter bør ha på plass tiltak for å begrense risiko og konsekvens dersom en hendelse inntreffer. 
 
+### Bruk av CDN
+Content-delivery-networks for å distribuere Javascript-bibliotek har blitt brukt av mange som en enkel måte å inkludere disse i koden uten å måtte inkludere dette i build eller deploy-prosessen. Tanken er god, men du får da en direkte avhengighet til en kilde du ikke har noen kontroll på som kan [misbrukes til å spre malware](https://sansec.io/research/polyfill-supply-chain-attackX). 
+
 ### Lisensmodell
 Det finnes mange ulike lisensmodeller; noen er helt frie og får ingen konsekvenser for brukerne, mens andre som AGPL og GPL stiller klare krav til alle som konsumerer kode under denne lisensen, også inkludert det øvrige systemet som benytter seg av den. De aller fleste økosystemer tillater også bruk av proprietære lisenser, som kan begrense hva du kan bruke en pakke til. Noen har spesifikke krav i lisensen, andre er gratis for personlig bruk, men krever at du kjøper en lisens dersom den skal brukes kommersielt. 
 
@@ -60,4 +63,6 @@ Software Bill Of Materials (SBOM) er en tilnærming der vi genererer en oversikt
 
 # Veien videre
 * [Sonatype: State of the software supply chain](https://www.sonatype.com/state-of-the-software-supply-chain/introduction)
-* [Wikipedia: Source Composition Analysis](https://en.wikipedia.org/wiki/Software_composition_analysis)
+* [Wikipedia: Source Composition Analysis](https://en.wikipedia.org/wiki/Software_composition_analysis)
+* [Eksempel på CDN-angrep: Polyfill supply chain attack hits 100K+ sites](https://sansec.io/research/polyfill-supply-chain-attackX)
+* [Eksempel på kompromittert bibliotek: xz-Utils](https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/)

docs/04_deploye/01_bygg_og_deploy.md

@@ -44,4 +44,5 @@ I en deployment pipeline er det viktig å ha et forhold til når det er greit å
 # Veien videre
 * [Microsoft: Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops)
 * [Github: Github Actions](https://docs.github.com/en/actions)
-* [OWASP Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/)
+* [OWASP: Top 10 CI/CD Security Risks](https://owasp.org/www-project-top-10-ci-cd-security-risks/)
+* [OWASP: CI/CD Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html)

docs/05_forvalte/04_forvaltning_avhengigheter.md

@@ -8,9 +8,16 @@ title: Forvaltning av avhengigheter
 Status på avhengighetene vi har vil endre seg over tid, og det er ikke til å unngå at svakheter oppdages som må mitigeres av oss. Denne jobben kan være så enkel som at vi oppdaterer til en ny versjon, men kan også kreve større endringer i applikasjonen.
 :::
 
-Når teamet er i forvaltningsmodus gjelder fremdeles de fleste problemstillingene nevnt i artikkelen om [Software Supply Chain](../03_utvikle/05_software_supply_chain.md). 
+Når teamet er i forvaltningsmodus gjelder fremdeles de fleste problemstillingene nevnt i artikkelen om [Software Supply Chain](../03_utvikle/05_software_supply_chain.md). Dere vil komme i situasjoner der 
+* det oppdages en kritisk sårbarhet i en pakke dere bruker
+* pakker deprekeres og erstattes med noe nytt som ikke er direkte kompatibelt med det gamle
+* utviklere bak pakker slutter å vedlikeholde pakkene
+* ondsinnede aktører overtar en pakke og bruker den for å spre malware
+
+....og helt sikkert andre varianter som resulterer i at dere må gjøre _noe_. For å sikre at pakker som treffer ett eller flere av punktene over tas tak i. Verktøy som Sonatype og andre gir muligheten til å overvåke ulike steg i livssyklusen, med mulighet til å varsle når sårbarheter eller andre hendelser som påvirker kvaliteten inntreffer. 
 
 # Veien videre
-* [OWASP Procactive Controls: C9: Implement Security Logging and Monitoring](https://owasp.org/www-project-proactive-controls/v4/en/c9-security-logging-and-monitoring.html)
-* [OWASP: Application Logging Vocabulary Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html)
-* [OWASP: Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
+* [Sonatype: State of the software supply chain](https://www.sonatype.com/state-of-the-software-supply-chain/introduction)
+* [Wikipedia: Source Composition Analysis](https://en.wikipedia.org/wiki/Software_composition_analysis)
+* [Eksempel på CDN-angrep: Polyfill supply chain attack hits 100K+ sites](https://sansec.io/research/polyfill-supply-chain-attackX)
+* [Eksempel på kompromittert bibliotek: xz-Utils](https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/)

docs/05_forvalte/05_preparedness.md

@@ -0,0 +1,40 @@
+---
+sidebar_position: 1
+title: Øv på gjenoppretting
+---
+
+# Øv på gjenoppretting
+:::tip Kort oppsummert
+En backup som ikke er testet er verdiløs, og det samme gjelder alt av planer for disaster recovery såsant disse ikke testes. Teamet må verifisere backups og planer jevnlig, slik at alle vet hva som må skje.  
+:::
+
+Dersom teamet har gjort alt rett til nå har dere en plan for [disaster recovery](../01_planlegge/03_business_continuity.md) som forteller dere hva som må gjøres for å gjenopprette infrastruktur, applikasjoner og data slik at en kommer tilbake til normal drift. 
+
+Årsakene til at en er nødt å gjenopprette kan være mange, og svært varierende i omfang. Hvem har vel ikke kjørt en ```delete from <table> where x = 'something'``` med manglende eller feil parametre, eller droppet feil tabell fra en database? Eller slettet en server eller appservice fra et prodmiljø ved en feil (_jeg skulle bare fikse noe kjapt...._). I slike tilfeller kan det gå kjapt å gjenopprette dersom en vet hva som gikk galt, men i andre og mer komplekse tilfeller som f.eks. involverer ukjente feil i programvaren eller problemer hos en skytjenesteleverandør kan det bli mer komplekst. 
+
+For at planene skal ha noen reell verdi, er man nødt til å teste disse i praksis. I en perfekt verden bør planene være så detaljerte at gjenoppretting er mulig selv om [hele teamet blir påkjørt av bussen](https://en.wikipedia.org/wiki/Bus_factor), eller på annet vis blir utilgjengelige. I praksis er dette ofte vanskelig å oppnå, men teamet bør ha et mål om å lage en god oppskrift på hvordan en recovery kan foregå under gitte forutsetninger, og deretter teste denne regelmessig i et alternativt miljø. 
+
+En tenkt oppskrift for løsningen tegnet opp i [artikkelen om systemskisser](../02_designe/02_systemskisser.md) kan være som under. Premisset for planen under er at vi har kildekode og pipelines tilgjengelig i eksempelvis Azure DevOps, og at applikasjon og ressurser på mystisk vis er fjernet fra Azure:
+
+1. Sjekk at nye subscriptions er på plass i Azure 
+    * Konfigurer Azure Pipelines slik at de deployer til disse 
+    * Verifiser at alle Entra-grupper er tilgjengelige
+2. Deploy infrastruktur-som-kode
+3. Konfigurer NSG'er og brannmurer (dersom dette ikke gjøres som kode)
+    * Skru av aksess utenfor leveranseteamet for å unngå at brukere forstyrrer restoreprosessen
+4. Verifiser at ressursene har tilgang til dataplatformen
+5. Verifiser tilganger til database
+6. Restore applikasjon og data: 
+    1. Restore data til database fra siste backup 
+    2. Deploy backend
+    3. Deploy frontend
+9. Verifiser at applikasjon fungerer
+10. Publiser PowerBI-rapport
+    * Verifiser at den kan lese data fra backend
+11. Skru på aksess for sluttbrukere slik at de kan bruke applikasjonen igjen.
+
+Det er vedt å nevne at hvert av punktene kan trenge utfyllende informasjon, med henvisninger til aksesspakker eller gruppemedlemsskap for at personen som restorer skal få nødvendig tilgang. 
+
+# Veien videre
+* [Nasjonal Sikkerhetsmyndighet: Forbered virkshomheten på håndtering av hendelser](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnprinsipper-for-ikt-sikkerhet/handtere-og-gjenopprette/forbered-virksomheten-pa-handtering-av-hendelser/)
+

docs/05_forvalte/06_incident_response.md

@@ -0,0 +1,33 @@
+---
+sidebar_position: 6
+title: Beredskapsplaner og hendelseshåndtering
+---
+
+# Beredskapsplaner og hendelseshåndtering
+:::tip Kort oppsummert
+Når en hendelse først oppstår er det viktig å være forberedt slik at en unngår å kaste bort verdifull tid på aktiviteter som burde vært klart i forkant. Hvem skal varsles, hvem har ansvar og hvem kan hjelpe? 
+:::
+
+Mange tenker gjerne på sikkerhetshendelser som målrettede angrep der _noen_ angriper en løsning ved å _hacke_ den. I noen tilfeller er dette gjerne korrekt, men en hendelse kan være mye mer.  
+
+NSM definerer en sikkerhetshendelse som _"En avvikssituasjon hvor det er et potensiale for tap av konfidensialitet, integritet, og/eller tilgjengelighet for informasjon eller IKT-tjenester. En sikkerhetshendelse kan oppstå som følge av et dataangrep, teknisk svikt, eller utilsiktede feilhandlinger."_ Med andre ord kan en hendelse være nesten hva som helst som påvirker konfidensialitet, integritet og tilgjengelighet, og avhengig av konteksten vil ulike kunder ha ulike krav til når vi må rapportere og/eller agere på dette. 
+
+## Forberedelser
+Dette er dekket i flere artikler under "[Planlegge](../01_planlegge/)", men noe av det viktigste du gjør er å dokumentere hvilke krav vi må etterleve og hvilket ansvar vi har innenfor de ulike fasene i tillegg til kontaktpunkter hos kunden. Noen kunder er tett på sikkerhet og vil monitorere og varsle leveranseteam på egenhånd, andre basererer seg på at teamene selv følger med.
+
+[NSM lister en del nyttige punkter](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnprinsipper-for-ikt-sikkerhet/handtere-og-gjenopprette/forbered-virksomheten-pa-handtering-av-hendelser/) en også bør vurdere innad i teamet; flere av disse peker på  organisasjonen som helhet, men det kan være viktig for teamet å være kjent med de ulike tiltakene. 
+
+# Når hendelsen inntreffer
+Hendelser kan ta mange ulike former. En hendelse kan være svakheter eller sårbarheter som oppdages i en applikasjon, avhengigheter eller kjøremiljø, men det kan også være angrep - både åpenbare eller mer i det skjulte. 
+
+Dersom dere oppdager, eller har grunn til å tro at en løsning er under angrep må dette varsles til kunden umiddelbart. Det er ikke alltid tilfelle at løsningen som angripes er den som er målet, i mange tilfeller er en løsning bare et springbrett videre til en annen. Derfor er det også viktig å vite hvilke tilganger og nettverksåpninger denne har til andre løsninger, slik at kundens IT-organisasjon kan gå opp disse for å se etter tegn på angrep der. 
+
+Om dere kommer over tegn på at en løsning har blitt angrepet eller brukt til et angrep er det også viktig å si ifra, slik at kunden kan sikre informasjon og bevis på dette for videre etterforskning. 
+
+:::caution Husk
+Håndtering av, og etterforskning av hendelser er et eget fagfelt. Dersom dere kommer over tegn på at noe kan ha skjedd, _si ifra_ til deres kontaktpunkt og avvent beskjed fra denne _før_ dere gjør noe.
+:::
+
+# Veien videre
+* [Fortinet: The CIA Triad](https://www.fortinet.com/resources/cyberglossary/cia-triad)
+* [Nasjonal Sikkerhetsmyndighet: Forbered virkshomheten på håndtering av hendelser](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnprinsipper-for-ikt-sikkerhet/handtere-og-gjenopprette/forbered-virksomheten-pa-handtering-av-hendelser/)