Technology assurance
Pages
Page 9 of 35
Objectives of Principles Based Assurance (PBA)
There are five objectives guiding the development of PBA:
The ubiquity of connected technology means that more of the systems upon which we rely as a society must be resilient to cyber threats.
To cover such a broad spectrum of products, systems and scenarios, the NCSC’s technical resources must be used in ways which add the most value, where the impact of failure is greatest. To do this, we will use PBA to enable and empower others to gain and provide confidence consistently and effectively, at scale. To do this, we must first put the necessary infrastructure in place.
PBA infrastructure
The NCSC will allocate resources and put in place the necessary artefacts and initiatives. This will include:
- Publishing a comprehensive portfolio of NCSC Assurance Principles on our website. These will enable self-assessment and provide a base from which cyber security assurance requirements can be derived for use on specific technologies and the context they are used in.
- Continue working with DCMS to deliver their legislative and standardisation efforts on Connected Consumer Devices, support the Secure by Design initiative and help grow the impact and coverage of both.
- Developing a capability which can assess the technical efficacy of assurance services and any labs that deliver them.
Assurance that adapts
Feedback loops are essential to ensure that our processes remain as effective and relevant as possible. We will seek to continually learn and improve our approach, in support of proportionate and threat-led assurance.
As appropriate, we will disseminate any insights, lessons learned and updates through effective and usable communication channels.
NCSC in-house assurance
NCSC in-house assurance services will continue to focus on those technologies and systems most critical to the UK, where we can add the most value and deliver the most impact. Over time we will be developing our evaluation approach to align with PBA and to assess aspects relating to vendor competence and through-life, as well as a technology’s design and functionality.
We will grow our capability to deliver assurance services beyond CAPS evaluations to cover other priority technologies, such as our Critical National Infrastructure (CNI). We will seek to augment our NCSC assurance services with industry partners to gradually expand this capability over time, allowing us to deliver these services to more customers.
To keep the UK safe, we can no longer constrain our assurance capability to just security products – that is, technologies, such as encryption tools, whose sole function is cyber security. We must assess all technologies that need to be cyber secure.
This begs the question, what do we need to be cyber secure? To answer this, the NCSC will work with its partners to develop a holistic view of the UK’s priority technologies and their cyber security needs. Securing these will bolster the overall cyber security of the UK.
Effective cyber security cannot be ‘bolted on’ to a product at the end of its development.
We believe in the benefits of weaving cyber security into the design and development process from the beginning. We also fiercely advocate usability and inclusion.
Cyber security can also be an important differentiator in a crowded market. Technology which is secure by default has the best security it can, without people knowing it’s there or having to turn it on. Products which are both user friendly and secure by default have a strong competitive advantage.
Developer assurance
Our technology assurance requirements will include usability, vendor competence and through-life security. This will help people understand how much they can trust vendors, but also enable vendors to publicly declare that they are achieving appropriate security standards.
These requirements will be published through our Product Development Principles. These will guide vendors towards improved security engineering and better informed trade-offs in development, helping them to spend money where it’s known to be effective.
We realise that developers and engineers are not necessarily security experts. To help with this, we will publish Cyber Security for Engineering guidance. This will help teams and individuals weave security into their development process. It will also clarify how to achieve the outcomes demanded by both the DCMS Consumer IoT Code of Practice, and the NCSC’s assurance requirements.
Framing issues of cyber security in terms of risk is not the same as saying that compliance-based approaches are always bad. They are not. What this means is that compliance activities, where needed, should stem from risk-based thinking. We also need to understand what compliance does and does not, give us.
On the plus side, compliance-based approaches provide us with standards for specific technologies, at a specific time, against a specific threat model. Independent evaluation activities that demonstrate compliance against a standard can provide a much-needed, reusable, baseline for security.
However, compliance-based approaches provide a limited snapshot that cannot fully account for the unique set of risks that exist when a technology is implemented into new systems and settings. When assurance relies solely on compliance we can lose flexibility and efficiency as well as innovation and diversity – all of which are crucial to getting the job done.
Assessing the risks
Determining risk is not easy. It involves a complex discussion of goals, threats, opportunity, time, context, and priorities. The defensive measures for one scenario or organisation may not be right for another.
A clearly communicated risk statement that articulates the level of confidence a customer can have in a technology and the development process behind it, is a key part of enabling others to manage their own cyber security risk.
For instance, the assurance process may indicate that the technology is resilient against a commodity threat but not provide confidence against an attacker using bespoke capabilities. How we articulate that risk in a way that people can understand is a key part of this vision.
We appreciate that not everyone is ready for a detailed discussion of their system’s cyber security threats and risks. For some people, such as citizens and SME’s, the NCSC will need to work with vendors and put in place mitigations to manage cyber security risks on their behalf, and enable people to put the Cyber Aware behaviours into practice. For other people and organisations, supporting and improving the way in which they manage their own cyber security risks is a key goal. To this end, we will soon be expanding our Risk Management portfolio.
Commodity threats involve a remote attacker with widely accessible and available tools.
Bespoke capabilities refer to a remote, or close access, attacker with more sophisticated tools that are not widely available.
Risk management is an iterative process, requiring an approach where confidence can be continually reviewed to deal with an ever-changing threat and risk landscape.
What is safe today may not be tomorrow, even though we continue to assume it is. So, our new assurance requirements, in addition to assessing design and functionality will demand better engineering processes and that security be sustained through a product’s lifetime.
We also seek, through the Principles, to explicitly gain confidence in the usability of the security of a product in practice. Our research over several years has taught us that, in practice, security and usability are inextricably linked. If security doesn’t work for people, it doesn’t work.
Assurance maintenance
Re-validation of assurance should focus around the changes to the context and threat which a system faces, rather than requiring the full assurance process repeated every time.
Threat first
We need to develop and embed a ‘threat-first’ mindset, one that can react and adapt, supporting resilience as well as driving ‘smarter’, more efficient and proportionate protection techniques. We want to create feedback loops which will test and verify our world-class approach to technology assurance, measure success, and help us to understand the vulnerability of the UK.
Challenges ahead
Realising a system of technology assurance that can support more dynamic risk management approaches will be challenging. Implementing current good practice that can support data-driven approaches such as vulnerability disclosure and management, monitoring and logging, near miss reporting and scanning is still hard for many.
The NCSC will continue to build on the capabilities developed so far, such as the Active Cyber Defence programme, Early Warning Service and Logging Made Easy toolkit. But we know we also need to strive to discover and develop new, innovative solutions too. We must help people to achieve the fundamentals more effortlessly but also to deliver new capability into some of our more connected and critical domains.
