baa2d0220b
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>
22 KiB
22 KiB
Sikkerhets-scoringsrubrikker (6×5)
Sist oppdatert: 2026-02 (v1.0) Kategori: AI Security Engineering Status: Established Practice Formål: Deterministiske rubrikker for security-assessment-agent — erstatter vage 1-5 beskrivelser med eksakte, verifiserbare sjekkpunkter
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 % |
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å 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 Statens vegvesen. 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: Azure AI Foundry med custom model, borgermøtende, sensitiv persondata
Scenario: Offentlig skjemaveileder for Statens vegvesen. Brukere (borgere) fyller ut søknader med støtte fra AI. Systemet prosesserer fødselsnummer, helseopplysninger og førerkortdata. Basert på Azure AI 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 |
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 2026-02)
- 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
- Azure AI 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
- Start med kontekst: Identifiser scope (intern/ekstern, datatyper, plattform) — dette påvirker hvilke sjekkpunkter som er relevante.
- Gå gjennom hver dimensjon: Evaluer hvert av de 5 sjekkpunktene med ja/nei. Dokumenter evidens for hvert svar.
- Beregn dimensjonscore: Tell antall "ja" → score (5 ja = 5, 4 ja = 4, osv.).
- Beregn totalscore: Bruk vektingsformelen. Rund av til 2 desimaler.
- Mapper til risikokategori: Bruk tabellen over. Sjekk absolutte triggere.
- 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
- "Kan du vise meg rolletildelingene for deres AI-ressurser i Azure?" — Avdekker over-privilegerte kontoer (dimensjon 1).
- "Er public network access deaktivert på AI-tjenestene?" — Enkel ja/nei som avgjør dimensjon 2 score.
- "Hvilken region kjører AI-tjenestene i, og har dere dokumentert data residency-valget?" — Avgjør dimensjon 3.
- "Har dere tilpasset content filter severity levels, eller bruker dere default?" — Default = score 3, tilpasset = score 4+.
- "Finnes det en DPIA for dette AI-systemet?" — Ja/nei som påvirker dimensjon 5 mest.
- "Hva skjer hvis AI-systemet begynner å gi feilaktige svar? Hvem blir varslet?" — Avdekker monitoring og IR-gap (dimensjon 6).