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).
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”).
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.
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.
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. These risks can then be analyzed and treated appropriately (e.g. by mitigation or avoidance) or accepted.