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’.

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

At the "partially achieved" level you should have implemented solutions at your network boundaries which protect against content based attacks by:

• analysing incoming data
• transforming, blocking or filtering out harmful content

See NCSC guidance on content based attack protection for more information.

Supporting evidence

To support your response, you can 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

National services

The following national services may help you meet the requirements of B4.a Secure by design:

• Training services | Cyber Incident Response Exercise (CIRE)
• Security services | Secure boundry
• Security services | Vulnerability Monitoring Services (VMS)
• Security services | Bitsight
• Security services | Cyber assurance service (CAS)
• NCSC services | Early warning
• NCSC services | Exercise in a box
• NCSC services | Check your cyber security

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

Overview

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

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.

Organisations using Microsoft Defender for Endpoint (MDE) will have a good start for identifying networked devices. 

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 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

National services

The following national services may help you meet the requirements of B4.b Secure configuration:

• Security services | Secure Boundary 

• Security services | Vulnerability Monitoring Service (VMS) 

• Security services | Bitsight 

• Security services | Microsoft Defender for Endpoint (MDE) 

• NCSC services | Early Warning 

• NCSC services | Check your cyber security 

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

Overview

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

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:

• dedicated privileged access workstations, specifically configured and protected for privileged operations and not used for any other activity 

• ‘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 

• ‘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 

• issuing users with separate privileged accounts that have no access to the internet, email, or other higher-risk resources used by normal user accounts

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 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

National services

The following national services may help you meet the requirements of B4.c Secure management:

• NHS England | Secure boundary service
• NHS England | Cyber assurance service

Additional guidance

For additional guidance, see:

National Cyber Security Centre CAF guidance | B4 System security
National Cyber Security Centre | Secure system administration

Overview

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

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 procedures you have in place, for example a well implemented policy to update by default, and the technical capabilities you use to help effectively implement those procedures, such as automated patching with regular review to ensure any missed deployments are promptly addressed. 

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.

NCSC have included good practice timescales for rolling out updates in their guidance on vulnerability management. Your judgment should inform the path to resolution and a timeline for implementation, taking into account the risk posed by the vulnerability and your local circumstances.

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.

Where a serious vulnerability is known (or is likely) to be actively exploited, such as is often the case in high-severity cyber alerts issued by NHS England, your timescales should reduce significantly see NCSC guidance on responding to active exploitation. You should have the organisational and technical capabilities to apply mitigations very urgently when needed, even outside of normal working hours. 

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 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

National services

The following national services may help you meet the requirements of B4.d Vulnerability management: 

• Security services | Vulnerability Monitoring Service (VMS) 

• Security services | Bitsight 

• Security services | Technical Remediation 

• Security services | Cyber assurance service (CAS) 

• Security services | Microsoft Defender for Endpoint (MDE) 

• NCSC services | Early Warning 

• NCSC services | Check your cyber security 

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