ms-ai-architect/skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md

AI Security Scoring and Risk Rating Framework

Last updated: 2026-06-19 Status: Established Practice Category: AI Security Engineering Type: reference Source: https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Å score og rangere AI-sikkerhetsrisiko krever et strukturert rammeverk som kombinerer kvantitativ måling med kvalitativ vurdering. Microsoft sin tilnærming, basert på AI Risk Assessment Framework v4.1.4, gir en systematisk metode for å evaluere AI-systemer gjennom hele livssyklusen — fra datainnsamling til produksjonsdrift.

Et effektivt scoring-framework balanserer tre dimensjoner: severity (alvorlighetsgrad av kompromittering), likelihood (sannsynlighet for utnyttelse), og impact (konsekvenser for organisasjonen). Dette gir ledelsen et beslutningsgrunnlag for å prioritere sikkerhetstiltak basert på faktisk risiko, ikke bare teoretiske trusler.

Rammeverket er designet for å "snappes inn" i eksisterende risikostyringsprosesser (ISO 27001, NIST 800-53, PCI-DSS) heller enn å erstatte dem. Målet er å utvide tradisjonelle IT-sikkerhetsrammeverk med AI-spesifikke kontroller som dekker hele ML-livssyklusen.

Kjernekomponenter

1. Severity Scoring (Alvorlighetsvurdering)

Severity evalueres basert på datatype, bruksområde og potensielle konsekvenser ved kompromittering:

Severity Level	Kriterier	Eksempler
Critical	Sensitiv persondata (GDPR), klassifisert data, compliance-krav (PCI, HIPAA), kritisk infrastruktur, risiko for fysisk skade/død	Medisinsk diagnostikk-AI, betalingssystemer, strømnett-styring
High	Forretningskritiske data, omfattende operasjonell påvirkning, kunde-vendte systemer	Kundeservice-bots, supply chain-optimalisering
Medium	Delmengde sensitiv data, påvirkning på produksjonsmodeller, ikke-kritiske forretningssystemer	Intern rapportering, pre-prod testmiljøer
Low	Ikke-produksjonsdata, begrenset eksponering	Dev/test-modeller, offentlige datasett
Informational	Uklassifisert data, ingen produksjonsbruk	Research prototyper, akademiske modeller

Viktig: Differential privacy og andre defensive teknikker kan redusere potensiell impact, men endrer ikke selve severity-klassifiseringen av system/data/modell.

2. Likelihood Assessment (Sannsynlighetsvurdering)

Likelihood har to hovedkomponenter:

A. Attack Surface Availability

• Ekstern eksponering (API-endepunkter, web-grensesnitt)
• Intern tilgjengelighet (nettverk-segmentering, tilgangskontroller)
• Model availability (query-based vs. full model access)

B. Attack Technique Availability

• Kjente angrepsmetoder (MITRE ATT&CK for ML)
• Verktøy og eksploits tilgjengelig (offentlige proof-of-concepts)
• Kompetansekrav for utnyttelse

Reduserende faktorer:

• Rate limiting på modell-endepunkter
• Network segmentation (VPN, private endpoints)
• Logging og alerting (rask deteksjon → lavere likelihood)
• Security patching (oppdatert infrastruktur)

3. Attack Type Impact Matrix

Microsoft bruker en 5x3 severity matrix for ML-spesifikke angrepstyper:

Attack Type	Likelihood	Impact	Exploitability	Beskrivelse
Extraction	High	Low	High	Stjele modell-parametere eller treningsdata
Evasion	High	Medium	High	Manipulere input for å unngå deteksjon
Inference	Medium	Medium	Medium	Avdekke sensitiv info via modell-spørringer
Inversion	Medium	High	Medium	Rekonstruere treningsdata fra modell
Poisoning	Low	High	Low	Korruptere treningsdata for å påvirke modell

Merknad: Dette er baseline-estimater. Organisasjoner må justere basert på egen kontekst (e.g., offentlig sektor har høyere reputasjonsrisiko ved data leakage).

4. Kvantitativ Scoring Metodikk

AI Risk Score Formula (forenklet):

Risk Score = Severity × Likelihood × Exploitability
Severity: 1-5 (Informational → Critical)
Likelihood: 0.1-1.0 (basert på attack surface + controls)
Exploitability: 0.1-1.0 (basert på attack complexity)

Eksempel:

• Model evasion attack på High severity system (4)
• Medium likelihood pga. rate limiting (0.5)
• High exploitability pga. kjente verktøy (0.8)
• Risk Score = 4 × 0.5 × 0.8 = 1.6

Tolkning:

• 0-1: Low risk — standard monitoring
• 1-2: Medium risk — proaktive tiltak anbefalt
• 2-4: High risk — umiddelbar risikoreduksjon påkrevd
• 4+: Critical risk — stopp produksjonsutrulling til mitigert

5. Kvalitativ Risk Assessment

Ikke alle risikoer lar seg kvantifisere. Kvalitative indikatorer inkluderer:

• Ethical concerns: Bias, fairness, inkludering
• Transparency issues: Forklarbarhet av beslutninger
• Accountability gaps: Uklar ansvarsfordeling
• User trust: Subjektiv oppfattelse av AI-systemet
• Reputational risk: PR-konsekvenser ved svikt

Responsible AI Principles som scoring-dimensjoner:

Principle	Assessment Question	Scoring
Privacy & Security	Håndteres sensitiv data sikkert?	1-5 scale
Reliability & Safety	Kan systemet feile kritisk?	1-5 scale
Fairness	Risiko for urettferdig behandling?	1-5 scale
Inclusiveness	Ekskluderes grupper?	1-5 scale
Transparency	Kan beslutninger forklares?	1-5 scale
Accountability	Er ansvarslinjer klare?	1-5 scale

Aggregert Responsible AI Score: Gjennomsnitt av alle dimensjoner (1=Poor, 5=Excellent).

Arkitekturmønstre

Pattern 1: Continuous Risk Monitoring Dashboard

Beskrivelse: Sanntids-dashboard som viser risk scores på tvers av alle AI-workloads i organisasjonen.

Komponenter:

• Azure Monitor for logging (inference requests, latency, errors)
• Azure Resource Graph for security assessments (Defender for Cloud)
• Custom metrics for model drift, data quality, fairness
• Power BI / Grafana for visualisering

Fordeler:

• Proaktiv deteksjon av risiko-trender
• Stakeholder-synlighet (non-technical leadership)
• Compliance-rapportering (audit trail)

Ulemper:

• Initial setup kompleksitet
• Krever vedlikehold av metrikk-definisjoner
• False positive alerts kan føre til alert fatigue

Best practice: Start med "golden dataset" baseline — sammenlign prod-performance mot kjent god tilstand.

---

Pattern 2: Risk-Based Model Approval Workflow

Beskrivelse: Modeller må score under risk threshold før produksjonsdeployment.

Workflow:

1. ML Engineer submitter modell til model registry (Azure ML)
2. Automatisk risk assessment kjører (security scanning, bias testing)
3. Risk score beregnes basert på model + deployment context
4. Hvis score > threshold → manual security review påkrevd
5. Godkjent modell får digital signatur før deployment

Fordeler:

• Preventive control (stopper høyrisiko-modeller før prod)
• Audit trail for compliance (hvem godkjente hva når)
• Standardisert prosess på tvers av team

Ulemper:

• Kan forsinke releases (manual review bottleneck)
• Krever klare approval-kriterier (hva er "akseptabel risiko"?)
• Ikke effektiv for rapid iteration (eksperimentering)

Best practice: Bruk separate thresholds for dev/test/prod environments. Tillat higher risk i sandboxes.

---

Pattern 3: Red Team Scorecard for Adversarial Testing

Beskrivelse: Periodisk adversarial testing med strukturert scoring av attack success rate (ASR).

Metrikker:

• Overall ASR: % av angrep som lykkes
• Risk Category ASR: Success rate per risikokategori (hate, violence, self-harm, sexual)
• Attack Complexity ASR: Success rate for easy/moderate/difficult attacks

Tooling:

• PyRIT (Python Risk Identification Tool for Generative AI)
• Microsoft Foundry safety evaluations
• Custom jailbreak test suites

Fordeler:

• Realistisk vurdering av faktisk robusthet
• Identifiserer "unknown unknowns" (creative attacks)
• Builds organizational red team capability

Ulemper:

• Ressurskrevende (skilled red teamers)
• Subjektiv scoring (hva er "success"?)
• Snapshot i tid (modeller endrer seg)

Best practice: Kjør red teaming quarterly for high-risk systems, annually for low-risk. Document findings i ADR.

Beslutningsveiledning

Når bruke hvilken scoring-tilnærming?

Scenario	Tilnærming	Rationale
Pre-deployment risk assessment	Kvantitativ (severity × likelihood × exploitability)	Trenger objektiv threshold for go/no-go beslutning
Quarterly governance review	Kvalitativ (Responsible AI principles)	Bredere stakeholder audience, fokus på etikk/compliance
Post-incident analysis	Hybrid (både kvantitativ + kvalitativ)	Root cause analysis krever både teknisk og organisatorisk perspektiv
Continuous monitoring	Kvantitativ (automated metrics)	Real-time dashboards krever numeriske verdier
Regulatory audit	Kvalitativ (policy compliance)	Auditorer vil se dokumentasjon av prosess, ikke bare tall

Vanlige feil i AI risk scoring

Feil	Konsekvens	Mitigation
Scoring modell alene, uten deployment context	Undervurderer risiko (prod eksponering ignorert)	Alltid inkluder attack surface i likelihood-vurdering
Ikke revidere scores over tid	Utdaterte scores (nye angrepsmetoder, endret threat landscape)	Bi-annual review minimum, quarterly for critical systems
Manglende stakeholder input	Teknisk bias (security team ser ikke business impact)	Inkluder business owners, legal, compliance i risk workshops
Over-reliance på automated scoring	Misser kvalitative risikoer (reputational damage, ethical issues)	Kombiner kvantitativ + kvalitativ vurdering
Ingen baseline for "acceptable risk"	Uklare approval-kriterier (subjektive beslutninger)	Etabler risk appetite matrix med ledelsen (hva tolererer vi?)

Røde flagg (krever umiddelbar eskalering)

• Risk score øker 50%+ uten kjent årsak → Mulig angrep eller system degradering
• Responsible AI fairness score < 2.0 → Potensielt diskriminerende output
• Model performance drifter 20%+ fra baseline → Data poisoning eller concept drift
• Unauthorized model access detektert i logger → Mulig extraction attack
• Safety evaluations viser ASR > 10% for critical risk categories → Inadequate content filtering

Integrasjon med Microsoft-stakken

Microsoft Defender for Cloud

Secure Score for AI Resources:

• Azure OpenAI endpoints → Network isolation checks
• Azure ML workspaces → RBAC configuration validation
• Storage accounts (training data) → Encryption at rest verification

Integration:

SecurityResources
| where type == 'microsoft.security/assessments'
| where properties.displayName contains 'AI' or properties.displayName contains 'Machine Learning'
| extend riskLevel = case(
    properties.status.severity == "High", 3,
    properties.status.severity == "Medium", 2,
    properties.status.severity == "Low", 1,
    0)
| summarize AIRiskScore = avg(riskLevel) by subscriptionId

Bruk case: Automatisk beregning av AI-spesifikk Secure Score per subscription.

Azure Policy for AI Governance

Built-in policies:

• Azure AI services should use private endpoints
• Azure Machine Learning workspaces should disable public network access
• Diagnostic logs in Azure AI services should be enabled

Custom policy for risk thresholds:

{
  "policyRule": {
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.CognitiveServices/accounts"},
        {"field": "tags['RiskScore']", "greater": "2.0"}
      ]
    },
    "then": {
      "effect": "audit",
      "details": {
        "message": "High-risk AI resource deployed without security review"
      }
    }
  }
}

Azure Monitor Metrics for Risk KPIs

Custom metrics to track:

• ai_inference_latency_p95 → Performance degradation indicator
• ai_content_filter_trigger_rate → Safety policy effectiveness
• ai_model_drift_score → Data distribution shift
• ai_unauthorized_access_attempts → Security incident leading indicator

Alert rules:

Model drift score > 0.15 for 24 hours → Critical alert
Content filter trigger rate > 5% → Security team notification

Microsoft Purview for AI Risk Assessment

Data loss prevention for AI:

• Detect oversharing of sensitive data to AI workloads
• Insider risk management (employee misuse of generative AI)
• Adaptive protection based on user risk scores

Integration: Tag AI-generated content i Purview, track lineage tilbake til modell + treningsdata.

Offentlig sektor (Norge)

NSM Grunnprinsipper for IKT-sikkerhet

Mapping av AI risk scoring til NSM sin risikovurderingsmetodikk:

NSM Prinsipp	AI-Specific Control	Risk Scoring Impact
Identifisere og kartlegge	Model registry med metadata (severity, data sources)	Baseline for likelihood assessment
Beskytte	Network isolation, RBAC, content filters	Reduserer likelihood score
Oppdage	Anomaly detection på inference patterns	Øker detection capability (likelihood mitigation)
Håndtere og gjenopprette	Incident response playbooks for AI-specific attacks	Reduserer impact score

NSM anbefalt tilnærming: Bruk ROS-analyse (Risiko- og sårbarhetsanalyse) som overordnet metode, supplert med AI Risk Assessment Framework for tekniske kontroller.

Internkontrollforskriften § 5

AI risk scoring tilfredsstiller krav om systematisk HMS/internkontroll:

• Kartlegge farer og problemer: AI Risk Assessment identifiserer threats
• Risikovurdering: Severity × Likelihood metodikk
• Iverksette tiltak: Risk score driver prioritering av sikkerhetstiltak
• Evaluere tiltak: Continuous monitoring + quarterly reviews

Dokumentasjonskrav: Lagre risk scores, assessment rationale og mitigation actions i revisjonssikkert system (Azure DevOps, Linear).

DPIA (Personvernkonsekvensutredning)

Når AI risk score indikerer High severity og systemet prosesserer personopplysninger:

DPIA triggers:

• Automated decision-making med legal/significant effects
• Large-scale processing av sensitive personal data
• Systematic monitoring av publicly accessible areas (e.g. video analytics)

Integration: Bruk AI risk score som input til DPIA — høyere risk → mer detaljert personvernvurdering.

Utredningsinstruksen

For statlige AI-prosjekter som krever beslutningsgrunnlag:

Kapittel 5 - Vurdering av samfunnsøkonomisk lønnsomhet:

• Kvantifiser cost of risk mitigation vs. cost of potential breach
• Bruk severity × likelihood til å estimere expected loss (sannsynlighet × konsekvens)

Eksempel:

• Severity: Critical (kostnad ved breach = 50M NOK)
• Likelihood: 10% per år (basert på threat intelligence)
• Expected annual loss: 5M NOK → budsjetter for sikkerhetstiltak opp til 5M NOK er samfunnsøkonomisk forsvarlig

Kostnad og lisensiering

Verktøy for AI Risk Scoring

Tool	Lisens	Kostnad	Use Case
Azure Monitor	Inkludert i Azure subscription	Data ingestion: ~50 NOK/GB	Continuous monitoring, alerting
Microsoft Defender for Cloud	Standard tier: ~200 NOK/resource/måned	Per protected resource	Security posture assessment, compliance
Microsoft Purview	Compliance: fra ~40 000 NOK/måned	Per data source	Data governance, DLP for AI
Azure OpenAI safety evals	Inkludert i Azure OpenAI	Token-basert (~0.60 NOK/1K tokens)	Content harm assessment
PyRIT	Open source	Gratis (compute costs only)	Red team testing
Power BI	Pro: ~100 NOK/user/måned	Per user	Risk dashboard visualisering

Totalkostnad estimat (medium org, 10 AI workloads):

• Setup: 200-400K NOK (initial framework design + tooling config)
• Årlig drift: 300-600K NOK (monitoring + quarterly reviews + tooling)
• Red team testing: 150-300K NOK per test cycle (external red teamers)

Cost optimization:

• Start med gratis tier av Defender for Cloud (limited coverage)
• Bruk Azure Resource Graph queries i stedet for dedikert SIEM (ingen lisenskostnad)
• Intern red team capability i stedet for eksterne konsulenter

ROI av Risk Scoring

Verdi-realiseringer:

• Preventive: Stopper høyrisiko-modeller før kostbare breaches (1 prevented breach kan spare 10M+ NOK)
• Insurance: Lavere cyberforsikringspremier (dokumentert risk management)
• Compliance: Unngå bøter for GDPR/AI Act violations (opp til 4% av global omsetning)
• Reputation: Tillit fra kunder/borgere → customer lifetime value

For arkitekten (Cosmo)

Spørsmål å stille kunder

1. "Hvilke AI-systemer har dere i drift i dag, og hvordan har dere klassifisert deres kritikalitet?"

   • Hvorfor: Mange organisasjoner vet ikke hvor mange AI-modeller de faktisk har (shadow AI). Start med inventory.

2. "Har dere definert hva som er 'akseptabel risiko' for AI-systemer i deres organisasjon?"

   • Hvorfor: Uten risk appetite er det umulig å sette thresholds for go/no-go beslutninger.

3. "Hvilke compliance-rammeverk er dere underlagt, og hvordan dokumenterer dere etterlevelse for AI?"

   • Hvorfor: Risk scoring må tilpasses eksisterende compliance-prosesser (ISO, NIST, NSM).

4. "Hvem eier risikoen hvis en AI-modell feiler eller blir kompromittert?"

   • Hvorfor: Accountability gaps er vanlig problem. Etabler RACI tidlig (Responsible, Accountable, Consulted, Informed).

5. "Har dere kapasitet til å gjennomføre quarterly risk reviews internt, eller trenger dere ekstern støtte?"

   • Hvorfor: Risk scoring er ikke "one-and-done". Krever kontinuerlig vedlikehold.

6. "Hvordan håndterer dere risk scoring for third-party modeller (e.g., OpenAI GPT-4) vs. egenutviklede modeller?"

   • Hvorfor: Likelihood vurdering er annerledes for managed services (mindre control, men Microsoft tar noe av risikoen).

7. "Har dere et 'golden dataset' for å etablere performance baselines?"

   • Hvorfor: Uten baseline er det umulig å detektere model drift eller data poisoning.

8. "Hvordan kommuniserer dere AI-risiko til ikke-teknisk ledelse?"

   • Hvorfor: Risk scores må oversettes til business impact. Visualisering og stakeholder-tilpasset rapportering er kritisk.

Fallgruver å unngå

Fallgruve	Konsekvens	Hvordan unngå
"One size fits all" risk model	Under/over-estimerer risiko avhengig av context	Separate scoring models for dev/test/prod, PaaS vs. IaaS
Scoring uten re-evaluation trigger	Scores blir utdaterte (new threats, model updates)	Definer triggers: model retrain, new vulnerability disclosure, policy change
Manglende dokumentasjon av assumptions	Risk scores blir black box (ikke reproducerbare)	Dokumenter alle input-parametere + rationale i ADR
Over-kompleksitet i scoring formula	Stakeholders forstår ikke metoden → lav buy-in	Start enkelt (3x3 matrix), iterer til mer sofistikert
Ignorere false positives i alerting	Alert fatigue → ignorerer genuine threats	Tune alert thresholds basert på historical data

Anbefalinger basert på modenhet

Level 1 (Ad-hoc): Organisasjonen har AI i prod, men ingen formell risk assessment.

• Start: Manual risk scoring av top 3 mest kritiske AI-workloads
• Tool: Excel-basert severity × likelihood matrix
• Frekvens: Årlig review

Level 2 (Repeatable): Dokumentert risk scoring prosess, men manuell execution.

• Start: Automatiser data collection via Azure Monitor + Defender for Cloud
• Tool: Power BI dashboard med risk KPIs
• Frekvens: Quarterly reviews

Level 3 (Defined): Standardisert risk framework på tvers av org, noe automatisering.

• Start: Implementer risk-based approval workflow for model deployment
• Tool: Azure Policy + Azure DevOps for gating
• Frekvens: Continuous monitoring + quarterly governance

Level 4 (Managed): Fullstendig integrert risk management, proaktiv threat hunting.

• Start: Etabler internt red team capability + automated adversarial testing
• Tool: PyRIT + custom AI security tooling
• Frekvens: Real-time monitoring + monthly threat briefings

Level 5 (Optimizing): Prediktiv risk modeling, AI-powered threat detection.

• Start: Machine learning for anomaly detection i AI-inference patterns
• Tool: Azure Sentinel + custom ML models for security analytics
• Frekvens: Continuous adaptive risk scoring

(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 (f.eks. «Azure Language in Foundry Tools», «Azure Speech in Foundry Tools»). URL for cognitive-services-security-baseline er fortsatt aktiv men omdirigeres til 'Azure security baseline for Foundry Tools'.

Kilder og verifisering

Microsoft Learn (Verified via MCP)

1. AI Risk Assessment for ML Engineers https://learn.microsoft.com/en-us/security/ai-red-team/ai-risk-assessment Confidence: Verified — Primærkilde for severity/likelihood/impact metodikk + controls

2. Artificial Intelligence Security (MCSB) https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-artificial-intelligence-security Confidence: Verified — Security controls for AI workloads (content filtering, meta-prompts, model approval)

3. Govern AI (Cloud Adoption Framework) https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/govern Confidence: Verified — Organizational risk assessment process, Responsible AI principles

4. Security planning for LLM-based applications https://learn.microsoft.com/en-us/ai/playbook/technology-guidance/generative-ai/mlops-in-openai/security/security-plan-llm-application Confidence: Verified — References til MITRE ATT&CK, OWASP AI Security Guide, Skeleton Key mitigation

5. Azure security baseline for Azure AI services https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/cognitive-services-security-baseline Confidence: Verified — Logging, threat detection, compliance controls

6. Evaluate generative AI models (Microsoft Foundry) https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluate-generative-ai-app Confidence: Verified — AI quality metrics (NLP + AI-assisted), risk and safety metrics (content harm, ASR)

7. Azure Defender for Cloud - Resource Graph samples https://learn.microsoft.com/en-us/azure/defender-for-cloud/resource-graph-samples Confidence: Verified — Kusto queries for security assessments, risk scoring per management group

External References (Baseline knowledge)

8. NIST AI Risk Management Framework (AI RMF) https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf Confidence: Baseline — Framework for organizational AI risk governance

9. MITRE ATT&CK for ML https://github.com/mitre/advmlthreatmatrix Confidence: Baseline — Adversarial ML tactics and techniques taxonomy

10. OWASP AI Security and Privacy Guide https://owasp.org/www-project-ai-security-and-privacy-guide/ Confidence: Baseline — Security best practices for AI systems

11. NSM Grunnprinsipper for IKT-sikkerhet Confidence: Baseline — Norwegian national cyber security framework

12. ISO 27001:2022 Annex A Controls https://www.isms.online/iso-27001/annex-a-controls/ Confidence: Baseline — Information security management controls

Konfidensvurdering:

• Verified (8 sources): Hentet direkte fra Microsoft Learn via MCP; MCSB v2 AI Security re-verifisert 2026-06-19
• Baseline (4 sources): Etablert industripraksis, bekreftet via modellkunnskap (pre-2025)

Total kilder: 12 unike URLer MCP calls: 5 (3 søk + 2 fetch) Research coverage: Comprehensive — teknisk implementasjon, compliance, norsk offentlig sektor, cost optimization