Policy architecture, that is, a system of permissible targeted communications between isolated system components, is a pivotal concept in domain separation.
The Cyber Immune approach imposes a further requirement: the system of relationships defined by the policy architecture must follow the Cyber Immune integrity model, which is a variation on the Biba model and conceptually close to the Clark-Wilson model.
This divides all security domains into three classes: untrusted, trusted, and those which increase trust in data that flows through them. These are categorized by the impact they have on achieving security objectives. Recall that the job of a Cyber Immune system is to ensure that these objectives are met under any circumstances.
The Cyber Immune integrity model, just as the Clark-Wilson model, differs from the Biba model through an extra class of elements that increase integrity. The need for this class is justified by practical considerations: following the Biba integrity model while implementing all required application functionality is not always feasible. The Cyber Immune integrity model has a smaller scope of requirements than the Clark-Wilson model, also for practical reasons.
Research shows that an adversary cannot advance an attack into the critical components of a system that uses this security model. 1,2
With some simplification, the Cyber Immune policy architecture follows the diagram below:
Why is it only integrity? How about confidentiality and the other aspects of security? Functional and data integrity control is a prerequisite for any other type of security. Indeed, how is confidentiality even possible if the adversary can disrupt the functional integrity of the confidentiality module? Therefore, maintaining the integrity of functionality and data on the system level is a prerequisite for other aspects of security, which can be provided on the application level or intermediate level.
The third requirement to Cyber Immune architecture, minimizing the code base of the trusted modules, is covered in the next part.
Policy architecture, that is, a system of permissible targeted communications between isolated system components, is a pivotal concept in domain separation.
The Cyber Immune approach imposes a further requirement: the system of relationships defined by the policy architecture must follow the Cyber Immune integrity model, which is a variation on the Biba model and conceptually close to the Clark-Wilson model.
This divides all security domains into three classes: untrusted, trusted, and those which increase trust in data that flows through them. These are categorized by the impact they have on achieving security objectives. Recall that the job of a Cyber Immune system is to ensure that these objectives are met under any circumstances.
The Cyber Immune integrity model, just as the Clark-Wilson model, differs from the Biba model through an extra class of elements that increase integrity. The need for this class is justified by practical considerations: following the Biba integrity model while implementing all required application functionality is not always feasible. The Cyber Immune integrity model has a smaller scope of requirements than the Clark-Wilson model, also for practical reasons.
Research shows that an adversary cannot advance an attack into the critical components of a system that uses this security model. 1,2
With some simplification, the Cyber Immune policy architecture follows the diagram below:
Why is it only integrity? How about confidentiality and the other aspects of security? Functional and data integrity control is a prerequisite for any other type of security. Indeed, how is confidentiality even possible if the adversary can disrupt the functional integrity of the confidentiality module? Therefore, maintaining the integrity of functionality and data on the system level is a prerequisite for other aspects of security, which can be provided on the application level or intermediate level.
The third requirement to Cyber Immune architecture, minimizing the code base of the trusted modules, is covered in the next part.
