What should an Enterprise Architect know about threat modeling?

I recently asked on a LinkedIn group about threat modeling and Enterprise Architecture. My first surprise came when the first set of responses were from folks who didn’t appear to understand what threat modeling was. So I guess the first order of business for anyone wishing to consider themselves an Enterprise Architect is to study up on what Threat modeling is.

The Basics of Threat Modeling

I recommend the following basic tutorials. I consider threat modeling to be a core skill in EA and would NOT be comfortable hiring an EA who was not familiar with at least some aspects of threat modeling.  The tutorials below have references to further material if you’d like to go deeper, including a number of excellent books.

• Improving Web Application Security – Threats and Countermeasures, by J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, Microsoft Developers Network, June 2003, URL: https://msdn.microsoft.com/en-us/library/ff648644.aspx, retrieved August 2016
• Threat Risk Modeling, by the Open Web Application Security Project (OWASP Guide), Wiki, URL: https://www.owasp.org/index.php/Threat_Risk_Modeling, retrieved August 2016

To summarize for the folks who already know, or are not interested in following the links above, Threat Modeling is a guided practice that should take place as part of a system design process.  This practice requires an architect to evaluate a design in a specific and rigorous manner to uncover a series of potential risks to system assets and provides a mechanism to document mitigations for those risks. Those mitigations should be embedded in the design and implementation of a system, reducing the cost and effort associated with adding mitigations after a system is complete.

Who Does Threat Modeling?

This is actually a slightly complicated question.  First off, let’s ask the timing question: “when is threat modeling done?”  I have three answers and they tell us a little about the person doing the threat modeling and the results expected.

1. For application design, threat modeling is done during design and results in changes to a system’s design.  In this context, threat modeling is a Solution Architecture or Security Architecture activity.
2. For security audits, threat modeling is performed on a completed system (or group of systems) to provide insight into where to test for weaknesses.  In this context, threat modeling is a Security Architecture activity.  While this “after the fact” timing is less effective at preventing a security flaw, it is useful for ensuring that compliance with security policies and principles are truly independent of the development team.
3. For building a security strategy, threat modeling of one or more systems can be used as a technique to highlight specific security threats where a policy or principle should be enacted.  In this context, we are building or revising a security strategy or set of security principles.  This is an Enterprise Architecture or CISO activity.

So should an Enterprise Architect know how to do threat modeling?  Yes.  They should.  It is not difficult to learn, and the results are absolutely worth the effort.  Even if you will not perform threat modeling in your enterprise (because your enterprise has wisely invested in security architecture), it is a skill worth having.

If you are an Enterprise Architect whose primary responsibility is IT governance, your responsibility will fall to the following:

1. to make sure that the threat modeling activity occurs,
2. that threat modeling properly identifies threats and mitigations and
3. that those mitigations end up baked into the design and implementation of a system.

This type of governance is a function of an Architecture Review process (typically under the oversight of an Architecture Review Board or ARB).

Limitations of Threat Modeling

Threat modeling is a guided and specific activity.  It goes much deeper than SWOT analysis and examines specific threat vectors against identified assets and ranks the risks according to the potential for system impact.  (These two processes go by the acronyms STRIDE and DREAD).  While threat modeling will dramatically reduce the “predictable” risks, it will not address the ones that come at you “out of left field.”  These are what I would consider “unpredictable” risks.

Humans are limited in our understanding of the complexity of our own systems.  We make mistakes.  Our abstractions “leak.”  Some things, we simply cannot effectively predict.  Threat modeling will not find unpredictable risks, and the best threat model in the world does not replace diligence, maintenance, and monitoring in an overall managed security environment.

“Standard” threat models and their tools

Microsoft, in their efforts to improve the practices of securing software for the entire industry, made available not only the methods of STRIDE and DREAD, but also a basic tool for creating a “threat model” diagram.  This tool can be downloaded and installed for free (see this link).

Using the Microsoft tool can provide you with an interesting diagram.  The problem is that very few people can read it.  This is not a criticism… the “language” of the Microsoft threat model is very narrowly defined to be relevant to the activity of creating a threat model.  In other words, the language of threats forces you, the designer, to THINK about threats.  If you are not thinking, you will get no results.

In the discussion on LinkedIn, the consensus among the architects was clear on this point — the value of threat modeling was in the activity, not typically the result.  So, while there is a diagram, and while the diagram is rather unusual, the diagram doesn’t really matter.  The act of creating the diagram matters, and in creating the diagram, a security architect can enumerate threats into a list that they would then manage in another tool (Excel or Word or JIRA, for example). Based on this notion, other standards have emerged to compete with the Microsoft STRIDE model, including the FAIR (Factor Analysis of Information Risk) taxonomy from the Open Group (see this link).  To my eyes, both approaches are equally good.

The value is in the process.  The process (whether FAIR or STRIDE) starts with a system diagram and the process produces a threat model diagram that may or may not be useful on its own.  The valuable results are captured not in a diagram but typically in a Office document as a list of threats and mitigations.

Having worked in an environment where we tried to make “good” practices occur routinely, I am tempted to extend this thinking a little bit.  While the output of the threat modeling process doesn’t have to be standardized, the input to the threat modeling process should be.

The input is a system diagram, and that diagram can be in any language (UML, ArchiMate, etc).  Tool support is important for making this work.  For example, the Enterprise Studio tool from BizzDesign has a threat modeling add-on that allows a threat model to be based on ArchiMate 3.0 or UML (see this link).  Qualiware’s Enterprise Architecture platform also allows threat modeling on ArchiMate 3.0 or UML.  An excellent introduction to this space was developed in an Open Group paper on the subject of Threat Modeling in ArchiMate 2.1 from January 2016  (see this link).

If it were my team, I would insist that an enterprise would adopt a single standard for the system diagram (UML or ArchiMate), so that the security architect can (a) communicate effectively with the solution architect about the design, and (b) can start with a design that was created by the solution architect, rather than creating it himself or herself.  This is reuse at the process level. Reusing an existing diagram language (and toolset) rather than creating a new one makes the entire act of design go quicker.  Creating a dependency on the system design model requires the quality of the system model to be high.  This is a good “forcing function” to drive quality.

In conclusion, while the act of threat modeling is more important than the resulting diagram, I strongly recommend using a standardized language for describing the system, and for creating the threat model itself.  This is simply more efficient than starting the threat model “from scratch.”

Threat Modeling and Agile Software Development

The goal of threat modeling is not to create a pretty picture, or a lovely word document.  It is to drive good security practices into software development before the software is written!  The goal is Security By Design (instead of Security-after-the-fact).

If you create a threat model with a series of threats and mitigations, but you cannot connect those results with a software development process, you fail.  This is not a grey area.  Either security is baked in, or it is not.  While many tools can help you to find a security flaw after a system is created (by scanning for vulnerabilities, for example), most experts agree that the best way to avoid a security flaw is to prevent it in the first place.

So let’s say that you create your threat model.  In doing so, you identify your system’s assets, create a solid list of risks (through attack vectors), and a clear set of recommended mitigations.  How do you attach that information to an implementation, especially in the agile software design paradigm?  (In Waterfall, you’d simply deliver the risk mitigations document to the design team and cross your fingers… one of many reasons that Waterfall Doesn’t Work).

First off, I encourage my readers to disavow themselves of the notion that all design is wasted work.  I’ve heard this many times, and as a Scrum Master and Scrum Trainer, I’ve discussed the notion of Big Design Up Front (BDUF) as an agile anti-pattern.  I believe in agile architecture, which is architecture and design done in small increments, in each iteration.  So if the overall design of a system doesn’t exist until the system is emerging, when would threat modeling occur?

Let’s start with a basic truth — while Scrum (the most common Agile method) asserts that each sprint produces a “potentially shippable product increment”, the first few iterations of a system rarely ship.  That is because the design itself is emerging.  The developers don’t actually know where the boundaries of the objects are until they write the objects.

It is during these early sprints that high level design of a system should emerge as deliverables concurrent with initial code.  Not large long-winded documents, but as diagrams and software package templates that are “just enough architecture” to guide the team and add value.  As new areas of the system are developed, architectural models for those areas are developed or improved just in time to have the appropriate impact, while taking into account the emerging design in the code itself.  (that’s right: code as an input to architecture.)

I suggest that the first iteration of the high level design would be a deliverable of the second or third sprint of a project, and that the threat model and recommendations would follow in the subsequent sprint.  After that point, I suggest placing “anti-stories” in the backlog (credit to Matt Arnull for pointing out the notion of “anti-stories” to me, which he recommends as part of a Scaled Agile Framework approach (SAFe)).

Anti-stories, as I understand them, are agile stories that describe things that are NOT supposed to happen.  Each potential threat vector becomes a single anti-story.  The mitigations for any single anti-story are included as conditions of satisfaction within the anti-story itself.  (For example: “As a hacker, I want to maliciously inject SQL statements through SQL Injection so that I can retrieve or alter sensitive data.” — conditions of satisfaction — “no page that accepts input will allow the user to enter or post SQL statements in a manner that allows those statements to execute.”)

Through the use of anti-stories, the findings of a threat model can be embedded into the functional requirements of an agile backlog and delivered through the iterations of the project.

Conclusion

Solution Architects, Security Architects, and EA’s working to build and govern secure systems, must be aware of threat modeling as a technique for identifying and avoiding the lion’s share of security risks detectable in a system design.  Architects seeking to grow into the EA role must understand how threat modeling works and how to embed the requirements generated from the threat model into the requirements of a system, especially in Agile Software Development processes.

Special thanks to the following contributors who helped me to develop and refine this article: Henk Jonkers, Kenneth Lloyd, Ravila White, Bruce Krakower, Brian Seitz, Dr. Randy Frid, Marlene Rodriguez, Chris Blunt, John Mason, Matt Arnull, Adrian Campbell, Bala Vaddi,  Marie-Michelle Strah,  Nigel Tebbutt, Jim Heaton, Beth Kicinski,  Martin Jewell,  Duncan Hart, and Steve Skalski.