# AI Incident Response and Breach Handling Procedures

**Last updated:** 2026-04 | Verified: MCP 2026-04
**Status:** Established Practice
**Category:** AI Security Engineering

---

## Introduksjon

Effektiv håndtering av sikkerhetsbrudd i AI-systemer krever spesialiserte prosedyrer som adresserer både tradisjonelle cybersecurity-trusler og AI-spesifikke sårbarheter som data poisoning, model inversion og prompt injection. Moderne AI-systemer opererer i komplekse økosystemer hvor angrep kan manifestere seg på tvers av datalag, treningsinfrastruktur, inferens-endepunkter og integrasjoner med forretningsapplikasjoner.

Microsoft Azure tilbyr omfattende verktøy for incident response gjennom Microsoft Defender XDR, Microsoft Sentinel, og Azure-native forensics-kapabiliteter. En systematisk incident response-prosess sikrer rask deteksjon, effektiv containment, grundig forensisk analyse og læring som styrker organisasjonens modenhet over tid.

Incident response for AI-systemer følger NIST SP 800-61-rammeverket med fire hovedfaser: (1) **Preparation** — etablering av planer, verktøy og team-struktur før hendelser oppstår, (2) **Detection and Analysis** — høykvalitetsalarmering og systematisk etterforskning med AI-spesifikk kontekst, (3) **Containment, Eradication and Recovery** — rask isolering, fjerning av trusler og gjenoppretting av systemer, og (4) **Post-Incident Activity** — lessons learned og bevisbevaring for compliance og fremtidig forbedring.

## Kjernekomponenter

### 1. Incident Detection Triggers (AI-specific)

AI-systemer krever spesialiserte deteksjonsmekanismer utover tradisjonell SIEM-monitorering:

| Trigger Type | Detection Method | Azure Tool |
|-------------|------------------|------------|
| **Data Poisoning** | Anomaly detection i treningsdata-distribusjon, uventet modell-accuracy drop | Azure AI Anomaly Detector, Microsoft Purview |
| **Model Inversion** | Uvanlig query-mønster med høy confidence-score targeting, rate limit violations | Azure API Management analytics, Microsoft Sentinel |
| **Prompt Injection** | Malicious prompt patterns, jailbreak-forsøk, uautoriserte systemkommandoer | Azure AI Content Safety, custom detection rules |
| **Model Theft** | Path-finding queries, equation-solving patterns, ekstremt høyt query-volum | Azure Monitor Log Analytics, API request profiling |
| **Adversarial Examples** | Input med lave confidence-scores på kjente data, batch-misklassifikasjoner | Model monitoring dashboards, drift detection |
| **Backdoor Attacks** | Targeted misklassifisering på spesifikke input-patterns, trojaned model artifacts | ML-BOM tracking (OWASP CycloneDX), supply chain audit |

**Microsoft-stack integrasjon:** *(Verified MCP 2026-04)*
- **Microsoft Defender for AI Services / AI Security Posture Management** — Automatisk deteksjon og remediation av generative AI-risiko på tvers av Azure-miljøet (Microsoft Defender for Cloud)
- **Microsoft Purview Insider Risk Management** — Integrerer med andre security-suites for å vurdere enterprise-wide datarisiko og identifisere risky AI-atferdsmønstre og prompt-basert data exfiltration
- **Microsoft Sentinel AI/ML Analytics** — Custom KQL-queries for deteksjon av anomalous model behavior og data exfiltration-patterns
- **Azure API Management** — Sikrer Model Context Protocol (MCP) server-endepunkter som del av AI communication channel security

### 2. Response Playbooks (AI-Specific)

Automatiserte responsprosedyrer tilpasset AI-hendelser:

**Playbook A: Data Poisoning Response**
1. Isoler påvirket treningsdata-kilde (Azure Storage/Data Lake private endpoints)
2. Snapshot modell før quarantine (Azure ML model registry versioning)
3. Kjør data integrity validation på alle treningsdata (custom scripts + Purview DLP)
4. Retrain modell fra validert clean backup
5. Deploy canary deployment med A/B testing før full rollout

**Playbook B: Model Compromise Response**
1. Revoke API keys for påvirket modell (Azure Key Vault rotation)
2. Enable model access audit logging (Azure Monitor + diagnostics)
3. Forensisk analyse av model artifacts (Azure Blob immutable storage inspection)
4. Re-deploy modell fra verified source med ny endpoint
5. Notify downstream consumers om endpoint-endring

**Playbook C: Prompt Injection Incident**
1. Block malicious user/IP via Azure API Management policy
2. Enable enhanced input filtering (Azure AI Content Safety strict mode)
3. Analyze attack patterns for detection rule tuning
4. Implement guardrails: system message hardening, output sanitization
5. Red team testing med PYRIT for validation

**Playbook D: Insider Threat (Model/Data Exfiltration)**
1. Suspend user via Microsoft Entra ID Conditional Access
2. Isoler påvirket VM/Container (NSG rule modification via automation)
3. Forensisk snapshot av user workspace (Azure VM snapshot + memory dump)
4. Audit all data access logs (Azure Monitor + Purview Access audit)
5. Legal hold på alle artifacts (Azure Storage immutable policy)

### 3. Containment Strategies

AI-spesifikke containment-taktikker krever både tradisjonelle nettverksisolering og ML-pipeline-isolering:

| Strategy | Implementation | Speed | Impact |
|----------|---------------|-------|--------|
| **Network Isolation** | NSG rule modification, Azure Firewall block, VNET peering removal | Seconds | Full model unavailability |
| **API Rate Limiting** | Azure API Management throttling policies | Immediate | Degraded performance for legitimate users |
| **Model Endpoint Disable** | Azure ML endpoint deactivation, DNS record removal | Minutes | Complete service outage |
| **Credential Revocation** | Key Vault secret rotation, SAS token invalidation, MSI disable | Seconds | Re-authentication required |
| **Training Pipeline Halt** | Azure ML pipeline cancellation, compute cluster shutdown | Minutes | Stops active model updates |
| **Read-Only Mode** | Remove write permissions on ML workspace, lock ARM resources | Minutes | Prevents further model/data changes |

**Automatisering via Azure Automation runbooks:**
```powershell
# Eksempel: Automated VM isolation ved high-severity alert
workflow Isolate-CompromisedVM {
    param([string]$VMResourceId, [string]$IncidentId)

    $nsg = Get-AzNetworkSecurityGroup -ResourceId $VMResourceId
    Add-AzNetworkSecurityRuleConfig -NetworkSecurityGroup $nsg `
        -Name "Block-All-Incident-$IncidentId" `
        -Priority 100 -Access Deny -Protocol * -Direction Inbound `
        -SourceAddressPrefix * -DestinationAddressPrefix *
    Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg

    # Preserve forensic evidence
    New-AzSnapshot -SnapshotName "Forensic-$IncidentId" -Disk $vmDisk
}
```

### 4. Forensics and Logging

AI-incident forensics krever innsamling av både tradisjonelle system-logs og ML-spesifikke artifacts:

**Critical Evidence Sources:**
- **Model Artifacts**: Trained model binaries, configuration files, hyperparameters (Azure ML model registry)
- **Training Data Snapshots**: Data used for training with version/timestamp (Azure Data Lake snapshots)
- **Inference Logs**: All prediction requests/responses med timestamps og user context (Azure Monitor Application Insights)
- **API Access Logs**: Full audit trail of API calls med IP, user, query content (Azure API Management analytics)
- **System Logs**: Azure Activity Logs, NSG Flow Logs, Microsoft Entra ID sign-in/audit logs
- **Memory Dumps**: VM memory state ved suspected compromise (Azure VM diagnostics extension)
- **Network Packet Captures**: Azure Network Watcher packet capture for lateral movement analysis

**Immutable Evidence Storage:**
```json
{
  "storageAccount": "forensicstorage",
  "immutabilityPolicy": {
    "immutabilityPeriodSinceCreationInDays": 2190,
    "allowProtectedAppendWrites": false,
    "state": "Locked"
  },
  "legalHold": {
    "tags": ["incident-2026-02-001", "model-theft-investigation"],
    "enabled": true
  }
}
```

**Chain of Custody Automation:**
- Cryptographic hashing av alle innsamlede artifacts (SHA-256)
- Digital signatures med Azure Key Vault managed certificates
- Access logging med Microsoft Entra ID audit trail
- Tamper-evident storage med Azure Blob versioning enabled

### 5. Post-Incident Analysis

Systematisk lessons learned-prosess for kontinuerlig forbedring:

**Root Cause Analysis Framework:**
1. **Timeline Reconstruction** — Full incident timeline fra initial access til containment
2. **Attack Vector Identification** — Hvordan kom angriperen inn? (MITRE ATT&CK for ML mapping)
3. **Control Gap Assessment** — Hvilke security controls feilet eller manglet?
4. **Impact Quantification** — Business impact, data exposure, regulatory implications
5. **Improvement Recommendations** — Konkrete tiltak med owners og deadlines

**Metrics to Track:**
| Metric | Target | Measurement |
|--------|--------|-------------|
| Mean Time to Detect (MTTD) | < 15 min | Time from attack start to first alert |
| Mean Time to Respond (MTTR) | < 30 min | Time from alert to containment action |
| False Positive Rate | < 5% | Percentage of alerts requiring no action |
| Recurring Incident Rate | < 10% | Incidents with same root cause repeating |
| Evidence Preservation Success | 100% | Percentage of incidents with complete forensic evidence |

**Azure DevOps Integration:**
- Automated work item creation for hver improvement recommendation
- Tracking av remediation progress med burndown charts
- Integration med security roadmap for strategic planning

## Arkitekturmønstre

### Mønster 1: Automated Response with Human Oversight (SOAR)

**Scenario:** High-volume alerts krever rask automated containment, men kritiske beslutninger trenger human validation.

**Arkitektur:**
```
Microsoft Sentinel (SIEM)
  → Analytics Rules (AI-specific threat detection)
    → Automated Playbook (Logic Apps)
      → Containment Actions (automated: API block, rate limit)
      → Approval Workflow (Microsoft Teams Adaptive Card)
        → Human Decision (approve/reject/escalate)
          → Final Actions (VM isolation, model rollback)
            → Ticket Creation (Azure DevOps / ServiceNow)
```

**Fordeler:**
- ⚡ Rask automated containment for velkjente threats (seconds)
- 🛡️ Human oversight for business-critical decisions
- 📊 Complete audit trail med approval history

**Ulemper:**
- ⏱️ Approval delays kan gi angriper window of opportunity
- 🧑‍💼 Requires 24/7 on-call human responders
- 💸 Logic Apps execution costs ved høyt alert-volum

**Best practices:**
- Pre-approve low-risk automated actions (API rate limiting)
- Timeout-basert auto-approval for critical incidents (ransomware)
- Multi-factor approval for production model deletion

### Mønster 2: Defense-in-Depth Forensics (Multi-Layer Evidence Collection)

**Scenario:** AI-hendelser krever korrelering av data fra ML-lag, infrastruktur-lag og applikasjonslag.

**Arkitektur:**
```
Layer 1: ML Observability (Azure ML monitoring, model drift detection)
Layer 2: Application Layer (API Gateway logs, Application Insights traces)
Layer 3: Infrastructure (NSG flow logs, VM diagnostics, Azure Activity Logs)
Layer 4: Identity (Entra ID sign-in/audit logs, PIM activation logs)
Layer 5: Network (Network Watcher packet capture, ExpressRoute monitoring)

All layers → Azure Log Analytics → Microsoft Sentinel (unified investigation graph)
```

**Fordeler:**
- 🔍 Complete attack visibility på tvers av alle lag
- 🧩 Entity correlation (user → device → model → data)
- 📈 Timeline reconstruction med cross-layer event correlation

**Ulemper:**
- 💾 Massive storage costs for comprehensive logging
- 🔧 Complex query-building for cross-layer investigation (KQL expertise required)
- ⚠️ Signal overload without proper alert tuning

**Best practices:**
- Tiered logging retention (hot: 30 days, warm: 90 days, cold: 1 year for compliance)
- Pre-built KQL queries for common AI incident scenarios
- Entity behavior analytics (UEBA) for automatic anomaly surfacing

### Mønster 3: Immutable Infrastructure Response (Cattle, Not Pets)

**Scenario:** Suspected compromise krever full system replacement heller enn cleanup.

**Arkitektur:**
```
Detection → Incident Declared → Automated Actions:
  1. Snapshot compromised resource (Azure VM snapshot / Container image save)
  2. Deploy clean replacement from known-good image (Infrastructure-as-Code)
  3. Redirect traffic via Azure Front Door / Traffic Manager
  4. Forensic analysis på isolated snapshot
  5. Destroy compromised resource efter evidence collection
```

**Fordeler:**
- 🚀 Fastest recovery time (minutes vs. hours of cleanup)
- 🛡️ Eliminates persistence risk (no hidden backdoors survive)
- 🔬 Pristine forensic environment (no contamination during analysis)

**Ulemper:**
- 💸 Requires mature IaC practice and automated deployment pipelines
- 🗂️ Stateful data recovery complexity (databases, ML model state)
- 📋 May lose short-term data not committed to persistent storage

**Best practices:**
- Git-backed IaC for all infrastructure (Terraform/Bicep)
- Continuous backup of stateful components (Azure Backup, geo-redundant storage)
- Blue-green deployment for zero-downtime model replacement

## Beslutningsveiledning

### Severity Assessment for AI Incidents

| Factor | Critical | High | Medium | Low |
|--------|----------|------|--------|-----|
| **Data Exposure** | PII/PHI breached | Proprietary training data accessed | Internal test data exposed | No sensitive data |
| **Model Impact** | Production model poisoned | Model theft confirmed | Model drift detected | Performance degradation |
| **Service Availability** | Complete service outage | Degraded performance | Intermittent errors | No user impact |
| **Regulatory Implications** | GDPR/HIPAA breach (72h notification) | PCI-DSS incident | Internal audit finding | No compliance impact |
| **Attack Sophistication** | Nation-state APT indicators | Organized crime patterns | Opportunistic attack | Script kiddie |

### Decision Tree: To Contain or Not To Contain?

```
Incident Detected
  ├─ Is it affecting production models?
  │   ├─ YES → Immediate containment (isolate endpoint)
  │   └─ NO → Continue to next check
  │
  ├─ Is sensitive data at risk?
  │   ├─ YES → Immediate containment (revoke access)
  │   └─ NO → Continue to next check
  │
  ├─ Is attack still active?
  │   ├─ YES → Immediate containment (block attacker)
  │   └─ NO → Forensic analysis first (don't contaminate evidence)
  │
  └─ Is containment reversible?
      ├─ YES → Contain and investigate
      └─ NO → Seek approval before action (executive escalation)
```

### Vanlige Feil

1. **Premature Evidence Destruction**: Sletting av logs eller snapshots før forensic analysis er fullført (FEIL: Alltid preserve først, analyze senere)
2. **Over-Containment**: Full production shutdown uten vurdering av business impact (FEIL: Gradered containment basert på threat severity)
3. **Under-Notification**: Manglende varsling til legal/compliance teams ved data breach (FEIL: Always notify stakeholders early)
4. **Ignoring AI Supply Chain**: Ikke sjekke third-party model providers ved backdoor-suspects (FEIL: MLOps supply chain audit må inkluderes)
5. **Manual Response Only**: Ingen automated playbooks for velkjente AI threats (FEIL: Automate repetitive tasks, humans for complex decisions)

### Røde Flagg (Immediate Escalation Required)

- 🚨 **Model accuracy drop > 20% in production** → Suspect data poisoning or adversarial attack
- 🚨 **Unusual query patterns with 100% confidence targeting specific outputs** → Model inversion attempt
- 🚨 **API keys accessed from unknown geography** → Credential theft, potential model theft in progress
- 🚨 **Training pipeline triggered outside maintenance window** → Unauthorized model retraining (possible backdoor injection)
- 🚨 **Mass export of training data to external storage** → Data exfiltration, insider threat
- 🚨 **Prompt injection signatures detected in production logs** → Active jailbreak attempt, potential service abuse

## Integrasjon med Microsoft-stakken

### Azure-Native Incident Response Stack

| Capability | Azure Service | Key Feature for AI Incidents |
|------------|---------------|------------------------------|
| **Threat Detection** | Microsoft Defender for AI Services | AI-specific threat patterns (MITRE ATLAS) |
| **SIEM/SOAR** | Microsoft Sentinel | Unified incident management, automated playbooks |
| **XDR** | Microsoft Defender XDR | Cross-platform signal correlation (M365, Azure, endpoints) |
| **Forensics** | Azure Monitor + Log Analytics | KQL-based investigation, 30-day hot retention |
| **Evidence Preservation** | Azure Blob Immutable Storage | Legal hold, time-based retention policies (6 years HIPAA) |
| **Identity Response** | Microsoft Entra ID + PIM | Conditional Access, automated account suspension |
| **Network Isolation** | Azure Firewall + NSG | Automated rule deployment via Logic Apps |
| **Model Governance** | Azure ML + Purview | Model lineage tracking, data classification |

### Sample Integration: Sentinel Playbook for AI Model Poisoning

**Trigger:** Azure ML model drift alert (accuracy drop detected)

**Automated Actions:**
1. **Gather Context** (HTTP action to Azure ML REST API for model metrics)
2. **Create Sentinel Incident** (severity: High, type: Data Poisoning Suspected)
3. **Notify Stakeholders** (Microsoft Teams adaptive card to ML engineers + security team)
4. **Isolate Model** (Azure ML endpoint deactivation via ARM API)
5. **Snapshot Evidence** (Azure Storage copy of model artifact to forensic container)
6. **Approval Workflow** (Wait for ML engineer validation: false positive or genuine attack?)
7. **Rollback or Investigate** (if genuine: rollback to previous model version + forensic deep-dive)
8. **Create Work Item** (Azure DevOps task for root cause analysis + remediation)

**Logic Apps Connector Usage:**
- Azure Monitor (trigger condition)
- Azure ML (model metadata retrieval)
- Microsoft Sentinel (incident creation)
- Microsoft Teams (notifications)
- Azure Resource Manager (infrastructure actions)
- Azure DevOps (work tracking)

### Microsoft Security Contact Configuration

**Critical Step:** Configure security contacts i Microsoft Defender for Cloud for å motta incident-notifikasjoner fra Microsoft:

```powershell
# PowerShell example
Set-AzSecurityContact -Name "default1" `
    -Email "security-team@organization.com" `
    -Phone "+47-555-12345" `
    -AlertAdmin `
    -NotifyOnAlert
```

**Why It Matters:** Microsoft vil varsle deg direkte ved platform-level vulnerabilities eller detected compromise patterns som krever koordinert respons.

### Microsoft Collaboration Procedures

**When to Engage Microsoft Support:**
- Azure platform-level incidents (tjenestefeil som påvirker security)
- Suspected compromise of Azure infrastructure itself (ikke kun customer workloads)
- Zero-day vulnerabilities discovered i Azure AI Services
- Large-scale coordinated attacks affecting multiple tenants

**Escalation Path:**
1. Azure Support Ticket (Severity A for active security incidents)
2. Microsoft Security Response Center (MSRC) for vulnerability disclosure
3. Azure Security Response Team for platform-level compromise coordination
4. Microsoft Account Team (TAM/CSA) for strategic incident response planning

## Offentlig sektor (Norge)

### Meldeplikt til Datatilsynet (GDPR)

**Når melder man?**
- Personopplysningsbrudd som "kan medføre høy risiko for fysiske personers rettigheter og friheter"
- AI-scenario: Model inversion-angrep som eksponerer treningsdata med personopplysninger

**Tidsfrist:** 72 timer fra virksomheten ble kjent med bruddet

**Hva skal meldes:**
- Beskrivelse av bruddet og omfang (antall berørte, kategorier personopplysninger)
- Kontaktopplysninger til personvernombudet
- Sannsynlige konsekvenser av bruddet
- Tiltak iverksatt eller foreslått for å håndtere bruddet

**Azure-støtte:**
- **Microsoft Purview Compliance Manager** — GDPR assessment templates og incident tracking
- **Logic Apps automated notification** — Pre-approved templates for Datatilsynet reporting
- **Azure Policy compliance reports** — Documentation av security controls for regulatory audit

**Referanse:** [Datatilsynet — Meldeplikt ved personopplysningsbrudd](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/meldeplikt-ved-personopplysningsbrudd/)

### Varsling til NSM (Nasjonal sikkerhetsmyndighet)

**Når skal man varsle NSM?**
- Alvorlige IKT-sikkerhetshendelser i kritisk infrastruktur eller leverandører av digitale tjenester
- AI-scenario: Omfattende data poisoning-angrep mot AI-systemer i kritisk samfunnsfunksjon (helse, transport, finans)

**Tidsfrist:** Uten ugrunnet opphold etter at hendelsen er oppdaget

**Hva skal meldes:**
- Type hendelse og omfang
- Når hendelsen skjedde og ble oppdaget
- Konsekvenser for drift av tjenester
- Tiltak iverksatt

**Referanse:** [NSM — Varsle sikkerhetshendelser](https://nsm.no/fagomrader/digital-sikkerhet/varsle-sikkerhetshendelser/)

### Sikkerhetsloven §§ 2-4 (Sikkerhetstruende hendelser)

**Virkeområde:** Statlige og kommunale virksomheter, samt private virksomheter som håndterer gradert informasjon

**Hva skal meldes:** Sikkerhetstruende hendelser som kan skade nasjonale sikkerhetsinteresser

**AI-relevans:** Model theft eller data exfiltration av gradert informasjon brukt i AI-treningsdata

**Referanse:** [Lovdata — Sikkerhetsloven](https://lovdata.no/dokument/NL/lov/2018-06-01-24)

### Utredningsinstruksen (KMD)

**Relevans for AI-prosjekter:** Alle statlige utredninger må inkludere vurdering av sikkerhetsrisiko

**Incident Response Implications:**
- Lessons learned fra AI-incidents må integreres i fremtidige utredninger
- Root cause analysis skal dokumenteres strukturert
- Security control gaps skal rapporteres til beslutningstagere

**Referanse:** [Regjeringen — Utredningsinstruksen](https://www.regjeringen.no/no/dokument/dep/kmd/rundskriv/2016/rundskriv-r-112016-utredningsinstruksen/id2519304/)

### Norsk Compliance Checklist for AI Incident Response

- [ ] **GDPR**: Varsle Datatilsynet innen 72 timer ved personopplysningsbrudd
- [ ] **NSM**: Varsle uten ugrunnet opphold ved alvorlige IKT-hendelser (kritisk infrastruktur)
- [ ] **Sikkerhetsloven**: Meld sikkerhetstruende hendelser til NSM (gradert informasjon)
- [ ] **Arkivloven**: Bevare incident-dokumentasjon i minimum 10 år (statlige virksomheter)
- [ ] **Forvaltningsloven**: Sikre forsvarlig saksbehandling i incident response (dokumentasjonskrav)
- [ ] **Anskaffelsesforskriften**: Vurder leverandøransvar ved third-party AI-tjenester
- [ ] **Personopplysningsloven**: Gjennomfør DPIA før gjenoppretting av AI-tjenester med endrede risikoer

## Kostnad og lisensiering

### Azure-kostnader for Incident Response Infrastruktur

| Service | Typical Monthly Cost (NOK) | Notes |
|---------|----------------------------|-------|
| **Microsoft Sentinel** | 15 000 - 150 000 | Pay-per-GB ingested (ca. 20 NOK/GB), 100 GB/day = ~60k/month |
| **Microsoft Defender for Cloud** | 1 500 - 15 000 per server | Defender for Servers Plan 2: ~150 NOK/server/month |
| **Azure Monitor Log Analytics** | 5 000 - 50 000 | Pay-per-GB retention, first 5 GB/day free, then ~7 NOK/GB |
| **Azure Storage (Immutable)** | 500 - 5 000 | Forensic evidence storage, LRS ~0.20 NOK/GB/month |
| **Logic Apps (Playbooks)** | 1 000 - 10 000 | Standard tier ~0.50 NOK per 1000 actions |
| **Microsoft Defender XDR** | Included in M365 E5 | Or add-on ~35 NOK/user/month |

**Total Estimated Range:** 23 000 - 230 000 NOK/month (avhengig av scale og log volume)

### Lisensieringskrav

| Capability | Required License | Included in |
|------------|------------------|-------------|
| **Microsoft Sentinel** | Sentinel standalone | Or Microsoft 365 E5 Security |
| **Defender for Cloud** | Pay-per-resource | Or Microsoft Defender for Cloud (standalone) |
| **Defender XDR** | M365 E5 Security or E5 | Includes Defender for Endpoint, Identity, M365 |
| **Microsoft Entra ID P2** | Microsoft Entra ID P2 | Required for PIM, Conditional Access risk-based policies |
| **Azure Monitor** | Pay-per-GB | No upfront license, consumption-based |
| **Azure Automation** | Free for first 500 minutes/month | Then ~0.015 NOK/minute |

**Optimization Tips:**
- **Commitment Tiers:** Microsoft Sentinel har commitment tiers (100/200/300 GB/day) med 15-50% discount
- **Data Retention:** Use tiered storage (Archive to Azure Blob Cold after 90 days) for compliance retention
- **Alert Tuning:** Reduce false positives → lower analyst time costs (often larger than tool costs)
- **Shared Sentinel Workspace:** Multi-tenant scenario for managed service providers

### TCO Consideration: Build vs. Buy

**DIY Incident Response (open-source SIEM + manual playbooks):**
- Lower tool costs (~50% of Azure stack)
- Higher operational costs (3-5 FTEs for 24/7 SOC)
- Longer MTTD/MTTR (no native Azure integration)

**Azure-Native Stack:**
- Higher tool costs (as above)
- Lower operational costs (automation reduces manual work by 60-80%)
- Faster MTTD/MTTR (native integration, XDR correlation)

**Recommendation for offentlig sektor:** Azure-native stack for kritiske systemer (helse, finans), hybrid approach for less-critical workloads.

## For arkitekten (Cosmo)

### Spørsmål å stille klienten

1. **Incident Response Maturity**: "Har dere eksisterende incident response-planer, eller bygger vi fra scratch? Hvilke systemer er kritiske nok til å kreve 24/7 monitoring?"

    *Tips (per CAF Secure AI 2026-04):* Bruk Azure Resource Graph til å bygge et komplett AI asset inventory som grunnlag for prioritering av monitoring-scope. *(Verified MCP 2026-04)*

2. **Compliance Requirements**: "Hvilke regulatoriske krav gjelder? GDPR (Datatilsynet 72h)? NSM-varsling? Sikkerhetsloven? Dette påvirker notification workflows og evidence retention."

3. **Current Detection Capabilities**: "Hvilke security tools er allerede i bruk? SIEM? EDR? Kan vi integrere, eller må vi deploye helt nye verktøy?"

4. **AI-Specific Risks**: "Hvilke AI-trusler bekymrer dere mest: data poisoning, model theft, prompt injection? Dette avgjør hvilke detection rules vi prioriterer."

5. **Team Structure**: "Hvem er incident responders? Har dere in-house SOC, eller skal vi planlegge for managed detection and response (MDR)?"

6. **Automation Appetite**: "Hvor komfortable er dere med automated containment? Kan vi auto-blokkere API keys, eller trengs alltid human approval?"

7. **Budget and Licensing**: "Hva er budsjettet for security tooling? Har dere allerede Microsoft 365 E5? Dette påvirker om vi kan bruke Defender XDR eller må bygge custom."

8. **Evidence Retention**: "Hvor lenge må dere bevare incident-beviser? 1 år? 6 år (HIPAA)? 10 år (Arkivloven)? Dette driver storage costs."

9. **Training and Tabletop Exercises**: "Når var siste gang teamet øvde på incident response? Trenger vi tabletop exercises for AI-spesifikke scenarios?"

10. **Third-Party Dependencies**: "Bruker dere third-party AI models (OpenAI, Hugging Face)? Hvordan håndterer vi incidents i vendor-supplied models?"

### Fallgruver å unngå

1. **"One-Size-Fits-All Playbooks"**: AI-incidents krever spesialiserte playbooks (data poisoning ≠ ransomware response). IKKE gjenbruk tradisjonelle cybersecurity-playbooks uten AI-tilpasning.

2. **"Alert Overload Day 1"**: IKKE enable alle Sentinel analytics rules samtidig uten tuning. Start med high-fidelity AI-specific rules, tune in 2-4 uker før du legger til bredere coverage.

3. **"Forensics as Afterthought"**: IKKE implementer detection uten samtidig å rigge immutable storage for evidence. Legal hold må være klart FØR første incident.

4. **"Ignoring ML Supply Chain"**: IKKE glem å audit third-party models og training data providers. Backdoor attacks kommer ofte via supply chain.

5. **"Manual-Only Response at Scale"**: IKKE stol på kun manuelle prosedyrer hvis du har > 10 AI models i production. Automated playbooks er essensielt for skalerbarhet.

6. **"No Legal/Compliance Involvement"**: IKKE design incident response uten input fra legal og compliance teams. GDPR 72-timer notification må være baked in fra start.

7. **"Forgetting Cloud Shared Responsibility"**: IKKE anta at Microsoft håndterer all incident response. Du er ansvarlig for data, models, applications — Microsoft for platform. Clarify hvem gjør hva.

8. **"Testing Only Happy Paths"**: IKKE bare teste at playbooks kjører uten feil. Test også edge cases: Hva om Azure Logic Apps er nede? Hva om Key Vault er utilgjengelig?

### Anbefalinger for ulike scenario

**Scenario A: Startup med 1-2 ML models (pre-product/market fit)**
- **Anbefaling**: Microsoft Defender for Cloud (basic) + Azure Monitor alerts, manual response procedures, ingen SIEM ennå
- **Rationale**: Keep costs low, focus på core product development, scale security når revenue kommer
- **Investment**: ~5 000 NOK/month

**Scenario B: Scale-up med 10+ production models (Series A/B funded)**
- **Anbefaling**: Microsoft Sentinel + Defender XDR, automated playbooks for common threats, 24/7 on-call rotation (not dedicated SOC)
- **Rationale**: Growing attack surface krever automation, men in-house SOC er fortsatt for dyrt
- **Investment**: ~50 000 NOK/month

**Scenario C: Enterprise med kritisk AI infrastructure (finans, helse, offentlig sektor)**
- **Anbefaling**: Full Azure-native incident response stack (Sentinel, Defender XDR, immutable storage, 24/7 SOC), quarterly red team exercises
- **Rationale**: Regulatory requirements, high business impact av downtime, zero tolerance for data breaches
- **Investment**: ~200 000 NOK/month + 3-5 FTEs (SOC team)

**Scenario D: Offentlig virksomhet med begrenset budsjett (kommune, mindre statlig etat)**
- **Anbefaling**: Shared Sentinel workspace (multi-tenant), Microsoft 365 E5 Security (inkluderer Defender XDR), outsourced SOC (managed services)
- **Rationale**: Compliance-driven (NSM, Datatilsynet), cost-conscious, benefit from shared infrastructure
- **Investment**: ~30 000 NOK/month (tools) + managed SOC contract

## Kilder og verifisering

### Microsoft Learn Documentation (Verified via MCP)

**Incident Response Framework:**
- [Security Control: Incident Response](https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-incident-response) — NIST-aligned incident response controls med Azure implementation guidance
- [Architecture Strategies for Security Incident Response](https://learn.microsoft.com/en-us/azure/well-architected/security/incident-response) — Design patterns for Azure-native incident response
- [Microsoft Security Incident Management](https://learn.microsoft.com/en-us/compliance/assurance/assurance-security-incident-management) — Microsoft's internal federated security response model

**AI-Specific Security:**
- [Secure AI — Detect AI Security Threats](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/secure) — AI-focused threat detection and incident response procedures. Dekker: AI asset inventory (Azure Resource Graph), AI communication channel security (Managed Identities, Virtual Networks, APIM for MCP), data boundary definition (Microsoft Purview), DLP (Purview DLP + content filtering), og AI-spesifikk incident response (Defender for Cloud AI posture management). *(Verified MCP 2026-04)*
- [Threat Modeling AI/ML Systems](https://learn.microsoft.com/en-us/security/engineering/threat-modeling-aiml) — STRIDE + MITRE ATLAS mapping for AI threat landscape
- [AI/ML Pivots to SDL Bug Bar](https://learn.microsoft.com/en-us/security/engineering/bug-bar-aiml) — Severity classification for AI-specific threats (data poisoning, model inversion, etc.)

**Azure Security Tools:**
- [Microsoft Sentinel Playbooks](https://learn.microsoft.com/en-us/azure/sentinel/tutorial-respond-threats-playbook) — Automated incident response orchestration
- [Microsoft Defender for Cloud](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction) — Cloud-native threat detection og security posture management
- [Azure Monitor Incident Investigation](https://learn.microsoft.com/en-us/azure/azure-monitor/overview) — Centralized logging and forensics platform

**Evidence Preservation:**
- [Azure Immutable Storage for Blobs](https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-storage-overview) — Legal hold and time-based retention policies
- [Azure VM Snapshots](https://learn.microsoft.com/en-us/azure/virtual-machines/snapshot-copy-managed-disk) — Point-in-time forensic evidence capture
- [Azure Backup Overview](https://learn.microsoft.com/en-us/azure/backup/backup-overview) — Automated backup with long-term retention

### Compliance og Regulatory Frameworks

**Norwegian Regulations:**
- **GDPR**: [Datatilsynet — Meldeplikt ved personopplysningsbrudd](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/meldeplikt-ved-personopplysningsbrudd/)
- **NSM**: [NSM — Varsle sikkerhetshendelser](https://nsm.no/fagomrader/digital-sikkerhet/varsle-sikkerhetshendelser/)
- **Sikkerhetsloven**: [Lovdata — Lov om nasjonal sikkerhet](https://lovdata.no/dokument/NL/lov/2018-06-01-24)

**International Standards:**
- **NIST SP 800-61 Rev. 2**: [Computer Security Incident Handling Guide](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)
- **MITRE ATLAS**: [Adversarial Threat Landscape for AI Systems](https://atlas.mitre.org/)
- **OWASP Top 10 for LLM**: [Generative AI Security Risks](https://genai.owasp.org/)

### Konfidensnivå

**Verified (High Confidence)** — Alle Azure-native tools, services og incident response procedures er verifisert via Microsoft Learn MCP-research (februar 2026, re-verifisert april 2026). CAF Secure AI-dokumentet bekrefter: AI asset inventory via Azure Resource Graph, AI communication channel security (Managed Identities, Virtual Networks, APIM for MCP server-endepunkter), og Purview Insider Risk Management for prompt-basert data exfiltration-deteksjon. Prisestimater basert på offisiell Azure pricing, men kan variere ved currency fluctuation og regional pricing.

**Baseline (Model Knowledge)** — Generell incident response framework (NIST SP 800-61), MITRE ATT&CK for ML, og best practices for forensics/chain of custody basert på industry standards. Norwegian regulatory requirements verifisert via offentlige kilder (Datatilsynet, NSM, Lovdata).

**Note:** AI incident response er et raskt utviklende felt. Nye angrepsmetoder (f.eks. multimodal adversarial attacks, federated learning poisoning) kan kreve justerte detection rules og playbooks. Anbefaler kvartalsvise reviews av threat landscape og tool capabilities.

---

**For Cosmo:** Dette er et komplett utgangspunkt for å diskutere incident response-strategi med klienter. Start med maturity assessment, map til ett av de fire scenarioene (startup/scale-up/enterprise/offentlig), og tilpass playbooks basert på deres AI-specific risk profile. Husk: Incident response er ikke "set it and forget it" — kontinuerlig tuning og tabletop exercises er essensielt for å holde organisasjonen klar.
