Identifying threats help organizations generate relevant mitigating controls. To reach an appropriate level of security at a reasonable cost, organizations need to know which threats are applicable to them and the potential impact if a given threat is exploited. Thus, the first step is to build a threat library that is unique to your organization.

New threats are created for mobile devices, web services or different types of applications continuously.

Even though there are public threat libraries such as MITRE’s CAPEC, WASCTC and OWASP, some threats are unique to your organization. For example, if you’re building a medical device or an ATM machine, there will be threats unique to your business that do not concern others.

To support reliable and systematic security standards throughout the organization, the threat library should be built from a template to define threat properties.

These will include:

There are two ways to mitigate a threat. The first one is by implementing relevant security requirements in the code, there by addressing the issue at its source. The second way is adding a security control (i.e., compensating control) to mitigate the threat before it reaches the source (e.g., WAF, firewall, SSO, etc.). Enterprises have made investments in an overflow of compensating controls either as a detective or preventive measure. Security requirements are the basis for building security in the system. These requirements indicate the system’s course of action and what must not be allowed to happen. Compensating controls, on the other hand, are the foundation for the first line of defense (and, in some cases, the only line of defense).

When all potential threats have been evaluated, along with a resolution of the threats that must be mitigated, the next step is to identify security requirements. Organizations need to know how to mitigate each identified threat. From a security perspective, it is important to know the threats and risks to the organization, but from a developer’s perspective, the main concern is the security requirements necessary to mitigate a given threat. The list of threats also helps Security Architects identify the compensating controls that can be implemented to prevent these threats from reaching the vulnerable source.

When an organization identifies a threat and its associated risks andmitigations, this same “threat pattern” will remain across various applications. Building a threat pattern library allows organizations to reuse the work that has been completed, enabling them to scale quickly across hundreds of thousands of applications.

Applications are built from individual features, and each feature can be attacked. Consider your threat model from an applications perspective, and assume you have a feature like LOGIN. Whenever you wish to build a threatmodel for the LOGIN feature, you think in terms of potential attack vectors. If you have a weak password policy, for example, potential exploits could include a brute-force or dictionary-based password attack, a denial-of-service attack using an account lockout or session fixation, or any other path common to authenticating to an application.

When you consider the potential for exploits across other applications that utilize the same or a similar LOGIN feature, each application is subject to the same vulnerabilities. This only changes with applications built upon alternative platforms, infrastructures, or technologies requiring a completely different approach to the LOGIN.

The next step in develop an effective threat model and convert it into actionable output. A structural representation of a threat modeling process– attack surface identification – can recognize risks in a cyber ecosystem to prioritize mitigation of potential threats. Threat modeling can be a valuable source to understand components and how to mitigate threats.

The threat modeling process helps a good security system find a balance between what is likely to happen and what is relevant. From a security executive point of view, the model needs to clearly identify the organization’s high-value targets that attackers will likely prioritize. Developers must think like the attacker. This can be accomplished once the system is finally understood. Organizations also need to know their data exposure and the feasible cost of a breach. This will help them focus on the security requirements that need to be generated based on the threat model.

With actionable output identified, organizations can automate the process, integrate it with their existing workflow, and get various stakeholders to collaborate together. From an automation and scalability perspective, stakeholders will want to automate as much of the work of building a threatmodel and defining the threats as possible.

The next step is to integrate the threat modeling process into their existing workflow and DevOps toolchain, such as JIRA, ServiceNow, or Jenkins. Threatmodeling is about threat enumeration, not risk modeling.

Reporting and measuring the effectiveness of the threat model is the next step of the process. During this stage, stakeholders and decision-makers will want to review the organization’s threat portfolio and identify the top ten threats, either from an application or an enterprise perspective.

Effective threat modeling is not a security-team driven process. To achieve the scalability required for a successful threat modeling process, developers and architects should play an active role in every step of the process. Threat management focuses on protecting the organization by preventing attacks that might mitigate the system while updating it with the latest data about threats for a fast response.

Collaboration and efficiency throughout the SDLC are key points in this stage of the process. An online dashboard connecting stakeholders will help each one access essential reports based on their individual roles.

From an operationalizing point of view, the threat modeling process should be built to handle tens, hundreds, or even thousands of applications – and keep them up to date in a reasonable amount of time. It will scale across thousands of developers or stakeholders simultaneously, bringing them all together to work collaboratively and continuously minimize the organization’s risk exposure.

Organizations are now realizing the cost benefits of incorporating threatmodeling earlier in the SDLC. Traditionally, companies run vulnerability scans only after the application is developed and ready to go to production. Yet the scan comes back with a list of critical vulnerabilities that must be fixed before production, demanding a significant amount of time, money, and resources. The threat modeling process reduces cost and time expenditure by allowing organizations to understand the attack surface and introduce relevant controls to diminish the overall exposure to cyber threats.

A scalable threat modeling process builds a threat model in hours or days –depending on the size of the application – updating it with every release and making use of reusable templates. Although it is impossible to guarantee 100% security, effective risk management can assure 100% risk acceptance and mitigation, ensuring the protection needed to minimize damage for any given threat.