Threat Modeling has become a widely applied technique for the security evaluation of software. Since the early days when people like Bruce Schneier promoted the concept of Attack Trees, to people like Adam Shostack and Gary McGraw assembling a variety of concepts for an “architectural risk analysis” in a collaborative setup, it has evolved to a template that we now call Threat Modeling.
Despite the effectiveness widely documented not only by Microsoft overcoming its security challenges for the Windows platform in the early 2000s, Threat Modeling is rarely introduced into organizations by C-level leaders. Often it can be traced back to individual application experts, who are confronted with the question of how to better assess their applications. When multiple of these experts in an organization come together and exchange on the same challenges, that is where the journey of the Martians begins.
Planning the trip – which model suits your organization best?
Adapting the concept of Threat Modeling for an organization, always requires an initial phase of piloting. This initial phase requires the future Martians to play around with the various techniques, adopting the right soft-skills to motivate people, develop the right tool set to document the risk model and the identified risk, and to communicate these to management. Thereby every Threat Modeling program starts as a central initiative of experts. Soon though the question will arise, how to permanently anchor the concept within the organization, and thereby one fundamental question is whether to drive it as a central service or in a decentral manner.
While both models have validity, they come with implications that should be better considered earlier than later:
| Central model | Decentral model | |
| Pros |
|
|
| Cons |
|
|
| Summary | Best suited for small organization or short-term implementation | Best suited for mid- and big-size organizations and to build up a sustainable Threat Modeling program |
Start your trip – how to apply the decentral model in an organization?
When you decide on the decentral model, a lot of challenges stand in front of the Martian to constantly adapt the concept so that teams will apply it for their respective applications. After the fundamentals of the Threat Modeling concept have been defined, it is first of all time to ring the bell and promote the concept and the idea behind it to the larger organization. That could be in the form of an Info Session where experts speak about the concept, a sample session being conducted on an exemplary application, a newsletter, expert hours alike. Most important is to highlight that Threat Modeling is a joint brainstorming between application and security experts and not a compliance activity. Only when the teams perceive that they can learn about their own application and the security implications and that the results are benefiting them (in contrast to that the results are being used against them), will it allow a collaborative environment, going to the depths of the application specifics in minimal time.
As the next step, you likely find yourself Threat Modeling with interested experts joining in. Why would they join? There are numerous colleagues for sure in your organization, that like to look beyond the border, learning more about custom applications, or on the matter of security. This may even be complemented by a certification process, where experts first join a Threat Model workshop, then moderate a Threat Model workshop under supervision, before being certified. This certification would then allow them to moderate Threat Modeling workshops all by themselves.
Finally, one should also consider the concept itself. While the central experts may have come up with a concept that suits the first Threat Modeling pilots, soon you may find that the concept needs to be adapted. This could derive from:
-
the underlying security controls (your organization’s security requirements) not matching or are not sufficiently articulated for non-security people
-
the setup of the Threat Modeling workgroup showing to be inefficient, or roles are not matching your organization’s structure
-
the duration of the workshop being too short to go in depth or too long showing inefficiencies in the workshop structure
For better acceptance, a Threat Modeling Steering Group could be of help. It brings in a diverse perspective from the participants and the Steering members themselves, and they are likely to act as multipliers to the organization.
Dear Martians, good luck on your journey and aspire to the upcoming challenges!