# Sikkerhets-scoringsrubrikker (6×5)

**Last updated:** 2026-06-19 (v1.0)
**Category:** AI Security Engineering
**Status:** Established Practice
**Formål:** Deterministiske rubrikker for security-assessment-agent — erstatter vage 1-5 beskrivelser med eksakte, verifiserbare sjekkpunkter
**Type:** reference
**Source:** https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security

---

## Innhold

- [Oversikt](#oversikt)
- [Vektingsmodell](#vektingsmodell)
- [Dimensjon 1: Identity & Access Control (20 %)](#dimensjon-1-identity--access-control-20)
- [Dimensjon 2: Network Security (10 %)](#dimensjon-2-network-security-10)
- [Dimensjon 3: Data Protection (20 %)](#dimensjon-3-data-protection-20)
- [Dimensjon 4: Content Safety & AI Security (15 %)](#dimensjon-4-content-safety--ai-security-15)
- [Dimensjon 5: Compliance & Governance (25 %)](#dimensjon-5-compliance--governance-25)
- [Dimensjon 6: Monitoring & Incident Response (10 %)](#dimensjon-6-monitoring--incident-response-10)
- [Totalscoreberegning](#totalscoreberegning)
- [Referansecaser](#referansecaser)
- [Sammenligning av casene](#sammenligning-av-casene)
- [Kilder og forankring](#kilder-og-forankring)
- [For Cosmo Skyberg](#for-cosmo-skyberg)

## Oversikt

Denne filen definerer **30 rubrikk-celler** (6 dimensjoner × 5 nivåer) med ja/nei-sjekkpunkter for å sikre konsistent, reproduserbar sikkerhetsvurdering av Microsoft AI-arkitekturer. Rammeverket er forankret i Microsoft Cloud Security Benchmark (MCSB) v2, Azure AI security baselines og norske offentlig sektor-krav.

### Scoringsregel (gjelder alle celler)

Hver celle inneholder 5 sjekkpunkter. Regelen er:

| Antall "Ja" | Score |
|-------------|-------|
| 5/5 | 5 — Excellent |
| 4/5 | 4 — Good |
| 3/5 | 3 — Adequate |
| 2/5 | 2 — Poor |
| 0-1/5 | 1 — Critical |

**Merk:** Sjekkpunktene er kumulative — høyere nivåer forutsetter at lavere kontroller er på plass. Bruk dimensjonens sjekkpunkter for det relevante scope (intern/ekstern, sensitivitet).

---

## Vektingsmodell

| # | Dimensjon | Vekt | Begrunnelse |
|---|-----------|------|-------------|
| 1 | Compliance & Governance | 25 % | Regulatoriske brudd har høyest konsekvens for offentlig sektor (GDPR-bøter, AI Act, Schrems II) |
| 2 | Data Protection | 20 % | Personopplysninger og sensitiv data krever sterk beskyttelse (Personopplysningsloven) |
| 3 | Identity & Access Control | 20 % | Identitet er Zero Trust-fundamentet; kompromitterte identiteter er #1 attack vector |
| 4 | Content Safety & AI Security | 15 % | AI-spesifikke trusler (prompt injection, jailbreak) er unike for AI-systemer |
| 5 | Network Security | 10 % | Nettverksisolasjon er viktig men ofte PaaS-managed i moderne arkitekturer |
| 6 | Monitoring & Incident Response | 10 % | Oppdagelse og respons er siste forsvarslinje |
| | **Sum** | **100 %** | |

### Arbeidsbelastnings-profiler (adaptiv vekting)

Standard-profilen over er **kanonisk** og default. For arbeidsbelastninger med markant forskjøvet risikoprofil kan to varianter brukes — de bevarer Standard-profilens relative vektlegging, men flytter tyngdepunktet mot den dominerende trusselen. `security-assessment-agent` og `ms-ai-security` SKILL.md peker hit; vekttallene skal ikke dupliseres andre steder.

| Dimensjon | Standard (kanonisk) | Eksternt eksponert | Persondata-intensiv |
|-----------|:---:|:---:|:---:|
| Compliance & Governance | 25 % | 20 % | 30 % |
| Data Protection | 20 % | 15 % | 25 % |
| Identity & Access Control | 20 % | 25 % | 20 % |
| Content Safety & AI Security | 15 % | 20 % | 10 % |
| Network Security | 10 % | 15 % | 10 % |
| Monitoring & Incident Response | 10 % | 5 % | 5 % |
| **Sum** | **100 %** | **100 %** | **100 %** |

- **Standard** — default for interne og moderat eksponerte systemer. Compliance dominerer (offentlig sektor), deretter data og identitet.
- **Eksternt eksponert** — borgermøtende/anonymt tilgjengelige systemer. Løfter Identity (25 %), Content Safety (20 %) og Network (15 %) — angrepsflaten mot ukjente brukere (identitetsmisbruk, prompt injection, perimeter). Finansieres ved å redusere Compliance, Data og Monitoring med 5 % hver.
- **Persondata-intensiv** — systemer som prosesserer sensitiv persondata (fødselsnummer, helse). Løfter Compliance (30 %) og Data (25 %); reduserer Content Safety og Monitoring med 5 % hver.

Totalscoreformelen under bruker Standard-vektene. Ved variant: bytt ut vektene i formelen med den valgte profilens kolonne.

---

## Dimensjon 1: Identity & Access Control (20 %)

*Referanse: MCSB v2 Identity Management (IM), Privileged Access (PA)*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Entra ID er eneste autentiseringsmekanisme (API-nøkler deaktivert for alle AI-tjenester) | Azure Policy: `disableLocalAuth = true` på Foundry Tools (tidl. Cognitive Services) / OpenAI-ressurser |
| 2 | RBAC med least privilege er implementert (ingen Owner/Contributor på AI-ressurser uten PIM) | Sjekk rolletildelinger: kun custom roles eller innebygde reader/contributor med scope-begrensning |
| 3 | Managed Identities (system-assigned) brukes for alle service-til-service-kommunikasjoner | Ingen hardkodede credentials eller API-nøkler i kode eller config |
| 4 | Conditional Access-policyer er aktive (MFA påkrevd, lokasjon/device-baserte regler, risikobasert) | Entra ID → Conditional Access → minimum 2 policyer for AI-tilgang |
| 5 | Privileged Identity Management (PIM) er aktivert med JIT-tilgang for administrative roller | PIM-konfigurert for Global Admin, AI-ressurs-owners med max 8 timer aktivering |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Entra ID + RBAC + Managed Identity + Conditional Access + PIM |
| **4** | 4/5 oppfylt (vanligvis mangler PIM) | Solid identitetsgrunnlag, men admin-tilgang alltid aktiv |
| **3** | 3/5 oppfylt (typisk: Entra ID + RBAC + Managed Identity) | Grunnleggende identitetskontroller, ingen adaptive policyer |
| **2** | 2/5 oppfylt (typisk: Entra ID + grunnleggende RBAC) | API-nøkler fortsatt i bruk, brede rolletildelinger |
| **1** | 0-1/5 oppfylt | Kun API-nøkler, ingen sentral identitetsstyring |

---

## Dimensjon 2: Network Security (10 %)

*Referanse: MCSB v2 Network Security (NS), Azure AI services security baseline*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Private Endpoints er konfigurert for alle Azure AI-tjenester (OpenAI, AI Search, Storage) | Azure Portal → Networking → Private endpoint connections ≥ 1 per ressurs |
| 2 | Offentlig nettverkstilgang er deaktivert (`publicNetworkAccess: Disabled`) | Azure Policy: `publicNetworkAccess == Disabled` for alle AI-ressurser |
| 3 | NSG-regler begrenser trafikk (deny-all default + eksplisitte allow-rules for kjente sources) | NSG flow logs viser kun tillatt trafikk fra kjente IP-ranges/subnett |
| 4 | API Management (eller tilsvarende gateway) er plassert foran alle eksterne AI-endepunkter med rate limiting | APIM-instans med rate-limit policy (≤ 100 req/min per bruker) og IP-restriksjon |
| 5 | DNS-konfigurasjon bruker Private DNS Zones med korrekt VNet-linking (ingen DNS-lekkasje) | `privatelink.openai.azure.com` DNS zone linket til alle relevante VNets |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Full nettverksisolasjon med gateway, privat DNS, ingen offentlig eksponering |
| **4** | 4/5 oppfylt (vanligvis mangler APIM/gateway) | Private endpoints + NSG, men direkte intern tilgang uten gateway |
| **3** | 3/5 oppfylt (typisk: Private Endpoints + public disabled + NSG) | Grunnleggende isolasjon men uten gateway eller DNS-hardening |
| **2** | 2/5 oppfylt (typisk: Private Endpoints, men public fortsatt enabled) | Delvis isolasjon, AI-tjenester eksponert via hybrid-tilgang |
| **1** | 0-1/5 oppfylt | AI-tjenester fullt eksponert på internett, ingen nettverkskontroller |

---

## Dimensjon 3: Data Protection (20 %)

*Referanse: MCSB v2 Data Protection (DP), Azure AI services security baseline, Personopplysningsloven*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Kryptering i transit er TLS 1.2+ for alle AI-kommunikasjoner (ingen TLS 1.0/1.1) | Azure Policy: minimum TLS version = 1.2 på alle Storage, SQL, AI-ressurser |
| 2 | Kryptering at rest med Customer-Managed Keys (CMK) via Azure Key Vault for sensitive data | Key Vault → Keys → CMK-referanse aktiv på AI-tjenester og storage accounts |
| 3 | Data residency er sikret i godkjent region (Norway East/West for norsk offentlig sektor) | Alle AI-ressurser provisionert i `norwayeast` eller `norwaywest`; ingen cross-region replication uten DPIA |
| 4 | DLP-kontroller er aktivert (Azure AI data loss prevention for outbound URL-filtrering + Purview) | Outbound URL-liste konfigurert på AI-tjenester; Purview sensitivity labels på RAG-data |
| 5 | PII-deteksjon og redaksjon er implementert i AI-pipeline (input og output) | Azure AI Content Safety PII-deteksjon aktiv, eller custom PII-filter i pre/post-processing |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | CMK + Norway region + DLP + PII-redaksjon + TLS 1.2 |
| **4** | 4/5 oppfylt (vanligvis mangler PII-deteksjon i pipeline) | Sterk datakryptering og residency, men output-PII ikke filtrert |
| **3** | 3/5 oppfylt (typisk: TLS + platform-managed encryption + Norway region) | Grunnleggende kryptering, ingen CMK eller DLP |
| **2** | 2/5 oppfylt (typisk: TLS + platform-managed encryption) | Microsoft-managed keys, ingen region-kontroll eller DLP |
| **1** | 0-1/5 oppfylt | Ukjent krypteringsstatus, data i feil region, ingen PII-kontroller |

---

## Dimensjon 4: Content Safety & AI Security (15 %)

*Referanse: MCSB v2 Artificial Intelligence Security (AI-1 til AI-7), OWASP LLM Top 10, Azure AI Content Safety*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Azure AI Content Safety er aktivert med content filters for alle 4 harm-kategorier (hate, violence, sexual, self-harm) på medium+ severity | AI Foundry → Guardrails → Content filter konfigurasjon med severity ≥ medium |
| 2 | Prompt Shields er aktivert for å detektere jailbreak-forsøk og indirect prompt injection | Content filter → Prompt Shields = ON for både user prompts og documents |
| 3 | System message (meta-prompt) inneholder eksplisitte sikkerhetsgrenser og rolleinstruksjoner | System prompt inkluderer: rolleavgrensning, output-begrensninger, "do not reveal" instruksjoner |
| 4 | Output-validering er implementert (groundedness-sjekk, PII-redaksjon, hallucination-deteksjon) | Post-processing pipeline med groundedness-scoring ≥ 0.7, output PII-filter aktiv |
| 5 | Red team-testing er gjennomført og dokumentert (minst én runde med systematiske jailbreak/injection-tester) | Dokumentert red team-rapport med ASR (Attack Success Rate) < 10 % for alle harm-kategorier |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Full content safety + prompt shields + meta-prompt + output-validering + red team |
| **4** | 4/5 oppfylt (vanligvis mangler red team-rapport) | Alle tekniske kontroller på plass, men ingen formell adversarial testing |
| **3** | 3/5 oppfylt (typisk: content filters + prompt shields + system message) | Default-kontroller aktivert, men ingen output-validering eller testing |
| **2** | 2/5 oppfylt (typisk: content filters + system message) | Default content filter, men ingen prompt shields eller output-validering |
| **1** | 0-1/5 oppfylt | Ingen content safety-kontroller, ingen system message, åpent for jailbreak |

---

## Dimensjon 5: Compliance & Governance (25 %)

*Referanse: GDPR/Personopplysningsloven, EU AI Act, Schrems II, Digdir-prinsipper, NSM grunnprinsipper*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | DPIA (personvernkonsekvensutredning) er gjennomført og dokumentert for AI-systemet | DPIA-dokument finnes med risikomatrise, tiltakstabell og godkjenning fra personvernombud |
| 2 | AI Act risikoklassifisering er utført (unacceptable/high/limited/minimal risk) med tilhørende tiltak | Dokumentert klassifisering + transparensterklæring for limited/high risk + human oversight-prosedyre |
| 3 | Databehandleravtale (DPA) er signert med Microsoft og eventuelle tredjeparter | Gjeldende DPA for Azure-tjenester + sub-processor liste gjennomgått |
| 4 | Schrems II-vurdering er dokumentert (EU Data Boundary, overføringskonsekvensvurdering — TIA) | TIA-dokument eller bekreftelse på at EU Data Boundary er aktivert og ingen USA-overføring skjer |
| 5 | Audit trail er implementert (Azure Activity Log + Diagnostic Settings med ≥ 90 dagers retention) | Log Analytics workspace med retention ≥ 90 dager, diagnostic settings aktivert på alle AI-ressurser |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Komplett compliance-dokumentasjon med DPIA + AI Act + DPA + Schrems II + audit |
| **4** | 4/5 oppfylt (vanligvis mangler Schrems II TIA) | Solid governance, men overføringsvurdering ikke formalisert |
| **3** | 3/5 oppfylt (typisk: DPIA + DPA + audit trail) | Grunnleggende compliance, men AI Act og Schrems II ikke adressert |
| **2** | 2/5 oppfylt (typisk: DPA signert + grunnleggende logging) | Minimal governance, viktige vurderinger mangler |
| **1** | 0-1/5 oppfylt | Ingen DPIA, ukjent risikoklassifisering, ingen audit trail |

---

## Dimensjon 6: Monitoring & Incident Response (10 %)

*Referanse: MCSB v2 Logging and Threat Detection (LT), Incident Response (IR), Defender for Cloud AI threat protection*

### Sjekkpunkter

| # | Sjekkpunkt | Verifiseringsmetode |
|---|-----------|---------------------|
| 1 | Azure Monitor med Application Insights er konfigurert for alle AI-applikasjoner (latency, errors, throughput) | App Insights connected string i app config, live metrics visible i portal |
| 2 | Defender for Cloud er aktivert med AI threat protection (Defender CSPM plan med AI SPM) | Defender for Cloud → Environment Settings → Defender CSPM = ON med AI posture management |
| 3 | Diagnostic Settings er aktivert på alle AI-ressurser med logs til Log Analytics (retention ≥ 90 dager) | Diagnostic settings → `RequestResponse` + `Audit` logs enabled, sendt til LA workspace |
| 4 | Alerting-regler er konfigurert for AI-spesifikke hendelser (content filter triggers, uautorisert tilgang, anomalier) | Azure Monitor → Alerts → minimum 3 active alert rules for AI-relaterte metriker |
| 5 | Incident response-plan finnes med definert eskaleringssti, rolleavklaring og recovery-prosedyrer for AI-hendelser | Dokumentert IR-plan med RACI-matrise, eskaleringstider (< 1 time for critical), og øvelseshistorikk |

### Scoringstabell

| Score | Kriterier | Typisk scenario |
|-------|-----------|-----------------|
| **5** | Alle 5 sjekkpunkter oppfylt | Full observability + Defender + alerting + dokumentert IR med øvelser |
| **4** | 4/5 oppfylt (vanligvis mangler IR-plan med øvelser) | Teknisk monitoring på plass, men ingen formell incident response-prosedyre |
| **3** | 3/5 oppfylt (typisk: App Insights + Diagnostic Settings + grunnleggende alerts) | Monitoring finnes, men ingen Defender AI SPM eller IR-plan |
| **2** | 2/5 oppfylt (typisk: App Insights + noen logs) | Begrenset logging, ingen alerting eller threat protection |
| **1** | 0-1/5 oppfylt | Ingen monitoring, ingen logs, ingen incident response |

---

## Totalscoreberegning

### Formel

```
Totalscore = Σ (Dimensjonscore × Vekt)
           = (D1 × 0.20) + (D2 × 0.10) + (D3 × 0.20) + (D4 × 0.15) + (D5 × 0.25) + (D6 × 0.10)

Maks: 5.00, Min: 1.00
```

### Risikokategori-mapping

| Totalscore | Risikokategori | Anbefalt handling |
|------------|----------------|-------------------|
| 4.50 – 5.00 | **Lav risiko** | Vedlikehold nåværende sikkerhetsnivå, årlig gjennomgang |
| 3.50 – 4.49 | **Moderat risiko** | Adresser identifiserte gap innen 1-3 måneder |
| 2.50 – 3.49 | **Høy risiko** | Prioriter utbedring innen 2-4 uker, ledelsen informeres |
| 1.50 – 2.49 | **Kritisk risiko** | Umiddelbar handling påkrevd, vurder å stoppe produksjonsdrift |
| 1.00 – 1.49 | **Uakseptabel risiko** | Stopp produksjon, full sikkerhetsgjennomgang før videre drift |

### Absolutte triggere (overstyrer totalscore)

Uavhengig av totalscore skal risikokategorien oppgraderes til **Kritisk** dersom:
- Compliance & Governance ≤ 1 (regulatoriske brudd)
- Enhver dimensjon = 1 og systemet er borgermøtende (citizen-facing)
- 3 eller flere dimensjoner scorer ≤ 2

---

## Referansecaser

### Case A: Copilot Studio chatbot med SharePoint RAG, kun interne brukere, M365 E5

**Scenario:** Intern HR-chatbot i Direktoratet for digital tjenesteutvikling. Henter svar fra SharePoint-dokumentbibliotek via Copilot Studio. Ingen sensitiv persondata. Tilgjengelig kun for ansatte med M365 E5-lisens.

| Dimensjon | Forventet score | Begrunnelse |
|-----------|----------------|-------------|
| Identity & Access Control | **4** | Entra ID (auto via M365), RBAC via SharePoint-tillatelser, Conditional Access via E5, men PIM sjelden konfigurert for Copilot Studio |
| Network Security | **3** | Copilot Studio er SaaS (ingen private endpoints mulig), men intern-only tilgang via Entra + DLP. NSG ikke relevant for SaaS. |
| Data Protection | **4** | TLS 1.2 (Microsoft-managed), SharePoint kryptert at rest, Norway-region, DLP via M365 E5 Purview, men CMK sjelden for SharePoint |
| Content Safety & AI Security | **3** | Copilot Studio har innebygde guardrails og topic-avgrensning, men ingen custom prompt shields, ingen red team-testing |
| Compliance & Governance | **3** | DPA med Microsoft finnes, men DPIA ofte ikke gjennomført for intern chatbot, AI Act-klassifisering mangler typisk |
| Monitoring & Incident Response | **3** | M365 audit logs finnes, men ingen dedikert AI-monitoring, sjelden konfigurerte alerts eller IR-plan |

**Forventet totalscore:**
```
= (4 × 0.20) + (3 × 0.10) + (4 × 0.20) + (3 × 0.15) + (3 × 0.25) + (3 × 0.10)
= 0.80 + 0.30 + 0.80 + 0.45 + 0.75 + 0.30
= 3.40
```

**Risikokategori: Høy risiko** — Krever utbedring innen 2-4 uker. Hovedfunn: manglende DPIA, AI Act-klassifisering og formell monitoring.

---

### Case B: Microsoft Foundry med custom model, borgermøtende, sensitiv persondata

**Scenario:** Offentlig skjemaveileder for Direktoratet for digital tjenesteutvikling. Brukere (borgere) fyller ut søknader med støtte fra AI. Systemet prosesserer fødselsnummer, helseopplysninger og saksbehandlingdata. Basert på Microsoft Foundry med fine-tuned GPT-4o og Azure AI Search (RAG).

| Dimensjon | Forventet score | Begrunnelse |
|-----------|----------------|-------------|
| Identity & Access Control | **4** | Entra ID B2C for borgere, Managed Identity for backend, RBAC konfigurert, Conditional Access for admin — men PIM ofte mangler |
| Network Security | **4** | Private Endpoints for OpenAI + AI Search + Storage, public disabled, NSG-regler, men APIM gateway ofte ikke implementert i MVP |
| Data Protection | **3** | TLS 1.2, platform-managed encryption, Norway East region — men CMK sjelden for AI Search, PII-deteksjon ofte ufullstendig for norsk fødselsnummer |
| Content Safety & AI Security | **3** | Content filters aktivert (medium+), system message med rolleavgrensning, prompt shields ON — men output-groundedness sjelden validert, ingen red team |
| Compliance & Governance | **2** | DPA signert, noen audit logs — men DPIA ofte mangelfull for AI-spesifikke risikoer, AI Act-klassifisering (high risk) ikke formalisert, Schrems II TIA mangler |
| Monitoring & Incident Response | **2** | App Insights konfigurert for basic telemetri — men ingen Defender AI SPM, ingen AI-spesifikke alerts, ingen IR-plan |

**Forventet totalscore:**
```
= (4 × 0.20) + (4 × 0.10) + (3 × 0.20) + (3 × 0.15) + (2 × 0.25) + (2 × 0.10)
= 0.80 + 0.40 + 0.60 + 0.45 + 0.50 + 0.20
= 2.95
```

**Risikokategori: Høy risiko** — Krever prioritert utbedring innen 2-4 uker. Kritiske funn: mangelfull DPIA for high-risk AI-system, utilstrekkelig monitoring for borgermøtende tjeneste, Schrems II TIA mangler.

**Merk:** Compliance-score på 2 for et borgermøtende system med sensitiv persondata bør eskaleres til ledelsen selv om totalscore er moderat.

---

## Sammenligning av casene

| Aspekt | Case A (Intern Copilot) | Case B (Borger-AI) |
|--------|------------------------|---------------------|
| Totalscore | 3.40 | 2.95 |
| Risikokategori | Høy | Høy |
| Mest kritisk gap | Compliance (DPIA, AI Act) | Compliance (DPIA, Schrems II) + Monitoring |
| Letteste quick-win | Gjennomfør DPIA → +1 Compliance | Aktiver Defender AI SPM → +1 Monitoring |
| Største investering | Red team-testing → +1 Content Safety | Full DPIA + AI Act compliance → +2 Compliance |
| Tidshorisont utbedring | 1-2 måneder | 2-4 måneder |

---

*(Verified MCP 2026-06)* — Microsoft har omdøpt 'Cognitive Services' til '**Foundry Tools**' i sikkerhetsbaselines (Azure Security Benchmark); MCSB v2 AI Security bruker «Foundry Tools» gjennomgående i implementasjonseksemplene. URL for cognitive-services-security-baseline er fortsatt aktiv men omdirigeres til 'Azure security baseline for Foundry Tools'.

## Kilder og forankring

### Microsoft Cloud Security Benchmark (MCSB) v2 (preview)

Dimensjonene er mappet til MCSB v2 security domains:

| Rubrikk-dimensjon | MCSB v2 domain(s) | Nøkkelkontroller |
|-------------------|--------------------|--------------------|
| Identity & Access | IM (Identity Management), PA (Privileged Access) | IM-1, IM-3, IM-7, IM-8, PA-1, PA-7 |
| Network Security | NS (Network Security) | NS-1, NS-2 |
| Data Protection | DP (Data Protection) | DP-1, DP-2, DP-3, DP-4, DP-5, DP-6 |
| Content Safety & AI | AI (Artificial Intelligence Security) | AI-1 til AI-7 |
| Compliance & Governance | GS (Governance and Strategy) | GS + GDPR + AI Act |
| Monitoring & IR | LT (Logging/Threat Detection), IR (Incident Response) | LT-1, LT-4, IR |

### Azure Security Baselines (verifisert via MCP; MCSB v2 AI Security re-verifisert 2026-06-19)

- Azure AI services security baseline: https://learn.microsoft.com/security/benchmark/azure/baselines/cognitive-services-security-baseline
- Azure OpenAI security baseline: https://learn.microsoft.com/security/benchmark/azure/baselines/azure-openai-security-baseline
- Microsoft Foundry security baseline: https://learn.microsoft.com/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline
- MCSB v2 AI Security domain: https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security

### Norske rammeverk

- Personopplysningsloven (GDPR-implementering)
- NSM Grunnprinsipper for IKT-sikkerhet
- Digdir Arkitekturprinsipper for digitalisering
- Schrems II (Datatilsynets veileder for overføring til tredjeland)

---

## For Cosmo Skyberg

### Slik bruker du rubrikkene i en vurdering

1. **Start med kontekst:** Identifiser scope (intern/ekstern, datatyper, plattform) — dette påvirker hvilke sjekkpunkter som er relevante.
2. **Gå gjennom hver dimensjon:** Evaluer hvert av de 5 sjekkpunktene med ja/nei. Dokumenter evidens for hvert svar.
3. **Beregn dimensjonscore:** Tell antall "ja" → score (5 ja = 5, 4 ja = 4, osv.).
4. **Beregn totalscore:** Bruk vektingsformelen. Rund av til 2 desimaler.
5. **Mapper til risikokategori:** Bruk tabellen over. Sjekk absolutte triggere.
6. **Presenter funn:** Bruk output-formatet fra security-assessment-agent med den beregnede scoren.

### Vanlige kalibreringsfeller

| Felle | Konsekvens | Slik unngår du |
|-------|------------|----------------|
| **Gi høy score for "default"-kontroller** | Overvurderer sikkerhetsnivået (default er baseline, ikke "good") | Default = 3. Proaktive tiltak kreves for 4-5. |
| **Score SaaS-tjenester (Copilot Studio) som on-prem** | Irrelevante sjekkpunkter (f.eks. private endpoints for SaaS) | Juster sjekkpunkter: SaaS-tjenester har andre nettverksmodeller |
| **Ignorere compliance fordi "det er IT sin jobb"** | Compliance-gap oppdages for sent (audit, Datatilsynet) | Compliance-dimensjonen har høyest vekt (25 %) av en grunn |
| **Anta at M365 E5 dekker alt** | E5 gir verktøy, men de må konfigureres aktivt | Sjekk: er DLP/Purview/Conditional Access faktisk konfigurert, eller bare lisensiert? |
| **Utelate red team for "lavrisiko"-systemer** | Selv intern chatbot kan lekke sensitiv info via jailbreak | Minimum: kjør 10 standard jailbreak-prompts manuelt og dokumenter resultater |

### Spørsmål å stille kunder

1. **"Kan du vise meg rolletildelingene for deres AI-ressurser i Azure?"** — Avdekker over-privilegerte kontoer (dimensjon 1).
2. **"Er public network access deaktivert på AI-tjenestene?"** — Enkel ja/nei som avgjør dimensjon 2 score.
3. **"Hvilken region kjører AI-tjenestene i, og har dere dokumentert data residency-valget?"** — Avgjør dimensjon 3.
4. **"Har dere tilpasset content filter severity levels, eller bruker dere default?"** — Default = score 3, tilpasset = score 4+.
5. **"Finnes det en DPIA for dette AI-systemet?"** — Ja/nei som påvirker dimensjon 5 mest.
6. **"Hva skjer hvis AI-systemet begynner å gi feilaktige svar? Hvem blir varslet?"** — Avdekker monitoring og IR-gap (dimensjon 6).