The Security by Design approach implies that aspects of security must be considered when creating the architecture, that is, prior to the technical threat modeling stage. This may sound paradoxical: security controls are the product of modeling, which requires an architecture to be in place, which needs to be created with security requirements in mind! What does the Cyber Immune methodology suggest as a solution?
This is the underlying concept of the Cyber Immune approach: critical parts of the system directly responsible for the assets need to be defined and isolated from any potential unwanted impact before doing formal threat modeling. This requires monitoring communications of the critical parts of the system and all others, fragmenting these critical parts, and leaving only the indispensable ones.
The process continues for as long as the underlying architecture of the system takes shape. We keep answering the question, “What happens if a certain component is compromised?” This leaves us with a relatively small number of critical components that must not be compromised. These must be thoroughly developed, tested, and verified. The attack surface of these components – and hence, that of the system as a whole – will be small, and the cost of the attack, high.
Does this approach deny complete technical threat modeling? No, it doesn’t, but it helps to reduce the scope of architectural changes that follow technical modeling – ideally, to zero. Besides, this approach ensures greater system resilience to threats, attack scenarios and techniques that were still unknown when the modeling was done.
Verification of code – confirmation of its correct operation and quality from a security perspective – constitutes a key stage in creating a secure system. Verification methods and tools may change, but the procedure is mandatory.
What makes the Cyber Immune approach different is that the verification process covers not all code but only a small portion, the so-called trusted code: critical components directly relevant to achieving security objectives. The rest of the code is verified through the most economical methods available.
The Security by Design approach implies that aspects of security must be considered when creating the architecture, that is, prior to the technical threat modeling stage. This may sound paradoxical: security controls are the product of modeling, which requires an architecture to be in place, which needs to be created with security requirements in mind! What does the Cyber Immune methodology suggest as a solution?
This is the underlying concept of the Cyber Immune approach: critical parts of the system directly responsible for the assets need to be defined and isolated from any potential unwanted impact before doing formal threat modeling. This requires monitoring communications of the critical parts of the system and all others, fragmenting these critical parts, and leaving only the indispensable ones.
The process continues for as long as the underlying architecture of the system takes shape. We keep answering the question, “What happens if a certain component is compromised?” This leaves us with a relatively small number of critical components that must not be compromised. These must be thoroughly developed, tested, and verified. The attack surface of these components – and hence, that of the system as a whole – will be small, and the cost of the attack, high.
Does this approach deny complete technical threat modeling? No, it doesn’t, but it helps to reduce the scope of architectural changes that follow technical modeling – ideally, to zero. Besides, this approach ensures greater system resilience to threats, attack scenarios and techniques that were still unknown when the modeling was done.
Verification of code – confirmation of its correct operation and quality from a security perspective – constitutes a key stage in creating a secure system. Verification methods and tools may change, but the procedure is mandatory.
What makes the Cyber Immune approach different is that the verification process covers not all code but only a small portion, the so-called trusted code: critical components directly relevant to achieving security objectives. The rest of the code is verified through the most economical methods available.
