Threat Analysis and Risk Assessment (often referred as TARA) are key activities defined by ISO/SAE 21434. Plenty of different risk assessment methods have been described by both academia and industry, and most (if not all) of them can be realized with Security Analyst. The workflow described below is inspired by MoRA (Modular Risk Assessment). MoRA has been developed at the Fraunhofer AISEC (Fraunhofer-Institut für Angewandte und Integrierte Sicherheit). Other popular approaches are often based on attack trees, which can be used in conjunction with MoRA or independently.
It is important that the method scales with the status of the development process so that secure system design is possible right from the start (Security by Design), but can also be applied for existing and detailed systems. This is less difficult if a clear separation of impact assessment and threat assessment is achieved. A model of the evaluated system is very helpful to support that, because it can serve as independent unit keeping everything together. This is required to determine the risk, which is defined as the combination of the damage potential (result of the impact assessment) and the likelihood (result of the threat assessment).
The overall process of the Threat Analysis and Risk Assessment method (TARA)
Model System
In a first step, data about the System under Development (SUD) or Target of Evaluation (ToE), must be collected or imported. The primary modeling entities are functions, components, data and data flows. Functions describe the functionality of the system. Components represents hardware or communication participants. Data is any information stored inside components or transferred in between. The actual communication is captures by data flows. In addition, the relation between functions and the other entities are modeled (“function mapping”).
Note that ISO21434 calls this the Item Definition and considers this a step before the TARA is performed (section 9.3). However, we observed it to be a necessary part of every TARA and thus like to see it as a first step of the process.
Identify Protection Needs
Any of the system elements described above can become an asset when a security attribute like confidentiality, integrity or availability is attached to it, e.g. “confidentiality of personal information”. This is captured by a security goal. For every security goal the impact must be evaluated. This happens based on damage criteria. Possible damage criteria are safety, financial losses, legal consequences or loss of reputation. This results in a damage potential. ISO21434 calls this Asset Identification, Threat Scenario Identification and Impact Rating (sections 8.3 through to 8.5).
Analyze Threats
Threats as well as possible controls should be analyzed based on catalogs of known threats or vulnerabilities and countermeasures. Identified threats are connected with components or data flows. Threats are evaluated based on risk factors like time, access, knowledge and equipment. This results in an estimated likelihood. ISO21434 refers to this as Attack Path Analysis and Attack Feasibility Rating (sections 8.6 and 8.7).
Analyze Risks
Based on the system model it is possible to calculate how security goals might be threatened. Wherever the estimated likelihood of a threat meets the impact (damage potential) of a security goal, it is possible to calculate a risk level. We call this propagation. These risks can then be analyzed and treated appropriately (e.g. by mitigation or avoidance) or accepted. ISO21434 named these activities Risk Determination and Risk Treatment Decision (sections 8.8 and 8.9).
Reduce Risks with Controls
The knowledge of the risks levels of the existing system allows to identify unacceptable risks. The unacceptable risks are those with a high Damage Potential and low Estimated Attack Effort. In order to make informed risk treatment decisions, security analysts need to find good controls that reduce the damage potential (such as an insurance that reduces financial damage) or increase the required attack effort (such as encryption to harden confidentiality).
However, a control itself also introduces some assets that need to be protected, such as an encryption key. As a result, the assets that were co-introduced with a control will also need to undergo the identification of protection needs (such as confidentiality of the key), analysis of the threats and attack paths (such as extracting the shared key from another device) and analysis of the risks. Including controls in the analysis makes TARA an iterative process: The security analysts will loop back to modeling controls and assessing their results until they found a control configuration that seems to be satisfactory.
The ISO doesn’t describe this loop as far as I know. Controls in the concept phase are called “Cybersecurity requirements” and their co-introduced assets (such as Confidentiality of a Key) are not considered in the TARA of ISO21434. Only in the development phase, Controls are derived based on the given Cybersecurity Requirements, at that later stage, they will need to do the same looping as we described here.
Got a comment? Want to discuss this further? Feel free to contact us.
Author Bastian Kruck secure@itemis.com