Impacts on ICS from the updated Cyber Assessment Framework (CAF)

NCSC has released an update of the Cyber Assessment Framework (CAF). The CAF represents where the rubber hits the road for the UK’s NIS regulations.

TL;DR

• The NCSC CAF has been updated to version 3.2.
• There has been a material change to three aspects of the CAF.
• The changes are broadly sensible and will improve the cyber security of companies covered by NIS.
• They may create challenges in some areas, such as with legacy technologies, and make it harder for some companies to achieve the required standard.

What is the CAF?

The CAF defines cyber security objectives and principles that companies that are subject to the NIS regulations, should be addressing and sets out goals that they should be aiming to achieve. The CAF is split into Objectives with each Objective having a number of Cyber Security Principles. These Principles are then split into Contributing Outcomes (CO) which have associated Indicators of Good Practice (IGP).

The IGP’s can be judged to be either Not Achieved, Partially Achieved, or Achieved. A company will assess themselves across the objectives and principles against individual IGPs to define their CAF profile. This profile can be compared to their regulators expected industry profile, or enhanced profile if applicable, and is the baseline from which companies can drive forward cyber security improvements.

What has changed in the CAF?

On 18th April 2024 NCSC announced the latest iteration of the CAF with version 3.2.

Traditionally updates to the CAF have been fairly minor outside of major release updates. So if you are subject to the NIS regulations is there anything of interest for you in CAF v3.2?

In short yes.

Whilst most of the changes are minor and not really material to cyber security (slight rewording, aligning language with the NIS regulations, tidying up some other language etc.) there are three material changes to IGPs that may impact your company.

Those three material changes

• Two of these changes relate to the Identity and Access Control Principle and in particular the Identity Verification, Authentication and Authorisation CO.
• The third change impacts the Secure Configuration CO of the System Security Principle.

To fully meet the requirements to achieve across the board success within the Identity Verification, Authentication and Authorisation CO it now requires the use of:

“…additional authentication mechanisms, such as multi-factor (MFA)Multi-Factor for all user access, including remote access, to all network and information systems that operate or support your essential function(s).”

Previous versions of the CAF only required additional authentication methods, such as MFA, for privileged and remote user access.

This change has the potential to massively increase the numbers of users that need additional authentication methods to be able to achieve this IGP. Addressing this will require investment as well as changes to working practices and culture, especially in ICS / OT environments. This is also likely to create some challenges with legacy ICS / OT equipment, and software, that does not support modern authentication methods.

Example
Some SCADA systems do not natively support MFA but may support alternative authentication methods, such as LDAP authentication, which can be leveraged to provide MFA capability.

However, this may require configuration changes to the SCADA solution and possibly the purchase of additional software solutions to provide the MFA capability.

In addition it is required that a company’s “…approach to authenticating users, devices and systems follows up to date best practice.”.

Whilst this may be regarded as a sensible approach it is broadly worded and doesn’t suggest what “best practice” might be! So when considering how to meet this requirement companies should ensure that they are able to provide justification, and evidence, for the choices they make to achieve this requirement, i.e. what makes it best practice and why.

The third material change to the CAF is to the System Security Principle and, in particular, the Secure Configuration CO. This now requires that:

 “Generic, shared, default name and built in accounts have been removed or disabled. Where this is not possible, credentials to these accounts have been changed.”

This is another sensible, and some might suggest overdue, inclusion in the CAF.

It is to be hoped that, in most instances, this has already been done but, again, this may create some challenges with legacy ICS / OT equipment where this may not be achieved straightforwardly.

Example
There are legacy RTU devices that are known to have hard-coded credentials that either require firmware updates to remove the hard-coded credentials, or may no longer be supported and therefore will need to be replaced to deal with the hard-coded credentials.

This may have significant costs, both design and implementation related, and knock-on effects on other devices or software.

Recommendations

Review the new version of the CAF and ensure that these new requirements are covered within your cyber security programmes of work and remediation plans. Where it is not, ensure they are updated to include them and look to fund the investment required to implement the changes needed to meet these new requirements.

Understand where you may not be able to achieve the new requirements, for example with legacy devices and software, and ensure you implement compensating controls to mitigate the risks that this may present. Until such time that they are addressed by your cyber security programmes of work and remediation plans.