The Cyber Immune approach dictates how the system’s underlying architecture must be organized. We suggest using proven architectural security templates that significantly simplify development of truly secure and reliable systems. This sort of development process is faster and more efficient, and the result is more trustworthy.
There are several fundamental requirements for system architecture and design:
In this part we’ll discuss the first two requirements.
The underlying architectural patterns that the Cyber Immune approach suggests following are presented in the MILS 1 and FLASK 2 architectures. The equivalent of MILS under Russian standards is domain separation, which is the term we will use going forward. 3 4
A system that has domain separation is a system broken down into strictly isolated modules called security domains, with communications between these defined by the policy architecture and controlled by the system’s separation kernel. All other security features are implemented inside the isolated security domains.
This architectural approach rests on the conclusion of information security researchers that a system’s security is determined by two factors: how well system components are isolated from one another and the quality of these components’ own security features. 5 6
The strength of this approach is that you can assess and verify the security level of a system with domain separation within a finite time. For a sophisticated system with heterogeneous components, possibly from different vendors, this property becomes a requirement rather than just nice to have.
In a system with domain separation, each security domain relies on its own security features without trusting anyone but the separation kernel: the most trusted component in the whole system. The concept follows the same philosophy as Zero Trust, which has proven effective in ensuring enterprise network security. 7 MILS also follows the well-known Distrustful Decomposition secure design pattern. 8
The creators of the original FLASK architecture had a similar goal to the one pursued by the developers of domain separation. Both approaches dismiss a monolithic security kernel that handles all system security. FLASK developers, too, sought reliable control over communications between system modules, but they focused on flexible security policies. The ability to manage previously granted access permissions and the absence of centralized, pre-configured rules set by the security kernel are both essential for this flexibility.
The concept of security has been expanded, and no single definition can be considered final or suitable for all cases. However, any concept can be expressed in a security policy, so a generally acceptable system of defining and calculating policies must allow arbitrary expansion of both the set of policies and their types.
The task of managing access permissions includes control over the granularity, propagation and revocation of permissions. None of these three aspects are trivial. For instance, UNIX-like operating systems assign permissions to the handle of each opened file, so revocation will not affect files that are already opened. Controlling the propagation of permissions is a serious issue when using the popular Object Capabilities access control model. As in any system with discretionary access control, an object can grant permissions (capabilities) to another object, and tracking these can get extremely convoluted. The creators of FLASK proposed an architecture that became another widely known security template: separation into components that grant access based on predefined permissions (policy enforcement points) and components that calculate these permissions (policy decision points, also known as security monitors or servers) – see the image below.
The Cyber Immune approach to requirements for system architecture obligates system designers to follow the Distrustful Decomposition (DD) and Policy Decision Point/Policy Enforcement Point Separation (PDP/PEP) design patterns on the system level, in line with two architectural models: domain separation and FLASK (in its original microkernel version).
In the next part we explain requirements for architecture and design, and also touch on the Cyber Immune system integrity model.
The Cyber Immune approach dictates how the system’s underlying architecture must be organized. We suggest using proven architectural security templates that significantly simplify development of truly secure and reliable systems. This sort of development process is faster and more efficient, and the result is more trustworthy.
There are several fundamental requirements for system architecture and design:
In this part we’ll discuss the first two requirements.
The underlying architectural patterns that the Cyber Immune approach suggests following are presented in the MILS 1 and FLASK 2 architectures. The equivalent of MILS under Russian standards is domain separation, which is the term we will use going forward. 3 4
A system that has domain separation is a system broken down into strictly isolated modules called security domains, with communications between these defined by the policy architecture and controlled by the system’s separation kernel. All other security features are implemented inside the isolated security domains.
This architectural approach rests on the conclusion of information security researchers that a system’s security is determined by two factors: how well system components are isolated from one another and the quality of these components’ own security features. 5 6
The strength of this approach is that you can assess and verify the security level of a system with domain separation within a finite time. For a sophisticated system with heterogeneous components, possibly from different vendors, this property becomes a requirement rather than just nice to have.
In a system with domain separation, each security domain relies on its own security features without trusting anyone but the separation kernel: the most trusted component in the whole system. The concept follows the same philosophy as Zero Trust, which has proven effective in ensuring enterprise network security. 7 MILS also follows the well-known Distrustful Decomposition secure design pattern. 8
The creators of the original FLASK architecture had a similar goal to the one pursued by the developers of domain separation. Both approaches dismiss a monolithic security kernel that handles all system security. FLASK developers, too, sought reliable control over communications between system modules, but they focused on flexible security policies. The ability to manage previously granted access permissions and the absence of centralized, pre-configured rules set by the security kernel are both essential for this flexibility.
The concept of security has been expanded, and no single definition can be considered final or suitable for all cases. However, any concept can be expressed in a security policy, so a generally acceptable system of defining and calculating policies must allow arbitrary expansion of both the set of policies and their types.
The task of managing access permissions includes control over the granularity, propagation and revocation of permissions. None of these three aspects are trivial. For instance, UNIX-like operating systems assign permissions to the handle of each opened file, so revocation will not affect files that are already opened. Controlling the propagation of permissions is a serious issue when using the popular Object Capabilities access control model. As in any system with discretionary access control, an object can grant permissions (capabilities) to another object, and tracking these can get extremely convoluted. The creators of FLASK proposed an architecture that became another widely known security template: separation into components that grant access based on predefined permissions (policy enforcement points) and components that calculate these permissions (policy decision points, also known as security monitors or servers) – see the image below.
The Cyber Immune approach to requirements for system architecture obligates system designers to follow the Distrustful Decomposition (DD) and Policy Decision Point/Policy Enforcement Point Separation (PDP/PEP) design patterns on the system level, in line with two architectural models: domain separation and FLASK (in its original microkernel version).
In the next part we explain requirements for architecture and design, and also touch on the Cyber Immune system integrity model.
