The TARA workflow described under Threat Analysis and Risk Assessment requires rich tool assistance. With Microsoft Excel you 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. Nevertheless, their threat modeling website is a good source of information.
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.