Altaz Valani is Director of Insights Research at Security Compass, provider of the Balanced Development Automation platform.
GETTY
Concerns about software security have been with us since the early days of modern computing. Within software security, we have used threat modeling as a security activity to analyze meaningful threats and recommend appropriate mitigations. Many of our modern software threat modeling approaches, in fact, have their roots back where our systems and threat actors were well understood. Corresponding mitigations, derived from threat modeling, would be stated as requirements for the system developers to complete. Examples include enumeration of threats and corresponding impacts, analysis of threat actors and their intentions and prioritized mitigations. The longevity of threat modeling and its procedures testifies to its ongoing importance.
Much has changed since the early days of threat modeling. For example, monolithic systems and architectures have given way to distributed systems and microservices. Siloed development, operations and security teams have given way to cross-functional teams with a shared knowledge base. Longer software development life cycles have given way to shorter ones. Changes such as these continue to be driven by organizational needs. Governments, for instance, want to provide secure e-government services to their citizens, and commercial organizations want to release secure features quickly in order to gain market share.
The Evolution Of Threat Modeling
Looking back at the history of threat modeling, the focus was on trying to identify threats to a system where we understood who the threat actors were, and we had a complete understanding of our systems. Our monolithic applications were delivered over longer development cycles. Today, however, the threat actors are not always immediately apparent. Furthermore, our software has become more complex, and it is difficult even for a modest-sized team to understand how all components integrate together. On top of that, our delivery cycles have shrunk.
Thankfully, threat modeling is evolving to keep up. No longer do we assume that we can stop our delivery cycle to threat model our systems. Organizational leaders across many different verticals expect continuous delivery, after all. That means threat modeling must respond by evolving to produce threat analysis in a shorter time frame and with greater frequency.
To achieve this, threat modeling is fast becoming a cross-functional activity that is increasingly automated and driven by an underlying knowledge base. One way this is operationalized is through the introduction of a security champion who helps to integrate threat modeling with DevOps workflows. Another way is to break threat modeling into discrete scope elements to provide mitigations as incremental work. This evolution does not imply that security is compromised. On the contrary, it brings security into the delivery process rather than remaining as an outsider.
Becoming More Cross-Functional
It is no longer possible for a single threat modeler, or even a modestly sized group of threat modelers, to anticipate all threats to a system. New attacks emerge regularly. The threat modeling landscape is too complex with old assumptions being regularly challenged.
A good example of this is the gradual decline of implied trust and the rise of zero trust. With so many mitigations to consider and only one vulnerability being sufficient for an attacker to exploit, we have great asymmetry. This asymmetric nature of security implies a need for a more efficient way to understand the risk in a complex technology landscape. The way to manage complexity is to diversify our security perspectives. This is in line with thinking about threats from an attacker’s perspective; they work from several different perspectives (as witnessed through advanced persistent threats). Cross-functional teams help by reducing threat modeling bias based on personal preference or experience. The different perspectives provide opportunities to consider additional attack patterns.
Increasing The Level Of Automation
When we describe automation, we generally try to remove as much human intervention as possible. This improves consistency and increases speed. Unfortunately, as of today, we don’t have fully automated threat modeling. There is work being done to bring the benefits of AI into threat modeling. As of now, however, we still need a consistent way to rapidly translate recommended mitigations from threat modeling into actionable stories that have clear exit criteria—something developers can execute against.
The answer to this lies in creating a map between vulnerability mitigations and software code (which does not preclude configuration files and other “as code” artifacts). Using such a map, a test is triggered to verify the requirement and the corresponding mitigation. In this way, by reporting all mitigations that are still open, the security posture across a software portfolio is immediately realized and benchmarked against a given threshold. This information is useful to business stakeholders in making decisions around risk mitigation.
Growing A Knowledge Base
Over time, a repeating set of threats and remediation patterns will begin to emerge. Capturing this type of recurring information in a knowledge base and propagating it across similar architectures can save time and allow us to scale our threat modeling. For example, teams no longer need to spend time conducting threat modeling for similar types of applications only to recommend similar mitigations. The knowledge base can also ingest additional information from the efforts of other organizations like NIST and MITRE. In this way, the value of the knowledge base increases as it accumulates knowledge from a wider set of vulnerability and remediation data.
Threat Modeling Is Now A Critical Business Capability
Threat modeling has now become a critical capability for business leaders. It helps to identify areas of security risk, a board-level imperative. Not only that, but it also provides the steps required to mitigate the threat. This provides a basis for cost/benefit analysis. Areas of software security risk must be analyzed and remediated without sacrificing speed and agility. To a business stakeholder, having this type of information available in a timely manner can make a huge difference in managing operational risk and value delivery.