Merge pull request #131 from bouvet/en_translation2

English translation
bouvet · Oct 18, 2024 · 90dc863 · 90dc863
2 parents a39d85f + 9f400ee
commit 90dc863
Show file tree

Hide file tree

Showing 114 changed files with 2,823 additions and 26 deletions.
diff --git a/docs/01_planlegge/01_ansvarsfordeling.md b/docs/01_planlegge/01_ansvarsfordeling.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 1
+slug: /planlegge/ansvarsfordeling
 ---
 
 # Ansvarsfordeling

diff --git a/docs/01_planlegge/02_data_og_klassifisering.md b/docs/01_planlegge/02_data_og_klassifisering.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 2
+slug: /planlegge/data_og_klassifisering
 ---
 
 # Data og klassifisering

diff --git a/docs/01_planlegge/03_business_continuity.md b/docs/01_planlegge/03_business_continuity.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 3
+slug: /planlegge/business_continuity
 ---
 
 # Business Continuity

diff --git a/docs/01_planlegge/04_verktoy_og_bruk.md b/docs/01_planlegge/04_verktoy_og_bruk.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 5
+slug: /planlegge/verkøy
 ---
 # Verktøy brukt i leveransen
 :::tip Kort oppsummert
@@ -53,12 +54,12 @@ Et tips er å bruke [pre-commit](https://pre-commit.com) til å kjøre alt av li
 :::
 
 ## CI/CD
-Et godt [CI/CD-system (Continuous Integration / Continuous Deployment)](../04_deploye/01_cicd.md) kan brukes til å øke sikkerheten på sluttproduktet betydelig, gjennom å automatisere ulike sjekker og tester som sikrer kvaliteten i leveransen. 
+Et godt [CI/CD-system (Continuous Integration / Continuous Deployment)](/deploye/cicd) kan brukes til å øke sikkerheten på sluttproduktet betydelig, gjennom å automatisere ulike sjekker og tester som sikrer kvaliteten i leveransen. 
 
 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)](../03_utvikle/05_software_supply_chain.md) 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.
+[Software composition analysis (SCA)](/utvikle/software_supply_chain) 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.
@@ -68,10 +69,10 @@ Vær obs på at flere av punktene under krever tilleggssoftware. Vi har per idag
 * Test for strict [JWT valdiation](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens)
 
 ### Statisk kodeanalyse (SAST)
-[Statisk kodeanalyse (SAST)](../03_utvikle/08_sikkerhetstesting.md) 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.
+[Statisk kodeanalyse (SAST)](/utvikle/sikkerhetstesting) 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](../03_utvikle/02_secrets.md) - 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. 
+[Sjekking av hemmeligheter](/utvikle/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.

diff --git a/docs/01_planlegge/05_sikkerhetsgater.md b/docs/01_planlegge/05_sikkerhetsgater.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 6
 title: Sikkerhetskontrollpunkt 
+slug: /planlegge/sikkerhetskontrollpunkt
 ---
 
 # Sikkerhetskontrollpunkt
@@ -17,7 +18,7 @@ Disse kan defineres mellom logiske faser i prosjektet, eksempelvis mellom design
 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
+* skal foreligge et [design](/designe/systemskisser) 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
 

diff --git a/docs/01_planlegge/introduction.md b/docs/01_planlegge/introduction.md
@@ -1,3 +1,7 @@
+--- 
+slug: /planlegge/introduksjon
+---
+
 # Planlegge
 
 <div className="row category-into">

diff --git a/docs/02_designe/01_sikkerhetskrav.md b/docs/02_designe/01_sikkerhetskrav.md
@@ -1,5 +1,7 @@
 ---
 sidebar_position: 1
+slug: /designe/sikkerhetskrav
+
 ---
 
 # Sikkerhetskrav

diff --git a/docs/02_designe/02_systemskisser.md b/docs/02_designe/02_systemskisser.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 2
+slug: /designe/systemskisser
 ---
 
 # Systemskisser

diff --git a/docs/02_designe/02a_network.md b/docs/02_designe/02a_network.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 3
+slug: /designe/nettverkskonsepter
 ---
 
 # Nettverkskonsepter
@@ -57,7 +58,7 @@ Send all utgående trafikk gjennom en egen proxytjeneste som blokkerer alt som s
 
 ## Konfigurasjon
 
-Konfigurasjon av nettverk bør automatiseres i så stor grad som mulig, helst ved bruk av et [CI/CD-system](../01_planlegge/04_verktoy_og_bruk.md).
+Konfigurasjon av nettverk bør automatiseres i så stor grad som mulig, helst ved bruk av et [CI/CD-system](/planlegge/verktøy).
 
 - Begrens hvem som kan konfigurere både nettverket og nettverksregler direkte
     - Sett opp Just-in-time (JIT)-tilgang der det er mulig

diff --git a/docs/02_designe/03_segregering.md b/docs/02_designe/03_segregering.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 4
+slug: /designe/segregering
 ---
 
 # Segregering av miljø

diff --git a/docs/02_designe/04_autentisering.md b/docs/02_designe/04_autentisering.md
@@ -1,5 +1,6 @@
 ---
 sidebar_position: 4
+slug: /designe/autentisering_og_autorisasjon
 ---
 
 # Autentisering og autorisering

diff --git a/docs/02_designe/05_trusselmodellering.md b/docs/02_designe/05_trusselmodellering.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 5
 title: Trusselmodellering
+slug: /designe/trusselmodellering
 ---
 # Trusselmodellering
 :::tip Kort oppsummert

diff --git a/docs/02_designe/06_kompetanseheving.md b/docs/02_designe/06_kompetanseheving.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 6
 title: Kompetanseheving
+slug: /designe/kompetanseheving
 ---
 # Kompetanseheving
 :::tip Kort oppsummert

diff --git a/docs/02_designe/introduction.md b/docs/02_designe/introduction.md
@@ -1,3 +1,6 @@
+--- 
+slug: /designe/introduksjon
+---
 # Designe
 
 <div className="row category-into">

diff --git a/docs/03_utvikle/01_utviklingsmiljoer.md b/docs/03_utvikle/01_utviklingsmiljoer.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 2
 title: Utviklingsmiljø
+slug: /utvikle/utviklingsmiljø
 ---
 # Utviklingsmiljø, verktøy og byggmiljø
 :::tip Kort oppsummert

diff --git a/docs/03_utvikle/02_secrets.md b/docs/03_utvikle/02_secrets.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 3
 title: Hemmeligheter
+slug: /utvikle/hemmeligheter
 ---
 # Hemmeligheter
 :::tip Kort oppsummert

diff --git a/docs/03_utvikle/03_datavalidering.md b/docs/03_utvikle/03_datavalidering.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 4
 title: Datavalidering
+slug: /utvikle/datavalidering
 ---
 # Datavalidering fra andre systemer
 :::tip Kort oppsummert

diff --git a/docs/03_utvikle/04_sikkerhetspraksiser.md b/docs/03_utvikle/04_sikkerhetspraksiser.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 5
 title: Sikkerhetspraksiser
+slug: /utvikle/sikkerhetspraksiser
 ---
 # Sikkerhetspraksiser
 :::tip Kort oppsummert

diff --git a/docs/03_utvikle/05_software_supply_chain.md b/docs/03_utvikle/05_software_supply_chain.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 6
 title: Software Supply Chain
+slug: /utvikle/software_supply_chain
 ---
 
 # Software supply chain

diff --git a/docs/03_utvikle/06_interne_komponenter.md b/docs/03_utvikle/06_interne_komponenter.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 7
 title: Interne komponenter
+slug: /utvikle/interne_komponenter
 ---
 
 # Interne komponenter

diff --git a/docs/03_utvikle/08_sikkerhetstesting.md b/docs/03_utvikle/08_sikkerhetstesting.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 6
 title: Sikkerhetstesting
+slug: /utvikle/sikkerhetstesting
 ---
 
 # Sikkerhetstesting
@@ -20,7 +21,7 @@ Dersom dette ikke tas hensyn til kan det få konsekvenser, både for kundeforhol
 :::
 
 ## Testmiljø
-Når en skal bedrive sikkerhetstesting mot et kjørende miljø er det viktig at en alltid avklarer dette godt i forkant. Mange typer testing kan være destruktiv, så dersom [miljøene ikke er godt nok adskilt](../02_designe/03_segregering.md) kan en risikere å påvirke andre miljø enn tiltenkt.
+Når en skal bedrive sikkerhetstesting mot et kjørende miljø er det viktig at en alltid avklarer dette godt i forkant. Mange typer testing kan være destruktiv, så dersom [miljøene ikke er godt nok adskilt](/designe/segregering) kan en risikere å påvirke andre miljø enn tiltenkt.
 
 En god løsning, spesielt dersom en bruker infrastruktur-som-kode (IAC) er å ha en pipeline som deployer et eget miljø som kan brukes for sikkerhetstesting. Dersom dette designes inn i leveransen fra starten, vil det ofte være enkelt å sette opp miljø som er identiske med produksjonsmiljøet, der en også kan kopiere databaser og eventuelt kjøre anonymiseringsprosesser mot dataene. 
 

diff --git a/docs/03_utvikle/09_dokumentasjon.md b/docs/03_utvikle/09_dokumentasjon.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 6
 title: Software Supply Chain
+slug: /utvikle/dokumentasjon
 ---
 
 # Dokumentasjon
@@ -17,7 +18,7 @@ Det er mange årsaker til at vi må dokumentere løsningen vi bygger; den mest
 Prosjektet må finne en løsning for hvor dokumentasjon oppbevares som gir mening i prosjektet. Husk at god dokumentasjon er like sensitivt som kildekoden, og må behandles deretter. I mange tilfeller kan det være lurt med verktøy som støtter versjonskontroll - i mange tilfeller kan det være lurt å legge dokumentasjon sammen med kildekoden, eller evt i egne repos som kan brukes f.eks. med Azure DevOps wiki. 
 
 ## Hva skal dokumenteres
-Hva vi bør dokumentere vil variere fra prosjekt til prosjekt. Vi bør alltid ha et [design](../02_designe/02_systemskisser.md) som gir et innblikk i eksempelvis infrastruktur, IAM og dataflyt slik at det er mulig å ettergå dette på senere tidspunkt. 
+Hva vi bør dokumentere vil variere fra prosjekt til prosjekt. Vi bør alltid ha et [design](/designe/systemskisser) som gir et innblikk i eksempelvis infrastruktur, IAM og dataflyt slik at det er mulig å ettergå dette på senere tidspunkt. 
 
 Trusselmodell må alltid dokumenteres og vedlikeholdes, og eventuelle mitigerende tiltak må også dokumenteres. 
 

diff --git a/docs/03_utvikle/introduction.md b/docs/03_utvikle/introduction.md
@@ -1,3 +1,6 @@
+--- 
+slug: /utvikle/introduksjon
+---
 # Utvikle
 
 <div className="row category-into">

diff --git a/docs/04_deploye/01_cicd.md b/docs/04_deploye/01_cicd.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 2
 title: CI/CD
+slug: /deploye/cicd
 ---
 
 # CI/CD

diff --git a/docs/04_deploye/02_bygg.md b/docs/04_deploye/02_bygg.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 3
 title: Bygging
+slug: /deploye/bygging
 ---
 
 # Bygging 
@@ -18,7 +19,7 @@ Selvstyrte agenter er mer komplekse da du har ansvar for alt av vedlikehold og k
 
 Selv om det første alternativet somoftest er godt nok, er det viktig å være klar over mulighetene som finnes, og når en bør vurdere disse. Uansett løsning er det viktig å tenke på at byggmiljøet er et veldig sårbart punkt; dersom dette kompromitteres kan en angriper potensielt utføre endringer som påvirker _alt_ som bygges der. 
 
-Dette er spesielt viktig med bruk av [tredjepartspakker](../03_utvikle/05_software_supply_chain.md), og et minimum her bør være at pakker pinnes til spesifikke versjoner og at en aldri henter siste versjon av en pakke automatisk. 
+Dette er spesielt viktig med bruk av [tredjepartspakker](/utvikle/software_supply_chain), og et minimum her bør være at pakker pinnes til spesifikke versjoner og at en aldri henter siste versjon av en pakke automatisk. 
 
 # Veien videre
 * [Microsoft: Azure Pipelines](https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops)

diff --git a/docs/04_deploye/03_deploy.md b/docs/04_deploye/03_deploy.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 4
 title: Deployering
+slug: /deploye/deployering
 ---
 
 # Deployering

diff --git a/docs/04_deploye/04_pentesting.md b/docs/04_deploye/04_pentesting.md
@@ -1,14 +1,15 @@
 ---
 sidebar_position: 5
 title: Penetrasjonstesting 
+slug: /deploye/pentesting
 ---
 
 # Penetrasjonstesting!
 :::tip Kort oppsummert
 Penetrasjonstesting, ofte omtalt som pentesting er kunsten å teste et system for å finne svake punkter som kan utnyttes, samt risikoen disse svakhetene medfører for eieren av løsningen. 
 :::
 
-[Sikkerhetstesting](../03_utvikle/08_sikkerhetstesting.md) og pentesting har mange fellestrekk, men der tilnærminger som DAST primært fokuserer på webapplikasjoner og mer automatiserte tester, vil en pentest være mer omfattende og typisk også inkludere underliggende infrastruktur og nettverk. I noen tilfeller vil den også kunne ha et fysisk element der pentesterne vil forsøke å komme seg inn i lokalene for å avdekke svakheter ved fysisk sikring eller rutiner. 
+[Sikkerhetstesting](/utvikle/sikkerhetstesting) og pentesting har mange fellestrekk, men der tilnærminger som DAST primært fokuserer på webapplikasjoner og mer automatiserte tester, vil en pentest være mer omfattende og typisk også inkludere underliggende infrastruktur og nettverk. I noen tilfeller vil den også kunne ha et fysisk element der pentesterne vil forsøke å komme seg inn i lokalene for å avdekke svakheter ved fysisk sikring eller rutiner. 
 
 En penetrasjonstest vil _alltid_ ha et avtalt omfang som regulerer hva pentesterne kan gjøre, når de kan gjøre det og hvilke ressurser og tjenester de kan teste. 
 
@@ -20,7 +21,7 @@ Etter at testingen er gjennomført vil det normalt overleveres en rapport som be
 ## Hva kreves for å gjennomføre en pentest? 
 Først og fremst trenger man en eller flere pentestere. Dette er ikke noe man gjør på egenhånd etter å ha sett noen videoer på Youtube! En pentest krever kompetanse på flere områder da noen angrep avhenger av å utnytte flere sårbarheter som hver for seg ikke er spesielt alvorlige. 
 
-Som utviklerteam må man sikre at miljøet som skal testet er skikkelig identifisert, slik at alle forstår hvor testingen finner sted. Omfanget av testen må defineres - husk på at det må være mulig å skille et faktisk angrep fra en pentest dersom begge skjer samtidig: Dersom du ser tegn på angrep mot et miljø som ikke er en del av testen og du har [segregert miljøene dine](../02_designe/03_segregering.md) bør du ta grep! 
+Som utviklerteam må man sikre at miljøet som skal testet er skikkelig identifisert, slik at alle forstår hvor testingen finner sted. Omfanget av testen må defineres - husk på at det må være mulig å skille et faktisk angrep fra en pentest dersom begge skjer samtidig: Dersom du ser tegn på angrep mot et miljø som ikke er en del av testen og du har [segregert miljøene dine](/designe/segregering) bør du ta grep! 
 
 Som en del av planleggingen er det viktig å sjekke opp med kunden hvilke rutiner de har for pentesting. I mange tilfeller vil de ha et sikkerhetssenter (Security Operations Center, SOC) og/eller et nettverkssenter (Network Operations Center, NOC) som overvåker infrastrukturen kontinuerlig, disse må være en del av planleggingen for å unngå misforståelser eller problemer når testen begynner. 
 

diff --git a/docs/04_deploye/introduction.md b/docs/04_deploye/introduction.md
@@ -1,3 +1,6 @@
+--- 
+slug: /deploye/introduksjon
+---
 # Deploye
 
 <div className="row category-into">

diff --git a/docs/05_forvalte/01_verifisering_av_design.md b/docs/05_forvalte/01_verifisering_av_design.md
@@ -1,14 +1,15 @@
 ---
 sidebar_position: 1
 title: Verifiser design
+slug: /forvalte/verifiser_design
 ---
 
 # Verifiser designet
 :::tip Kort oppsummert
 Når vi utvikler en løsning bør vi alltid validere at løsningen er i henhold til designet. Dersom den avviker må vi enten korrigere løsningen eller oppdatere designet.
 :::
 
-Når vi lager et [design](../02_designe/02_systemskisser.md) for en ny løsning hender det at det er detaljer vi ikke kjenner, eller at det oppstår uventede komplikasjoner underveis i implementeringen. Dette kan resultere i at designet vi opprinnelig laget avviker fra den ferdige løsningen. 
+Når vi lager et [design](/designe/systemskisser) for en ny løsning hender det at det er detaljer vi ikke kjenner, eller at det oppstår uventede komplikasjoner underveis i implementeringen. Dette kan resultere i at designet vi opprinnelig laget avviker fra den ferdige løsningen. 
 
 Dokumentasjonen er viktig for å forstå hvordan en løsning er satt opp og hvordan den fungerer, spesielt om det oppstår en hendelse som krever redeployment eller disaster recovery. For å sikre at gapet mellom dokumentasjon og ferdig produkt ikke er for stort bør vi derfor alltid validere designet i etterkant. 
 

diff --git a/docs/05_forvalte/02_audit.md b/docs/05_forvalte/02_audit.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 1
 title: Audit/revisjon
+slug: /forvalte/revisjon
 ---
 
 # Audit eller revisjon av prosjekt eller leveranse

diff --git a/docs/05_forvalte/03_logging_monitorering.md b/docs/05_forvalte/03_logging_monitorering.md
@@ -1,6 +1,7 @@
 ---
 sidebar_position: 1
 title: Logging og monitorering
+slug: /forvalte/logging_og_monitorering
 ---
 
 # Logging og monitorering

diff --git a/docs/05_forvalte/04_forvaltning_avhengigheter.md b/docs/05_forvalte/04_forvaltning_avhengigheter.md
@@ -1,14 +1,15 @@
 ---
 sidebar_position: 1
 title: Forvaltning av avhengigheter
+slug: /forvalte/avhengigheter
 ---
 
 # Forvaltning av avhengigheter
 :::tip Kort oppsummert
 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). Dere vil komme i situasjoner der 
+Når teamet er i forvaltningsmodus gjelder fremdeles de fleste problemstillingene nevnt i artikkelen om [Software Supply Chain](/utvikle/software_supply_chain). 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