Problem 2 - How do we make system security assessments more data driven?
How do we make system security assessments more data driven?
Along with many private sector consultancy companies, the NCSC offers security architecture reviews as a service, by highlighting flaws in system designs so they can be corrected. The NCSC has a small number of highly skilled and experienced security architects who make professional judgements about whether a system design is secure enough to protect against certain threats. The demand for these architects will always be greater than their capacity. Another problem is that as threat-actor tradecraft is always evolving, it’s not possible to have in-depth and current knowledge of all threats. So unless we evolve the approach, mistakes will be inevitable, and systems that could have been defended will be breached.
We need to apply more rigour to the approach to system security assessments, to improve efficacy and repeatability, while also enabling a larger workforce. We also need to be able to apply knowledge of threat actor tradecraft to guide these security assessments, or perhaps even automatically validate designs as being secure against known threats.
Strands or sub-problems
-
Data science and modelling
It's important that we can map system architectures, component properties and security mitigations in a way that is suitable for automated reasoning. We also need to validate if any given system can defend against threat actor TTPs (tactics, techniques and procedures). We need research and analysis on modelling techniques for this problem, along with real-world examples of their application.
-
Product assurance
Security products are designed to mitigate certain risks, but which ones do they mitigate, and how well? A codified model here would be another vital component necessary for automated reasoning on overall system security where multiple security products are in use. As well as security products, we also need to consider the security properties of other products or components when securing a wider system: how can we better understand the provenance and supply chains that make up the hardware and software bills of materials for a component in the architecture, and how that affects the confidence we can have in that component?
-
Socio-technical factors
People using or operating the system also pose or mitigate risks, and it's important to factor this into a model for system security – how can these risks be codified?
-
Security architecture
This sub-strand is about modelling architectural mitigations rather than security products or configurations: for example, an architecture with more independent layers of defence. This area is also a logical place to be able to apply the above models to consider the different mitigation options – what are the practical tools and assessment methodologies needed to do that?
-
Measuring software security quality
This is about developing a taxonomy and objective measures for how difficult it's likely to be for security researchers to find vulnerabilities in any given software project, to inform the level of confidence we then have when that software is present in a system architecture. In other words, lack of knowledge of specific vulnerabilities shouldn’t be taken as a clean bill of health, as it may just be that no one has looked for vulnerabilities yet. So can we come up with an objective measure of how easy it might be to find vulnerabilities?
-
Attack simulation
Breach or attack simulation tools are another method to gain evidence of resilience to defend against an attack. How can we make tooling representative of real-world threat actors and their TTPs?
-
Risk
Finally, there is a need to bring together all of these strands to support a system owner’s risk decision about whether the defences in place are sufficient. How can we help a system owner make that decision confidently? And how can this more data-driven approach combine with other risk assessment approaches such as system theoretic process analysis (STPA)?
Why this is important
“As one of the people responsible for defending the NCSC’s own technology from cyber attacks, I grapple with making decisions that balance security, usability and cost. Much of this decision hinges on my own judgement and the advice from security advisors, as there is little good-quality data about whether the security mitigations in place on a given system are sufficient to defend against current threats. This research challenge represents the best chance we have to move security assessments from an art to science, helping people like me make more confident decisions that the defences in place are sufficient. Ideally, I’d have data and tooling telling me automatically when we need to take some action because threat actor tradecraft has changed, and my particular systems are now at risk.”
Carolyn A, Chief Engineer, NCSC