CyberShield Tender CA18158

1.1 Project CyberShield CA18158

CyberShield Security Limited and DataFlow Dynamics have formed a Joint Venture (the “JV”) to respond to Tender CA18158 issued by the UK Government for the delivery of a secure, zero-trust data pipeline for NHS healthcare infrastructure. The project addresses the growing need for protected health information (PHI) processing across trust boundaries, enabling secure analytics, audit, and interoperability between NHS Digital systems and partner organisations.

The JV combines CyberShield’s deep expertise in government-grade security architecture, threat intelligence, and NCSC compliance with DataFlow’s proven track record in NHS data engineering, FHIR/HL7 integration, and the NHS Data Security and Protection Toolkit (DSPT). Together, the partnership delivers a complete, auditable, and resilient data pipeline designed to protect the most sensitive patient information while enabling life-saving clinical analytics.

1.2 Joint Venture Structure

1.3 Scope & Objectives

The JV will deliver the following scope items under Tender CA18158:

• End-to-end encrypted data pipeline from NHS source systems to authorised consumers, processing up to 10 TB/day of structured and unstructured PHI across 47 NHS trusts.
• Zero-trust architecture with no implicit trust between any network segments, enforcing cryptographic identity at every hop via SPIFFE-issued short-lived certificates.
• Full compliance with NHS Data Security and Protection Toolkit (all 10 standards), UK GDPR Article 9 (special category data), and all 10 NCSC Cloud Security Principles.
• Immutable audit trail with cryptographic chaining (SHA-256 hash-linked blocks), meeting NHS Records Management Code of Practice 2024 for minimum 7-year retention.
• Multi-region active/standby deployment (London + Dublin) with synchronous replication, RPO=0, RTO=60 seconds, and quarterly full disaster recovery testing.

1.4 Key Milestones

1.5 Healthcare Security Context

The UK healthcare sector faces an evolving threat landscape. Between 2020 and 2026, NHS organisations reported over 4,000 cybersecurity incidents, with ransomware attacks causing significant patient care disruption. The JV architecture addresses this context directly.

2.1 Trust Zones & Segmentation

Four-zone network segmentation with strict east-west traffic controls. Each zone enforces its own authentication boundary and data handling policy.

2.2 Authentication & Authorisation

• Service Identity - SPIFFE (Secure Production Identity Framework for Everyone) issues X.509 short-lived certificates to every service instance via the internal SPIRE server. Certificate validity: 6 hours. Automatic rotation.
• Human Identity - NHS federated login via OpenID Connect with multi-factor authentication. Session tokens expire after 15 minutes of inactivity.
• Authorisation - Attribute-based access control (ABAC) evaluated at every request. Attributes include: user role, data sensitivity label, purpose of processing (from approved register), time window, and device posture.
• Just-In-Time Access - Privileged access requests are approved via an automated workflow, granting time-bound, purpose-limited credentials that self-revoke. Audit-logged and dual-authorised for sensitive operations.

2.3 Encryption Standards

2.4 Monitoring & Observability

• SIEM Integration - All pipeline logs (ingestion, transformation, access, auth decisions, errors) stream to a central Splunk/SOAR instance with 1-year hot retention.
• Behavioural Analytics - User and entity behaviour analytics (UEBA) models establish baselines for data access patterns and trigger alerts on anomalous activity.
• Automated Response - SOAR playbooks automatically quarantine compromised credentials, isolate affected pipeline segments, and page the on-call security engineer.
• Availability Monitoring - Synthetic health checks every 30s across all pipeline stages. SLA alerting at 99.99% uptime per calendar month.

2.5 NHS Data Security & Protection Toolkit (DSPT)

2.6 UK GDPR Compliance

2.7 NCSC Cloud Security Principles

3.1 Network Topology

Multi-zone network segmentation with strict east-west traffic controls across four security zones. Each zone enforces its own authentication and data handling policy.

Figure 3.1: Four-zone network topology. Arrows indicate approved data flow paths. All inter-zone communication passes through an application-layer gateway with full inspection. East-west traffic within zones is also encrypted.

3.2 Data Flow Diagram

End-to-end data flow from NHS source to authorised consumer, showing encryption boundaries and audit checkpoints.

Figure 3.2: End-to-end data flow. Every record is validated, pseudonymised, and encrypted before storage. The continuous audit log records all operations with cryptographic chaining.

3.3 Component Interaction Diagram

Service-to-service interactions showing authentication, data exchange, and dependency relationships across the pipeline.

Figure 3.3: Component interaction. The auth service mediates all inter-service communication via SPIFFE-issued identities. Every data access is logged by the audit service before reaching storage.

3.4 Deployment Model

The JV pipeline is deployed across two UK-region availability zones with hot-hot failover. RPO: 0 (synchronous), RTO: 60 seconds.

Figure 3.4: Multi-region deployment. Synchronous replication for data durability; failover in under 60 seconds. All cross-region traffic is encrypted.

3.5 STRIDE Threat Model for Government Infrastructure

This threat model follows the STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) applied to each component of the CyberShield CA18158 pipeline.

4.1 Data Ingestion

• Sources - NHS Spine, GP Connect, Summary Care Record, and partner HL7 FHIR endpoints. All sources authenticate via NHS federation or client certificates.
• Protocols - HTTPS with mutual TLS (mTLS 1.3) for REST; AMQP 1.0 with TLS for streaming; SFTP for batch imports (deprecated by Q3 2026).
• Validation - Schema validation against published NHS FHIR profiles. Malformed records are quarantined for manual review, never processed.
• Data Minimisation - Ingestion filters strip fields not required for the declared processing purpose. A purpose register defines permitted field sets.

4.2 Processing & Pseudonymisation

• Pseudonymisation - All direct identifiers (NHS number, name, address, DOB) are replaced with pseudonym tokens using a deterministic HMAC-SHA256 with a rotating salt. The salt is stored in the HSM, separate from the data.
• Transform Environment - Processing occurs in memory within the Trusted App Zone (Zone 2). No intermediate results are written to disk unencrypted. Ephemeral scratch space uses encrypted RAM-backed volumes.
• Error Handling - Processing failures enter a dead-letter queue with full payload and metadata. DLQ access requires dual-authorisation (data engineer + security officer).

4.3 Storage & Retention Policy

Retention periods align with the NHS Records Management Code of Practice 2024. Legal holds override automatic deletion. Cryptographic erasure renders data unrecoverable by deleting the wrapping key.

4.4 Access Control Policy

• RBAC Foundation - Roles: Data Steward, Data Analyst, Security Officer, Auditor, System Administrator. Each role has a defined permission set aligned to the principle of least privilege.
• ABAC Overlay - Access decisions also consider: data sensitivity label (PATIENT-IDENTIFIABLE, PSEUDONYMISED, ANONYMISED), purpose of processing (DIRECT-CARE, RESEARCH, AUDIT), time of day, and workstation compliance status.
• Purpose Register - Every access request must declare a purpose from the approved register. Purposes are reviewed quarterly by the Data Protection Officer. Unregistered purposes are denied by default.
• Emergency Access - Break-glass mechanism for clinical safety. Activates a pre-configured emergency role with full audit trail. Dual notification to Security Officer and Data Controller within 15 minutes.

4.5 Audit Trail & Logging

• Scope - Every data access (read, write, update, delete), authentication event, authorisation decision, configuration change, and system error. Captures: timestamp, user/service identity, action, resource, outcome, purpose code.
• Immutability - Audit records are written to an append-only store with cryptographic hash chaining. Each block references the SHA-256 hash of the previous block. Tampering is detectable by recomputing the chain.
• Retention - Minimum 7 years, permanent for security incidents and legal holds. Indexed for query by the Auditor role only.
• Review Cycle - Automated anomaly detection triggers daily reviews. Manual spot-check by the Security Officer: weekly. Full audit log review: quarterly.

4.6 Breach Notification Process

The JV maintains a documented incident response plan aligned with the NCSC Cyber Incident Response framework and UK GDPR Article 33 requirements:

4.7 Encryption Key Lifecycle Management

• Key Generation - All keys generated inside FIPS 140-2 Level 3 HSM. Master keys never leave the HSM in plaintext. Wrapping keys encrypted under HSM identity.
• Key Rotation - Data encryption keys (DEKs) rotated every 90 days. Key encryption keys (KEKs) rotated annually. Automated via KMS with no service downtime.
• Key Destruction - On key deletion, HSM performs a secure zeroisation. Backups of key material encrypted under a separate escrow key stored in a tamper-evident container.
• Audit - All key lifecycle events (generation, rotation, destruction, access) logged to the immutable audit trail. Key access requires dual-authorisation and is limited to the Key Manager role.

4.8 Technical Controls Summary