Systems Security Rules of Engagement
Like the military, engineering for security needs rules of engagement to prioritize action

Systems Security Rules of Engagement

Taking something from my book draft I expect to publish sometime in 2024. Changing to fit to this format and I'll also likely change the draft so in 2024 you can check how close this ends up to the book

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

A principal tenet of military rules of engagement is that of graduated response. If force is necessary, it is applied as a last resort, gradually in relation to the extent of demonstrated aggression, and with only necessary force to accomplish the mission when used. [MW1]?

In designing a system for security, the opposite is needed – an ungraduated response to the potential for loss, or hazards. Borrowing from military language, the first course of action is to “kill” – eliminate the hazard. For example, rather than permit e-mail on a laptop used for maintenance and risk a phishing attack that plants malware, design maintenance systems to not require e-mail on the laptops directly interacting with operational systems.???

The second course of action is “apprehend and restrain” – control or reduce the possibility. Finally, the third course of action: If it does occur, limit the loss.

The ungraduated response approach is a practice in systems safety engineering referred to as the hierarchy of preferences for safety interventions (Saleh, Marais, & Favaro - System Safety Principles: A multidisciplinary perspective). The figure below shows the Saleh, et al hierarchy . The U.S. Department of Defense’s Standard Practice System Safety MIL-STD-882E can be seen as deriving a design order of precedence from the hierarchy[1], which has been adapted for security (NIST SP 800-160 Vol 1 Rev 1).

No alt text provided for this image
Systems Security has an almost identical view, on my list of things to do


SecDOP

The security design order of precedence (SecDOP) provides a prioritized approach to secure design. The approach seeks to reduce design-based susceptibility, vulnerability, and other hazards and effectively control susceptibility, vulnerability, and hazards that cannot be eliminated. SecDOP identifies options (including options to be executed in operations) and lists those options in order of decreasing effectiveness in a manner paralleling the hierarchy for security interventions.

Reflecting an ungraduated response mindset, the design order prefers the pre-emptive versus the reactive, as pre-emptive is generally more effective. Pre-emptive addresses actions taken to prevent and limit loss before the event could occur, including avoiding it, while the reactive addresses actions taken to limit loss and its effects once an event has occurred. Pre-emptive recognizes the conditions where loss may occur and addresses the scenarios before loss occurs, whether in engineering (preferred) or in building in capability to respond in operations to potential loss. If loss occurs, pre-emptive actions can limit the consequences and pre-emptive planning, such as the engineering of military ships with many watertight compartments that can be sealed off in operations after being hit. The defined actions in such cases are independent of any specific knowledge of attacks or attacker objectives and are focused simply on what is possible in the system’s life cycle.

The reactive recognizes that loss will sometimes occur despite any effort to prevent it. This is often due to new, unanticipated, and otherwise unforeseen adverse consequences that occur despite best due diligence. Engineering needs to plan the enabling informed operational decision making for the system in use and a loss or loss condition occurs, proactively giving operational organizations greater capability to response when loss or failure is imminent or occurs.

Realizing mechanisms can fail and can produce unintended emergence and side effects, the prioritization is to those architectural solutions not exhibiting behavior and enabling more confident evidence-producing analysis. For example, segmentation (partitioning such as a system to subsystems) other architectural features often support avoidance and limitation of exposures, defects, weaknesses, and flaws that may constitute a vulnerability, and those limiting the propagation of loss when it does occur, and also can enable better mediated access and system control.

Still, mechanisms are still necessary for functions such as enforcing constraints on system behaviors and outcomes. When rigorously engineered, these mechanisms can be effective so long as they function as intended.

From highest priority to lowest, SecDOP is:

1.?????Eliminate hazards and limit extent of loss through design alternative creation and selection.

2.?????Optimize the ability to avoid loss and limit loss’s extent through design alteration.

3.?????Incorporate engineered features and devices to control the hazards and to control the effect of loss that does occur.

4.?????Provide visibility and feedback to external entities.

5.?????Incorporate signage, procedures, training, and proper equipment.

SecDOP should be applied iteratively as system design matures and recursively as the system is decomposed into to lower levels of detail (e.g., subsystems, components, and elements).

Applying SecDOP also considers defense-in-depth (coordinated employment of multiple design features and mechanisms to handle hazards) when a hazard cannot be eliminated.

Closing

Thoughts, comments?

With the summer coming, writing a book, and needing to prepare a tutorial for INCOSE International Symposium (#INCOSEIS) in July, I may slow this posts down to 3 times per month or every other week. Of course, I can share draft excepts from the book as well so maybe I can keep it up.

If you are going to #INCOSE IS, the tutorial is on Sunday, July 16th. Skip the beach, you don't need the sunburn (though I may spend time there on Saturday so may come in a bit pink if I'm not careful).


[1] Author’s note: I do not know if this is the origin of the safety design order of precedence, but it might be.?


?[MW1] Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3121.01B. (2005). Standing rules of engagement/standing rules for the use of force for U.S. forces.


Pons Mudivai Arun

Curious about systems' interconnectedness, emergence, and impact

1 年

Well said Mark W.; regarding the application of "force," Like Kevin Levin (1951) beautifully articulated in his "force field analysis,"?minor influence on both sides of the equation (i.e., forces favouring and against) helps us reach the intended goal/objective.?But often, we prioritise our efforts on one side of the force (perhaps humans are hard-wired with the desirability across the decision-making process).? https://en.wikipedia.org/wiki/Force-field_analysis Looking forward for your book.

要查看或添加评论,请登录

Mark W.的更多文章

  • RIF Incoming

    RIF Incoming

    My company is preparing for its first broad Reduction in Force (RIF) in a generation - though there have been targeted…

    5 条评论
  • The New Triad?

    The New Triad?

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

    3 条评论
  • Confusion: Social Security

    Confusion: Social Security

    Last time I did an article on confusion around the chaos of financial aspects, with intent in time to get back it with…

    1 条评论
  • Red Tape

    Red Tape

    Reading through Senator Roger Wicker's Restoring Freedom's Forge this week, the quote of Admiral Hyman Rickover at the…

    5 条评论
  • Confusion

    Confusion

    For a second post, and maybe the immediate next few, I thought I would talk to the confusion around income generation…

    2 条评论
  • Ron Ross

    Ron Ross

    With Ron Ross' announced retirement this past week (Post | Ron Ross' Retirement), I thought I'd take some time to talk…

    4 条评论
  • Embracing Opportunity for Change

    Embracing Opportunity for Change

    My current company allows easy transitions to part time - and I've just ended the second week of it. I do see this as a…

    5 条评论
  • Evidence-Based Assurance

    Evidence-Based Assurance

    Some readers may have heard Michael McEvilley and/or I speak to evidence-based assurance. I forget when we even started…

    1 条评论
  • Visiting McNamara's Fallacy and Folly

    Visiting McNamara's Fallacy and Folly

    Talking about a pivot - I was about one thing on data/evidence fallacies with things security/resilience, and in…

    2 条评论
  • "Security" or Pseudo-Science

    "Security" or Pseudo-Science

    David Slater is a great follow. Safety and Security are closer related than most realize - much of what Michael…

    8 条评论

社区洞察

其他会员也浏览了