Practice-strategy capstone

This capstone module contains no new concepts. It synthesises every topic from the practice-strategy stage: secure SDL, zero trust architecture, cloud and runtime security, supply chain security, vulnerability management, detection and incident response, privacy and ethics, and system quality. Work through the scenario and questions as you would when preparing a security architecture recommendation for a regulated client engagement. The questions are structured to produce artefacts suitable as CPD (Continuing Professional Development) evidence.

MedCore Health Systems is a mid-sized NHS Digital-partner organisation providing digital patient record management, appointment booking, and medical device telemetry aggregation to six NHS Trusts. MedCore currently operates an on-premises data centre running VMware-virtualised infrastructure and has received funding to migrate to hybrid cloud over 18 months.

Current environment: NHS Summary Care Record equivalent data for approximately 2.3 million patients in an on-premises PostgreSQL cluster; NHS billing data in SQL Server; real-time telemetry from 400 connected medical devices (infusion pumps, patient monitors, ECG devices) via a proprietary IoT gateway; Active Directory federated to NHS N3/HSCN identity; a patient-facing Angular SPA and a clinician-facing Windows Forms application (.NET Framework 4.7.2). Security tooling: Sophos endpoint antivirus; Cisco ASA perimeter firewall; no SIEM; no SBOM; quarterly manual vulnerability scanning.

Proposed architecture (Microsoft Azure): patient records and billing data in Azure SQL Managed Instance (PaaS, encrypted at rest via Azure Disk Encryption); medical device telemetry via Azure IoT Hub and Azure Time Series Insights; staff identity via Entra ID (Azure AD Connect sync from on-premises AD); patient portal backend on Azure Kubernetes Service (AKS); clinician desktop API on Azure App Service; connectivity via ExpressRoute private connection (no public internet access to patient records).

Regulatory context: UK GDPR applies to all patient PII and staff personal data; NHS Data Security and Protection Toolkit (DSPT) compliance is mandatory; medical device software may fall under MHRA Class A or B regulation; the ICO must be notified within 72 hours of becoming aware of a data breach; HSCN connectivity requirements mandate specific encryption and authentication standards.

The medical device telemetry pipeline: IoT device (infusion pump) sending telemetry via MQTT over HSCN; on-premises IoT gateway; Azure IoT Hub; Azure Time Series Insights. Apply STRIDE to each pipeline component and identify the two highest-priority threats per component with mitigations.

Key consideration: medical device telemetry introduces patient safety risk beyond confidentiality. A tampered infusion pump dosage reading (Tampering) could cause clinical staff to administer incorrect treatment. A spoofed device feeding false readings (Spoofing) could trigger the same outcome. Rank threats where patient safety is at risk above threats where only data confidentiality is at risk. Relevant controls: mutual TLS between devices and IoT Hub for authentication; Azure IoT Hub per-device authentication tokens; integrity verification of telemetry values before clinical display.

Construct an attack tree for the goal "Attacker exfiltrates 2.3 million patient records from Azure SQL Managed Instance." Include at least five leaf-node attack paths. For each, identify which proposed controls (if any) would mitigate it, and which paths remain unmitigated under the current proposal. Candidate paths: compromised Entra ID credential with MFA bypass; AKS pod escape to underlying node; unpatched vulnerability in the patient portal API; SQL injection via the data migration pipeline; ExpressRoute compromise or misconfigured private endpoint.

The proposed pipeline adds one component the original design never had: an LLM-assisted triage service that summarises device telemetry and flags anomalies for clinical review. Threat-model it with the OWASP Top 10 for LLM Applications in scope, and two categories dominate. LLM01, prompt injection, applies because telemetry values and device-supplied metadata become part of the model input: a tampered device field written to read as an instruction could steer a summary that a clinician then trusts. LLM06, excessive agency, applies if the triage service is allowed to act on its own conclusions, for example suppressing an alert or moving a device threshold, because a wrong or manipulated inference then has a direct clinical effect rather than an advisory one. The mitigations are the ones from the AI modules: treat all telemetry as untrusted input to the model, keep the triage output advisory with a human in the loop for any safety-relevant action, and constrain the tools the model can call so its agency cannot exceed its assurance.

The current environment uses perimeter-based security (Cisco ASA, HSCN boundary). The proposed Azure architecture retains implicit trust within the Azure VNet. Produce a zero trust architecture recommendation covering: identity (Entra ID Conditional Access policy for clinical users requiring phishing-resistant MFA such as FIDO2 passkeys versus administrative users requiring Privileged Identity Management); device (compliance requirements for NHS Trust-owned devices accessing patient records via Microsoft Intune); network (default-deny Network Policies between AKS pods and Azure SQL, explicit allow for required traffic only); application (RBAC model for the patient portal versus the clinician desktop API).

Using the CISA Zero Trust Maturity Model v2.0, assess MedCore's current state. Without a SIEM and using perimeter-only network controls, MedCore is at Traditional maturity across most pillars. The proposed Azure architecture, if properly configured with Microsoft Sentinel (SIEM), Defender for Cloud (CSPM), and Azure Policy (governance), could reach Initial or Advanced in several pillars.

The data migration pipeline and patient portal API migration require SDL gates. Mandatory activities per phase: Requirements (security and privacy NFRs per UK GDPR Article 25, abuse cases for unauthorised data export); Design (threat model for each new component, attack surface analysis); Implementation (SAST with Semgrep or SonarQube, approved dependency list, no CRITICAL CVEs in production images); Verification (DAST against staging, penetration test of AKS cluster and API endpoints before go-live). The clinician desktop application (.NET Framework 4.7.2, cloud-exposed via App Service) requires CWE Top 25 2023 assessment before migration: prioritise CWE-89 (SQL injection), CWE-79 (XSS in any web-rendered output), CWE-352 (CSRF), and CWE-20 (input validation gaps) for a .NET web-exposed context.

Supply chain risk assessment for the Azure migration: the shared responsibility boundary under PaaS (Azure SQL Managed Instance) places infrastructure and platform security with Microsoft but database configuration, IAM, network access controls, and application layer security with MedCore. SBOM requirements: generate SPDX 2.3 (ISO/IEC 5962:2021) for any DSPT compliance submission and CycloneDX 1.5 for continuous vulnerability management via Syft in the CI/CD pipeline. The data migration pipeline (new bespoke component handling patient records) should target SLSA L2 on GitHub Actions as a minimum: signed provenance tied to the known build platform. Due diligence for the three open-source libraries (PostgreSQL connector, cryptographic library, Azure SDK): verify SLSA provenance publication, review NIST SP 800-161r1 C-SCRM criteria (maintenance status, known CVEs, dependency depth), and confirm transitive dependency scanning is enabled in Snyk or Dependabot configuration.

Vulnerability management for the hybrid cloud: authenticated scanning of all Azure assets via Defender for Cloud with daily frequency for patient-facing systems; SBOM-driven CVE matching for all deployed containers; KEV catalogue integration triggering re-triage for any existing open finding newly added. SLAs: Critical with KEV entry or EPSS above 50% on patient-facing systems: 48 hours; Critical otherwise: 14 days; High: 30 days. Exception approvals for patient-facing systems require CISO sign-off, documented in the risk register, with a 30-day maximum.

MedCore requires a formal IR plan before the migration goes live. IR plan outline: team structure with named ICO notification owner (UK GDPR Article 33 requires notification within 72 hours of becoming aware of a breach); internal escalation triggers; patient notification thresholds; NHS Digital reporting obligations; containment authority (who can authorise isolation of a system processing active patient care data, and what is the out-of-hours escalation path). Detection triggers in the proposed Azure environment: Microsoft Sentinel alert on service account performing bulk EXPORT operations outside the migration runbook; Defender for Cloud alert on anomalous Azure SQL query patterns; AKS runtime anomalies from Falco or Microsoft Defender for Containers.

None of the earlier parts asked the plain governance question: which laws actually bite on MedCore, and who owns the answer. Run the organisation through a regulatory applicability map rather than a compliance checklist. MedCore is not itself a designated operator of essential services, so the Network and Information Systems Regulations 2018 reach it indirectly, through its NHS partnership and the DSPT it must satisfy to connect. The Cyber Security and Resilience Bill is changing that trajectory: its direction of travel is to widen the regime towards critical suppliers and managed service providers, so a body only indirectly in scope today should plan for direct obligations tomorrow. The Data (Use and Access) Act adjusts the UK data protection regime the patient records already sit under, so the UK GDPR duties named in the scenario have to be read against it rather than in isolation. The output is not a tick-list; it is a short table of obligation, source, owner and evidence, so the answer already exists when a regulator or an NHS partner asks.

Regulation sets the floor; resilience sets the plan. For the patient-record service the board has to agree a recovery time objective and a recovery point objective before the migration, not in the middle of an incident. A record clinicians rely on for active care cannot tolerate a long outage, so its RTO belongs in hours rather than days, and the tolerable data loss behind its RPO is close to zero, because a lost hour of a patient record is a lost hour of clinical history. Those two numbers are not a storage preference; they drive the backup frequency, the case for immutable and frequently synchronised copies, and the recovery testing schedule that proves the numbers are real rather than aspirational. Set them explicitly, sign them off at board level, and rehearse the restore, because an untested RTO is only a guess.

The last exercise takes the ransom-payment decision to the board, because control design alone does not close the governance loop. Walk the five-gate ransom-payment procedure against MedCore’s own position. MedCore is not a public body, so the targeted payment ban announced on 22 July 2025 does not bar it outright, but the payment prevention regime still requires it to notify and engage the authorities before any payment, and its NHS Trust customers sit inside the ban, which shapes what they will contractually expect of it. The legality and sanctions gate, insurer consent, evidence that a decryptor would restore service at production scale, evidence that stolen records would genuinely be deleted, and a single named board authority are all settled in advance, in writing, and rehearsed in a tabletop exercise. Framed this way the board does not improvise under extortion; it approves a procedure while calm, and the link between the technical work and the money is finally explicit.

Work through these prompts to produce artefacts suitable as CPD evidence:

1. The MedCore scenario involves medical device telemetry where security failures could directly affect patient safety. How does the potential for physical harm change your approach to risk prioritisation compared to a purely financial system? Which frameworks covered in this stage explicitly address safety alongside security?
2. MedCore has been operating without a SIEM, IR plan, or formal vulnerability management. If you were the first security hire, in what order would you implement the practice-strategy controls, and why? What would your 30, 60, and 90-day plan look like?
3. The NHS DSPT requires evidence of compliance with specific standards. Which practice-strategy stage controls provide the most direct evidence for which DSPT assertions? How would you structure a compliance mapping exercise?
4. The mTLS trade-off for 400 medical devices with limited compute resources illustrates the tension between security maximalism and practical implementability. How would you defend a risk-accepted partial implementation to a clinical safety officer who argues that safety-critical systems should accept no security compromises?