Why Threat Modeling is the Key to Security Architecture

Weak Link problem increases importance of coordination and options

Before we dive into Security Architecture, let's start with any kind of Technology architecture, say software architecture, Cloud architecture, and so on. The primary goal in technology architecture overall is to first understand the target use case or deployment (say a new mobile app/api set). From there, the architect adds value by

1) working on the conceptual design for the components and services to realize the use case/deployment in practice and

2) finding options and leverage points in how that conceptual design is driven through to end users, development, QA/Test/Assurance, and operational teams

Security architecture is no different, if anything, because security is a weakest link problem, fro security architects the importance of factoring in connectivity and coordination across teams only grows.

But where the situation flips for security architects is that the use case and deployment zones are only one part of the problems to design for. Each of the functional goals that the dev and ops teams are trying to plan and build for create some type of risk. So the security architect's job is to use a threat model to identify these risks more clearly.

The overall goal of architecture - creating cohesion across teams - remains. For security architecture, the threat model inverts the focus from functional goals (make this service work over mobile, move my on prem to the cloud) and inverts that focus to the things that can go wrong in this new system design.

The threat model starts as Adam Shostack observes, by asking what are working on? Our job as defenders is to deliver a tested, control set for the system, but where do these controls come from? Which ones are relevant? The right answer is not always adding more controls. Sometimes controls hang on like barnacles and should be considered for pruning. Paraphrasing Michael Howard, every control should justify its place by serving as a countermeasure to at least one threat.

This makes threat modeling the essential starting point of security architecture. In the same way, that a UX design cannot work without factoring in a user, a security design cannot work if it does not account for threats. When said this way, it sounds obvious. But think about how many times you have heard "our security is based on Vendor XYZ".

One way these sorts of product based security schemes can go wrong is that security products are often capable of many things. Think of a WAF, they can block dozens and dozens of types of attacks, all depends on what rules you deploy. So if you say your web layer design is defended by WAF, you are covered right? But what is actually turned on on the WAF? What is the coverage level? Where is it logged to? When and how is it tested?

Instead when a security design begins with a set of threats then you can follow through to the control capabilities (which may be implemented on a WAF) and methodically work through how resilient your system is. This level of threat specificity pays off in many ways. Architecture is all about connecting disparate domains, devs, ops, and test teams all have different playbooks, goals, and incentives. Architecture is in a good place to help them connect, but the starting point should be specific so that you can pull the thread all the way through the system in most efficient way.