MILS is a high-assurance security architecture characterized by untrusted and trusted components and based on security models.
This chapter describes how to model a RTCS based on security architecture and services to perform security analysis.
1. MILS (Multi Independent Levels of security) architecture
MILS uses the divide and conquer approach to reduce the effort for security evaluation of a system.
MILS adopts a classification level for subjects and objects that guides information control.
MILS introduces many concepts that are represented in Cheddar.
A real-time critical system based on MILS security architecture is defined as follows:
- At least a processor and a core.
- Cheddar address spaces that represent MILS partitions.
- Cheddar tasks that represent MILS processes. Each task has to be assigned to an address space
- Cheddar shared resources such as messages and buffers that represent MILS Objects.
- For each task, object, and address space, there attributes that define their degree of sensitivity.
The Confidentiality_Level attribute can be Unclassified, or Classified, or Secret, or Top_Secret.
The Integrity_Level attribute can be Low, or Medium, or High.
- Each task and address space is characterized by the attribute MILS_component_type that specifies classification
in MILS architecture.
It can be SLS for Single Level Secure component, or MLS for Multi-Level Secure component, or MSLS for Multi Single-Level
Secure component.
- Cheddar dependencies that represent MILS communications. MILS messages can be modeled by asynchronous communication
Cheddar dependencies.
- In MILS architecture, information flow control is performed through trustworthy components such as access control guard,
MILS Message Router (MMR), downgrader, collator, etc.... These components are represented by tasks in Cheddar.
Each task is characterized by an attribute MILS_Task_Type that specifies whether a task is a regular application or
a security monitor. It can be Application, MMR, Guard, Collator, Downgrader,
or Upgrader.
Users should consider the above information in the XML file of a Cheddar-ADL system model.
2. Security services
This section is dedicated to how to perform security analysis based on some security models.
A security model describes the security strategy for a system to ensure security objectives.
Bell-La Padula, Biba, and chinese wall are examples of security models.
They were implemented in Cheddar to verify Cheddar ADL models which are their main point of entry.
- Bell-La Padula concerns confidentiality, which is the assurance of preventing the system from disclosing information.
It is based on the principle "No read up/No write-down". The implemented method "bell_lapadula (Sys: System )" checks
if the Cheddar ADL model "Sys" complies with the Bell-La Padula rules by returning the number of violations of
the "No read up/No write-down" rule.
- Biba concerns data integrity, meaning the protection of the system against unauthorized modifications.
It is based on the principle "No read down, no write up". The implemented method "biba (Sys: System)" checks
if the Cheddar ADL model "Sys" conforms to Biba rules by returning how many times the Read down and Write up rules are missed.
- Chinese wall model addresses conflicts of interest. The implemented method "chinese_wall
(Sys : System; COIs : array_tasks_set; M: in out matrice)" returns for the Cheddar ADL model "Sys",
the number of information flows that cause conflict of interest, based on the defined conflict of interest classes "COIs".
All these methods are available on the Cheddar svn repository at this
link.
3. Example of security analysis
In this section we present an example of ARINC 653 scheduling with Cheddar.
This example is stored in the file security.xmlv3.
It contains tasks with different security levels that lead to some security violations.
Some of these violations are already solved by the use of downgraders.
The security analysis of this model is shown in the screenshot below.
In this screenshot, there are 3 communications that violate integrity and 0 violations of confidentiality.
The confidentiality issues have been solved by downgraders in the model.
Contact : Frank Singhoff
mailto:singhoff@univ-brest.fr
Last update : April, the 4th, 2020