feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-analyse-ai-systems.md
+++ b/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-analyse-ai-systems.md
@ -0,0 +1,576 @@
+# ROS-analyse for AI-systemer
+
+**Last updated:** 2026-02
+**Status:** Gjeldende
+**Category:** Norwegian Public Sector AI Governance
+
+---
+
+## Introduksjon
+
+ROS-analyse (Risiko- og Sårbarhetsanalyse) er en systematisk tilnærming til å identifisere, vurdere og håndtere risikoer knyttet til IKT-systemer. For AI-systemer i norsk offentlig sektor innebærer dette en utvidet metodikk som tar høyde for AI-spesifikke risikoer som modellsikkerhet, dataintegritet, bias, og konsekvenser av automatiserte beslutninger.
+
+**Hva er ROS-analyse?**
+ROS-analyse dekker tre hovedsteg:
+1. **Risikoidentifisering** – identifisere hva som kan gå galt
+2. **Risikoanalyse** – vurdere sannsynlighet og konsekvens
+3. **Risikoevaluering** – prioritere og beslutte tiltak
+
+For AI-systemer må denne prosessen inkludere både tekniske sårbarheter (prompt injection, datalekkasje, modellmanipulasjon) og samfunnsmessige risikoer (diskriminering, feilbeslutninger, manglende forklarbarhet).
+
+**Hvorfor er dette kritisk for offentlig sektor?**
+- Offentlige tjenester påvirker borgeres rettigheter og velferd direkte
+- AI-beslutninger kan ha alvorlige konsekvenser (ytelser, tillatelser, helsetjenester)
+- Lovkrav om forsvarlig risikostyring og internkontroll
+- Tillitskrav til offentlige digitale tjenester
+
+---
+
+## Lovgrunnlag og krav
+
+### Sikkerhetsloven
+Sikkerhetsloven regulerer sikkerhet i virksomheter av betydning for nasjonale sikkerhetsinteresser, herunder IKT-sikkerhet i kritiske samfunnsfunksjoner.
+
+**Relevans for AI-systemer:**
+- AI-systemer i kritisk infrastruktur (helse, samferdsel, energi) må tilfredsstille sikkerhetskrav
+- Krav om risikovurdering av IKT-systemer som behandler gradert informasjon
+- Leverandørvurdering for skytjenester med AI-kapabiliteter
+
+### Sektorregelverk
+
+**Helseregisterloven og Pasientjournalloven**
+- Særlige krav til behandling av helseopplysninger med AI
+- Dokumentasjonskrav for automatiserte beslutninger i helsesektoren
+
+**Forvaltningsloven**
+- § 11: Begrunnelsesplikt for enkeltvedtak – gjelder også AI-assisterte beslutninger
+- Krav om forsvarlighet og sporbarhet i saksbehandling
+
+**Personopplysningsloven (GDPR)**
+- Art. 22: Rett til ikke å bli undergitt automatiserte individuelle avgjørelser
+- Art. 35: DPIA (Data Protection Impact Assessment) for høyrisiko AI-behandling
+- Art. 32: Sikkerhetstiltak tilpasset risiko
+
+**Offentleglova (Offentlighetsloven)**
+- Innsyn i offentlige AI-systemer (med visse unntak)
+- Dokumentasjonsplikt for beslutningsgrunnlag
+
+### Internkontrollforskriften
+Pålegger virksomheter å:
+- Kartlegge farer og problemer
+- Analysere risiko
+- Iverksette tiltak for å redusere risiko
+- Systematisk oppfølging og revisjon
+
+**For AI-systemer betyr dette:**
+- Dokumentert risikovurdering før iverksetting
+- Kontinuerlig overvåking av AI-ytelse og sikkerhet
+- Beredskapsplaner for AI-feil eller misbruk
+
+---
+
+## ROS-metodikk for AI
+
+### Verdivurdering (Asset Identification)
+
+**Identifiser verdier som skal beskyttes:**
+1. **Data**
+   - Treningsdata (ofte personopplysninger)
+   - Spørringer/prompts fra brukere
+   - Loggdata fra AI-interaksjoner
+
+2. **AI-modeller**
+   - Proprietære modeller eller fine-tuned versjoner
+   - Konfigurasjoner og prompt engineering
+   - Vektinger og hyperparametre
+
+3. **Tjenester**
+   - Tilgjengelighet av AI-tjenesten
+   - Integritet i beslutningsgrunnlag
+   - Konfidensiell behandling av brukerdata
+
+4. **Omdømme og tillit**
+   - Tilliten til offentlig sektor
+   - Virksomhetens ansvarlighetsmål
+
+### Trusselvurdering (Threat Assessment)
+
+**Kartlegg relevante trusler:**
+
+| Trusselelement | Beskrivelse | Eksempel (AI-kontekst) |
+|----------------|-------------|------------------------|
+| **Sabotasje** | Forsettlig skade på system | Data poisoning, adversarial attacks |
+| **Spionasje** | Uautorisert tilgang til informasjon | Model extraction, training data inference |
+| **Svikt** | Tekniske eller menneskelige feil | Modell-drift, hallusinasjoner, bias |
+| **Ulykke** | Utilsiktede hendelser | Feilklassifisering med alvorlige konsekvenser |
+
+**AI-spesifikke trusler:**
+- **Prompt injection** – manipulering av AI-respons via ondsinnet input
+- **Jailbreaking** – omgåelse av sikkerhetsbegrensninger
+- **Model inversion** – rekonstruksjon av treningsdata fra modell
+- **Bias amplification** – systematisk forskjellsbehandling
+
+### Sårbarhetsanalyse (Vulnerability Analysis)
+
+**Vurder sårbarhet langs ulike dimensjoner:**
+
+1. **Teknisk sårbarhet**
+   - Eksponering av API-endepunkter
+   - Manglende input-validering
+   - Svak autentisering/autorisasjon
+   - Manglende kryptering av data i transit/rest
+
+2. **Organisatorisk sårbarhet**
+   - Manglende kompetanse på AI-sikkerhet
+   - Uklar ansvarsfordeling for AI-drift
+   - Manglende prosedyrer for hendelseshåndtering
+
+3. **Juridisk sårbarhet**
+   - Uklare retningslinjer for AI-bruk
+   - Manglende dokumentasjon av beslutningslogikk
+   - Ikke-compliance med GDPR eller AI-forordningen
+
+### Konsekvensanalyse (Impact Assessment)
+
+**Vurder konsekvens på skala 1-5:**
+
+| Nivå | Beskrivelse | Eksempel (AI) |
+|------|-------------|---------------|
+| **1 - Ubetydelig** | Ingen merkbar påvirkning | Trivielle feil i ikke-kritiske tjenester |
+| **2 - Liten** | Begrenset påvirkning | Forsinkelser i saksbehandling |
+| **3 - Moderat** | Merkbar påvirkning | Feilaktig avslag på søknad (reversibel) |
+| **4 - Alvorlig** | Betydelig skade | Diskriminering i tjenesteyting |
+| **5 - Svært alvorlig** | Katastrofal skade | Feil i helsebeslutninger med livsfare |
+
+**Konsekvensdimensjoner:**
+- Personvern og individuelle rettigheter
+- Tjenestekvalitet og tilgjengelighet
+- Juridiske konsekvenser (erstatning, sanksjoner)
+- Omdømme og tillit
+- Økonomisk tap
+
+### Sannsynlighetsvurdering (Likelihood Assessment)
+
+**Vurder sannsynlighet på skala 1-5:**
+
+| Nivå | Beskrivelse | Estimat |
+|------|-------------|---------|
+| **1 - Svært lite sannsynlig** | Ekstremt sjelden hendelse | < 1 gang per 10 år |
+| **2 - Lite sannsynlig** | Kan skje, men sjelden | 1 gang per 5-10 år |
+| **3 - Mulig** | Kan skje med jevne mellomrom | 1 gang per 1-5 år |
+| **4 - Sannsynlig** | Vil sannsynligvis skje | 1-5 ganger per år |
+| **5 - Svært sannsynlig** | Forventes å skje ofte | Ukentlig/månedlig |
+
+**Faktorer som påvirker sannsynlighet:**
+- Eksponering (intern vs. eksternt tilgjengelig AI)
+- Kompleksitet av systemet
+- Modenhetsgrad på sikkerhetstiltak
+- Trussel-landskap (målrettet vs. opportunistisk)
+
+### Risikoberegning
+
+**Risiko = Sannsynlighet × Konsekvens**
+
+| Risiko | Farge | Tiltak |
+|--------|-------|--------|
+| **1-4** | 🟢 Grønn | Akseptabel – dokumenter og overvåk |
+| **5-9** | 🟡 Gul | Moderat – vurder tiltak |
+| **10-14** | 🟠 Oransje | Betydelig – implementer tiltak |
+| **15-25** | 🔴 Rød | Uakseptabel – umiddelbare tiltak eller avslutt aktivitet |
+
+**Eksempel:**
+- **Trussel:** Prompt injection som gir tilgang til sensitiv data
+- **Sannsynlighet:** 4 (sannsynlig – offentlig eksponert chatbot)
+- **Konsekvens:** 4 (alvorlig – brudd på personvern)
+- **Risiko:** 16 (rød – krever umiddelbare tiltak)
+
+### Tiltaksplan (Risk Treatment)
+
+**Fire hovedstrategier:**
+
+1. **Redusere risiko** – implementere tekniske/organisatoriske tiltak
+2. **Akseptere risiko** – dokumentert beslutning om å leve med restrisiko
+3. **Overføre risiko** – forsikring, leverandøransvar
+4. **Unngå risiko** – ikke implementere AI-løsningen
+
+**Prioritering:**
+- Røde risikoer først
+- Fokuser på tiltak med høyest effekt vs. kostnad
+- Kombiner flere tiltak for forsvar i dybden (defense-in-depth)
+
+---
+
+## AI-spesifikke risikoer
+
+### Modellsikkerhet
+
+**Trusler:**
+- **Adversarial attacks** – subtile endringer i input som får modellen til å feile
+- **Model poisoning** – manipulering av treningsdata for å påvirke modell
+- **Backdoor attacks** – skjulte triggere som aktiverer ondsinnet oppførsel
+
+**Tiltak:**
+- Robust training med adversarial examples
+- Validering av treningsdata (data provenance)
+- Red teaming og penetrasjonstesting av AI-modeller
+- Versjonshåndtering og auditlogg for modellendringer
+
+### Dataintegritet og konfidensialitet
+
+**Trusler:**
+- **Training data leakage** – gjenoppbygging av treningsdata via model queries
+- **Membership inference** – avdekke om spesifikke data var i treningssett
+- **Data poisoning** – injisere korrupte data i treningspipeline
+
+**Tiltak:**
+- Differential privacy i treningsprosess
+- Anonymisering og pseudonymisering
+- Streng tilgangskontroll til treningsdata
+- Kryptering av data i hvile og under overføring
+- Secure multi-party computation (SMPC) for sensitive datasett
+
+### Bias og diskriminering
+
+**Trusler:**
+- **Historisk bias** – gjenspeiling av diskriminering i treningsdata
+- **Representasjonsbias** – underrepresenterte grupper i treningsdata
+- **Aggregasjonsbias** – feil aggregering av data fra heterogene populasjoner
+
+**Tiltak:**
+- Fairness-testing på beskyttede grupper
+- Balanserte datasett (resampling, synthetic data)
+- Fairness constraints i treningsalgoritmer
+- Kontinuerlig overvåking av ytelse per demografisk gruppe
+- Menneskelig oversyn ved beslutninger som påvirker rettigheter
+
+### Tilgjengelighet (Availability)
+
+**Trusler:**
+- **DDoS mot AI-endepunkter** – overbelaste modellen med forespørsler
+- **Resource exhaustion** – langvarige eller komplekse queries som blokkerer tjenesten
+- **Dependency failures** – feil i underliggende infrastruktur (Azure OpenAI throttling)
+
+**Tiltak:**
+- Rate limiting og throttling
+- Caching av vanlige svar
+- Redundans og failover-mekanismer
+- Azure Front Door med DDoS-beskyttelse
+- Kapasitetsplanlegging med PTU (Provisioned Throughput Units)
+
+### Forklarbarhet og sporbarhet
+
+**Trusser:**
+- **Black-box problem** – umulig å forklare hvorfor AI tok en beslutning
+- **Manglende audit trail** – ingen sporbarhet i beslutningsprosess
+- **Repudiation** – bruker eller system nekter for handling
+
+**Tiltak:**
+- Explainable AI (XAI) metoder – SHAP, LIME
+- Omfattende logging av alle AI-interaksjoner
+- Menneske-i-løkken (HITL) for kritiske beslutninger
+- Versjonering av modeller og beslutningslogikk
+- Digital signering av AI-genererte beslutninger
+
+---
+
+## Microsoft-verktøy for risikostyring
+
+### Azure Security Benchmark og Secure Score
+
+**Funksjon:**
+Azure Secure Score gir kontinuerlig vurdering av sikkerhetsstatus for Azure-ressurser.
+
+**For AI-systemer:**
+- Evaluer sikkerhet for Azure OpenAI, Azure AI Search, Azure ML
+- Identifiser misconfigurations (f.eks. offentlig tilgjengelige endepunkter)
+- Prioriterte anbefalinger for sikkerhetstiltak
+
+**Praktisk bruk:**
+```bash
+# Azure CLI kommando for å hente Secure Score
+az security secure-score list
+```
+
+### Microsoft Defender for Cloud
+
+**Funksjon:**
+CSPM (Cloud Security Posture Management) og trusseldeteksjon for Azure-ressurser.
+
+**For AI-systemer:**
+- **Defender for AI Workloads** (preview) – detekterer onormale AI-interaksjoner
+- **Just-in-Time (JIT) access** – reduser eksponering av AI-administrasjonsportaler
+- **Threat intelligence** – advarsler om kjente angrep mot AI-systemer
+
+**Sikkerhetspolicies for AI:**
+- Påkrev private endpoints for Azure OpenAI
+- Krev managed identity istedenfor API keys
+- Aktiver diagnostikklogging for alle AI-tjenester
+
+### Microsoft Purview Compliance Manager
+
+**Funksjon:**
+Overvåk compliance med regelverk (GDPR, AI Act, ISO 27001).
+
+**For AI-systemer:**
+- **Compliance Score** – sporbare tiltak for AI-compliance
+- **Improvement Actions** – spesifikke anbefalinger (f.eks. DPIA-mal)
+- **Assessments** – forhåndsdefinerte maler for AI-relaterte regelverk
+
+**Praktisk eksempel:**
+1. Velg "Data Protection Baseline" assessment
+2. Filtrer på AI-relevante kontroler (automated decision-making)
+3. Dokumenter hvordan Azure OpenAI oppfyller GDPR Art. 22
+
+### Microsoft Threat Modeling Tool
+
+**Funksjon:**
+Strukturert trusselmodellering basert på STRIDE-rammeverket.
+
+**For AI-systemer:**
+- Importer Azure-arkitektur (Azure AI Foundry, Copilot Studio)
+- Identifiser trust boundaries (f.eks. bruker → AI → backend-database)
+- Automatisk generering av trusler basert på dataflyt
+- Eksport til Azure DevOps for sporing av tiltak
+
+**STRIDE for AI:**
+- **Spoofing** – forfalsket brukeridentitet i prompt
+- **Tampering** – manipulering av treningsdata
+- **Repudiation** – benekt AI-generert handling
+- **Information Disclosure** – lekkasje av treningsdata
+- **Denial of Service** – overbelasting av AI-endepunkt
+- **Elevation of Privilege** – prompt injection som gir admin-tilgang
+
+### Azure Policy og Blueprints
+
+**Funksjon:**
+Automatiser compliance-krav gjennom policy-as-code.
+
+**Eksempler på AI-policies:**
+```json
+{
+  "policyRule": {
+    "if": {
+      "allOf": [
+        {"field": "type", "equals": "Microsoft.CognitiveServices/accounts"},
+        {"field": "Microsoft.CognitiveServices/accounts/publicNetworkAccess", "equals": "Enabled"}
+      ]
+    },
+    "then": {
+      "effect": "deny"
+    }
+  }
+}
+```
+*Denne policyen blokkerer opprettelse av Azure OpenAI-ressurser med offentlig nettverkstilgang.*
+
+**Azure Blueprints for AI:**
+- Standard-oppsett med private endpoints, logging, og RBAC
+- Compliance-preset for GDPR eller ISO 27001
+
+### Microsoft Sentinel (SIEM)
+
+**Funksjon:**
+Security Information and Event Management for AI-tjenester.
+
+**Bruksområder:**
+- **Anomalideteksjon** – uvanlige mønstre i AI-bruk (f.eks. massiv datautvinning)
+- **Threat hunting** – aktiv søking etter prompt injection-forsøk
+- **Incident response** – automatiske playbooks ved AI-sikkerhetshendelser
+
+**Eksempel-query (KQL):**
+```kql
+AzureDiagnostics
+| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
+| where Category == "RequestResponse"
+| where ResultType == "Failure"
+| where Properties contains "prompt injection"
+| summarize count() by CallerIPAddress, bin(TimeGenerated, 1h)
+```
+
+---
+
+## ROS-mal for AI-prosjekter
+
+### Mal for ROS-analyse (Excel/tabellformat)
+
+| ID | Trussel | Sårbarhet | Sannsynlighet (1-5) | Konsekvens (1-5) | Risiko | Eksisterende tiltak | Restrisiko | Nye tiltak | Ansvarlig | Frist |
+|----|---------|-----------|---------------------|------------------|--------|---------------------|------------|------------|-----------|-------|
+| AI-001 | Prompt injection | Ingen input-sanitering | 4 | 4 | 16 (🔴) | Ingen | 16 | Implementer Azure AI Content Safety | IT-sikkerhet | 2026-03-01 |
+| AI-002 | Training data leakage | Ingen differential privacy | 2 | 5 | 10 (🟠) | Pseudonymisering | 10 | Differential privacy i ML pipeline | Data Science | 2026-04-01 |
+| AI-003 | Bias i modell | Ubalansert treningsdata | 3 | 4 | 12 (🟠) | Ingen | 12 | Fairness-testing + diverse datasett | AI-lead | 2026-03-15 |
+| AI-004 | DDoS mot API | Ingen rate limiting | 3 | 3 | 9 (🟡) | Azure Front Door | 6 | Rate limiting per bruker | DevOps | 2026-02-20 |
+
+### Rapportmal
+
+**1. Sammendrag**
+- Kort beskrivelse av AI-systemet
+- Overordnet risikonivå (rød/oransje/gul/grønn)
+- Kritiske funn (røde risikoer)
+
+**2. Systembeskrivelse**
+- Formål og bruksområde
+- Arkitektur (dataflyt-diagram)
+- Brukergrupper og tilgangsnivåer
+
+**3. Verdivurdering**
+- Hvilke verdier skal beskyttes?
+- Klassifisering av data (åpen, sensitiv, gradert)
+
+**4. Trusselvurdering**
+- Identifiserte trusler (intern/ekstern, forsettlig/utilsiktet)
+- Trusselbilde (referanse til NSM, ENISA, OWASP)
+
+**5. Risikoanalyse**
+- Tabell med alle identifiserte risikoer (se mal over)
+- Risikomatrise (heat map)
+
+**6. Tiltaksplan**
+- Prioriterte tiltak for røde/oransje risikoer
+- Tidsplan og ansvarlig
+- Ressursbehov
+
+**7. Restrisiko og akseptanse**
+- Dokumentert aksept av restrisiko av ledelsen
+- Forbehold og forutsetninger
+
+**8. Vedlegg**
+- Referanser (lover, regelverk, standarder)
+- Deltakerliste (hvem var involvert i analysen)
+- Revisjonsplan (neste gjennomgang)
+
+### Prosess-sjekkliste
+
+**Før ROS-analyse:**
+- [ ] Etabler tverrfaglig team (AI, jus, sikkerhet, domeneekspert)
+- [ ] Skaff dokumentasjon (arkitektur, dataflyt, personvernkonsekvensvurdering)
+- [ ] Definer scope (hvilke deler av AI-systemet dekkes?)
+
+**Under ROS-analyse:**
+- [ ] Identifiser verdier (hva skal beskyttes?)
+- [ ] Kartlegg trusler (brainstorming, threat libraries)
+- [ ] Vurder sårbarheter (gap-analyse mot beste praksis)
+- [ ] Beregn risiko (sannsynlighet × konsekvens)
+- [ ] Foreslå tiltak (teknisk, organisatorisk, juridisk)
+
+**Etter ROS-analyse:**
+- [ ] Dokumenter i rapport
+- [ ] Få godkjenning fra ledelsen
+- [ ] Implementer tiltak (følg opp i backlog)
+- [ ] Planlegg neste revisjon (årlig eller ved vesentlige endringer)
+
+---
+
+## For arkitekten (Cosmo)
+
+Når du møter en virksomhet som skal utføre ROS-analyse for et AI-system, bruk disse spørsmålene:
+
+1. **Hva er formålet med AI-systemet?**
+   - Hvilke beslutninger tar systemet? (automatiske eller assisterte)
+   - Hvem er brukerne? (interne saksbehandlere, eksterne borgere)
+   - Hvilke data behandles? (personopplysninger, sensitive opplysninger, gradert info)
+
+2. **Hvilke juridiske krav gjelder?**
+   - Er dette et høyrisiko AI-system ihht. AI Act?
+   - Kreves DPIA etter GDPR Art. 35?
+   - Gjelder særlovgivning (helseregisterloven, sikkerhetsloven)?
+
+3. **Hvordan er AI-systemet arkitektonisk bygget?**
+   - On-premises, cloud (Azure), hybrid?
+   - Proprietær modell eller LLM-as-a-service (Azure OpenAI)?
+   - Hvilke integrasjoner finnes? (databaser, fagsystemer, tredjepartstjenester)
+
+4. **Hvilke trusler bekymrer virksomheten mest?**
+   - Datalekkasje, bias, tjenestefeil, manipulering, omdømmetap?
+   - Har det vært sikkerhetshendelser tidligere (for AI eller andre systemer)?
+
+5. **Hvilke sikkerhetstiltak er allerede implementert?**
+   - Input-validering, autentisering, kryptering, logging?
+   - Content filtering (Azure AI Content Safety)?
+   - Overvåking og alerting (Azure Monitor, Sentinel)?
+
+6. **Hvem er ansvarlig for AI-sikkerheten?**
+   - Finnes dedikert AI-sikkerhetsrolle?
+   - Hvordan er ansvaret fordelt mellom IT, jus, og fagavdeling?
+
+7. **Hvordan håndteres AI-hendelser?**
+   - Finnes beredskapsplan for AI-feil eller angrep?
+   - Hvem kontaktes ved mistanke om prompt injection eller datalekkasje?
+   - Hvordan kommuniseres hendelser til brukere/berørte?
+
+8. **Når skal ROS-analysen oppdateres?**
+   - Årlig revisjon?
+   - Ved vesentlige endringer (nye funksjoner, nye datasett, ny lovgivning)?
+   - Etter sikkerhetshendelser?
+
+**Anbefalinger basert på scope:**
+
+| Scenario | Primær risiko | Anbefalt Microsoft-verktøy |
+|----------|---------------|----------------------------|
+| Intern chatbot for saksbehandling | Datalekkasje, bias | Azure OpenAI + Private Endpoint, Fairness-testing |
+| Automatisk vedtak i forvaltning | Diskriminering, feilbeslutninger | Menneske-i-løkken, Explainable AI, omfattende logging |
+| Prediktiv analyse på helsedata | Personvern, databrudd | Differential privacy, Defender for Cloud, Purview |
+| Kunnskapsbase med RAG | Informasjonslekkasje | Azure AI Search med RBAC, Document-level security |
+
+---
+
+## Kilder og verifisering
+
+### Norske myndigheter og organisasjoner
+
+1. **Direktoratet for samfunnssikkerhet og beredskap (DSB)**
+   - [Samfunnssikkerhet i arealplanlegging](https://www.dsb.no/veiledere-handboker-og-informasjonsmateriell/samfunnssikkerhet-i-kommunenes-arealplanlegging/) – Veileder til ROS-analyse som metode
+   - [Helhetlig ROS i kommunen](https://www.dsb.no/lover/risiko-sarbarhet-og-beredskap/artikler/helhetlig-ros-i-kommunen/) – Metodikk for kommunal ROS
+
+2. **Nasjonal sikkerhetsmyndighet (NSM)**
+   - [Risikovurdering av IKT-systemer (PDF)](https://nsm.no/getfile.php/136603-1718717207/NSM/Filer/Bildegalleri/Bilder%20til%20grunnprinsipper/Risikovurdering%20av%20IKT-systemer.pdf) – Praktisk verktøy for risikovurdering
+   - [NSMs Grunnprinsipper for IKT-sikkerhet v2.1 (PDF)](https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf) – 21 prinsipper og 118 sikkerhetstiltak
+   - [Gode risikovurderinger ved tjenesteutsetting](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/sikkerhetsfaglige-anbefalinger-ved-tjenesteutsetting/gode-risikovurderinger-for-a-kunne-ta-riktig-beslutning/)
+
+3. **Universitetet i Oslo (UiO)**
+   - [Kapittel 7: Risiko- og sårbarhetsanalyser](https://www.uio.no/tjenester/it/sikkerhet/lsis/7.html) – Krav og metodikk for ROS i universitetssektor
+
+4. **Finanstilsynet**
+   - [Risiko- og sårbarhetsanalyse (ROS) 2024](https://www.finanstilsynet.no/publikasjoner-og-analyser/risiko--og-sarbarhetsanalyse/2024/ros-2024/risiko--og-sarbarhetsanalyse-ros-2024/) – Sektorspesifikk ROS for finansnæringen (inkl. IKT-risiko)
+
+5. **KS (Kommunesektorens organisasjon)**
+   - [Styrking av digital robusthet i kommunal sektor (PDF)](https://www.ks.no/contentassets/c1f4618f50e448069935735d9451765d/Digital-robusthet-i-kommunal-sektor-samlet.pdf) – Veiledning for kommuner om cybersikkerhet
+
+6. **Datatilsynet**
+   - [Risikovurdering](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/informasjonssikkerhet-internkontroll/risikovurdering/) – Personvernperspektivet på risikovurdering
+
+### Microsoft Azure dokumentasjon
+
+7. **Microsoft Learn – Threat Modeling**
+   - [Security considerations for mission-critical workloads on Azure](https://learn.microsoft.com/en-us/azure/well-architected/mission-critical/mission-critical-security#threat-modeling) – STRIDE-rammeverk for Azure
+   - [Architecture strategies for threat analysis](https://learn.microsoft.com/en-us/azure/well-architected/security/threat-model) – Microsoft Threat Modeling Tool
+   - [Design secure applications on Azure](https://learn.microsoft.com/en-us/azure/security/develop/secure-design#design) – SDL og threat modeling i design-fasen
+
+8. **Microsoft Training – Threat Modeling**
+   - [Secure your infrastructure with threat modeling](https://learn.microsoft.com/en-us/training/modules/threat-modeling-enterprise-infrastructure/) – Praktisk trening i trusselmodellering
+   - [Choose a client application with threat modeling](https://learn.microsoft.com/en-us/training/modules/threat-modeling-secured-environment/) – Sikkerhetsvurdering av applikasjoner
+   - [Use a framework to identify threats](https://learn.microsoft.com/en-us/training/modules/tm-use-a-framework-to-identify-threats-and-find-ways-to-reduce-or-eliminate-risk/) – STRIDE-basert trusselidentifikasjon
+
+9. **Microsoft Security Benchmark**
+   - [DevOps Security – DS-1: Conduct threat modeling](https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-devop-security#ds-1-conduct-threat-modeling) – Integrere threat modeling i DevOps
+
+10. **Microsoft Security Development Lifecycle**
+    - [SDL Threat Modeling Tool](https://www.microsoft.com/securityengineering/sdl/threatmodeling) – Gratis verktøy for trusselmodellering
+
+### Internasjonale standarder og rammeverk
+
+11. **ISO/IEC 27005** – Information security risk management
+12. **NIST SP 800-30** – Guide for Conducting Risk Assessments
+13. **OWASP Threat Modeling** – [Threat Modeling Process](https://owasp.org/www-community/Threat_Modeling_Process)
+14. **ENISA** – [AI Cybersecurity Challenges](https://www.enisa.europa.eu/topics/artificial-intelligence-cybersecurity) (EU-perspektiv på AI-risiko)
+
+### Verifikasjon og aktualitet
+
+Denne kunnskapsreferansen er basert på:
+- **10 unike kilder** (DSB, NSM, Microsoft Learn, Datatilsynet, KS, Finanstilsynet, UiO)
+- Dokumenter publisert i perioden **2021-2026**
+- **NSMs Grunnprinsipper v2.1** (oppdatert 2024)
+- **Microsoft Well-Architected Framework** (kontinuerlig oppdatert)
+- Norsk regelverk gjeldende per **februar 2026**
+
+**Sist verifisert:** 2026-02
+**Neste revisjon:** 2027-02 (eller ved vesentlige endringer i AI-forordningen/NSM-veiledere)