Key elements Dynamic Distributed MILS platform Dynamic MILS platform with deterministic networking Mechanisms for dynamic reconfiguration and configuration introspection Declarative dynamic architecture modeling 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 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 systems

1. CITADEL Platform Architecture
The Open Group Training - Context - CITADEL platform architecture 1

2. Top-level architecture of an
adaptive CITADEL system
The Open Group Training - Context - CITADEL platform architecture 2
Concept of operation
of the CITADEL platform

3. CITADEL Adaptive MILS Framework
 Key elements
 Dynamic Distributed MILS platform
● Dynamic MILS platform with deterministic networking
● Mechanisms for dynamic reconfiguration and configuration introspection
 Declarative dynamic architecture modeling 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 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 systems
The Open Group Training - Context - CITADEL platform architecture 3

4. 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
The Open Group Training - Context - CITADEL platform architecture 4

5. Top-level architecture of an
adaptive CITADEL system
The Open Group Training - Context - CITADEL platform architecture 5
The Planes of the CITADEL Framework

6. The Open Group Training - Context - CITADEL platform architecture 6
Planes of the CITADEL Framework
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(S)
Target
Config
(RE-)CONFIGURATIONPLANE
Config
Cmds
Config
Cmds
Config
Cmds
FDI
Exceptions
Exceptions
Exceptions
Exceptions
Introspection
Observations & Events
Certification
Assurance
Artifact

7. Schematic of CITADEL Framework
Plane interactions and system Model
The Open Group Training - Context - CITADEL platform architecture 7
The central formal artifact is the system model
The CITADEL Framework uses the system model for
various purposes
Parametrized
architecture
Properties
Reconfiguration
transitions
Certification
Assurance Plane
Model
Operational Plane
(dynamic application)
Foundational Plane
(dynamic platform)
Analysis
tools
Engineer
represents
specifies
is used by
Monitoring Plane
Configuration Plane
Adaptation Plane
FBK Software Modeling and Verification 13
Detailed training on each of the CITADEL Framework planes
are provided in the respective CITADEL training modules.

8. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 8
The Operational Plane(s)

9. MILS Policy Architecture:
“Boxes and Arrows Diagram”
Showing System Decomposition
C2
C4C1
C3
C5
Circles represent
subjects or objects
Arrows represent
information flow
Trusted
Subject
Represents logical structure
abstracted from physical resources
“Boxes” represent logical
or physical resources
Untrusted
Subjects
The Open Group Training - Context - CITADEL platform architecture 9

10. 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
The Open Group Training - Context - CITADEL platform architecture 10

11. Policy Architecture with Isolated Subsystems
R 1
R 2
MILS Platform
R 3
R 5
R 4
Q 2
Q 5 R 3Q1
R 4
The Open Group Training - Context - CITADEL platform architecture 11

12. MILS Platform
Q 2
Q 5
R 4
The Open Group Training - Context - CITADEL platform architecture 12
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

13. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 13
The Foundational Plane

14. Foundational Plane:
the MILS Platform definition
 The minimal MILS platform is a separation kernel
 The separation kernel idea was introduced by Rushby in
1981, and subsequently elaborated in the Separation Kernel
Protection Profile (SKPP)
 A separation kernel includes all of the hardware, firmware
and software that are required to satisfy the SKPP
 A MILS platform consists of a separation kernel plus zero
or more of the other MILS foundational components
 The MILS platform is defined by the MILS Platform Protection
Profile (MPPP)
 Each MILS foundational component includes all of the
hardware, firmware and software required to satisfy its PP
14The Open Group Training - Context - CITADEL platform architecture 14

15. The MILS Platform: Components
A MILS separation kernel (SK) is the base component of the MILS platform
Provides shared use of processor resources, memory, and device I/O spaces
Making these available in the form of “exported resources”
While permitting only explicitly permitted information flow among exported resources
The SK is the combination of the physical resources represented by the hardware,
and the firmware and software that is used to manage it securely
Additional MILS foundational components compose with the SK and each other
Each providing shared use of another kind of physical resource
Making these available as additional types of exported resources
Also managing information flow among the created resource abstractions
Each foundational component is the combination of physical resources represented
by hardware, firmware, and software.
MILS Network System (MNS), MILS Console System (MCS), MILS File System
(MFS), MILS Extended Attributes (MEA), MILS Audit System (MAS)
These foundational components combine to seamlessly provide a diverse
collection of exported resources from which systems may be constructed.
The Open Group Training - Context - CITADEL platform architecture 15

16. The MILS Platform: a Composition of
Foundational (resource-sharing) Components
SW
HW
SW
MP
SW
HW
SW
HW
SK
(MSK)
Network
(MNS)
Console
(MCS)
File
(MFS)
   
Exported
Resources
 Additive
Composition
Extended
Attributes
(MEA)
Audit
(MAS)
SW
HW
SW
MP
additive compositionality – e.g., a
Partitioning Kernel  Partitioning Net
= Partitioning (Kernel + Net)
MP = MILS Platform

The Open Group Training - Context - CITADEL platform architecture 16

17. 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.
The Open Group Training - Context - CITADEL platform architecture 17
Min

18. The MILS Platform: Assurance Ambitions
Security assurance requirements as found in MPPP, SKPP, MNSPP, and MCSPP
 Formal specification and verification required to achieve a high Evaluation Assurance Level
(EAL) according to the International Common Criteria
Additional MILS-specific assurance requirements
 Explicit assurance case, formal specification encouraged in PP/ST (Security Target)
Compositional assurance
 Composability of components assured by separation kernel functions/properties
 Additive compositionality of components implies
● MSK + foundational component acts as a separation kernel with added resource type
● Configuration-time cross-component configuration data coordination
● Initialization-time sequencing of component initialization
● Runtime independence of physical resource managing components
● MSK provides global resource identifiers for all exported resources
● Simple dependence by MILS Extended Attributes on memory and file storage to provide
a binding of extended attributes to exported resources of other foundational components
Abstract specification of platform components must be satisfied by refined component
specifications in component PPs and STs
 Consistency and proper refinement demonstrated when PPs and STs are evaluated
 Internal consistency and well-formedness of specs checked in each document
The Open Group Training - Context - CITADEL platform architecture 18

19. 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
The Open Group Training - Context - CITADEL platform architecture 19
Evidence
Evidence
Evidence

20. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 20
The Configuration Plane

21.  In the CITADEL framework, the configuration plane (XP),
plays an executive role which is to reconfigure the
Adaptive MILS system.
 Reconfiguration performed by XP covers mainly:
 The MILS policy architecture:
● subjects,
● communication between subjects, and
● the deployment of subjects.
 The MILS monitoring system:
● monitor applications, and
● monitoring virtual sensors.
 To achieve reconfiguration, XP interacts with other
planes of the CITADEL framework, namely the
Adaptation Plane (AP), the Monitoring Plane (MP), the
Operational Plane (OP) and the Foundational Plane (FP)
as shown in the next slide.
(Re-)Configuration Plane (XP)
The Open Group Training - Context - CITADEL platform architecture 21

22. XP Interactions with other planes
22
Adaptation Plane
(AP)
1- target
configurationnotification
2- reconfiguration
step
notification
2- reconfiguration
step
notification
Foundational (FP)/Operational Planes (OP)
…
Reconfiguration Plane
(XP)
Monitoring Plane (MP)
Node 1
S1 Si
…
TSN
Net.
PikeOS
Node M
Si+1 SN
…
PikeOS
1. XP receives a target configuration
from AP, i.e. the new system
configuration to reach.
2. Based on that, XP issues
reconfiguration commands to
reconfigure MP and OP.
3. XP always expects a
notification back from
the reconfigured
planes.
Training - Context - CITADEL platform architecture
4. Notification back to AP.
The Open Group 22

23. Reconfiguration operation: overview
23
Configuration
Plane
Operational/Foundational Planes
Curent intermediate
Configuration
Target intermediate
Configuration
…
Intermediate Abstract Configurations
Current Concrete
Configuration
…
Small Step
Small Steps
Primitive Primitives
Target Concrete
Configuration
…Primitives
Current Architecture
(SLIM Model + Parameter Vector1)
Adaptation
Plane
Target Architecture
(SLIM Model + Parameter Vector2)
Big Step
XP proceeds by refining a high-level reconfiguration objective (big step) into
an intermediate plan (small steps) then into low-level primitives.
Training - Context - CITADEL platform architectureThe Open Group 23

24.  The Configuration plane is designed as
a back-end and a front-end
 The back-end
● encompasses the Reconfiguration
Planner and the Reconfiguration State
Controller
 The front-end
● consists of multiple instances of
Configuration Change Agents
XP Overall design
The Open Group Training - Context - CITADEL platform architecture 24

25. Deployment of new configuration by the XP
The Open Group Training - Context - CITADEL platform architecture 25
reconfiguration
commands
Foundational (FP)/Operational Planes (OP)
…
XP back-end
Node 1
S1 Si
…
TSN
Net.
PikeOS
Node M
Si+1 SN
…
PikeOS
Planner
Controller
Reconfig.
planNotification
XP
front
-end
XP
front
-end
Notification
Notification
 The XP back-end is to be deployed on the same node as
the other CITADEL framework components. It is
deployed as a partition on PikeOS.
 The front-end is deployed on the different nodes of the
distributed MILS Platform. Each node of the system
hosts an XP front-end Configuration Change Agent
(CCA).

26. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 26
The Monitoring Plane

27.  Monitors components in the Operational Plane and
resources in the Foundational Plane, and generates alarms
when it detects specified patterns, and reports to the
Adaptation Plane
 Monitors may be derived form the architectural model
properties and other security policy specifications
 CITADEL MP performs both Network and State monitoring
 Network monitoring extracts and analyses message
features
 Strategies: signatures, white-box, learning, feature-binning
 State monitoring is based on the flexible and extensible
Kaspersky Security System (KSS), which provides a
framework for the construction of monitoring applications
and the virtual sensors they need to detect network and
state events and changes
 Allows specification of security and monitoring policies
distinct from the monitoring implementation and
applications
Monitoring Plane (MP)
The Open Group Training - Context - CITADEL platform architecture 27

28. Architectural Design Pattern
of the Kaspersky Security System
The Open Group Training - Context - CITADEL platform architecture 28
Detached Security System
Architectural Design
Kaspersky Lab UK Training – Advanced Technical Module – State Monitoring

29.  The KSS architecture and its framework
are designed to provide support for
diverse security policies, including
monitoring policies
 The specification framework consists of
● a set of policy templates for the security
server
● interface definition language (IDL)
● component definition language (CDL)
● entity definition language (EDL)
● security specification language (CFG)
● toolchain to translate CFG specification into
executable code
Monitoring Specification
The Open Group Training - Context - CITADEL platform architecture 29

30. KSS: Policy Definition Framework
The Open Group Training - Context - CITADEL platform architecture 30
KSS: Policy Definition Framework

31. Multilayer security configuration
The Open Group Training - Context - CITADEL platform architecture 31
Multilayer security configuration

32. Implementation Example
The Open Group Training - Context - CITADEL platform architecture 32
Implementation Example

33. Implementation scheme for
CITADEL state monitoring
The Open Group Training - Context - CITADEL platform architecture 33Kaspersky Lab UK Training – Advanced Technical Module – State Monitoring 37
Implementation Scheme

34. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 34
The Adaptation Plane

35.  Adaptation Engine is the core component
of the AP
 Evaluator is a helper component that
performs model-based reasoning to find
the next architectural configuration
 Context Awareness provides a display of
current context on the MILS Console
System
The Adaptation Plane (AP)
The Open Group Training - Context - CITADEL platform architecture 35

36. Adaptation Plane architecture
The Open Group Training - Context - CITADEL platform architecture 36

37. Adaptation plane
components and their inputs
The Open Group Training - Context - CITADEL platform architecture 37

38. Handling of alarms/commands by the
Adaptation Engine
The Open Group Training - Context - CITADEL platform architecture 38

39. Introduction to the
CITADEL components
The Open Group Training - Context - CITADEL platform architecture 39
The Certification Assurance Plane

40.  Certification is a judgment that a system is
adequately safe/secure/whatever for a given
application in a given environment
 Should be based on explicit credible evidence
 Should be systematic and repeatable
 CP builds a “Certification Assurance Artifact”
that can be presented on demand to a
certification authority
 Adaptive MILS Evidential Tool Bus (AM-ETB)
is a subsystem that automates the building
and maintenance of an assurance case for
the current configuration of the system
The Certification Assurance Plane (CP)
The Open Group Training - Context - CITADEL platform architecture 40

41.  Assurance case patterns are instantiated
to create a concrete assurance case
 Patterns may be added to the library
 Components in patterns may be
modified, added or deleted
 Patterns developed for CITADEL
represent the top-level claims of the
system, the Adaptive MILS planes, and
the operational plane
Modular Assurance Cases
The Open Group Training - Context - CITADEL platform architecture 41

42. Top-level Adaptive MILS argument
The Open Group Training - Context - CITADEL platform architecture 42

43. Assurance case argument pattern
structure
The Open Group Training - Context - CITADEL platform architecture 43

44.  instantiation of AC patterns
 develop/instantiate recursively the pattern
goals for given parameters (system model
and properties, tools)
 produce a flat assurance case
 track errors
 when evidence nodes are encountered
trigger evidence (re-)construction and (re-
)validation
AM-ETB Core Workflow
The Open Group
Training -
Context -
CITADEL44

45. AC Pattern Instantiation: Example
{P} is safe
{P} is deadlock-free
foreach standard {X} in iso-
xxx, iso-yyy
{P} conforms to {X}
{X} certificate for
{P}
S2S1
Policy architecture « A »
{P} is deadlock-free
foreach subject {S}
of {P}
{P} composition is
deadlock-free
{S} is deadlock-free
Proof-of-
deadlock-
freedom {S}
Deadlock-free
composition {P}
Top (main) AC pattern
The Open Group
Training -
Context -
CITADEL45

46. AC Pattern Instantiation: Example
{P} is safe
{P} is deadlock-free
foreach standard {X} in iso-
xxx, iso-yyy
{P} conforms to {X}
{X} certificate for
{P}
S2S1
Policy architecture « A »
A is safe
A is deadlock-free foreach standard
A conforms to iso-
xxx
A certificate for
iso-xxx
A conforms to iso-
yyy
A certificate for
iso-yyy
Pattern « call » needing to be
further instantiated…
The Open Group
Training -
Context -
CITADEL46

47. The Open Group Training -
Context -
CITADEL
47
AC Pattern Instantiation: Example
{P} is deadlock-free
foreach subject {S}
of {P}
{P} composition is
deadlock-free
{S} is deadlock-free
Proof-of-
deadlock-
freedom {S}
Deadlock-free
composition {P}
S2S1
Policy architecture « A »
A is deadlock-free
foreach subject S of
A
A composition is
deadlock-free
S1 is deadlock-free
Proof-of-
deadlock-
freedom S1
Deadlock-free
composition of A
S2 is deadlock-free
Proof-of-
deadlock-
freedom S2

48. The Open Group Training -
Context -
CITADEL
48
AC Pattern Instantiation: Example
A is deadlock-free
foreach subject S of
A
A composition is
deadlock-free
S1 is deadlock-free
Proof-of-
deadlock-
freedom S1
Deadlock-free
composition of A
S2 is deadlock-free
Proof-of-
deadlock-
freedom S2
S2S1
Policy architecture « A »
A is safe
A is deadlock-free foreach standard
A conforms to iso-
xxx
A certificate for
iso-xxx
A conforms to iso-
yyy
A certificate for
iso-yyy
Assurance Case for « A »
Current implementation available at svn/Tech-Notes/ETB1/code/v1/

49.  Assurance cases for static MILS
 Modular presentation of argumentation and
evidence for system properties
 Structured according to system model
 Dynamic assurance cases for the Adaptive
MILS Framework
 Patterns to cover dynamic architectures
 Just-in-time assurance case update for new
configuration
 “Certifier-in-the-Box” – must successfully
create an assurance case for the next
configuration
The Open Group Training - Context - CITADEL platform architecture 49
MILS Assurance Cases