The kind of scalability described here is targeted to a software system undergoing design and developed by multiple engineering teams. In this situation the development is usually divided among the teams, every team responsible for a part of the system. It is also likely that there is a dedicated team, the architecture team, coordinating the ‘big picture’ of the whole system, but this is not always the case.
Other frameworks for threat model scalability like P.A.S.T.A. , are more suited for securing a multiplicity of hosted and acquired systems participating on shared data, typically an enterprise business unit.
The challenges met in approaching threat modeling of a developing complex software system are:
- Lack of composability and coordination: the composition of the threat models is less than the sum of parts and often not compatible and homogeneous, due to:
- Different maturity and TM features
- Different level of abstraction (C4 like)
- Different Asset naming conventions (incompatible diagrams)
- Lack of common templates, data structure and tooling
- The is no party that has the knowledge of big picture and the details too (that is expected for complex systems)
- Maintainability of the threat model in time during the entire software lifecycle
Top down approach
While it is often attempted to require for every dev team to produce a threat model (good luck with that), these sparse threat models are going to be inhomogeneous in most aspects. There will be no synergy of effort and the union of the threat models will not add value when considering the total ... and will likely be an incoherent aggregate.
Another more structured approach is to create a top-down structure of threat models. On the top of the threat model hierarchy the scope will be the whole system and its main interaction. There will then be ‘child’ threat models. Those more focused threat model will inherit the characteristic, naming conventions, diagrams etc. form this higher level ‘parent’ threat model and focus on specific part of the system. The children threat models will define the scope to coincide with the team’s work/responsibility (ref. “What are we building?”)
This hierarchical parent-child approach logic is analogous to the C4 models used to “zoom in/out” of a software architecture. Using C4 conventions for diagrams is in itself advisable.
Composability features and coordination
To achieve this kind of hierarchy there will be a threat model at the highest level of abstraction. This parent threat model will be used to bootstrap and demonstrate the process. Can be executed be the AppSec team with the support of architecture or engineering teams. Every ‘child’ threat model would be an expansion of the initial one.
If necessary, additional level of abstraction may be defined to divide the scope of a single team in multiple more fined-grained scope threat models (3rd level). Finally, at the most detailed level, a single feature/story level threat modeling practice should be in place, for example “abuse cases” definition during implementation. We’ll see soon how to harmonize the result of different level of abstraction of secure software design and threat modeling in a way that the results are incremental and coherent.
The phase of creating this initial ‘umbrella threat model’, especially the scope definition is what we call the bootstrap phase. This should be the result a collaboration between the architecture team (or the engineering members that are responsible for the system architecture) and the threat model facilitator from the security team.
Once this “umbrella” scope is defined a first successful execution of threat modeling with development a team is crucial as a trailblazer, PoC and reference for the other teams that are going to be involved in the effort.
Common and simple data structure
What will enable a synergic and incremental unified threat model in the large system will be the use of a compatible simple data structure.
At any level of abstraction, the secure design analysis on the specific scope should produce this simple data structure that explains “what can go wrong?” and “what are we doing about it?”
In the below example from OAuth2 threat model example from RFC we can see an example of “what can go wrong?”, circled in red and “what is done about it?”, circled in green.
We can think of this simple data structure also as a mini attack tree:
Risk-impact <-> Attack <-> Mitigation
The ‘risk-impact’ and ‘attack’ are the same as the “what can go wrong?” and the ‘mitigation’ and countermeasure is ‘what do we do about it?’. This data structure is applicable to high level abstraction like encryption protocols and authentication mechanisms and fine-grained sub-features constructs like specific data validations functions.
This data can be easily represented in a data structure language, for example XML, JSON or YAML. Using structure data for defining the threat model findings is key as it enables tooling and homogeneity.
Here’s an UML example:
Attributes can be added to the simple data structure, for example, severity/CVSS, links, notes...
The following nested structure is another example of such data structure and it attributes:
Specific tools and processes should also be defined to facilitate execution, handling of data, and coordination of the TM efforts.
Comments
Post a Comment