Mils architectural approach

MILS Architectural Approach
The Open Group Training - Context - MILS Architectural Approach 1

Key characteristics of MILS

Key characteristics of Modern MILS
 MILS is a component-based approach to secure and dependable systems
design and implementation that encourages a marketplace of general-
purpose commercial components, leading to lower development cost
 MILS is a two phase approach (John Rushby’s “Modern MILS”):
 Design a Policy Architecture
● Abstract architecture diagram represented by “boxes and arrows”
● Operational components and architecture achieve system purpose
● Assumes the architecture (components and connectors) will be
strictly enforced in the implementation
 Implement the policy architecture on a robust resource-sharing platform
● MILS foundational components (FCs) enable sharing of physical
resources, creating strongly separated “exported resources”
● FCs should be individually developed and assured according to
standardized specifications
● FCs compose “additively” to form a distributed trusted sharing
substrate, the MILS Platform
 MILS provides a compositional approach to construction, assurance, and
system certification

History and Future of
MILS
Pre-MILS, Classic, Modern, and Progressive MILS
and beyond

 We define the “Eras” in the emergence
and evolution of MILS 1980-2020
 Pre-MILS
 “Classic” MILS
 “Modern” MILS
 “Progressive” MILS
 MILS 2020 and beyond
 Overview of the “reservoir” of present
and past MILS research and development
activities
History and Future of MILS

 Seminal work by John Rushby
 Study of ongoing secure systems efforts 1980
 Design and Verification of Secure Systems – original
Separation Kernel paper 1981
 Separability 1982-1983
 Non-interference and channel control 1982-1992
 Partitioning for security and safety 1999-2003
 MILS research at SRI 2004-2012 Rushby-DeLong
 MILS is born and advances through its “Eras”
 “Classic” MILS 2000-2007 various parties
 “Modern” MILS 2008-2012 Rushby-DeLong
 “Progressive” MILS 2012-Present, DeLong et al
● Distributed MILS (D-MILS project)
● Dynamic MILS and Adaptive MILS (CITADEL project)
● Heterogeneous (CPU/GPU/FPGA) MILS Platforms (PHANTOM
project)
The Birth of MILS and its Evolution

The Emergence of “MILS”
 “MILS”, by that name, emerged circa 2000
 Originally “MILS” stood for Multiple Independent Levels of Security. In 2007
members of The Open Group’s Real Time and Embedded Systems (RTES) Forum
recognized that the expanded acronym was not an accurate characterization* and
took a decision to henceforth regard “MILS” not as an acronym but as a proper
name for the architectural approach.
 MILS was initiated in part upon a recognition that commercial partitioning kernels
for avionic safety could be applied to high assurance security.
 Strong partitioning (“separation” or “isolation”) provides a basis for the prevention
of information flow, upon which “controlled information flow” can be established.
 This led to the rediscovery of Rushby’s Separation Kernel (SK), in the Design and
Verification of Secure Systems (1981), to become the foundation for MILS.
 Development of Common Criteria “protection profiles” for partitioning kernels (The
Open Group) and for separation kernels (NSA) ensued from 2000 until 2008.
 Other associated protection profile developments were also undertaken.
 The Open Group’s Real Time and Embedded Systems (RTES) Forum
became the home to an active community of interest in MILS (the “MILS
Initiative”).
* “multiple levels of security” is easily confused with multilevel security (MLS), which is a legitimate
application of MILS, but the implied ordering of “levels” does not accurately characterize MILS.
“Multiple independent domains” would be more accurate, but even the use of “independent” is not
generally valid.

The Evolution and the Eras of “MILS”
 2000-2007 This is the Era of “Classic MILS” during which MILS proliferated
 The seminal work of Rushby was recognized and built upon
 Other contributors included: Vanfleet, Dransfield, Alves-Foss, Harrison, Oman, Taylor,
Greeve, Wilding, Richards, Uchenick, Millen, Delange, Calloni, Hardin, DeLong, Beckwith
 2004 – Rushby at SRI International, who had been working on safety, now became
engaged with the MILS community
 2004-2012 Research on MILS was funded on several projects at SRI International
 2008 – Rushby declared the advent of “Modern MILS” as the concepts had crystalized
 2008-2012 – The Era of “Modern MILS”, in addition to establishing the foundations,
spawned the ideas of principled delivery, configuration & initialization, just-in-time
MILS certification, as well as distributed, dynamic & adaptive MILS
 2012-2019 and beyond – the Era of “Progressive MILS”, built on Modern MILS results
 Principled Delivery, Configuration and Initialization of MILS Components & Integrations
 Distributed MILS – assured scalable distributed deterministic systems
 Dynamic MILS – assured reconfigurable systems, cloud computing, IoT systems
 Adaptive MILS – assured critical infrastructures, adaptive & resilient systems
 Heterogeneous MILS – non-separation kernel-based MILS platforms (CPU, GPU, FPGA)
 Mixed-Critical MILS – assured mixed-critical cyber-physical systems
 Autonomous MILS – assured self-healing, adaptive, and intelligent cyber-phys systems

History and Future of
MILS
Overview of a palette of
MILS research and development
(The Reservoir of MILS)

Implementation
Science
StandardsAssurance &
Certification
Products
Dissemination
Vision
Constitution
Manifesto
Lecture
Notes
RTI
OIS
GHS
Math/
Logic
Lynx WRS
SKPP
MPPP
Concepts
Compos.
Certif’n
DCI
Galois
System Integrators
Example
CCAE
LAW
Who and What?
Overview of
MILS Research and
Commercial Activities*
Activity Categories
Research
CDSs
MCSPP
MNSPP
LM
EADS
ICCC
RCI
DASC
TOG
RCI
Found’nl
Comps
Opera’nl
Comps
Compos.
Assur. Cases
Inter-op
Assemblies
Ref Impls
TOG Mils™
Scheme
SYSGO
The Open Group
Ongoing
AADL
DeterLab
MASPPMILCOM
Devel’t
Practice
Mils™
D-MILS
Future
Thales
Distributed
MILS
EURO-MILS
MILS Workshop
Smart
Phone
Product
Evals
MCNF
Patterns
D-MILS
EURO-MILS
D-MILS
EURO-MILS
D-MILS
EURO-MILS
MFSPP
MEAPP
Commercial
UNSW
Reservoir
of MILS
TSE
UGA
Conf
papers
TU/e SRI
T-Systems
IK4
atsec
* and others not
mentioned due
to space limits
Mixed-Crit
MILS
Autonomous
MILS
MILS-
AADL
GD NGC
Raytheon
CITADEL
PHANTOM
CITADEL
CITADELPHANTOM
GSN, CAE,
SACM
CertMILS
FBK
Dynamic
MILS
Adaptive
MILS
CITADEL

Concepts of the MILS
architectural approach
MILS “policy architecture”
Components, Connections and Local Policies

 We say “The MILS Architectural Approach” rather
than “The MILS Architecture”
 An architecture is a specific collection of
components and their connections
 The term “MILS architecture” is sometimes used in
error to refer not to a specific architecture but to
an approach.
 Thus, we are careful to say “MILS Architectural
Approach” or just “MILS approach”
 (If there is any “MILS architecture”, it is the
architecture of the MILS platform, that is, the
collection of foundational components and their
connections that comprise the platform.)
 The specific architecture of an application
developed using the MILS architectural approach
we refer to as a “policy architecture”
The MILS Architectural Approach

MILS Policy Architecture
C2
C4C1
C3
C5
Circles represent
architectural
components
(subjects /
objects)
Arrows represent
interactions
Suitability of the architecture for some purpose
presumes that the architect’s assumptions are met
in the implementation of the architecture diagram.
C6
The absence of an
arrow is as significant
as the presence of one
This component
has no interaction
with any other
Components are
assumed to perform
the functions specified
by the architect
(trusted
components enforce
a local policy)
The architecture
expresses an
interaction policy
among a collection
of components
Trusted
Subject

 A specific composition of MILS Foundational Components
(FCs), we are primarily concerned with the first three:
 Separation Kernel (the minimal MILS platform)
 MILS Network System (MNS)
 MILS Console System (MCS)
 Others (defined but not yet implemented)
● MILS File System (MFS)
● MILS Extended Attributes (MEA)
● MILS Audit System (MAS)
 Most of the MILS foundational components comprise both
hardware and software (and firmware if present)
 Specifically, these foundational components are not just
software!
 E.g. a Separation kernel is the software and the processor it
runs on; a MILS Console System is the software and the
user interface devices, controllers, and associated firmware
and drivers; a MILS File System is the storage device, the
controller, the firmware, the file system software, and APIs.
MILS Platform

The Distributed MILS Platform
SW
HW
SW
HW
SK MNS MCS
 
Exported
Resources
 Additive
Composition
SW
HW
additive compositionality property – e.g., a
Partitioning kernel  Partitioning network system
= Partitioning (kernel + network system)
MNS = MILS Network System
MCS = MILS Console System
Console for
some AppsDistributed MILS nodes
The minimal MILS platform is SK alone.
The Distributed MILS Project (EC FP7)
implemented Distributed MILS nodes
with SK and MILS Network System (MNS)
(MNS) using Time-Triggered Ethernet,
and one of the D-MILS demonstrators
implemented a special-purpose
MILS Console System (MCS).
CITADEL implements a new MNS
using Time-Sensitive Networking (TSN)
with a new SK.
An updated version of the D-MILS
MCS was developed for CITADEL.
Min

MILS Platform – Provides Straightforward
Realisation of Policy Architecture
Architecture
Realisation
SK, with other MILS
foundational components,
form the MILS Platform
allowing operational
components to share
physical resources while
enforcing Isolation and
Information Flow Control
Validity of the architecture
assumes that the only
interactions of the circles
(operational components)
is through the arrows
depicted in the diagram
R 1
R 2
R 3
R 5
R 4
MILS Platform

“Modern MILS” Platform Architecture – a composition of
foundational components creating one or more Operational Planes
P 1
P 2
Separation Kernel 
P 3
P 5
P 4 Configuration Data
Configuration Data
CONFIGURATIONPLANE
FOUNDATIONAL PLANE
OPERATIONAL PLANE
MFS
MNS
MEA
MCS
MILS Platform
The MILS Platform is
an abstraction of the
Foundational Plane
The MILS Foundational Plane
is the composition of MILS
foundational components
The Configuration
Plane runs off-
line in static MILS
Operational Plane(s) comprise
operational components of the
application’s policy architecture

MILS Platform
Q 2
Q 5
R 4
Isolated Subsystems as Distinct “Operational” Planes
R 1
R 2
R 3
R 5
R 4
Q 2
Q 5 R 3Q1
R 4
MILS PlatformOPERATIONAL PLANE
R 1
R 2
R 3
R 4
R 5
MILS PlatformOPERATIONAL PLANE Q1 R 3
The two disconnected
components of this policy
architecture represent
distinct subsystems or
applications …
… and may be
thought of as distinct
operational planes.
… and may be
considered as distinct
operational planes.
Planes can be used as a convenient
organisational principle to facilitate
conceptual understanding or graphical
representation of complex systems

 Applications as Operational Planes
 Distinct subsystems of an application, or
 Distinct applications
 E.g., a communications subsystem sharing
a platform with a cyber-physical control
subsystem
 Major subsystem planes of extended MILS
 Operational planes dedicated to system
support functions
 E.g., Monitoring Plane, Configuration Plane
Using Planes in a complex system

MILS Foundational, Operational, Monitoring, and
Configuration Planes
P 1
P 2
Separation Kernel 
P 3
P 5
P 4
Configuration Data
Configuration Data
Configuration Data
CONFIGURATIONPLANE
FOUNDATIONAL PLANE
OPERATIONAL PLANE
MONITORING PLANE
MFS
MNS
MEA
MCS
PERFORMANCE
DEBUG
HEALTH
RESOURCE
MILS Platform
MILS Platform

 Distributed MILS Platform
 Scalability beyond a single computer
 Geographic distribution
 Dynamic MILS Platform
 Standalone or Distributed MILS Platform
 Extended for dynamic reconfiguration
 Mode changes and/or generalized reconfiguration
 Basis for a wide range of adaptation strategies
 Adaptive MILS Systems
 Dynamic MILS Platform plus adaptation framework
 Adapt operational system to changing conditions
 Resilience to environment changes and failures
Extensions to basic MILS concepts
and additional capabilities provided

 CITADEL Project use case demonstrators
 Partners represent use cases needing one
or more of the MILS extension aspects:
distributed, dynamic, and adaptive
 Multiple critical infrastructure domains:
● Communications
● Transportation
● Manufacturing
 All use cases are assurance-critical
Demonstration of extensions

Standalone versus
Distributed MILS Systems

CITADEL builds on Distributed MILS*:
Policy architecture deployment spanning nodes
Node Hardware
SK
MNS
Node Hardware
SK
MNS
Node Hardware
SK  MNS
Foundational Plane+ 
Node Hardware
Subjects SubjectsSubjects
* European Commission FP7
ICT-2011.1.4 Trustworthy ICT
Project #318772
2012 – 2015
Distributed MILS concept
originated with the
MILS Network System
(MNS) Protection
Profile in 2010
Distributed MILS nodes D-MILS platform
Minimum of SK and MNS
foundational components

MNS exports logically
unidirectional “wormholes”
that span D-MILS nodes
Node Hardware
SK  MNS
Foundational Plane
Node Hardware
Subjects
Wormhole
D-MILS Node 1 D-MILS Node 2
Relocatable subjects communicate
with resources without
knowing on what node the
resource resides. (A subject
that controls a local device
on a node is not relocatable.)
This “global information flow
policy” defines three
inter-node flows.

The Distributed MILS Platform
SW
HW
SW
HW
SK MNS MCS
 
Exported
Resources
 Additive
Composition
SW
HW
additive compositionality property – e.g., a
Partitioning kernel  Partitioning network system
= Partitioning (kernel + network system)
MNS = MILS Network System
MCS = MILS Console System
Console for
some AppsDistributed MILS nodes
The minimal MILS platform is SK alone.
The Distributed MILS Project (EC FP7)
implemented Distributed MILS nodes
with SK and MILS Network System
(MNS) using Time-Triggered Ethernet.
One of the D-MILS demonstrators
implemented a special-purpose
MILS Console System (MCS).
CITADEL implements a new MNS
using time-sensitive networking (TSN)
with a new SK.
An updated version of the D-MILS
MCS was developed for CITADEL.
Min

Static vs Dynamic
(reconfigurable) MILS Systems

Overview of Dynamic MILS
 Conventional approaches to high-confidence systems
have been static: fixed implementation, thoroughly
scrutinized through analysis and testing
 SKPP* described several feasible options for
reconfiguration of separation kernels
 Dynamic total configuration change – requires restart
 Constrained selective configuration change –
unchanged portion of system continues to operate
 Dynamic MILS platform has reconfiguration mechanisms
and (potentially) a configuration change policy
 Configuration change monitor constrains configuration
change according to configuration change policy(ies)
Training - Context -
MILS Architectural
* Separation Kernel Protection Profile
The Open Group 28

Dynamic MILS Configuration Change Examples
F2
F4F1
F3
F5
F2
F4F1
F3
F6
F2
F4F1
F3
1a 1b 1c
2a 2b 2c 2d 2e
Example 1
Example 2
1a and 2a represent current configuration states …
… 1c and 2e represent target configuration states

Dynamic MILS – a foundation for robust
adaptation and resilience
 Classic MILS – robust systems through simplicity
 Extended with reconfiguration mechanisms
 And policy-driven reconfiguration constraints
 Within a flexible framework for the integration of
new resilience strategies and techniques
 A hierarchy of monitors and decision procedures
mediate requests for, and execution of,
configuration change operations
 Anticipated, routine changes executed
“deterministically”
 Response to unanticipated change may consult
higher-level models to dynamically synthesize new
target configurations
MILS ArchitecturalThe Open Group 30

 The MILS architectural approach along with a statically
configurable MILS platform enables a designer to create a
vast array of high-assurance systems backed by an
assurance case that includes the guarantees provided by
the platform, allowing high levels of traditional certification.
 The MILS architectural approach along with a distributed
MILS platform enables a designer to create scalable and
physically distributed, deterministic, high-assurance MILS
systems with assurance case for the distributed platform,
allowing high levels of traditional certification.
 The MILS architectural approach along with a dynamically
reconfigurable (distributed) MILS platform enables a
designer to create systems that can assume new
configurations while in operation. While this enables a
designer to create (in principle) almost any imaginable
MILS system, the new capabilities come with added
assurance burdens, and challenges for traditional
certification practice.
MILS Assurance and Certification

Dynamic vs Adaptive
MILS Systems

 The dynamically reconfigurable MILS
platform poses at least two new
challenges:
 The assurance of the dynamically
reconfigurable MILS foundational
components and their composition as a
reconfigurable platform.
 The assurance of applications and systems
that take advantage of the reconfigurable
platform to adapt to changing conditions.
Reconfiguration and Adaptation as a
new quality

 This is a bounded problem and it is not
too difficult to see how to solve it.
 The platform must maintain its key
characteristics between reconfigurations.
 The mechanisms of reconfiguration must
behave in a way allows one to
demonstrate that the platform can
maintain its key characteristics over
sequences of reconfiguration operations
subject to certain specific constraints.
 The formal models must provide the
above to enable an assurance case for the
reconfigurable platform.
Assurance of the Dynamic MILS Platform

 This is a potentially open-ended problem,
and it is not easy to see how to solve it in
its most general case.
 In order to further our own rule of
“conservative extensions” of MILS, we
want to do this in a way that preserves
the ability to achieve assurance.
 Therefore, formal models must exist to
provide objective evidence as a basis for
an assurance case.
 And, we must convince certification
authorities to embrace a paradigm they
have previously regarded untenable.
Assurance of dynamically reconfigured systems

 Traditionally, for certification, a system
along with supporting artifacts, was
presented to a certifier for approval to
operate in an environment that met
specific assumptions.
 In the past, a system that was modified
by its developer to account for new
requirements or operating assumptions
could be re-certified by resubmission with
modified artifacts for reconsideration.
 The modified system was subject to
similar scrutiny before approval.
Traditional Certification Paradigm

 For a dynamically reconfigurable certified
system, the scrutiny for recertification
must somehow be incorporated into the
reconfiguration cycle.
 The certification criteria must be
precisely specified and made objectively
checkable.
 This is how we conceptualize the model
of dynamically reconfigurable systems.
Modeling dynamic reconfiguration

…

Operational
Interval
Trace of
System
States

s0
1
Configuration
Property
Conformance Property
 
Requirements R

R – requirements specification
 - conformance property
 - interval configuration property
Static
Configuration Requirements
are fixed
Conformance property captures
the Requirements and can be
objectively evaluated
Configuration property
represents a strict relation on
the configuration state data
The system exhibits a trace of
states that conform to the
configuration property

…
1
Operational
Interval 1
…
2
Operational
Interval 2
Trace of
System
States

s0
1
s0
2
Interval Configuration
Properties
 

Requirements R

Rk – requirements specification
i - interval configuration property
Total Configuration
Change
restart
Requirements
are fixed
A distinct new
configuration is
evaluated
according to the
Conformance
Property
The system is
restarted with the
new configuration
A new
operational
interval
exhibits
new
behaviours

…
1
Operational
Interval 1
…
2
Operational
Interval 2
Trace of
System
States
state

s0
1
s0
2
Interval Configuration
Properties
 

Requirements R
. . .

R
R – requirements specification
i - interval configuration property R - reconfiguration transition
. . .
Dynamic
Configuration Change Requirements
are fixed
Distinct new
configurations
are evaluated
according to the
Conformance
Property
The system transitions
to a new configuration
without restart
A new
operational
interval
exhibits
new
behaviours

Reconfiguration Big and Small Steps
Current
Config
Dynamic Re-Configuration Primitives
Target
Config
Reconfiguration
Plan
1 -> 2
1 2

R
RIndividual
Configuration
Properties
Parameterized Architecture
Properties
System Requirements
…
Big-Step
Re-Configuration
Transition
Small-Step
Configuration
State Transitions
Configuration State
 R
1  2 

 Ability to model and analyze dynamic
platforms and adaptive systems
 Ability to maintain now for dynamic
systems the potential for high assurance
levels and certification that was achieved
in static MILS
 “Just-in-time certification” – Ability to
re-certify on-the-fly and to produce an
assurance case and supporting evidence
(Certification Assurance Artifact) on-
demand
New challenges posed by Dynamic
and Adaptive MILS

More challenges of Dynamic MILS (1)
 Traditional safety-critical domains have long,
stable deployments
 New applications for cyber physical systems target
fast-changing and unpredictable environments
 SKPP identified added assurance burden of
dynamic reconfiguration – this burden must be met
 Starting from static MILS systems and their
assurance cases, we conservatively extend MILS
to achieve high-assurance adaptive systems
 Has clear advantage over approaches to resilience
that do not start with a rigorous foundation

 Additional assurance burden
 Reconfiguration mechanisms add complexity
 Mechanisms for proposing new configurations
as solutions to problems posed by changing
environment
 Techniques for “safely” changing configuration
without disrupting unchanged portions
 “Simple assurance” of a static system
 Single execution session maintains critical
invariants
 Thoroughly analyzed for certification and
approval to operate

 Assurance of reconfiguration transitions
 Change the configuration state
 Move to a new set of invariants (or properties)
– Interval Configuration Property
 Overarching System Configuration Property
governs permissible changes to interval
configuration property
● Captured in CITADEL parameterized architectures
 May be generalized to deeper hierarchies,
including Requirements Change
● May be extended in the future with adaptation
techniques that pose greater assurance challenges

Assurance of MILS
Platforms and Systems

 MILS provides a platform on which to
establish and enforce an architecture
with high assurance.
 But how can we have assurance that the
architecture achieves our intended
objectives?
 We design the architecture to reflect the
properties we desire of the system.
 Then we reason from the properties of
the components, and the manner of their
composition, to the properties of the
system.
Architectural Aspect of Assurance

 Assurance can be scalable if done
compositionally.
 We start with what a system (or a
component) relies upon from its
operational environment, and claim the
guarantees it can make under those
conditions.
 We can decompose a system into
subsystems and components separately
build, and its assurance case into
subclaims, separately justified.
Compositional Assurance

System,
subsystem or
component
Inputs =
<In1, … , Inn>
a tuple
Composition Fundamentals
Inputs and Outputs; Relies and Guarantees
Relies Guarantees
Operational Environment
Behavior B( Inputs, Outputs ) or Property P( Inputs, Outputs )
are relations on traces, each property defining a set of traces
In1
Inn
Outputs =
<Out1, … , Outm>
a tupleOut1
Outm
Inputs =
trace( Inputs )
(a sequence
of tuples)
Outputs =
trace( Outputs )
(a sequence
of tuples)
...
...

S
Inputs Outputs
c
c
c
c
c
System S is made from
Components (or subsystems) c
Relation:
S ( Inputs, Outputs )
Relies and Guarantees are
properties: P ( Inputs, Outputs )
Relies Guarantees
S satisfies P if S is a subset* of P
traces(S) a subset of traces (P)
* More precisely, the sets of traces generated by S and P

A
B
C
Policy Architecture Assurance – Incremental
Rely/Guarantee (R/G) Compositional Reasoning
Relies Guarantees
S
A
B
a)
b)
c)
A
B
composite
composite’
R/G composition of A and B
A as part of a composite
B becomes part of new composite’ which is then composed with C to form S
A
Relies
Guarantees

Concrete and abstract components under composition
A
guarantee
rely (assume)
Bguarantee
rely (assume)
A B
Abstract and concrete component A
(may write as AA and AC to distinguish)
The concrete component is a refinement
of the abstract component. The abstract
component is greater in the sense that
it admits a greater set of behaviors.
connector
AA
ConcreteAbstract
We consider compositions of abstract components and
refinements of such compositions that preserve the
rely / guarantee relationships
Abstract components may have
rely / guarantee relationship
A connector represents
an information flow or
causality between components
>
ports

Abstract and concrete policy architecture elements
ComponentA ComponentC
ConnectorA
Abstract
Component
(container)
Concrete
(refined)
Component
Concrete is a
proper refinement
of abstract
Concrete not a
proper refinement
of abstract (e.g., I/O)
ConnectorC
Abstract
Connector
Concrete
Connectors
Refinements of abstract connector:
•buffered message passing
•synchronous rendezvous
•shared memory with synch.
•shared memory w/o synch.
•etc.
ComponentA >
ComponentC
ComponentA ≤≥
ComponentC
A refinement may later
be further refined( )
Information flow
or causality
Mode or
mechanism
Conn.
port

Abstract components: realised by units or composites
ComponentA
ComponentC
1
Abstract
Component
(container)
Concrete
Unit realisation
(monolithic)
Can serve for
the abstract
component
ComponentC
2
Concrete
Composite
realisation
Can serve for
the abstract
component
Equivalent unit
and composite
realisations are
interchangeable
with respect to
the abstract
component
≈

Example: Abstract policy architecture
of Rushby’s “Red-Crypto-Black” System
R
H
C
B
RedA
CryptoA
Header bypassA
BlackA
One may delete the dot
indicating the existence
a port associated with an
abstract component when
a connecter shown in an
architecture diagram makes
Its existence obvious.
Trusted local
policy-enforcing
component
Un-trusted
component
“Red-Crypto-Black” system:
Red is connected to a Red network
with sensitive data. This system
is presumed to be connected
to a mirror image across the Black
network.
Black is connected to a
network that cannot
protect sensitive data.
Therefore the data must
be encrypted on the Black
network.

Properties required of “Red-Crypto-Black” system
established architecturally by relying on properties of trusted
components H and C and the form of the composition
R
H
C
B
RedA
CryptoA
Header bypassA
BlackA
r h
cb
i o
Annotate connectors
Define properties
P ( Inputs, Outputs )
= plaintext ( i ) ∧
nonplaintext ( o )
H  nonplaintext ( h )
C  nonplaintext ( c )
plaintext ( i )
Trusted local
policy-enforcing
component
Un-trusted
component

Realisation of “Red-Crypto-Black” System
Step 1: architecture + un-trusted components
R
H
C
B
RedC
CryptoA
Header bypassA
BlackC
r h
cb
i o
Trusted local
policy-enforcing
component
Un-trusted
component
nonplaintext ( o )

Step 2: policy-enforcing component Header bypass
R
H
C
B
RedC
CryptoA
Header bypassC
BlackC
r h
cb
i o
nonplaintext ( o )
Trusted local
policy-enforcing
component
Un-trusted
component

Step 3: policy-enforcing component Crypto
R
H
C
B
RedC
CryptoC
Header bypassC
BlackC
r h
cb
i o
nonplaintext ( o )
Trusted local
policy-enforcing
component
Un-trusted
component

 Assurance cases for static MILS
 Pioneered in the D-MILS project with
assurance case patterns and automation
 Modular presentation of argumentation and
evidence for system properties
 Structured according to system model and
dependent on platform assurance case
 Dynamic assurance cases for Adaptive
MILS Framework
 Patterns to cover dynamic architectures
 Just-in-time maintenance of assurance
case for current configuration
 “Certifier-in-the-Box” – give certifiers
confidence that approach is trustworthy
MILS Assurance Cases

A MILS System Assurance Case
Compose assurance cases using Assume-Guarantee Reasoning
MILS System assurance requires the validity of three sub-cases
Assumptions from MILS System assurance case become obligations on the sub-cases
MILS
System
Claims
Sub-case
Sub-case
Sub-case
Policy Architecture
Environment
MILS System High-Level
Assurance Argument
MP
Claims
PA
Claims
Policy Architecture
Assurance Argument
MILS Platform
Assurance Argument
Env
Claims
Environment
Assurance Argument
Assume GuaranteeGuarantee Assume
MILS Platform

The MILS Platform (MP) Assurance Case
Compose assurance cases using Assume-Guarantee Reasoning
Assumptions of the MP assurance case are obligations on the MSK, MNS and MCS
components’ assurance cases
Assured Claims from component assurance cases become evidence for MP assurance case
MP
Claims
Sub-case
Sub-case
Sub-case
Inference rule
Inference rule
MILS Platform
Assurance Argument
MSK
Claims
MNS
Claims
MCS
Claims
Inference rule
Inference rule
Inference rule
Inference rule
Inference rule
Inference rule
MSK Assurance
Argument
MNS Assurance
Argument
MCS Assurance
Argument
Assume GuaranteeGuarantee
Evidence
Evidence
Evidence

The MILS architectural
approach as realised in
CITADEL
The Dynamic MILS Platform

 Each Dynamic MILS platform foundational component provides
primitives for dynamic (re-)configuration
 Together these primitives provide a coherent reconfiguration
interface for the MILS platform
 Each distributed MILS node has a Configuration Change Agent to
carry out reconfiguration instructions of the Configuration Plane
The Dynamic MILS Platform
Dynamically
reconfigurable
Separation
Kernel
Dynamically
reconfigurable
MILS Network
System (MNS)
Dynamically
reconfigurable
Distributed
MILS Platform
Dynamic (Re-)Configuration Primitives
Configuration
Change Agent(s)
Dynamically
reconfigurable
Time-Sensitive
Network Devs
Dynamically reconfigurable MILS Platform Node(s)

The MILS architectural
approach as realised in
CITADEL
The CITADEL Framework for Adaptive Systems

CITADEL
property spec
language
Language
translation
Dynamic
Separation
kernel
Dynamic
TTEthernet
Configuration
Change
Monitor Adaptive MILS
Evidential Tool
Bus
Static
Config
Tools
Configuration
Change Agent
Dynamic MILS
Platform
CITADEL
modeling
language Offline
Verification
Framework
Runtime
Monitoring
plug-in
framework
Offline
Configuration
Synthesis
Online
config’n
synth
Adaptive MILS
Runtime
Adaptation
System
Monitoring
System
Online
Verification
Framework
Dynamic
MNS
Certification
Assurance
Artefact
Repository
Config
Dynamic Config’n Primitives
Config
Chg
Policy
Adaptive MILS
Evidential Tool
Bus
CITADEL MILS Platform with Adaptation

CITADEL Adaptive MILS Framework (CF)
 Key elements
 Dynamic Distributed MILS platform
● Dynamic MILS platform with reconfigurable deterministic networking
● Mechanisms for dynamic reconfiguration and configuration introspection
 Declarative dynamic architecture modelling and verification
● Language to describe reconfigurable systems architecture, component
models, failure models and fault propagation
● Theory and framework for dynamic reconfiguration
● Theory and framework for adaptation
● Language to express critical dynamic system properties to be verified
● Compositional verification framework
 Monitoring, Adaptation, Configuration, & Certification Assurance Planes
 Assurance-based security evaluation methodology and runtime
mechanisms for just-in-time certification of adaptive MILS systems

 The key characteristics of MILS
 The beginnings and the evolution of
the MILS architectural approach
 The concepts underlying the MILS
architectural approach
 The extensions of progressive MILS
and the challenges they pose
 The role of assurance in MILS
 The realisation of the MILS
architectural approach in CITADEL
Summary of what’s been described

Planes of the CITADEL Framework (CF)
Separation Kernel FOUNDATIONAL PLANE
OPERATIONAL PLANE(S)
MONITORING PLANE / FW
MFS
MNS
MEA MCS
Fault Diagnoser
COMMSTATE
RESOURCE
P 1
P 2
P 3
P 5
P 4
MILS Platform
MILS Platform
CONFIGURATION
ADAPTATIONPLANE
Target
Config
CONFIGURATIONPLANE
Config
Cmds
Config
Cmds
Config
Cmds
FDI
Exceptions
Exceptions
Exceptions
Exceptions
Introspection
Observations & Events
Certification
Assurance
Artifact

Mils architectural approach

Recommended

Recommended

More Related Content

Similar to Mils architectural approach

Similar to Mils architectural approach (20)

More from RamnGonzlezRuiz2

More from RamnGonzlezRuiz2 (11)

Recently uploaded

Recently uploaded (20)

Mils architectural approach