Threat modeling is no longer just a theoretical exercise. It is rapidly evolving into a practical process by which organizations can be proactive in their security efforts. By identifying threats early in the design phase and prioritizing mitigation efforts in alignment with strategy and budget allocations, organizations realize both their security and business goals. This post talks about the Application Threat Modeling vs Operational Threat Modeling processes.
The traditional DFD-based approach does not differentiate between creating models for applications and models for infrastructure operations. But to realize the benefits of this evolution, organizations need to address the separate and unique concerns of both the development team and the infrastructure team.
Consider, for example, the two aspects of any given web application.
- One aspect is the application itself as created by the development team.
- The other aspect is the underlying operational infrastructure – the servers, databases, load balancers, and other such infrastructure components – that constitute the operational environment in which this application will operate.
In order to fully consider risk mitigation for this application, both aspects must be addressed in accordance with their own unique concerns. The development team will benefit from an application-focused threat model while writing the code. But that model will be of little use to the infrastructure team since writing secure code is not their primary purview. An operational threat modeling process helps the infrastructure team mitigate the inherent risk in the infrastructure – issues which an application threat model simply does not address. Since the development team and the infrastructure team have completely different purviews and responsibilities, their respective threat models should also be kept separate and optimized for each of their unique risk mitigation needs.
Application Threat Modeling
An application threat model should focus solely on the application for which it is created. The primary purpose is to (1) identify the threats (OWASP Top 10, etc) that are pertinent to that application, and (2) to indicate how developers need to address those threats. And the most effective means to accomplishing these purposes is to start with the creation of a process flow diagram (PFD).
The PFD allows developers, security professionals, and other stakeholders to build and modify threat models as functional maps – a visual decomposition of the application in accordance with the way developers think about the coding process – regardless of their security subject matter expertise. However, by integrating developers into the PFD-based threat modeling process, tremendous efficiency and productive momentum can be achieved. The operational result is an Agile security process that augments the developers’ Agile production process.
The benefit of a security process that complements the mainstream adaptation of Agile methodology for development is hard to underestimate. Development’s goal, of course, is to create functional products in the shortest possible time frame while still meeting the business requirements. As more organizations adopt and mature in their implementation of the Agile development method, the competitive advantage realized by early adopters becomes elusive to maintain. This is particularly notable if potential threats make it to the vulnerability mitigation stages, which then becomes a bottleneck to getting applications to production. And it is precisely at this point where an effective PFD-based application threat model benefits the development team and keeps the production sprint on target.
Operational Threat Modeling
By contrast, an operational threat model looks at the end-to-end data flow of the organization’s infrastructure. The first step to creating an operational threat model is to identify the operational environment, including shared components – i.e. SSO servers, encryption servers, database servers, and so forth. Next, every component’s attributes may be provided to give additional context to the potential threats. For example, a database which has unrestricted admin access or which contains a large quantity of confidential data may have more potential threats than a database without these attributes. Finally, the potential threats and known common vulnerabilities (CVE) – both from internal and external sources – may be systematically identified and the relevant security controls enumerated.
The operational threat model enables the organization to visualize the “big picture” of its infrastructure risk profile, and enhances stakeholder understanding of the full attack surface. By utilizing an operational threat model, organizational leaders are equipped to effectively plan and prioritize their infrastructure risk mitigation strategy. This is in sharp contrast to how a development team benefits from an application threat model.
Both Threat Model Types are Needed
Effective risk mitigation means different things to different teams and departments within the organization. Attempting to address the mitigation needs of one team with the appropriate mitigation process from the other is like trying to wear a left-handed glove on both hands. What works well for one simply cannot address the full scope of concerns for the other. However, when organizations implement effective and separate processes for their application and operational threat modeling, they will achieve a measurable increase in the efficiency of their security efforts and demonstrate effectiveness in aligning security with the business’ strategic goals.
To learn more about threat modeling contact us today for ThreatModeler™ demo.