Automotive OEMs and their suppliers that want to comply with ISO21434 will need rich tool assistance. Especially the workflow to analyze threats and assess the resulting risks will no longer be manageable in Excel spreadsheets. Excel users will soon lose the overview how everything is connected. Currently, there are very few tools with a corresponding focus. Microsoft’s Threat Modeling Tool (TMT) is one of those, but it only covers the TA (threat analysis) part and not the RA (the risk assessment) part including impact assessment. Also the re-analysis on the resulting risk after implementing controls will be a challenge.
Let’s go through some other places where tool assistance is desirable.
There is one relation between system entities that is particularly cumbersome to capture: the mapping of functions to components, data and data flows. However, it is important to know which functions are affected if a certain component is vulnerable. Fortunately, it is possible to use existing modeled relations between the remaining elements to ease function assignment. For example, if some data is stored in a component, it is likely that any function mapped to this data should also be mapped to that function. YAKINDU Security Analyst offers a reduced data-centric view on the function mapping with corresponding consistency checks.
With increasing number of system elements it becomes difficult to ensure that all assets have been considered. An overview of possible assets and the security attributes (e.g. confidentiality, availability, integrity) per element is very helpful. Because the system is subject to change it is important that snapshots of this overview can be compared.
A similar overview like for asset identification is possible for threats. This only requires that the threat catalog is classified in some way, e.g. based on Microsoft STRIDE.
Technology tags are a very simple but powerful addition to enrich catalogs. Based on this information a tool is able to provide much more precise suggestions about possible threats and controls for a given system.
Relations between Elements
When following our recommended workflow, attack effort and impact are assessed at separate elements. If this separation is not uphold there is a danger of inconsistent assessments. But this implies a large number of relations between security goals, threats and controls. Fortunately, this can be largely automated based on the system model.
As an example let’s assume that we have identified the asset “password” which is transferred between two components. Furthermore, we have identified a threat “eavesdropping” on the communication channel between these components. Because the tool is aware that the data is transferred over this channel it can suggest that the confidentiality of the password is threatened by eavesdropping. In YAKINDU Security Analyst the rules which are used to generate these suggestions are highly customizable. It can be precisely configured which relations in the system model are considered and which security attributes (e.g. confidentiality, integrity, availability) are affected.