Principles and how they can help us with assurance

The NCSC is developing a new approach to the way we determine if a piece of technology is suitably secure for its intended use. This approach is centred on a set of principles. It is a quite radical departure from traditional methods of ‘Technology Assurance’. We are calling it Principles Based Assurance.

In this blog, I’d like to give you a clear picture of why we’ve chosen to pursue this approach, and explain how it’ll work to secure the UK, and provide a basis for continued innovation.

What is a principle?

The short answer is that a principle describes ‘what’ needs to be achieved, not the ‘how’. For us, a principle describes the overarching aim, as opposed to providing specific granular instructions for users to follow.

For instance, rather than specifying the detail of what physical protection a device should have in place (e.g. armed guards, anti-tamper, locked room…) we would instead describe the aim of ensuring that the device has adequate physical protection against the threats it is likely to see in its deployed context.

The lure of the checklist

The ‘what’ rather than the ‘how’ distinction is an important one. What would make life much easier is a clear, simple list of cyber security tasks. We’d like to tick off each item in that list to prove we have done everything necessary to keep our people safe from cyber attackers.

Sadly, this checklist-based approach only goes so far and work best when we know exactly how something is going to be used, in a static environment, where threats don’t change much.

Principles are preferable

In cyber security we don’t have the luxury of an unchanging world. Technologies are connected to each other, and people. Cyber attackers are developing new techniques and capabilities all the time. What is a highly motivated and resourced capability today, can quickly turn into an ‘off-the-shelf’ attack tomorrow.

So, not only does the checklist for a connected kettle look very different to that for a Smart Meter, or a nuclear submarine… but the list needs to be constantly updated to stay useful.

Principles, on the other hand, are flexible, providing a guide which can be adapted to any given situation. For this reason, we prefer principles.

Principles, guidance and standards

These terms get used quite a bit, so here are some working definitions:

• Principles: the overarching security outcomes that need to be achieved in a given scenario
• Guidance: a descriptive piece that helps people to interpret principles for their context
• Standards: how the principles should be applied for a given use case

Principles and guidance work best at the system-level, where there are many ways in which a technology may be deployed or used. Standards work best for more constrained use cases and technology scopes.

Often, the NCSC combines principles and guidance, for instance in our Cloud security guidance.

Origin of principles

So, where did these principles come from? The short answer, is ‘experience’. Working with industry and other government departments, the NCSC has, for many years, helped industry and government departments gain confidence in all kinds of technologies and systems.

During this process, one thing we contribute time and time again, thanks to our specialised knowledge, are the sociotechnical questions that we would ask of any technology in order to work out whether its cyber security is good enough for the threats it is likely to face.

These questions form the basis of our new approach to assurance and, over the next few months we will be publishing them as the “NCSC Technology Assurance Principles”.

We think this resource will help lots of people to understand how they can gain confidence in the cyber security of a technology.

These Technology Assurance Principles are divided into three sections, each of equal importance:

• Design & Functionality - principles that are relevant to the security functionality which the product must implement to mitigate cyber threats.
• Product Development – principles that are relevant to the secure development of a product and the engineering practices of a vendor, developer or manufacturer.
• Through-life – principles that are relevant to maintaining the security of a product throughout its lifetime.

For the first time, we are explicitly including usability outcomes. For a number of years the NCSC has promoted the importance of security working for people. Understanding exactly how we can demand and demonstrate usability as part of our assurance requirements will be a learning experience for us all.

Anatomy of a principle

We realise that not everyone else has the same depth of cyber security expertise as the NCSC. So, the principles need to be usable and accessible.

We want the principles to facilitate considered discussion, building a deeper understanding of the security outcomes which the principles encapsulate, and why they are needed.

We've given a lot of thought to the structure that our technology principles should have. The end result looks like this:

• Principle e.g. “Protect sensitive data when in transit”
• Description - what the principle is aiming to achieve and why
• The threat - the potential routes to compromise the principle is mitigating
• Protective measures - the security outcomes which will ensure the principle is met

e.g. “use encryption to protect the confidentiality of the data” and “ensure that any messages that have been modified in transit can be identified”

• List of example defensive measures - practical techniques that can be used to achieve the outcomes

e.g. “Use standardised algorithms to encrypt the message content. The content should be encrypted at the source and decrypted only at the destination, never en-route. Message integrity should be verified”

This is the same structure as we used in the Security principles for cross domain solutions.

Deriving more specialised principles and standards

Where there is a strong customer need for further help and clarification regarding a certain technology or domain, the NCSC will be developing and deriving more specific principles and standards (or we will help other people to do so).

Over time, we will update our assurance principles portfolio on our website, adding new principles as they are developed.

Examples of such lower level principles and standards are:

• Cross domain solutions
• Cloud security principles
• Smart Meters
• Secure communications
• High Grade Engineering Standard
• AI/ML-based technologies
• Code of practice for consumer IoT & Consumer IoT security - ETSI

The wider benefits of principles

A principles-based approach brings with it a range of other benefits:

• Risk-based assurance – principles enable a proportionate approach to cyber security assurance. For any principle, we can turn the dial between 'don't need to do anything' and 'we need the highest level of protection'. This promotes thought and discussion of risk appetite, as well as the ownership of risk.
• Innovation & capability – Principles introduce flexibility to how an outcome can be achieved and demonstrated. This enables the NCSC ambition to drive innovation in cyber capability, whilst keeping the UK and its people secure.
• Diversity – enabling flexibility in the way a security outcome can be achieved promotes diversity across the supply chain.

Proof of principle

Work is already underway at the NCSC to develop rigorous, repeatable, and robust ways in which evidence can be provided that principles have been met.

This builds on the findings of the Cross domain solutions pilot and the work that we have already explored through approaches such as claims, argument, evidence (CAE).

In the Autumn, we will be publishing the Technology Assurance Principles on this website. The primary audience for this is likely to be vendors and buyers of technology who care about security risk. But we hope that the full audience will be much wider.

At the same time, work is underway to develop our internal capability, as well as that of our industry partners, so that we can deliver Principles-Based Assurance in a timely and effective manner. 

Helen L
Head of Technical Assurance Group (TAG)