Long live threat modeling

If you are part of an application security team, you have probably heard this conversation. It is a never-ending task. A week after you complete a threat model and share your findings with the engineering teams, the design and findings are already out of date. You get a response back: “Oh, we are no longer using that design. It was not suitable for our use case and workload,” or some other version of that. You are pouring money into consultants. Your team is struggling. You are perhaps missing critical design-level findings and increasing the overall risk. With a vulnerable design, no matter how robust the construction and operations, the application will eventually fail.

In the age of cloud-native applications driven by continuous integration and continuous deployment (CI/CD), the old paradigm of a static, waterfall-based design review process is all but dead. Threat modeling has become a clear bottleneck, and most application security teams either skip it altogether or struggle to keep up. Application security practice in this space hasn’t evolved like the rest of the discipline.

Current design practice

From my personal experience leading application security programs, I have the following key observations:

1. The time from design to deployment has decreased significantly — from months to weeks, and in some cases the same day — made possible by cloud infrastructure.
2. The cost of changing the initial design in the development stage is negligible. One can swap one type of service for another with minimal effort: from a relational data store to NoSQL, from containers to Lambda and back. Each has an impact on the design.
3. The design, the flows, and the types of services are continually changing as engineering teams find the optimal design to meet the business case.
4. With the popularity of microservices, new components, services, and flows get added to existing production applications pretty much continuously.
5. Seldom is there an updated architecture diagram, and if one exists, it is a significant overhead to maintain.
6. There is an initial design of the application — usually a rough design of how it should work: services, data stores, flows. It is not an accurate representation of how the application exists in development or production.
7. Traditional threat modeling looks at the hypothetical design, or perhaps at the initial implementation. In most cases it is a point-in-time representation and gets quickly outdated.

The need for a change

All of the above makes traditional threat modeling not only ineffective but also a bottleneck. Threat modeling requires a high level of expertise; it is perhaps one of the most expensive application security practices. It is time-consuming, can mostly be done only by highly experienced senior security staff, and requires senior staff from both engineering and security, making it hard to schedule and extremely expensive to execute. The engineering practices noted above add to that, making it costly and obsolete in its current state and leaving unknown risks within an environment.

If everything moves at the speed of business, then every aspect of application security should too — and that includes the design review process. The process must be automated and continuous: accurate enough that the high-risk areas can be identified and added to the engineering team’s backlog as they change. The application security team can then focus on the most critical applications for a deep dive. If the design changes, a new threat model is generated. Perhaps the engineering team does not need to remediate the findings while they keep tweaking, but they will always have an up-to-date threat model. The automated process may not initially be sophisticated to a human expert’s level, but it is accurate, consistent, and continuous, making it a lot more valuable in reducing risk.

The solution: automated threat modeling

Any solution in this space should be able to accomplish the following:

1. Build an accurate application architecture diagram as it exists in infrastructure.
2. Identify all services and components associated with that application.
3. Identify access and flows between components.
4. Keep all of the above updated continuously, without any human interaction.
5. Perform a threat model on the services and flows.

Based on the above, service-level or component-level automated threat modeling is possible today and can add significant value to most application security teams. More work is needed to automate business-logic and software threat models; this requires a deeper understanding of the application functionality and business requirements. That area can remain a human-led activity, working from continuously updated architecture diagrams. Over time, however, it can be automated using common design patterns and the threats specific to particular application functionality — user authentication logic, the handling of sensitive information, fraud detection, and so on.

In conclusion, this area is ripe for innovation; it is a bottleneck for many application security and engineering teams. The traditional design process is dead. From the engineering team’s perspective, the cloud-native application’s design and architecture move at the same speed as the CI/CD pipeline. From a risk mitigation perspective, it is superior to threat-model the architecture that actually exists as infrastructure in an environment than a hypothetical design, or something the team believes is the architecture. Designs change, releases are faster, and threat modeling is lagging. The old king is dead. Long live threat modeling.