Principle: B4 System security

Overview

To achieve this outcome, you need to demonstrate that your system design has been constructed through a secure by design approach, lowering the chance of compromise and enabling more efficient recovery.

Please note that this outcome is focussed on cyber security ‘secure by design’ controls. For information governance (IG) controls required for ‘data protection by design and by default’, please see ‘A2.a Risk management process’.

Mapping to the 23-24 DSPT framework

Under the previous 23-24 Data Security and Protection Toolkit (DSPT) framework, your organisation was required to perform activities that help meet the expectations of this contributing outcome.

For more detail on what these activities were, see the mapping exercise published by NHS England and Department of Health and Social Care (DHSC).

Designing network and information systems

You must take a secure by design approach to ensure that effective cyber security practices are incorporated into your system design, including systems procured from third parties. This means having informed experts in your organisation who can make judgments on the way networks and systems are constructed that make your essential service less vulnerable to compromise and easier to recover in the event of an incident.

Boundary defences

To design strong boundary defences, you need to identify all the points in your network and systems which external and internal organisations and actors can connect to. 

For each point of connection, you should have a technical solution in place (such as a firewall, authentication protocol, intrusion detection or prevention system) which blocks unapproved connections, manages access and validates message format and content.

Data flows

Where you have data flows going between your organisation and external networks, for example when working with a third-party supplier who processes or stores data on your behalf for the provision of services, the data flows should be encrypted end-to-end to ensure the confidentiality of the data. 

Simple validation and authentication measures should be implemented for all your data flows to ensure the integrity of the data being transferred. 

Designing for system recovery

To show that you have designed for system recovery, you should evidence that you have made deliberate design decisions whilst building your network to simplify recovery processes.

These might include consideration of:

• device naming conventions
• network addressing schemes and registers
• standard builds 
• automated deployment
• network segmentation
• configuration management automation
• infrastructure as code

You should be able to rationalise how these build decisions have contributed towards recovery of your systems from potential incidents being simpler, faster or less resource-intensive.

Content-based attacks

To protect against content-based attacks, you should implement solutions at your network boundaries which analyse incoming data and transform, block or filter out harmful content. See NCSC guidance on content based attack protection for more information.

Supporting evidence

To support your response, you can review and upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• Network architecture documentation. 
• Evidence of deliberate design choices to make the network less vulnerable to compromise and easier to recover. 
• Evidence of boundary defences in place. 
• Data flow mapping. 
• Sample of monitoring report or dashboards. 
• Evidence of deliberate design choices to simplify recovery process. 
• Evidence of automatic checking and validation of all inputs to important networks and information systems. 
• Evidence of monitoring in place for content-based attacks. 
• Security zone risk analysis. 
• Evidence of technical and physical solutions being applied proportionately to zone security levels. 
• Evidence of boundary protection solutions being applied proportionately to data flow sources. 
• Evidence of controls for mitigating content-based attacks. 

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Interpreting indicators of good practice

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | B4 System security
National Cyber Security Centre | Secure design principles
NHS England | Network segmentation - An introduction for health and care organisations
NHS England | Network segmentation for connected medical devices
NHS England | Backups and Office 365
NHS England | Public key infrastructure documentation
NHS England | Public key infrastructure root certification authority information
NHS England | Secure boundary service
NHS England | Vulnerability monitoring service
NHS England | Cyber assurance service
NHS England | Bitsight cyber security ratings service

Mapping to other cyber frameworks

NHS England and DHSC have produced a mapping document showing where the requirements of the CAF-aligned DSPT overlap with those of other cyber frameworks. New frameworks will be added to this document over the course of the year. 

Overview

This outcome is about the way you configure devices across your estate to guard against a variety of threats.

Mapping to the 23-24 DSPT framework

Under the previous 23-24 Data Security and Protection Toolkit (DSPT) framework, your organisation was required to perform activities that help meet the expectations of this contributing outcome.

For more detail on what these activities were, see the mapping exercise published by NHS England and Department of Health and Social Care (DHSC).

Configuring assets

Assets which need to be carefully configured to maintain the security of your essential functions should be identified in the documentation you use to catalogue your assets (see ‘A3.a Asset management’). This includes network devices such as switches, firewalls and virtual private network (VPN) software.

You should be able to rationalise the way these assets have been configured to reduce the possibility of compromise.

Secure platform and device builds

You should use a collection of base images which are appropriate for your environment to build your end user devices. 

Unnecessary services and connectivity should be disabled. 

Changes to security configurations

All changes to security configurations should be approved and documented. It will help further down the line to have clear context and a rationalisation for why each change decision was made.

Verifying software

You should implement technical controls on your devices which control the software that can be installed. For example: 

• deploying application allow listing technology 
• restricting local administrative access rights

See NCSC’s guidance on device security for more information.

Supporting evidence

To support your response, you can review and upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• Documented configuration profiles for assets supporting the operation of essential functions. 
• Evidence of operating environment being considered for configurations. 
• Baseline builds for different devices. 
• Procedures for approving and documenting changes to security configurations. 
• Procedures for assessing the security of a software before deployment. 
• Evidence of generic, shared, default name and built-in accounts being removed, disabled, password changed or robustly restricted through technical controls. 
• Procedures for reviewing and updating configurations profiles based on changes in the environment. 
• Procedures to applying latest configurations to assets. 
• Evidence that configurations are applied to all assets, and configuration statuses tracked. 
• Evidence of baseline builds being correctly applied to all devices. 
• Procedures for validating application of configurations settings to devices. 
• Software allow list. 
• Evidence of security impacting settings changes being identified and controls implemented to prevent standard user access. 
• Evidence of any automated decision-making technologies in use being understood and their decisions replicated. 

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Interpreting indicators of good practice

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | B4 System security
National Cyber Security Centre | Device security guidance
Centre for Internet Security | CIS Benchmarks - prescriptive configuration recommendations
NHS England | Network segmentation for connected medical devices
NHS England | Backups and Office 365
NHS England | Public key infrastructure documentation
NHS England | Public key infrastructure root certification authority information
NHS England | Secure boundary service
NHS England | Vulnerability monitoring service
NHS England | Cyber assurance service
NHS England | Bitsight cyber security ratings service

Mapping to other cyber frameworks

NHS England and DHSC have produced a mapping document showing where the requirements of the CAF-aligned DSPT overlap with those of other cyber frameworks. New frameworks will be added to this document over the course of the year.

Overview

This outcome relates to you having a robust system management practices which combine technical, procedural and physical measures.

Mapping to the 23-24 DSPT framework

Under the previous 23-24 Data Security and Protection Toolkit (DSPT) framework, your organisation was required to perform activities that help meet the expectations of this contributing outcome.

For more detail on what these activities were, see the mapping exercise published by NHS England and Department of Health and Social Care (DHSC).

Administration and maintenance of systems and devices

Privileged operations such as system administration should only be carried out from corporately owned and managed devices, with controls in place to separate those privileged operations from normal user activity. Examples of this type of control include:

• issuing users with separate privileged accounts that have no access to the internet, email, or other higher-risk resources used by normal user accounts
• ‘browse-up’ administration, such as using an ordinary device to access a remote desktop environment for privileged operations - this approach is not recommended (see NCSC guidance on the ‘browse-up’ anti-pattern) but you may decide the risk is tolerable for a period of time while you implement a better solution
• ‘browse-down’ administration, such as using a highly-trusted device to access a remote desktop environment for normal user activities - this can include thin clients accessing multiple remote environments separated for privileged and normal user activities
• dedicated privileged access workstations, specifically configured and protected for privileged operations and not used for any other activity

Wherever possible, the administration of a system should be performed from a device that is trusted to at least the same level as that system.

If you have third party suppliers carrying out privileged operations, you should seek assurance (or set requirements) on the devices and architectures used – see NCSC guidance on systems administration architectures for examples and further information.

Preventing, detecting and removing malware and unauthorised software

You should employ a broad range of techniques to protect your networks and systems from malware and unauthorised software. 

Technical measures might include:

• technology solutions that prevent users accessing potentially malicious websites such as the UK Public Sector domain name system (DNS) service
• anti-malware software
• automatic file scanning
• email filtering such as domain-based message authentication, reporting and conformance (DMARC)

Procedural measures might include:

• using dedicated privileged systems for administration (see B2.c Privileged user management)
• having policies, processes and procedures in place for acceptable use (B1.a Policy, process and procedure development)
• ensuring staff members know how to identify and report spam messages

Physical measures might include:

• restricting access to facilities and systems
• port locks

Supporting evidence

To support your response, you can review and upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• Documentation identifying systems and devices supporting essential functions. 
• List of privileged users and procedures for authorising privileged access. 
• Evidence of separation of devices used for system administration and maintenance. 
• Procedures for reviewing and updating network diagrams and other technical documentation relating to networks and information systems. 
• Procedures and defensive measures against malware and unauthorised software. 
• Evidence of devices being specifically configured and dedicated solely to administration and maintenance operations. 
• Evidence of security measures in place for stored network diagrams and other technical documentation relating to networks and information systems.

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Interpreting indicators of good practice

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | B4 System security
National Cyber Security Centre | Secure system administration
NHS England | Secure boundary service
NHS England | Cyber assurance service

Mapping to other cyber frameworks

NHS England and DHSC have produced a mapping document showing where the requirements of the CAF-aligned DSPT overlap with those of other cyber frameworks. New frameworks will be added to this document over the course of the year. 

Overview

This outcome relates to the way you identify, prioritise and manage vulnerabilities in your networks and systems.

Mapping to the 23-24 DSPT framework 

Under the previous 23-24 Data Security and Protection Toolkit (DSPT) framework, your organisation was required to perform activities that help meet the expectations of this contributing outcome.

For more detail on what these activities were, see the mapping exercise published by NHS England and Department of Health and Social Care (DHSC).

Publicly-known vulnerabilities

You should have a process for identifying and managing known vulnerabilities. Your knowledge of vulnerabilities should come from, at a minimum:

• software manufacturers’ vulnerability publication channels
• cyber alerts issued by NHS England’s National Cyber Security Operations Centre (CSOC)
• other public and commercial sources of vulnerability information

Mitigating vulnerabilities

You should be able to rationalise how you safeguard against exploitation of known vulnerabilities through the procedural and technical controls you have in place.

Vulnerabilities should be prioritised according to the risk they pose, and your process should ensure that follow up actions such as patching and system segregation are taken accordingly.

This should be fed into your risk management process (see ‘A2.a Risk management process’), resulting in appropriate senior oversight of decisions that have been taken.

Temporary mitigations

In areas where your organisation is using assets with known vulnerabilities that have not been patched or unsupported systems, you should apply temporary mitigations to manage the associated risk. These may include:

• isolating the asset or system from the network
• disabling services on the asset or system
• micropatching
• enhanced monitoring of the asset or system, recognising that this does not reduce the risk of the vulnerability being exploited

You should have an improvement plan with realistic timescales for patching the vulnerabilities (including migrating to supported systems where relevant), and consider any compensating controls you can put in place in the interim.

Vulnerability testing

You should do tests on a periodic basis to understand where your networks and systems have vulnerabilities. These include:

• penetration testing
• vulnerability scans

Supporting evidence

To support your response, you can review and upload (or link to) evidence which best demonstrates your achievement of the contributing outcome. Examples include:

• Procedures for gathering and analysing threat intelligence. 
• Vulnerability management process. 
• List of announced vulnerabilities. 
• Evidence of temporary mitigations being applied. 
• List of unsupported systems and software. 
• Evidence of plans to migrate unsupported systems or software. 
• Sample of network scans. 
• Evidence of internal vulnerabilities being remediated. 
• Evidence of third-party testing of network and information system vulnerabilities. 
• Process for planning end-of-life for critical systems. 

This is not an exhaustive list. You're welcome to provide other types of evidence if you feel they are relevant to the contributing outcome.

Your supporting statement should cross-reference how each piece of evidence provides justification for your achievement of the contributing outcome, including relevant page numbers where appropriate. 

Interpreting indicators of good practice

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | B4 System security
National Cyber Security Centre | Vulnerability management
NHS England | Vulnerability monitoring service
NHS England | Threat advice and intelligence
NHS England | Respond to an NHS cyber alert
NHS England | Cyber assurance service
NHS England | Technical remediation service
NHS England | Microsoft Defender for Endpoint service
NHS England | Bitsight cyber security ratings service

Mapping to other cyber frameworks

NHS England and DHSC have produced a mapping document showing where the requirements of the CAF-aligned DSPT overlap with those of other cyber frameworks. New frameworks will be added to this document over the course of the year.