Date: 2023-04-04

Status

Accepted

Context

Our system will process confidential patient information - this information is incredibly important to the patients who it is about and, as the custodians of this information during processing, we need to take measures to keep it confidential. This means ensuring our technology, people and processes are secure.

To ensure the data we are processing is secure, we need to have the system penetration tested up to CHECK standards. This fact is relied upon in several other key pieces of assurance for the project: namely the clinical safety assurance (DCB0129) and information governance (DPIA and others).

Setting a security policy will ensure we have clearly stated the principles we will be adhering to in order to keep the system secure. We can check our final product and policies against the security policy, and if the principles in the security policy are met we can be better assured of the security of our system.

Decision

We will adopt the below high-level security policy covering both systems and people:

  • Principle of least priviledge - automated systems and real users will only be given the ability to access, and perform the most restrictive set of actions on, the smallest possible set of assets to carry out their role.
  • Need to know access - only those with a genuine need to access the information should be provided with access to it. Where this access is to identify and fix system issues, the number of people with this level of access should be limited.
  • Defence in depth - we will employ multiple layers of security throughout the system, so that in the event that one is compromised, there is adequate redundancy and the system remains secure.
  • Zero trust - work on an assumption that the system has been compromised and seek to reduce the possible blast radius (through e.g. encryption, etc)
  • Track and audit - make sure that any actions taken are auditable, so that in the event of a breach or incident, they can be investigated and dealt with quickly.

Consequences

Each of these principles will have a specific implementation, starting with the below:

  • Infrastructure (AWS Account)
    • Personnel
      • User access to live application should be limited to BPSS cleared, UK-based staff only
    • Service Users
      • Service users for build and deploy (CodePipeline / CodeBuild) and operations (e.g. Lambda) should have minimum possible IAMs priviledges
  • Management Interface (Django, on ECS)
    • Container
      • Expose only port 80 access on container
      • Hide Django behind both Gunicorn and Nginx
    • Network
      • Only expose access to internet via public application load balancer to /admin
      • Allow-list IP addresses that can access /admin
      • Only expose access to serverless application via VPC-only application load balancer for /care-provider-location
      • Do not expose VPC-only application load balancer to the internet, instead provide access to the Serverless API via network configuration (subnets and security groups) at a VPC-level
    • Application
      • Authenticate user access via SSO using The PSC logins or NHS Mail (Cognito)
    • Personnel
      • User access to live application should be limited to BPSS cleared, UK-based staff only
  • Serverless API (SAM)
    • Network
      • Only expose access to internet via API gateway to /message/hl7v2
      • Internet access to /message/hl7v2 should be via Mutual TLS (using AWS as the certificate manager for this)
      • Only expose access to management interface via API gateway (within the VPC) for /subscription