The Cyber Immune process imposes requirements on deliverables at each development stage, but it only provides guidelines rather than dictates how work should be done. This is in line with the “outcome over process” rule.
A more formal definition of a Cyber Immune system is, a system that achieves security objectives defined for it in every operation scenario and under any circumstances, subject to specified constraints.
A security objective is a condition or requirement that applies to the system as a whole and must be fulfilled throughout its life cycle. Example: “The data must remain unknown to unauthorized persons during read, write, and transfer operations.”
Defining security objectives is the first stage in the development of a Cyber Immune system. The objectives guide subsequent architecture development and system design efforts.
Security objectives can be defined in various ways: through analysis of regulatory requirements in tightly regulated industries, or through analysis of security needs defined by the owner or customer in sectors with little or no regulation. The needs often relate to protection of system assets, and in real-life scenarios the customers understand how to derive security objectives from these needs. The Cyber Immune approach can thus be used in any applied field of cybersystem development.
An important practical aspect of the approach is separation of responsibility. None of the security tools and technologies, such as cryptographic keys, passwords, or certificates, can be considered a system asset or appear within the customer’s view. While not reducing the scope of the task, this helps the customer to define system assets in their own language rather than pass this job to the developer, who, in turn, is then free to use any security tools and methods available.
Before designing an architecture for a certain set of security objectives, each of these objectives is converted into a set of security requirements that detail what exactly needs to be done to achieve the objective – in other words, the requirements for security features are formulated. It is at this stage that requirements like protection of cryptographic keys appear.
Threat modeling is widely used in the methodology of creating Cyber Immune systems. To employ this tool efficiently, you need to know which objects to apply modeling to, what inputs and methods to use, and what outcomes to expect.
Threat modeling is most often understood to mean technical procedures that draw on knowledge bases containing information about typical threats, attack vectors, and adversary tactics and techniques, such as MITRE, STRIDE, or FSTEC’s data security threat database. These procedures must deliver a threat model that describes threat sources or an adversary model, a list of threats, and relevant technical scenarios of attacks. The goal of threat modeling is frequently to describe threats for the purpose of risk assessment in terms of the amount and likelihood of damage. This information can be used to plan countermeasures.
Complete technical threat modeling requires a system architecture variant already present and engagement of qualified professionals.
High-level threat modeling is a less formal procedure which doesn’t require a full description of the system architecture. This can be referred to as “what-if” modeling. The Cyber Immune approach employs both types: high-level modeling to create an architecture that serves predefined security objectives, and formal technical modeling to test the quality of the architecture, fix errors, or confirm that the architecture meets the security objectives.
Our further explanation of process requirements for the Cyber Immune approach details creation of an architecture that serves cybersecurity objectives and verification of code quality.
The Cyber Immune process imposes requirements on deliverables at each development stage, but it only provides guidelines rather than dictates how work should be done. This is in line with the “outcome over process” rule.
A more formal definition of a Cyber Immune system is, a system that achieves security objectives defined for it in every operation scenario and under any circumstances, subject to specified constraints.
A security objective is a condition or requirement that applies to the system as a whole and must be fulfilled throughout its life cycle. Example: “The data must remain unknown to unauthorized persons during read, write, and transfer operations.”
Defining security objectives is the first stage in the development of a Cyber Immune system. The objectives guide subsequent architecture development and system design efforts.
Security objectives can be defined in various ways: through analysis of regulatory requirements in tightly regulated industries, or through analysis of security needs defined by the owner or customer in sectors with little or no regulation. The needs often relate to protection of system assets, and in real-life scenarios the customers understand how to derive security objectives from these needs. The Cyber Immune approach can thus be used in any applied field of cybersystem development.
An important practical aspect of the approach is separation of responsibility. None of the security tools and technologies, such as cryptographic keys, passwords, or certificates, can be considered a system asset or appear within the customer’s view. While not reducing the scope of the task, this helps the customer to define system assets in their own language rather than pass this job to the developer, who, in turn, is then free to use any security tools and methods available.
Before designing an architecture for a certain set of security objectives, each of these objectives is converted into a set of security requirements that detail what exactly needs to be done to achieve the objective – in other words, the requirements for security features are formulated. It is at this stage that requirements like protection of cryptographic keys appear.
Threat modeling is widely used in the methodology of creating Cyber Immune systems. To employ this tool efficiently, you need to know which objects to apply modeling to, what inputs and methods to use, and what outcomes to expect.
Threat modeling is most often understood to mean technical procedures that draw on knowledge bases containing information about typical threats, attack vectors, and adversary tactics and techniques, such as MITRE, STRIDE, or FSTEC’s data security threat database. These procedures must deliver a threat model that describes threat sources or an adversary model, a list of threats, and relevant technical scenarios of attacks. The goal of threat modeling is frequently to describe threats for the purpose of risk assessment in terms of the amount and likelihood of damage. This information can be used to plan countermeasures.
Complete technical threat modeling requires a system architecture variant already present and engagement of qualified professionals.
High-level threat modeling is a less formal procedure which doesn’t require a full description of the system architecture. This can be referred to as “what-if” modeling. The Cyber Immune approach employs both types: high-level modeling to create an architecture that serves predefined security objectives, and formal technical modeling to test the quality of the architecture, fix errors, or confirm that the architecture meets the security objectives.
Our further explanation of process requirements for the Cyber Immune approach details creation of an architecture that serves cybersecurity objectives and verification of code quality.
