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.
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.
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?