Guidance on public cloud connectivity to HSCN

The UK Government introduced a ‘cloud first’ policy for public sector IT in 2013. The use of cloud services was also endorsed in the National Information Board’s Personalised Health and Care 2020 framework, published in November 2014.

Services and systems are being developed and deployed into Public Cloud infrastructure to enable organisations to take advantage of the benefits that the Public Cloud can provide. (for example cost savings, scalability, reliability).

These guidelines define how Public Cloud provisioned services should be accessed by HSCN connected organisations and consumers, and how those Public Cloud services interact with other services currently provisioned on HSCN.

HSCN was intentionally designed as a hybrid network to support both private and public connectivity. HSCN consumers typically purchase their, internet, Cloud and wide area connectivity from a single Consumer Network Service Provider (CNSP), moving away from historic approaches of multiple services from multiple providers. 

NHS Digital strongly recommend that organisations have a clear cloud strategy defined before designing their network connectivity. This is to ensure this can be implemented correctly and allows for scale to accommodate cloud transformation and other future demands placed on the network.

This guidance advises on the policies and procedures that should be adhered to when connecting Public Cloud infrastructure-based services to HSCN.

The intended audience is

• HSCN Consumer Network Service Providers (CNSPs)
• Cloud Service providers (CSPs)
• IT Service Providers (ITSPs), and
• HSCN Consumers- End users wishing to interact or provision a service for HSCN/NHS Users/Services from the Public Cloud

NHS Digital recommends reading this guidance alongside the existing published and maintained policies and procedures that should be adhered to for accessing HSCN and NHS data.  These are detailed below and depend upon the role of the organisation in the provisioning of the defined use cases.

We have defined five roles in relation to the provisioning of public cloud access to health and social care organisations on HSCN.

NHS Digital have defined five roles in relation to the provisioning of Public Cloud access to Health and Social Care organisations on HSCN.

An IT service provider (ITSP) - The organisation provisioning the public cloud-based service.

A CSP - Cloud Service Provider (CSP) as defined in HSCN CSP policy. 

A CNSP - Consumer Network Service Provider

An HSCN consumer - End users wishing to interact or provision a service for HSCN/NHS Users/Services from the Public Cloud

Public cloud provider - Such as AWS, Azure, GCP 

We have set out guidance on the standards/policies/obligations within this document that each role will agree to abide by.

In addition to these roles the data controller and data processor roles have General Data Protection Regulations (GDPR) responsibilities. 

Data controller

A data controller is: “a natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of processing of personal data.”

Data processor 

A data processor, processes personal data on behalf of the controller.

Any organisation which uses a cloud provider (a processor) retains overall responsibility for legal compliance (for personal data) including adequate security.  

There are some responsibilities under GDPR that fall direct to the processor e.g. fails to meet its obligations, or acts outside or against the controller’s instructions, then it will be liable to pay damages in legal proceedings or be subject to fines or other penalties.

Therefore, organisations should not just rely on the cloud provider’s advice or security arrangements, as that may leave the organisation with the risks. We recommend that an organisation assigns the responsibilities (where appropriate) to the cloud provider in the contract and transfers the risk from the controller to the processor.

The Information Commissioner's Office (ICO) is the UK regulator for data protection.  It is the ICO’s intention to update the Data Protection Act 1998 guidance to explain the requirements of the GDPR, but in the meantime the general principles still apply. 

In setting out this guidance, NHS Digital has made the following assumptions: 

• all access connectivity to HSCN is protected by appropriate firewall implementation
• HSCN Consumers have implemented suitable perimeter controls including firewall provision as required as part of their HSCN Connection Agreement.  (This may be included as a managed service within their HSCN access connectivity service)
• Guidance on selecting an appropriate firewall, and applying suitable perimeter security includes:
  • NHS Digital - Boundary Protection – Good Practice Guide
  • NHS Digital - guidance on Perimeter security for CCG’s and Gp’s:
  • NHS England - General Practice IT Infrastructure Specification document,
  • NHS Digital - Firewalls - security assurance accreditation and certification standards
  • National Cyber Security Centre (NCSC) - guidance for securing data networks,
  • National Cyber Security Centre (NCSC) - 10 Steps to Network Security
  • CareCERT: Firewall Good practice Guide:  
  • NIST – Guidance on Firewalls and Firewall Policy
• CNSPs protect HSCN by implementing their own perimeter security between the HSCN connectivity services they provide and any Public Cloud provider(s) or approved external networks. Is specified in the Health and social care cloud security – good practice guide. 
• each individual service provided by the ITSP are logically separated so that individual service's traffic can be identified.
• controls have been implemented by the ITSP and the CSP/CNSP to ensure appropriate controls are in place to stop Cloud access being used to allow inbound internet traffic onto HSCN
• IP addresses in use have been obtained from NHS Digital via the HSCN IP address management process and are registered with the consuming organisation
• CSPs, and where appropriate CNSPs, manage access to the dedicated network links into the cloud services. This includes logging, blocking, filtering and Access Controls List (ACL) capabilities in conjunction with already specified obligations.  
• it should not be assumed that all HSCN connected users have internet access provided by their CNSP 
• the Security Operations Centre (SOC) will review NAS reports and IPFix data, to identify any IP addresses which aren’t registered within NHS Digital's IP Address Management (IPAM) records will be tracked down and the appropriate CNSPs will be contacted to identify owners and ensure all IP addresses are registered appropriately

The NHS Internet First policy sets out the vision to make digital service available over the internet instead of over private networks.  The Internet First policy and guidance provides industry best practice, standards and guidelines for creating services provisioned to the internet. 

“The Government Digital Services Technology Leaders Network reviewed the positioning of centralised private networks in January 2017 and confirmed that, for the vast majority of public services, the internet is OK. They say that new services should be made available on the internet, secured appropriately using the best available standards-based approaches. When we are updating or changing services, we should take the opportunity to move them to the internet. The Government Transformation Strategy February 2017 extended the digital agenda from the citizen to maximising the benefit of collaboration and flexibility across departments and government bodies. “

Solutions available to meet the capabilities described in this document adopt and utilise the following standards within any implementation.

NCSC standards: Encryption using IPsec, Prime and foundation profiles:

NCSC Standards: TLS to protect data

HSCN VPN services:

• NCSC Standards using IPsec to protect data 
• NCSC Standards provisioning and securing security certificates 
• NCSC Standards: Introducing new guidance on Virtual Private Networks (VPNs)
• NCSC Standards: NCSC IT: Networking in the cloud 

Any existing transport encryption and/or security requirements for existing services will be maintained for any traffic on HSCN.  These policies and guidance do not impact or change the security requirements of those services.

Four cloud connectivity use cases have been identified:

1. Outbound access from end user or system to a cloud-based service (over the internet)
2. Outbound access from end user or system to a cloud-based service (over HSCN)
3. Inbound access from system to an organisation over the internet (locally implemented internet provision)
4. Inbound access from Public-Cloud based systems to HSCN connected end users or systems

Different obligations and agreements apply for each of these use-cases, depending upon the role taken within the service provision.

In this use case the public cloud service is internet facing and the consumer accesses the service via the public internet, either via an immediate break-out from the consumers local site to the internet, or via internet access procured from their chosen CNSP and routed through the HSCN NHS Secure Boundary service.

Typically, this design does not use Direct Connect, ExpressRoute, Google Cloud Interconnect or similar infrastructure.

Points of control and their ownership are shown in numbered black squares in the diagram are: 

1. Consuming organisations' perimeter – Consumers responsibility
2. CNSPs connection to NHS Secure Boundary – CNSPs responsibility
3. NHS Secure Boundary – NHS Digital Data Security Centre (DSC) responsibility
4. The internet gateway configured in the public cloud provider's environment – service providers responsibility.

Examples include:

• accessing a national internet facing “directory of services” service
• Virtual Private Network (VPN) between cloud provider and organisation. 

Traffic destined for this Cloud provisioned service is directed via this CN-SP to the cloud environments. If consuming organisations aren't on the same CN-SP, then their traffic would be routed via their CN-SP, through the Peering Network (PN) and onto the connected CN-SP.

In this situation, the traffic isn't routed to the internet to get to the cloud providers and so traffic isn't routed via the NHS Secure Boundary service but is instead routed to the organisations' environment in the public cloud. The diagram shows the points of control being:  The consuming organisations' perimeter.  The CN-SP’s connection to the public cloud providers dedicated connectivity infrastructure and the gateway configured in the public cloud providers environment. 

In this use case the public cloud service is directly connected to HSCN via a cloud service provider/CN-SP.

The consumer (ORG B) accesses the Public Cloud service via HSCN and traffic will traverse the consumers CNSP (CN-SP-N), the HSCN PN (Peering Network) and the CNSP used to provide HSCN connectivity to the service (CN-SP-1).

This use case demonstrates a connection to external systems initiated from within HSCN.  Typically, this design uses Direct Connect, ExpressRoute, Google cloud Interconnect or similar infrastructure.

The points of control within the above diagram are:

1. Consuming organisations' perimeter – consumers responsibility
2. CNSPs connection between itself and cloud providers – CN-SPs responsibility
3. The internet gateway configured in the public cloud providers environment – IT service providers responsibility.

Use case 2 requires adherence to Obligation S08 and pre-approval by NHS Digital (DSC) Data Security Centre. 

To do this, please raise a call with the NHS National Service Desk by email at [email protected], or by telephone on 0300 303 5035. Calls should be raised with the HSCN service, defined that this is regarding Security Obligation S08 and marked for attention of the HSCN Compliance.

Examples include

• accessing eRS (both over HSCN and internet facing)
• accessing a regional service from organisations connected to different CN-SP’s. In the example shown Organisation B (yellow) doesn’t use any capacity of Organisations A’s (red) HSCN connection. They share the usage of the cloud connectivity service provided by a CN-SP for that regional service. Consideration for the distribution of your client’s access is key to delivering a successful network design.

In this situation, the connectivity isn't provisioned using HSCN infrastructure and is delivered locally to the customer site. The diagram shows the points of control being: The consuming organisations' perimeter and the gateway configured in the public cloud providers environment.

This use case represents locally implemented cloud connectivity where traffic is not routed over HSCN but is being kept locally to that organisations network. This could also include any locally provisioned cloud connectivity services (such as ExressRoute/Direct Connect, Google cloud Interconnect)

The points of control within this diagram are:

1. Organisation A perimeter – customers responsibility
2. The internet gateway configured in the public cloud providers environment – service providers responsibility.

Examples include:

• Hybrid Private cloud deployments
• Azure Application Peering over ExpressRoute (Office 365 etc). 

A similar implementation pattern exists where traffic is routed over the connecting organisations HSCN access circuits, but access is limited to only users/endpoints within that organisations network and the traffic isn’t exposed to any other HSCN consumers.  

The points of control within this diagram are:

1. Organisation A's perimeter - customers responsibility
2. The internet gateway configured in the Public Cloud providers environment – Service providers responsibility. Onwards control of access to ensure only via the connecting
3. CNSP’s connection between itself and the cloud providers – CNSP’s responsibility, with onwards control of access to ensure only accessible via the connecting organisation.

In this situation, the connectivity is using HSCN to get to the end points on the same or other CNSP's. If traffic needs to be routed to another CNSP to get to a specific HSCN endpoint, this will be achieved via the Peering network (PN). In this situation, the traffic is initiated in the Public cloud providers environment and is therefore inbound onto HSCN.  

The diagram shows the points of control being: The Consuming organisation’s perimeter; the CNSP’s connection to the public cloud providers dedicated connectivity infrastructure, and the gateway configured in the Public Cloud providers environment. 

In this use case the public cloud service is directly connected to HSCN via a Cloud Service Provider or CNSP. Service providers or consumers have access via this dedicated connection, and traffic traverses the consumers CNSP, HSCN Peering Network (if applicable), and the CNSP used to provide HSCN connectivity to the service. 

Examples include suppliers connecting to a system/source/endpoint and the interactions are initiated externally to HSCN (for example, within the Public Cloud environment). Typically, this design will use Direct Connect, ExpressRoute, Google cloud Interconnect or similar infrastructure.

This would potentially allow inbound internet access and would require adherence to the SO10 and SO10a obligations.

The points of control within this diagram are:

1. Organisation A perimeter – customers responsibility
2. Consumer Network Service Provider (CNSP’s) connection between itself and the cloud providers. – CNSPs responsibility. Onwards control of access to other endpoints (through peering to other CNSP customers)
3. The internet gateway configured in the public cloud providers environment – service providers responsibility.

This use case requires adherence to obligations S08 pre-approval by NHS Digital Data Security Centre (DSC).

This use case also requires providers and CN-SPs to adhere to the SO10 and SO10a obligations. To do this, please raise a call with the HSCN Compliance Team by email at [email protected]. Calls should be raised with the HSCN service, and identified as regarding Security Obligations SO8 and SO10/SO10a.

Examples include: regional service accessing systems or data from organisations connected to different CNSPs. In the example shown Organisation B (yellow) doesn’t use any capacity of Organisations A’s (red) HSCN connection. They share usage of the cloud connectivity service provided by a CNSP for that regional service.  Consideration for the distribution of your client’s access is key to delivering a successful network design.

These policies, guidelines and standards are defined by a number of different aspects:

• use cases approval
• IP Addressing
• roles and responsibilities.
• Public Cloud architecture design
• Data Security Protection Toolkit
• HSCN Connection Agreement
• HSCN Obligations Framework
• Health and Social Care cloud security good practice guide
• Inbound internet Connectivity Risk Mitigation for CNSPs and HSCN consumers
• Cloud service provider policy. 

Use case approval

Each of the use cases we have provided have been broken down into the table below.  

Use case 1 and use case 3 are approved use cases subject to addressing isolation requirements. The roles defined each have different responsibilities regarding the provision of those types of service.

Use case 2 requires compliance with S08 and explicit approval for the routing of traffic.

Use case 4 also requires compliance with S08 and explicit approval for the routing of traffic, and, in addition, it requires compliance with SO10 and SO10a which relate to Inbound internet

Obligations SO10 and SO10a have specific guidance available read the Inbound internet connectivity guidelines for CNSPs and consumers.  

For adherence to obligation SO8, pre-approval by the NHS Digital Data Security Centre is required.

To do this, please raise a call with the NHS National Service Desk by emailing the NHS national service desk  or by telephone on 0300 303 5035.  Call should be raised with the HSCN service, defined that this is regarding Security Obligation S08/SO10/10a and marked for attention of the data security centre.

IP addressing  

The very nature of public cloud services is that anyone can use them, including malicious actors who may use a public cloud service to initiate attacks and host or deliver malicious content. To mitigate the risk of malicious services hosted in public cloud, any public cloud service should always use addresses outside of the cloud providers public block. It is therefore required that when connecting a public cloud provisioned service to HSCN, this must be using HSCN approved addresses. Each service should have its own HSCN approved address so that isolation is maintainable between those services.

In the event of a malicious attack from a public cloud service the HSCN authority may be required to block the IP addresses where malicious traffic is originating from. Any service that uses public cloud addressing instead of HSCN approved addressing must ensure they mitigate the risks/ hazards associated with having their service blocked.

IP addresses need to be obtained from NHS Digital via the HSCN IP address management process and then be registered with the consuming organisation. 

It is the CNSPs responsibility to ensure that all IP addresses allocated to Inbound Cloud connections are registered on the NHS Digital IPAM (HSCN IP address management).

Roles and responsibilities 

We have provided a simple matrix of the associated standards and agreements and which roles are obliged to comply with which standards/agreements/policies/principles.

Public cloud architecture design

Services in the Public Cloud should be designed in line with NCSC Cloud Security Principles and Center for Internet Security (CIS) critical security controls.

• NCSC Cloud Security Collection (includes separation, cloud security, IaaS managing responsibilities etc.)
• NCSC  Implementing Cloud security principles
• CIS Critical Security Controls. 

To support this some top tier cloud providers have created a template for deploying a solution in line with the NCSC and CIS and on how to deploy and secure dedicated network links.

• Amazon have setup templates for standardized AWS Cloud environments that support workloads classified to “OFFICIAL”
• Microsoft have setup Azure security and compliance UK NHS Blueprint

Both the AWS and Azure architectures provide a responsibility matrix for the above security controls. Other suppliers may also have produced similar materials and guidance

• AWS  

• Azure

The hosting policy sets out which locations are acceptable for hosting specific data types. If you are responsible for multi-region deployments, you should consider how Direct Connect/ExpressRoute/Google cloud Interconnect (or similar infrastructure) deployments can maintain service connectivity and resilience/availability.

Guidance includes: (others are available)

AWS direct connect resiliency recommendations

Microsoft ExpressRoute overview

Cloud dedicated interconnect overview.  

The Data Security Protection Toolkit (DSPT) has replaced the Information Governance Toolkit (IGT). All organisations that have access to NHS patient data and systems must use this toolkit to provide assurance that they are practicing good data security and that personal information is handled correctly.

All mandatory assertions must be completed within the DSPT.

Every organisation that wishes to use HSCN must complete a Connection Agreement. By "use HSCN", we mean 'send or receive data across HSCN'. CNSPs shall ensure every organisation that wishes to use HSCN must complete a HSCN Connection Agreement.

Three distinct HSCN Connection Agreements are available.

• standard Consumer Connection Agreement
• organisations representing other Organisations (such as CCGs) Connection Agreement
• IT Service provider (ITSP) Connection Agreement

A standard end user/consumer of HSCN services is required to sign a HSCN standard Consumer Connection Agreement.

A service provider (such as an application/Service or IaaS/PaaS service) is required to sign an ITSP Connection Agreement and is responsible for users/consumers of their service signing a standard Consumer Connection Agreement.

The organisation must confirm that you agree with the “Acceptable Use” statement and specify, at a high level, what sorts of services your organisation offers. Depending on the information which you submit you will either be automatically approved or your application to sign an HSCN Connection Agreement (and thereby gain access to HSCN) will be paused pending manual approval by the HSCN Authority. 

The HSCN Obligations Framework describes the obligations that HSCN Suppliers shall adhere to for the supply, delivery and operation of HSCN Connectivity Services to HSCN Consumers:

Aspects of the Obligations Framework applicable to this policy are:

• SO10 and SO10a are applicable to Inbound internet access, and guidance is available on inbound internet connectivity.  Use cases 2 and 4 will require adherence to SO10 and So10a
• S08 requires specific approval to connect to external networks. A Consumers or ITSPs VPC or cloud environment is classed as an external network.  

Use cases 2 and 4 require adherence to obligations S08 /S010 /SO10a.

Obligations SO10 and SO10a have a specific guide available, listed in the section below.     

For adherence to Obligation S08, pre-approval by NHS Digital Data Security Centre is required. To do this, please raise a call with the NHS National Service Desk by email at [email protected], or by telephone on 0300 303 5035.  Call should be raised with the HSCN service, defined that this is regarding Security Obligation S08 / SO10/10a and marked for attention of the Data Security Centre.

CNSPs shall ensure all Inbound Cloud connections are recorded in the HSCN Estate Data in accordance with HSCN CNSP Service Provider Management Requirement Addendum.

CNSPs shall generate network monitoring data for all inbound cloud connections in accordance with HSCN obligation SO1: Network Analysis.

CNSPs shall record the following information for each inbound connection:

• HSCN Consumer Organisation’s details
• External Service Provider / Customer details
• Source IP address(s), ports and protocols application or service details

CNSPs shall provide NHS Digital’s Data Security Centre (DSC) the aforementioned information upon request.   

The Health and Social Care Network (HSCN) Obligations Framework includes, where requested, the facility for consumers to receive service connections initiated from the internet. For example, if a consumer organisation is to receive application support remotely from an external service provider, via the internet, then they can request that their Consumer Network Service Provider (CNSP) facilitates the inbound internet connection:

HSCN Obligation SO10: “HSCN Suppliers shall provide access to HSCN consumer's business application services or other services (e.g. websites) from the internet - on request from the HSCN Consumer and after verifying that the HSCN Consumer has completed an HSCN Connection Agreement that includes their provision of external services.”

HSCN Obligation SO10a: “HSCN Suppliers shall ensure that attacks on the internet IP addresses of HSCN consumer business application services (or other services) available through the internet gateway do not disrupt the provision of outbound internet services across the internet gateway or the availability of the wider HSCN service.”

Further Cloud specific documentation may become available in the future. For example, guidance on implementing Microsoft Application Peering and Office 365.