Debbie: What is our Threat Modeling backlog?
Mark: We have about 30 new applications in the backlog and 90 older ones that need a review. Roughly 120 — we might add more.
Debbie: How quickly are we going through the backlog?
Mark: To be honest, not quickly enough, between scheduling meetings with the Engineering teams, getting architecture diagrams and the actual Threat Modeling session with the Engineering team takes up to 2 weeks per Threat model. The team is overworked, and it just never ends. As soon one is done, it is perhaps outdated. Engineering teams are continually updating the design and services. Quite frustrating and demoralizing, If I can be frank. Remember two months ago there was that incident. The Engineering team changed the flows and exposed a critical service after the initial design review.
Debbie: We need to get a better handle on the Design level risks. Please prioritize, and I will find the money for staff augmentation to help speed this up. We need a better solution here.
If you are part of an Application Security team, you probably have heard this conversation. It is a never-ending task. A week after you complete a Threat Model, 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 in money on 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 Continous Integration Continous 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 team either altogether skip it or struggle to keep up. Application Security practices in this space haven’t evolved like the rest of the Application Security practice.
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, 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 out one type of service with a different one with minimal effort, move from Relational Data Store to NoSQL Data Store, from containers to Lambda and back. Each has an impact on the design.
3 — The Design, the flows, the type of services are continually changing as the 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. It is usually a rough design of how it should work, services, data stores, flows, etc. Not an accurate representation of how the application exists in development or production.
7 — Traditional threat model practice looks at the hypothetical design or perhaps after 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 the traditional Threat Modeling practice 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 by highly experienced senior security staff, and requires senior staff from both Engineering and Security disciplines, making it hard to schedule and extremely expensive to execute. Current 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. That includes the design review process. The process must be automated and continuous, accurate enough so 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 if they keep tweaking, but they will always have an updated threat model. The Automated process, maybe initially, does not have to be sophisticated to a human expert level. But it is accurate, consistent, and continuous, making it a lot more valuable in reducing the 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 the above updated continuously without any human interaction.
5 — Perform a threat model on 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. This particular area can remain a human-led activity leveraging continuously updated architecture diagrams. However, over time, this can be automated using common design patterns and threats to specific application functionality, such as user authentication logic, handling sensitive information, fraud detection, etc.
In conclusion, this area is ripe for innovation; this 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. From a risk mitigation perspective, it is superior to perform a threat model on the existing architecture that exists as infrastructure in an environment than a hypothetical design or something the team believes is the architecture. Designs change, releases are faster … Threat Modeling is lagging. The old king is dead.
Ahsan Mir is the CEO and Co-Founder of Rapticore, Inc. Ahsan has multiple years of experience in the Cybersecurity. He has been a practitioner and has held Cybersecurity leadership positions. He has a breadth of experience leading Security Operations, Incident Response, Threat Intelligence, Security Engineering, Application, and Cloud Security, teams. One of his proud accomplishments was the creation of a Skunkworks team.
Rapticore is an Application Security Operations and Program Management Platform focused on Cloud-Native Applications. Rapticore was designed from the ground up to solve the challenges its founders faced while leading Cybersecurity portfolios.
More Information about Rapticore can be found on https://www.rapticore.com.
