Practice-strategy capstone
By the end of this module you will be able to:
- Produce a STRIDE threat model for a hybrid cloud healthcare environment
- Design a zero trust architecture recommendation for a regulated environment using CISA maturity model
- Define SDL gates, supply chain controls, and vulnerability management SLAs for a cloud migration
- Write an IR plan outline and apply the NIST SP 800-61r3 phases to a live incident scenario
Purpose of this module
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.
With an understanding of purpose of this module in place, the discussion can now turn to scenario: medcore health systems, which builds directly on these foundations.
Scenario: MedCore Health Systems
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.
With an understanding of scenario: medcore health systems in place, the discussion can now turn to part 1: threat modelling the iot pipeline, which builds directly on these foundations.
“A real-world security programme integrates threat modelling, zero trust architecture, secure SDL, supply chain risk management, vulnerability management, incident response, privacy engineering, and quality trade-off analysis. No single framework covers everything; the skill is knowing which framework applies to which problem.”
Practice-strategy capstone synthesis principle
“Security assurance activities should be integrated throughout the development and operational lifecycle of a system. Point-in-time assessments provide a snapshot; continuous monitoring provides ongoing confidence in the security posture across all six NIST CSF 2.0 functions.”
NIST CSF 2.0 (2024), Section 2.2: The CSF as a Common Language for Cybersecurity Risk Management - Core Functions
Common misconception
“A security programme that passes all annual compliance audits is a mature security programme.”
Compliance frameworks define a minimum baseline of controls documented at a point in time. A programme that maintains compliance by producing evidence for an annual audit cycle may have significant operational gaps: detection rules that have never been tested, IR plans that have never been exercised, vulnerability management SLAs that are defined but not enforced. NIST CSF 2.0 distinguishes between compliance evidence (a snapshot) and operational maturity (demonstrated through metrics like MTTR, mean time to detect, and tabletop exercise outcomes). The MedCore scenario illustrates this: an organisation could pass a DSPT audit with documented policies while having zero operational SIEM coverage.
Common misconception
“Security by design means making every component maximally secure regardless of cost or usability impact.”
Security by design means explicitly addressing security trade-offs at design time with documented decisions. It is the opposite of security by obscurity or security by accident. The MedCore scenario involves medical devices with limited compute that cannot support mTLS without hardware upgrade. A security-by-design approach documents this constraint explicitly, applies the strongest feasible control (device certificates with pre-shared keys), and records the residual risk with a named owner and review date. A design that ignores the trade-off and mandates full mTLS regardless is not better security by design; it is a security programme that will fail to get implemented.
Part 1: Threat modelling the IoT pipeline
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.
With an understanding of part 1: threat modelling the iot pipeline in place, the discussion can now turn to part 2: zero trust architecture and sdl gates, which builds directly on these foundations.
Part 2: Zero trust architecture and SDL gates
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.
With an understanding of part 2: zero trust architecture and sdl gates in place, the discussion can now turn to part 3: supply chain, vulnerability management, and incident response, which builds directly on these foundations.
Part 3: Supply chain, vulnerability management, and incident response
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.
With an understanding of part 3: supply chain, vulnerability management, and incident response in place, the discussion can now turn to cpd reflection prompts, which builds directly on these foundations.
CPD reflection prompts
Work through these prompts to produce artefacts suitable as CPD evidence:
- 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?
- 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?
- 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?
- 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?
Key takeaways
- A real-world security programme integrates threat modelling, zero trust, secure SDL, supply chain risk, vulnerability management, IR, privacy engineering, and quality trade-off analysis. The skill is knowing which framework applies to which problem at which moment.
- Healthcare environments introduce patient safety as a risk dimension that does not exist in purely financial systems. Security failures in medical device telemetry can have direct clinical consequences; this must be reflected in threat model severity rankings.
- Regulatory obligations (UK GDPR 72-hour breach notification, NHS DSPT compliance) impose process requirements on top of technical controls. A technically secure system that cannot produce evidence of compliance still fails regulatory requirements.
- Security debt accumulates fastest in organisations that have grown without formal security programmes. Prioritise controls providing the broadest foundational coverage first (SIEM, IR plan, patch management) before pursuing advanced controls.
- The NIST CSF 2.0 Govern function recognises that security is a governance and quality concern. The board-level framing of security posture must translate technical gaps into business risk terms to enable resource allocation decisions.
You have completed the full cybersecurity course. From the NCSC definition in Module 1 through enterprise-scale incident response in this capstone, you have covered 25 modules spanning foundations, applied techniques, and professional practice. The knowledge maps directly to the NIST CSF 2.0, CompTIA Security+ SY0-701, and ISO/IEC 27001:2022 frameworks. Return to the course overview to review your progress or take the final assessment.
Standards and sources cited in this module
NIST SP 800-207, Zero Trust Architecture
Section 2: Zero Trust Architecture principles. Section 3: Policy Engine, Policy Administrator, Policy Enforcement Point logical components.
NIST SP 800-218: Secure Software Development Framework (SSDF)
Section 2: Practice groups PO (Prepare the Organisation), PW (Produce Well-Secured Software), and RV (Respond to Vulnerabilities).
Article 32: Security of processing (appropriate technical measures). Article 33: 72-hour breach notification obligation to the ICO.
Six functions including the new Govern (GV) function. Full framework for organisation-level security posture assessment.
CISA Zero Trust Maturity Model v2.0 (2023)
Covers Identity, Devices, Networks, Applications & Workloads, and Data across four maturity stages. Used in this capstone to assess MedCore's current and target state.