risk based vs capability based

Tons of ideas for articles in the queue but I want back and looked at unfinished draft. This was perhaps the oldest - started December 2022.

The subject probably has some saying "what" or "agree - a lot used to thinking of security in terms of risk management go with "heresy". Later are probably not regular readers of my articles.

Kinetic warfare does not define defense in terms of managing risk like cyberspace does. While managing risk is a support role - it is not the primary.

Risk-based engineering to me is not systems engineering - and not the way to achieve an emergent property like security, or even cybersecurity (not the same!). The need is capability - and assurance in achieving it (and assurance is not "minimize the risk to acceptable" as some think).

Instead of ‘risk-based’ engineering that

• Chases vulnerabilities (of which there will always be more to find in a complex system)
• Does not apply SE requirements analysis principles to ‘cybersecurity’ requirements; accepting a lack of ‘good enough’ from the mission/business owners
• Fails to engineer a system with a defense capability that can defeat the adversary despite being a system fraught with vulnerabilities
• Fails to cause the pressure needed for at least some highly trustworthy IT in order to have an effective defense
• Forces ‘system security’ to forever be a stovepipe because this risk-based engineering is so different from capability-based as to not ‘fit in’ with SE for other types of requirements.

?

We need capability-based engineering that:

• Fits into the SE processes
• Readily relate SE concepts, principles, and processes.
• Applies good SE requirements analysis, aiming for requirements that clearly express the capability to be achieved with definition of good enough given the operational environment And capabilities include what is needed for active cyberspace defense
• Expects the mission/business owner to make the risk-management/assurance-of-success decisions
• Expects these decisions to be inculcated into the requirements to the SE; enabling the SE to then engineer to these requirements
• Proactively pushes back against unachievable or non-actionable requirements

We need to get past risk management frameworks driving the engineering, as well as get past defining architectures and designs then analyzing them to figure countermeasures to embed into the architecture and design - often referred to as "baking in security" - as the means to "secure". We need to stop thinking of securing the architecture, securing the design, securing the implementation and think in terms of developing a secure architecture, secure design, and secure system. "Securing" makes for a more complicated system and risks a game of "whac-a-mole" - each plugging of a hole leading to another hole or two.

Looking at the notes I had for this article in draft form - appears Gary Stoneburner deserves some thanks for help with the thinking on this.

Unless otherwise stated, all views expressed are mine and don’t necessarily reflect those of my employer or MITRE sponsors

?