Home > Docs > Best Practices > Security > STRIDE Threat Model

🛡️ STRIDE Threat Modeling for Fabric Reference Architecture¶

Last Updated: 2026-04-27 | Version: 1.0.0 | Companion to: SOC 2 Type II Readiness (CC3.1)

Disclaimer: This document provides a reference STRIDE threat model for the Microsoft Fabric reference architecture in this repository. It is not a substitute for a tailored threat model of your production environment. Your data, integrations, regulatory exposure, and threat landscape will differ. Engage a qualified security architect to validate and extend this model for your specific deployment.

📑 Table of Contents¶

• 🎯 Overview
• 📋 What is STRIDE
• 🆚 When to Use STRIDE (vs PASTA, OCTAVE, ATT&CK)
• 🔄 Threat Modeling Process
• 🏗️ Reference Architecture Data Flow
• 🧩 Per-Component STRIDE Analysis
• 📊 Consolidated Threat Catalog
• 🔗 Mitigation Mapping to Existing Docs
• ✍️ Residual Risk Acceptance
• 📅 Threat Model Maintenance
• 🛠️ Tooling Recommendations
• 🎰 Casino Implementation
• 🏛️ Federal Implementation
• 🚫 Anti-Patterns
• 📋 Implementation Checklist
• 📚 References

🎯 Overview¶

A threat model is not a vulnerability scan and not a pen test report. It's a structured exercise that asks: "What could go wrong with this system, and what are we doing about it?" The output is an inventory of threats, mitigations, and accepted residual risks — exactly what a SOC 2 auditor expects to see for CC3.1 (risk assessment) and what a security review board needs before a production go-live.

This document provides a STRIDE-based threat model for the canonical Fabric reference architecture deployed by infra/main.bicep. It is the auditor-grade artifact you hand over when asked: "Show me your threat model."

Why STRIDE for Fabric Workloads¶

What This Document Covers¶

• A reusable per-component STRIDE matrix tailored to Fabric services (Workspace, Lakehouse, Pipelines, Eventstream, Power BI, Workspace Identity, Key Vault)
• Trust boundaries on the canonical data flow diagram
• Mitigations that link back to existing best-practice docs (CMK, OAP, network security, identity)
• A residual-risk register template
• Maintenance cadence and re-modeling triggers

📝 Scope: This is a reference threat model. It assumes the architecture in infra/main.bicep and the deployed components (Fabric F64 capacity, ADLS, Key Vault, Eventhouse, Eventstream, Log Analytics). Your environment will introduce additional threats — extend the catalog, do not replace it.

📋 What is STRIDE¶

STRIDE is a threat-classification framework developed by Microsoft engineers (Loren Kohnfelder and Praerit Garg, 1999) and now codified in the SDL (Security Development Lifecycle). It enumerates six threat categories — one per letter — that map to the six core security properties:

Why STRIDE is well-suited to data platforms: - Each letter maps directly to a Fabric control surface (auth, encryption, audit, IAM, capacity, RBAC). - It's per-component, so multi-tenant or multi-domain workloads (casino chain, federal agencies) decompose cleanly. - It produces a checklist auditors recognize — no need to translate to a different framework for SOC 2 / ISO / FedRAMP.

🆚 When to Use STRIDE (vs PASTA, OCTAVE, ATT&CK)¶

Recommendation for this POC: STRIDE for the design-time model (this document). MITRE ATT&CK for SOC detection rules. CVSS for vuln-scan triage. The three are complementary, not alternatives.

🔄 Threat Modeling Process¶

A repeatable process keeps threat models honest. Skipping steps produces a checkbox artifact that fails its first auditor walkthrough.

Step 1 — Define the System¶

Produce or update a data flow diagram (DFD) showing: - Processes (rectangles) — services that transform data (e.g., a Spark notebook) - Data stores (cylinders / parallel lines) — Lakehouses, Key Vaults, Log Analytics - Data flows (arrows) — protocol + direction (HTTPS, JDBC, AMQP) - External entities (squares) — users, source systems, BI consumers - Trust boundaries (dashed lines) — places where authentication and authorization decisions occur

Trust boundaries are the most important element. A threat lives at a boundary crossing.

Step 2 — Decompose¶

Walk every component on the diagram. For each, list: - Its inputs (where does data come from?) - Its outputs (where does data go?) - Its identity (who runs it: user, SP, Workspace Identity?) - Its data classification (public, internal, confidential, highly confidential)

Step 3 — Identify Threats (STRIDE per Component)¶

For each component, ask the six STRIDE questions. Record every plausible threat — do not filter by likelihood at this stage. False positives are cheap; missed threats are not.

Step 4 — Determine Mitigations¶

For each threat, document: - Mitigation — the control that reduces likelihood or impact - Owner — who is responsible for operating the control - Verification — how you confirm it's working (audit query, test, runbook) - Reference — link to the doc / Bicep module / runbook implementing it

Step 5 — Validate (Residual Risk Acceptance)¶

Threats that cannot be fully mitigated become residual risks. They must be: - Documented with severity - Reviewed by a risk owner (Security Architect or CISO delegate) - Formally accepted in writing - Re-evaluated on the cadence below

Step 6 — Re-Do Annually + on Major Architecture Change¶

A threat model is a living artifact. Re-validate: - Annually at minimum - On any major architecture change (new component, new integration) - After a security incident (was the threat in the model? if not, why?) - On a regulatory shift (new data classification, new framework adoption)

🏗️ Reference Architecture Data Flow¶

The diagram below is the canonical Fabric reference architecture deployed by infra/main.bicep. Trust boundaries are dashed — every arrow that crosses a dashed line is a place where STRIDE threats apply.

flowchart TB
    subgraph Internet["🌐 Internet (Untrusted)"]
        EU[External User]
        ExtBI[BI Consumer]
        SrcAPI[Source API / SaaS]
    end

    subgraph TenantBoundary["🏢 Azure Tenant Boundary"]
        subgraph Identity["🆔 Identity Plane"]
            Entra[Entra ID]
            CA[Conditional Access]
            PIM[PIM / JIT]
        end

        subgraph FabricBoundary["⚙️ Fabric Workspace Boundary"]
            Portal[Fabric Portal]
            WS[Workspace + RBAC]
            SHIR[Self-Hosted IR]
            Pipe[Data Pipeline]
            ES[Eventstream]
            EH[(Eventhouse / KQL)]

            subgraph LakehouseBoundary["💧 Lakehouse / OneLake Boundary"]
                LB[(lh_bronze)]
                LS[(lh_silver)]
                LG[(lh_gold)]
                NB[Spark Notebook]
            end

            SM[Power BI Semantic Model]
            WI[Workspace Identity]
        end

        subgraph SupportPlane["🔧 Supporting Azure Services"]
            KV[(Key Vault)]
            ADLS[(ADLS Gen2)]
            LA[(Log Analytics)]
            AuditLog[(Immutable Audit)]
        end

        subgraph CICD["🔄 CI/CD Plane"]
            GH[GitHub Actions]
            FCICD[fabric-cicd]
            SP[Service Principal]
        end
    end

    EU -.->|HTTPS + MFA| CA
    CA --> Entra
    Entra --> Portal
    Portal --> WS
    PIM --> WS

    SrcAPI -.->|HTTPS / JDBC| SHIR
    SHIR --> Pipe
    Pipe --> LB
    SrcAPI -.->|AMQP| ES
    ES --> EH

    LB --> NB
    NB --> LS
    LS --> NB
    NB --> LG
    LG --> SM
    EH --> SM

    SM -.->|HTTPS / DAX| ExtBI

    WI --> ADLS
    WI --> KV
    Pipe --> KV

    WS --> LA
    NB --> LA
    Pipe --> LA
    LA --> AuditLog

    GH --> SP
    SP -.->|HTTPS| FCICD
    FCICD --> WS

    classDef trust stroke-dasharray: 5 5
    class TenantBoundary,FabricBoundary,LakehouseBoundary trust

Trust boundaries (dashed): 1. Internet ↔ Azure Tenant — every inbound user / API call crosses here. 2. Azure Tenant ↔ Fabric Workspace — workspace IAM enforced. 3. Fabric Workspace ↔ OneLake / Lakehouse — OneLake Security + RBAC enforced. 4. CI/CD ↔ Fabric Workspace — service-principal authorization gate.

Every numbered component below corresponds to a node — or a flow crossing a boundary — in this diagram.

🧩 Per-Component STRIDE Analysis¶

Each table below decomposes one component. Threats are denser at trust-boundary crossings (Components 1, 2, 5, 9) and thinner inside trusted zones (Components 4, 8). That asymmetry is expected — and a sign the model is calibrated correctly.

Component 1 — User Authentication (Entra ID + Conditional Access)¶

Boundary crossed: Internet ↔ Azure Tenant.

Component 2 — Workspace Access (Fabric Workspace IAM)¶

Boundary crossed: Azure Tenant ↔ Fabric Workspace.

Component 3 — Lakehouse / Warehouse Data Access¶

Boundary crossed: Fabric Workspace ↔ Lakehouse.

Component 4 — Pipeline / Notebook Execution¶

Boundary crossed: internal (within workspace), but with external code execution and secret access.

Component 5 — External Data Ingestion (SHIR / Mirroring / Eventstream)¶

Boundary crossed: Internet ↔ Azure Tenant and Azure Tenant ↔ Fabric Workspace.

Component 6 — BI Consumer (Power BI Direct Lake)¶

Boundary crossed: Internet ↔ Azure Tenant (for the consumer) and Workspace ↔ Lakehouse (for the Direct Lake path).

Component 7 — Service-to-Service (Workspace Identity → ADLS / Key Vault)¶

Boundary crossed: Fabric Workspace ↔ Supporting Azure Services.

Component 8 — Audit Log Subsystem¶

Boundary crossed: Fabric Workspace → Log Analytics → Immutable Audit.

Component 9 — CI/CD Pipeline (GitHub Actions + fabric-cicd)¶

Boundary crossed: CI/CD ↔ Fabric Workspace — historically the highest-risk boundary in modern attacks.

Component 10 — Secrets Management (Key Vault)¶

Boundary crossed: Fabric Workspace ↔ Key Vault.

📊 Consolidated Threat Catalog¶

The catalog below de-duplicates and prioritizes threats across all ten components. Use this as the single source of truth when handing the model to an auditor or risk committee. Likelihood and impact are scored 1 (low) – 5 (high). Residual risk = Likelihood × Impact after mitigation.

⚠️ Caveat: Residual scores assume mitigations are operating effectively. The SOC 2 Type II examination period is precisely the test of that assumption. A mitigation present in design but absent in operation provides zero residual reduction.

🔗 Mitigation Mapping to Existing Docs¶

Every mitigation in the catalog should resolve to a deployable control documented elsewhere. The mapping below makes that traceability explicit — auditors will follow these links.

✍️ Residual Risk Acceptance¶

Every threat in the catalog with residual ≥ 2 must be either (a) further mitigated, (b) transferred (insurance / contractual), or © formally accepted. The accepted set is what the risk owner signs.

Risk Acceptance Template¶

# Residual Risk Acceptance — [Threat ID]

**Threat ID:** T-005
**Component:** C3 Lakehouse — SP secret leaked in notebook source
**STRIDE:** Spoofing
**Residual Likelihood × Impact:** 2 × 5 = 10 (residual after Workspace Identity rollout)

## Decision
☑ Accept   ☐ Mitigate further   ☐ Transfer   ☐ Avoid

## Rationale
Workspace Identity covers 100% of new pipelines but ~5% of legacy notebooks
still use stored SP secrets pending migration in Phase 15. Secret scanning
on every commit catches accidental leaks within minutes.

## Compensating Controls
- Pre-commit secret scan (gitleaks)
- Quarterly notebook-source audit for credential patterns
- Targeted migration plan with completion date

## Re-Evaluation Date
2026-10-01 (post Phase 15)

## Owner
Security Architect — fgarofalo@example.com

## Signatures
Risk Owner: ____________________ Date: ____________
CISO Delegate: _________________ Date: ____________

Maintain the acceptance register in immutable storage alongside the threat model itself. Auditors will request both as a pair.

📅 Threat Model Maintenance¶

A threat model that hasn't been touched in 18 months is worse than no threat model — it gives false assurance.

Review Cadence¶

Triggers for Re-Modeling¶

A trigger means "stop and re-do the relevant component", not "wait for the annual review":

• New component deployed (e.g., adopting Mirroring for a new source)
• New integration crossing a trust boundary (new SaaS, new agency feed)
• New regulatory framework adopted (new agency = new compliance obligations)
• Security incident — even a minor one, even a near miss
• Major Microsoft Fabric platform change with security implications (new RBAC model, new identity primitive)
• Acquisition or divestiture changing the trust topology
• Pen test or red team result not anticipated by the model

Ownership¶

The threat model has one named accountable owner — the Security Architect — and a delegated co-owner from the platform team. Both names live in the document header, both rotate with the on-call handbook, and both review the catalog together once a quarter. Without a named owner, the model decays.

🛠️ Tooling Recommendations¶

You don't need a tool to do STRIDE — paper, a whiteboard, and discipline work — but tools help with version control, diagram regeneration, and team participation.

Recommendation for this POC: - Diagrams: Mermaid in this Markdown file (Git-diffable, renders on GitHub) - Catalog: Markdown table in this file - Acceptance register: Markdown files in docs/security/risk-acceptance/ - Optional advanced: PyTM or Threagile for CI-driven re-evaluation when the architecture changes

The point is traceability and review-ability — pick whichever tool your team will actually update.

🎰 Casino Implementation¶

The casino domain (NIGC MICS, BSA / FinCEN, multi-property chains) introduces threats not covered by the generic model.

Compliance Officer Access Controls¶

Compliance officers need broad read access to BSA-relevant data (CTR, SAR, W-2G) but must not have administrative write access. The threat is insider compromise of compliance data — exactly what the BSA examiner will probe.

• Workspace role: Viewer + custom item-level Build permission on regulatory reports only
• Data security: OneLake Security RLS bound to the officer's property assignment; cross-property visibility requires elevated role under PIM
• Audit: Every CTR/SAR query logged with the officer's UPN; queries reviewed monthly against case files
• Separation of duties: The compliance team cannot also approve their own access requests; that goes through the Security Architect

Multi-Tenant Casino Chain (Cross-Property Isolation)¶

A regional casino operator with 8 properties faces a different threat: cross-property data leakage via shared infrastructure.

• Workspace per property for sensitive cardroom & cage data; shared workspaces for chain-wide reporting only with tagged sensitivity labels
• OneLake shortcuts are reviewed quarterly — a misconfigured shortcut is the most common cross-property leakage vector
• Capacity isolation (per-property capacity assignment) prevents one property's saturation event from impacting another

Casino-Specific Threats Added to Catalog¶

🏛️ Federal Implementation¶

The federal expansions (USDA, SBA, NOAA, EPA, DOI, DOJ, Tribal Health, DOT/FAA) overlay FedRAMP, HIPAA, and CIPSEA controls on the same architecture.

DOJ Data Sensitivity (Restricted Access)¶

DOJ datasets include law-enforcement-sensitive information. The threat is broader workforce visibility into restricted data.

• Workspace isolation: DOJ workloads in a dedicated workspace, separate Entra group, separate Workspace Identity
• Conditional Access: Restrict access to managed devices + named locations only
• Data classification: Highly Confidential sensitivity label inherited end-to-end (Bronze → Silver → Gold → Power BI)
• Egress controls: OAP enforced; no shortcut writes outside workspace

HIPAA Tribal Health (PHI Handling)¶

Tribal Health workloads carry PHI under HIPAA Security Rule. The model adds: - Encryption: CMK with HSM-backed keys; 7-year retention floor - Audit: PHI access events retained ≥6 years (HIPAA), with patient-level access reports available on demand - BAA enforcement: Sub-processor list mirrored in Microsoft's BAA + maintained internally - Breach response: 60-day notification per HHS rules; runbook tested annually

Federal-Specific Threats Added to Catalog¶

🚫 Anti-Patterns¶

📋 Implementation Checklist¶

Before declaring "threat model ready" for SOC 2 / ISO / FedRAMP review:

• Data flow diagram drawn with all components and trust boundaries
• Diagram lives in version control (this Markdown is sufficient)
• Per-component STRIDE table completed for every component
• Threats deduped into the consolidated catalog
• Likelihood × Impact scored for every threat
• Residual risk computed and recorded post-mitigation
• Each mitigation links to a doc, Bicep module, or runbook
• Threats with residual ≥ 2 have a Risk Acceptance record
• Risk Acceptance records are signed and stored in immutable storage
• Named owner (Security Architect) and co-owner documented
• Review cadence captured in calendar / on-call handbook
• Re-modeling triggers communicated to platform & feature teams
• Casino-specific threats appended (if Casino domain in scope)
• Federal-specific threats appended (if federal expansions in scope)
• Walkthrough scheduled with auditor for SOC 2 CC3.1
• Quarterly review meeting recurring on team calendar
• Annual full re-validation scheduled
• Threat model output linked from SOC 2 Type II readiness doc (CC3.1)
• Threat model output linked from architecture review board template
• Postmortem template includes "was this in the threat model?" question
• CI gate runs Bicep / config drift detection against modeled assumptions
• Risk register reconciled monthly with this catalog

📚 References¶

Microsoft Resources¶

• Microsoft STRIDE Methodology
• Microsoft Threat Modeling Tool
• Microsoft SDL Practices
• Microsoft Fabric Security Documentation

OWASP & Industry¶

• OWASP Threat Modeling
• OWASP Threat Dragon
• OWASP Threat Modeling Cheat Sheet
• PyTM (Code-as-Threat-Model)
• Threagile

Standards & Frameworks¶

• NIST SP 800-154 — Data-Centric System Threat Modeling
• NIST SP 800-30 — Risk Assessment Guide
• ISO/IEC 27005 — Information Security Risk Management
• MITRE ATT&CK Framework
• SAFECode Tactical Threat Modeling

Related Wave 5 Docs (this Wave)¶

• SOC 2 Type II Readiness — anchor; CC3.1 directly cites this doc
• ISO 27001 Mapping
• GDPR Right to Deletion
• CCPA Privacy Rights
• Zero-Trust Blueprint
• Data Exfiltration Prevention
• Supply Chain Security
• Audit Trail Immutability

Related Existing Docs¶

• Network Security
• Identity & RBAC Patterns
• Customer-Managed Keys
• Outbound Access Protection
• Data Governance Deep Dive
• Disaster Recovery (BCDR)
• Capacity Planning & Cost Optimization
• Monitoring & Observability
• Incremental Refresh / CDC

Related Operational Docs (Wave 1)¶

• Incident Response Template
• Multi-Region Failover Runbook
• Capacity Throttling Response
• SLO/SLI for Fabric
• Change Management
• Observability Stack

Bicep Modules Referenced¶

• infra/main.bicep — root orchestration
• infra/modules/security/workspace-identity.bicep — Workspace Identity (Component 7 control plane)
• infra/modules/fabric/fabric-pipeline.bicep — Pipelines (Component 4)
• infra/modules/fabric/fabric-capacity.bicep — Capacity (Components 3, 5, 6 DoS controls)

⬆️ Back to Top | 📚 Security Index | 🏠 Home