Brian Snow of the NSA released an informative and insightful paper - "We Need Assurance!"
The paper starts with this question, that captures the balancing act between security and functionality.
When will we be secure? Nobody knows for sure - but it cannot happen before commercial security products and services possess not only enough functionality to satisfy customers' stated needs, but also sufficient assurance of quality, reliability, safety, and appropriateness for use.
This underscores why architecture is crucial to security, because architectural tradeoff analysis resolves conflicts and constraints from disparate domains.
Throughout these years, my mantra has been, "Managers are responsible for doing things right: Technical Directors are responsible for finding the right things to do.
Absolutely, the primary focus of these activities requires different mindsets.
In discussing failures of security products:
First to many of these products are still designed and developed using methodologies assuming random failure as the model of the deployment environment rather than assuming malice. There is a world of difference!
Second, users often fail to characterize the nature of the threat they need to counter. Are they subject only to a generic threat of an opponent seeking som weak system to beat on, not necessarily theirs, or are they subject to a targeted attack, where the opponent wants something specific of theirs and is willing to focus his resources on getting it?
This underscores the hazards of the dualistic "trusted and untrusted" view that many organizations have. Instead of the perimeter focus such as in networks, each architectural layer - physical, network, host, identity, application, and data - needs its own perimeter and control gradient.
The differentiation that Brian Snow points out is a chief design consideration, systems need one level of security to deal with generic door rattling threats and a deeper level to deal with targeted attacks. The latter requires asset valuation to determine which areas need this level.
The paper also brings an important point that questions the old standby that security somehow impedes business. Many car manufacturers have differentiated their products through superior quality, reliability and safety, why is this so hard for software manufacturers to grasp?
Assurance is best addressed during the initial design and engineering of security systems
Build Security In, anyone?
In addressing the current posture:
We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.
Sadly this bifurcation of perception and reality drives a lot of the software market.
During the next several years, we need major pushes and advances in three areas: Scalability, Interoperability, and Assurance. I believe that market pressures will provide the first two, but not the last one - assurance.
Another perceptive distinction, I am inclined to agree with one caveat that increased interop like we are starting to see with SAML, Federation, WS-* et. al. has some incremental improvements for assurance
Assurance is more formally defined:
1. The system's security policy is internally consistent and reflects the requirements of the organization.
2. There are sufficient security functions to support the security policy
3. The system functions meet a desired set of properties and only those properties
4. The functions are implemented correctly, and
5. The assurances hold up through the manufacturing, delivery, and life cycle of the system.
The paper then addresses six areas to target: OS, software modules, hardware, system engineering, thrid party testing, and legal constraints. I will blog/annotate this in a future post.
I really have to applaud Brian Snow for sharing this analysis with open community, collaboratiive knowledge sharing should help the open community if we are prepared to listen, learn, and *implement* these lessons.
Update: Adam, the lead saxophone player in the Emergent Chaos Jazz Combo, has placed Brian Snow's assurance view in the context of an hacker view and an economic view of software security. This is hugely instructive. None of these views, by themselves are adequate. The combination of horizontal and vertical views is what yields the most accurate picture. Obviously, iteration is the only way to work towards that. Adam's brilliant suggestion? OODA Loops.
Update 2: Part 2 analysis of Brian Snow's paper.
Comments