Acuity Health: Part 3 - STRIDE Threat Modeling & BOLA Elimination

Threat modeling is frequently cited as the most cost-effective security activity in software engineering. Fixing a structural authorization flaw during design costs a fraction of refactoring a production database or remediating a public data breach.

Yet in fast-moving engineering organizations, traditional threat modeling often fails. Multi-week architectural reviews create bottlenecks, resulting in developers bypassing security reviews to meet sprint deadlines.

To make threat modeling sustainable, it must be lightweight, developer-centric, and embedded directly into Agile ceremonies.

In this third installment of our Acuity Health Security Architecture series, we examine how to implement mini-STRIDE threat modeling gates in Agile sprints and deep-dive into code-level defenses against the single most devastating API threat in modern cloud applications: Broken Object Level Authorization (BOLA).

---

Shifting Left: The Mini-STRIDE Sprint Gate

Rather than holding marathon architecture reviews once a year, high-performing DevSecOps teams run mini-STRIDE sessions (15–20 minutes) during backlog refinement.

The Trigger Criteria

A mini-STRIDE assessment is automatically required whenever a backlog user story involves:

1. Ingesting, processing, or storing electronic Protected Health Information (ePHI) or Personally Identifiable Information (PII).
2. Introducing a new public or partner API endpoint.
3. Modifying authentication, authorization, or session management logic.
4. Integrating a third-party external service or webhook.

flowchart TD
    Story["Backlog User Story"] --> Check{"Touches ePHI, Auth, or External API?"}
    Check -- No --> Groom["Standard Sprint Grooming"]
    Check -- Yes --> STRIDE["15-Min Mini-STRIDE Session (Dev Lead + Sec Champion)"]
    STRIDE --> DFD["Draft / Update Data Flow Diagram (DFD)"]
    DFD --> ThreatList["Enumerate STRIDE Vectors"]
    ThreatList --> SecStories["Create Security Sub-Tasks in Jira (Mitigations)"]
    SecStories --> Groom
    Groom --> Sprint["Sprint Backlog: Mitigations Tracked with Equal Velocity"]

---

Mapping Clinical Data Flows & Trust Boundaries

Consider a cloud-native healthcare workflow: a patient checks in on a mobile device, uploads telemetry, and a clinician issues an electronic prescription that syncs with an external pharmacy API.

graph TB
    subgraph PublicZone ["Untrusted / Public Zone"]
        Patient["Patient Mobile App / Browser"]
        Attacker["Potential Attacker"]
    end

 subgraph EdgeBoundary ["Trust Boundary 1: API Edge"] APIGW["Azure API Gateway (OAuth 2.0 / Rate Limiting)"] end

 subgraph ServiceBoundary ["Trust Boundary 2: Microservice Network"] AuthSvc["Auth & Identity Service"] RxSvc["e-Prescription Microservice"] CheckInSvc["Check-in Telemetry Svc"] end

 subgraph InternalBoundary ["Trust Boundary 3: Secure Data Tier"] DB[(PostgreSQL / Cosmos DB - Encrypted AES-256)] EMRCore["Core Clinical EMR (HIPAA Vault)"] end

 subgraph ThirdPartyBoundary ["Trust Boundary 4: External B2B"] PharmacyAPI["External Pharmacy Network (mTLS / BAA)"] end

 Patient -->|1. TLS 1.3 / JWT Token| APIGW Attacker -.->|Probe Parameter IDs| APIGW APIGW -->|2. Validate Scope| AuthSvc APIGW -->|3. Route Request + Claims| RxSvc APIGW -->|Route Telemetry| CheckInSvc RxSvc -->|4. Context-Enforced Query| DB RxSvc -->|5. Sync Prescription Data| EMRCore RxSvc -->|6. Signed Webhook Payload| PharmacyAPI ```



### STRIDE Threat Vector Mapping for Healthcare APIs

| STRIDE Category | Specific Cloud Healthcare Threat | Required Mitigation Control |
| :--- | :--- | :--- |
| **S - Spoofing** | Attacker crafts forged JWT claims or impersonates a clinician endpoint. | Enforce RS256/ES256 asymmetric cryptographic token validation; mandate mTLS between microservices. |
| **T - Tampering** | Attacker alters prescription dosage parameters or patient ID during transit. | Parameterized input schemas; cryptographic request payload signatures; TLS 1.3 only. |
| **R - Repudiation** | User denies submitting an online medical declaration or altering a record. | Write immutable, tamper-evident audit logs to a dedicated Azure Sentinel / Log Analytics workspace. |
| **I - Information Disclosure** | Exposure of ePHI via verbose error traces, unencrypted payload logs, or BOLA. | Mask sensitive payload fields; enforce strict data-layer authorization context; encrypt at rest (AES-256). |
| **D - Denial of Service** | Volumetric HTTP floods overwhelm patient check-in portal during peak hours. | Azure Front Door Layer 7 DDoS mitigation; token-bucket API rate limiting per IP and authenticated user. |
| **E - Elevation of Privilege** | Standard patient account accesses clinician administrative endpoints. | Strict Role-Based Access Control (RBAC) enforced at both API gateway and business logic layers. |

---

## Neutralizing OWASP API1: Broken Object Level Authorization (BOLA)

According to the OWASP API Security Top 10, **Broken Object Level Authorization (BOLA)** remains the number one vulnerability across modern applications. BOLA occurs when an API endpoint accepts an object identifier from a client request without verifying that the requesting user has legitimate ownership or authorization over that specific resource.

### The Vulnerable Pattern: Sequential Integer IDs & Missing Context

In vulnerable architectures, endpoints expose sequential integer IDs (e.g., `/api/v1/prescriptions/1042`). An attacker logs in as Patient A (ID: 1042) and simply iterates the URL parameter to `/api/v1/prescriptions/1043` to harvest Patient B's medical records.



```python
# ❌ VULNERABLE IMPLEMENTATION (BOLA FLINK)
@app.route("/api/v1/prescriptions/<int:prescription_id>", methods=["GET"])
@jwt_required
def get_prescription(prescription_id):
    # Authenticated user identity is available, but NOT checked against the record!
    current_user_id = get_jwt_identity
    # Flaw: Queries database solely by ID supplied in the request parameter
    prescription = db.session.query(Prescription).filter_by(id=prescription_id).first
    if not prescription:
        return jsonify({"error": "Record not found"}), 404
    # Leaks Patient B's prescription data to Patient A!
    return jsonify(prescription.to_dict), 200

The Hardened Pattern: Cryptographic UUIDs & Data-Layer Context Checks

To eliminate BOLA, the architecture must implement two complementary controls:

1. Replace Sequential Identifiers with UUIDv4: Prevents enumeration and guessability across public interfaces.
2. Enforce Authorization Context at the Data Fetch Layer: Every database query must explicitly join or filter on the authenticated user's tenant/identity context.

# ✅ HARDENED IMPLEMENTATION (ZERO TRUST CONTEXT CHECK)
import uuid
from flask import abort, jsonify, request
from flask_jwt_extended import jwt_required, get_jwt_identity, get_jwt

@app.route("/api/v1/prescriptions/<uuid:prescription_uuid>", methods=["GET"]) @jwt_required def get_secure_prescription(prescription_uuid): current_user_id = get_jwt_identity claims = get_jwt user_role = claims.get("role", "patient") # 1. Parameter Validation: Ensure valid UUID format (handled by route converter) # 2. Context-Aware Query Execution query = db.session.query(Prescription).filter( Prescription.uuid == str(prescription_uuid) ) # 3. Role-Specific Authorization Context Binding if user_role == "patient": # Patients can ONLY access records where they are the explicit record owner query = query.filter(Prescription.patient_account_id == current_user_id) elif user_role == "clinician": # Clinicians can only access records within their assigned clinic facility clinic_id = claims.get("clinic_id") query = query.filter(Prescription.assigned_clinic_id == clinic_id) elif user_role == "system_admin": # Admins are logged for audit compliance audit_log_access(user_id=current_user_id, resource=prescription_uuid, action="READ") else: # Deny by default abort(403, description="Unauthorized access context")

 prescription = query.first if not prescription: # Return 404 rather than 403 to prevent resource existence enumeration return jsonify({"error": "Prescription record not found"}), 404 return jsonify(prescription.to_dict), 200 ```
{% endraw %}


---

## Defensive Cryptographic & Input Validation Standards

In addition to authorization context checks, modern cloud applications must enforce strict data protection baselines:

| Security Domain | Baseline Standard | Implementation Controls |
| :--- | :--- | :--- |
| **Cryptography at Rest** | AES-256-GCM / ChaCha20-Poly1305 | • Per-tenant cryptographic salts<br>• Automated key rotation via Azure Managed HSM<br>• Transparent database field-level encryption |
| **Cryptography in Transit** | TLS 1.3 Mandatory | • Strict forward-secrecy cipher suites only<br>• Enforced HTTP Strict-Transport-Security (HSTS)<br>• Automated mTLS between internal microservices |
| **Input Validation & Sanitization** | Schema-Enforced Typed Contracts | • Strict Pydantic and JSON Schema payload validation<br>• Parameterized SQLAlchemy ORM queries preventing SQL injection<br>• Content-Type and MIME type strict allow-lists |
| **Error Handling & Observability** | Opaque Client Responses | • Generic client-side error responses preventing information leakage<br>• Centralized, tamper-resistant audit logs in Microsoft Sentinel<br>• Real-time behavioral anomaly alerting |

---

## Implementation Takeaways: Part 2

- **Make Threat Modeling Atomic**: Embed 15-minute mini-STRIDE sessions into sprint planning for any user story touching sensitive data flows or APIs.
- **Never Trust Client-Supplied IDs**: Replace all sequential integer primary keys with cryptographically random UUIDv4 identifiers across public routes.
- **Enforce Context at the Data Layer**: Always bind database queries to the requesting user's verified token claims ({% raw %}`patient_id`, `clinic_id`, `tenant_id`).
- **Return Generic Errors**: When an authorization context check fails, return `404 Not Found` rather than `403 Forbidden` to prevent object existence enumeration.

---

## Up Next in the Series

In **Part 4: Automating CI/CD Quality Gates and Operationalizing ISO 27001 Risk Assessments** (releasing **Tuesday, September 29**), we complete the framework: - Configuring automated **SAST, SCA, and DAST** Quality Gates in CI/CD pipelines. - Establishing vulnerability remediation SLAs without causing developer fatigue. - Operationalizing the **10-Step ISO/IEC 27001:2013 Risk Assessment** methodology with a quantified cloud risk register.