Secure By Design Thoughts Part 1

With #securitybydesign , #securitybydefault , #securebydesign, #securebydefault trending this week, some thoughts on what it should mean.

First up, disclaimer - unless otherwise stated, all views expressed are mine and don’t necessarily reflect those of my employer or MITRE sponsors.

I don't if anyone except the authors saw the drafts of NIST SP 800-160 Volume 1 Revision 1 Engineering Trustworthy Secure Systems (V1R1) with it, but those early drafts had what is now Appendix D titled Secure by Design - in shared drafts and the final we went with Trustworthy Secure Design. These thoughts follow a bit along those lines of D, but also realize the team published Appendix D as part of the whole 15 months ago, and from there limited ourselves to clarifying based on comments received. So I'm feeling free to vary from that expression, following some lessons learned on presenting.

Design Approach

A design approach for engineering trustworthy secure systems must establish and maintain the ability to deliver system capabilities while minimizing the occurrence and extent of loss. The approach must provide a system structure for optimal employing engineered features and devices. The system design must provide the intended behaviors and outcomes, avoid the unintended behaviors and outcomes, prevent loss, and limit loss when it occurs (Opening of Appendix D.1 of V1R1, paraphrased for brevity).

Stated more philosophically, the design approach for a secure by design system must think strategically about outcomes: deliver required performance, minimize unacceptable effects of loss. Later may surprise many, but other than "pride" or other extraneous emotion, the ultimate aim is to avoid effects against a system's objectives - meet the system purpose, keep stakeholders happy, etc. Not security for security's sake.

Much written recently about security-by-design focuses to tactics. But tactics without strategy is the noise before defeat (Sun Tzu, Art of War). Granted, tactics are needed (Strategy without tactics is the slowest path to victory, ibid), but so much of security focuses to tactics without thinking strategy (Young & Leveson) ( William "Dollar" Young )

The elements to a design approach we identified in V1R1 include (again, paraphrasing - See V1R1 D.1)

• know the intended behaviors and outcomes for the system
• Identify the states and conditions reflecting those intended behaviors and outcomes
• Identify states and conditions that potentially lead to loss in the system (and NOT just the ones you "know" the malicious actor can create).
• select and alter the system design to prevent loss to the extent practicable (preferred) and limit the loss that does occur (where, when, and to the extent necessary and practicable)
• Iterate

Security Design Order of Precedence

Informing the design approach is the security design order of precedence. Very briefly

1. Among design alternatives, select those that eliminate the potential for loss
2. Within a selected design, select means to reduce loss potential (e.g., reduce interfaces, segment)
3. Incorporate engineered features to control loss potential
4. Provide visibility and feedback to external entities
5. Incorporate signage, training, etc.

As an order, those early stages are preferred means over later. One nuance is that in executing 1 and 2, need to look to setting the stage for successful incorporation of engineering features, such as those that support mediating access and inform situational awareness.

Assurance

For V1R1, we dedicated a whole appendix (Appendix F) though threads on it appear exist throughout. For now, just want to focus to assurance associated with incorporating engineered features to control loss potential.

Engineered features, or mechanisms, must meet four essential design criteria (Uchenick & Vanfleet, 2005):

• Non-Bypassable: the mechanism is of no use if it can be circumvented
• Evaluatable: if the mechanism is too complicated to be evaluated for correctness in implementation (not just tested!!!!!), then there cannot be sufficient confidence in its function.
• Always Invoked: loss may occur when the mechanism is off or suspended
• Tamper-proof: if it can be modified in an unauthorized manner, integrity of function is in doubt.

Two foundational principles

Two foundational principles for a secure system are completed mediation and system control.

Complete mediation dates back about 50 years (well before it become core to zero trust!), formalized in the work of Saltzer and Schroeder but you can see it expressed in some informal ways in the Ware Report (1970) and the Anderson Report (1972). It is the idea that any access to an entity (e.g., a resource) must be mediated - that is, the access must be authorized.

System control in simple terms means that system functions and behaviors are kept to what they should be.

Perhaps these are to be expanded on in future articles.

Closing

Secure by design is not just some baking in of tactics. It is a deliberate perspective to design, one that needs to be as foundational to system design as performance and safety ( INCOSE Systems Engineering Vision 2035)

Thoughts, comments, suggestions for follow ons?

#INCOSE #cyberresilience #cybersecurity

Additional reference info

Uchenick GM, Vanfleet WM (2005) Multiple Independent Levels of Safety and Security: High Assurance Architecture for MSLS/MLS. IEEE Military Communications Conference, pp. 610-614 Vol. 1.