A MILS™-based Security Assurance Case Template
Dylan McNamee, Galois Inc.
Dylan began with an important definition to set the base for the presentation and discussion: “An assurance case is evidence supporting a claim that a system, X, can be trusted to enable a mission, Y.” He indicated that an assurance case also does the following:
- It derives a set of attributes of the system, which are based on the system requirements and mission threats.
- It refines these attributes to a set of measurable properties.
- It measures those properties and expresses residual risk.
- Additionally, It enables stakeholders to make informed decisions, and system builders to monitor/maintain key properties dynamically, which is why it is so valuable.
Dylan provided a simple example of building an assurance case which involved pushing one-way data transfer from high integrity domains to low-integrity domains: medical sensor data out to consulting physicians. In relating this to MILS, Dylan concluded that MILS provides a default assurance case template and noted that the conversations enabled by a good assurance case are the point.
The Army Common Operation Environments (COEs)
Glen Logan, US Army
Glen Logan shared the RTES vision and how it ties to the concept of COEs. He highlighted several COEs that came before: Weapon System COE, Defense Information Infrastructure COE, Systems of Systems COE, before focusing on the main topic presentation, the Army COE. He referenced a Joint Memorandum issued by Vice Chief of Staff of the Army and Assistant Secretary of the Army.
Glen note that the COE Building Blocks include standards, products, architectures, and processes, and also noted the possibility that part of the future plans for COE may move to a selection of best software packages. The Army COE Includes four distinct computer/mission environments: enterprise, command post, mounted, soldier/sensor.
The timeline from design to implementation runs from FY11-FY17.
The presentation noted that there were two distinct environments in the COE: Aviation and the Ground-Vehicle domain. The Open Group standard, FACE is noted as playing a major role in the Aviation landscape of the COE, which to some extent depends on MILS™ and the RTES Forum’s Standard for MILS™ APIs that the Forum is working on. It was also noted that an ad hoc program is standing-up/managing the VICTORY (the Army/Ground-Vehicle domain) working group. There is a good deal of synergy here with Future NIE activities which may be a potential area to introduce RTES work products.
Component Competitions Readiness Levels (CCRL)
Gerard Walles, US Navy
Gerard Walles gave a Breakdown of Competition Static POV into major levels: Open Infrastructure, Acquisition, Roadmap, and Organization, and identified critical-essential areas of Organization which included: open data model, open API, open SKD/CDK, discussion of a plug-fest for demonstrating openness, Acquisition (verification and validation, unlocked supplier/vendor chain, data rights), and Organization (trained workforce: peer review of competition on openness at the component level, policy, and guidance).
He provided an interesting development model: that he called Personality Bands for CCRL – which was a bit of maturity graph of where a program should be at a certain phase of their development. He showed the differences in the phases of development between technical elements and the business model. The goal is to have a validation and verification processes to assess where a program really is in the open competition process. The presentation offered a breakdown of the Personality Bands, which can be used to provide relevant data that can be used by contractors or employees and indicates what needs to be done at the operational level and at the acquisition level to fill in the gaps. The analysis provides a set of milestones and a timeline to come up to the optimal level of openness. The goal is that before a program picks a sole-source contractor they will need to have gone through this analysis. Gerry indicated that he thinks this model will be applicable to all segments of the market, safety-critical, DoD, energy, etc., and indicated that if there were some pilots, this would be the best way to start building market adoption for this model.
Next steps for the Assurance Cases are to enumerate common use-cases for which the MILS™ and the Reliability Working Groups will likely be involved. Some suggestions that were discussed for a simple assurance case for MILS™ were: Console System using MILS™ and MILS Network Protection Profile.
Glenn will provide more information on the Army COE as it becomes available. And the MILS™ API Work Group will work at completing the Standard APIs so that they can be available for the FACE component of the COE.
Gerrard Walles will continue to work with the RTES Forum to see how the Forum can best help in moving the open competition model toward a “standard” model and through that help increase market adoption and further the cause of competition for open systems.
