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 (MoRA)
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).