It's about Assurance
LinkedIn Tools provided graphic

It's about Assurance

Last week I was in Melbourne Florida at a small gathering of military aviation focused folks including industry and multiple authorizing officials (AO) and folks from the AO offices. A kind of gathering that can spark a few articles.

I believe it was the last morning of our meetings when the government side folks were talking what was needed going forward and talked turned to need for descriptive or outcome focused regulation instead of prescriptive direction. The short of the discussion is the focus needs to be positively state what is needed rather than stating negative or some 900+ things to do to achieve ... what?

Within the midst of this discussion, one of the AOs present turned to me and stated "y'all should have named 800-160 Vol 1 'Systems Assurance Engineering'" and stating 'security', no matter how we defined it within, would still be thought of as a negative requirement.

In the instance, I knew he was right - but too late now (well, maybe for a future revision?).

Core to what we spoke Volume 1 is the need for trustworthiness and assurance - the outcome is really to deliver authorized intended behavior and outcomes and nothing else. That is, to assure the system does what it is supposed to and nothing else. We speak to delivering with the system the grounds for confidence in the claims for the system.

What my AO friend looks for in making a decision for an authorization to operate (ATO) is evidence, the core element of the grounds for confidence. Checking off a list of selected controls forms a weak form of assurance - or rather a insufficient set of evidence for many mission systems. Following a strong engineering process, with rigid analyses that produce evidence, is the core of the point of NIST SP 800-160 Vol 1 with its considerations needed for security.

Systems need to be build right the first time, not patched in endless cycles of vulnerability hunting and quick plugs.

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

What are we assuring? The system of interest? The security solution? Assurance cases are well described in ISO 15026 and leverage the processes of ISO 15288. V&V (IEEE1012). I agree that engineering security in systems is the answer. A strong engineering process, applied to security, would entail following ISO 15288 technical processes to develop the security solution FOR the system solution. That means that the security context needs to fit the system context. The security architecture fits the system architecture. This means analyzing the security needs, integral to the system needs, to identify measures of effectiveness and constraints properly. If we are developing security needs and requirements, where are the measures of effectiveness and performance aligned with the acquirer's/systems needs? I saw nothing in the draft Guide to Security Needs and Requirements that discusses MOEs, MOPs and TPMs. These are a critical element needed to measure if the security solution meets the system needs and provides assurance to the acquirer the system solution provides adequate safeguards to assure system operation for the contextual environment. We call this cyber mission assurance, a supporting element of mission assurance.

回复
Steve Pitcher

Senior Cyber Survivability Analyst at The Joint Staff

6 个月

To "positively state what is needed" is defining threshold performance requirements for both cybersecurity and cyber resilience, so cybersecurity compliance and cyber secure resilient engineering have specific requirements to achieve and sustain.

回复
Ryan Carr

Deputy Program Manager Engineering @ General Dynamics Mission Systems

6 个月

But what is the assurance being provided to prove? High Assurance Systems Engineering is targeted towards a few things, a major one being safety. If we look at the work of Dr. Shu-Kai Chin and Dr. Susan Older focused on HOL (higher order logic) which works to prove a design is secure logically. That alone would just show that the design was secure, but the implementation would likely fall short. If we look at HASE research, we would see the rigor you talk about applied to provide the proof that whatever was being built was done so correctly. Combine the two, and you get a formally defined and proven secure system, with formal verification. Which, is great in theory, but both of these take a lot of time (and therefore money) to do. They also take a lot of skilled and dedicated engineers to put the effort into learning the methods and then executing them. How do we make the jump from theory to actually being followed? I still personally think the RMF was fairly well thought out. Was it perfect? No. But how many people followed it, or for that matter, even read it? How do we ensure the transition to a 800-160 method doesn’t fall victim to same lackluster implementation?

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

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 条评论

社区洞察

其他会员也浏览了