5 Steps to Implement an Application Threat Modeling Program

Key Steps to Consider When Implementing the Application Threat Model.

1. Gaining executive support. Making sure the messaging to the C-level is clear and weighed.
2. Choosing a reputable framework. Threat modeling is an investment into not only your application’s future, but into your business’ security and continuity.
3. Reviewing input artifacts to be used in the threat modeling. Identifying required inputs to provide for a comprehensive overview of the application development and functionality.
4. Ensuring collaboration. A key for a successful implementation is making sure everyone involved into the process has a meaning input.
5. Identifying key players – RACI. Is there a clear understanding of responsibilities and roles among your team? We take a closer look at why this is one of the keys for the successful operation of the threat modeling program.

Let’s dive in deeper and examine the importance of each step.

GAINING EXECUTIVE SUPPORT

We are still witnessing that despite the growing and alarming cyber landscape in the post COVID-19 and tense geopolitical times, security continues to be shuffled behind the array of business efforts and priorities. Executive support is, unfortunately, still a luxury across most of the corporate environments. However, to adopt and sustain application threat modeling program and its long-term use, an executive top-down approach must be leveraged by a clear messaging of application security and business mission integral connection.

Security officers’ responsibility is to support the messaging, oversee security efforts, as well as communicate evolving security objectives to the executives. Application threat modeling provides for cohesiveness of communication across groups and helps sustain the common mission. While CISOs can implement the applicational threat model without executive support, it is necessary for its long-term success. However, getting C-Suite level executives on board can be a challenge, especially in the times of economic decline and budget cuts. Security officers can navigate the leadership in understanding that cybersecurity on applicational and organizational levels must be an essential part of business objectives, not a stand-alone mission.

Below are the recommendations on leveraging C-Suite Level Support: 

• Align the importance of a strong cybersecurity posture with the executives’ concerns. What is a potential effect of cybersecurity on business, its revenue? Does it affect data security and compliance? Be explicit and practical about potential threats to the organization and the ways to secure it. Executives need to see a clear correlation between security mission and business objectives.
• Understand the concerns of the C-Level. Just like it is important for executives to understand the need of investing into proper cybersecurity, it is necessary for security officers to recognize business objectives and company’s operational and budget concerns. If you are aware of their possible objections, you will be ready to proactively address them.
• Come prepared. Data breaches happen every day (in fact, there is a ransomware attack happening every 11 seconds), so using real-world examples can be helpful in getting across your message and its urgency. Make sure that examples and statistics are relevant to your industry and business objectives.
• Do your homework. When working on improving your organization’s cybersecurity posture, you will be faced with numerous methodologies and frameworks. Which one will work best for your application environment and business operations? Researching the threat modeling programs which will closely correlate and support business objectives is paramount. If you do not fully understand the effect and benefits of the threat modeling program on the software development lifecycle, its influence on overall cybersecurity and business mission, neither will executives and they will be likely to disregard it.
• Reiterate the financial risks. Ultimately, the C-Suites are running a business and its continuity and scalability will always be their top priorities. How will staying ahead of the threat actors and trends, having a better grasp on the cybersecurity posture, and consequently ensuring government compliance affect the company’s ability to scale? Compare the cost of potential breaches to the cost of the proactive prevention. By reducing software vulnerabilities, security teams reduce remediation time and efforts. Less time translates into less cost to the organization. The value of threat modeling to the business is great and clear, so should be the messaging.

CHOOSING A REPUTABLE FRAMEWORK

When looking at the options for the application threat modeling program, CISOs are faced with a few choices of frameworks and methodologies. Ultimately, a threat modeling program must be able to address what security requirements need to be present across multiple levels of the application environment as well as identify new attack vectors and potential exploits during the testing and validation efforts within the threat modeling process.

Meeting these goals ensure a comprehensive vulnerability assessment, reduces remediation efforts and risk exposure levels, and lays a foundation for a strong security framework that allows for ongoing sustainability of the program.

Here is a quick overview of some of the threat modeling programs and frameworks:

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). This method allows to organize security threats against an application system by classifying them. Classifying threats helps to show what security control is potentially vulnerable to exploitation. STRIDE is easy to use and understand for security professionals. However, it is not an application threat modeling methodology. It lacks definition of the threat modeling implementation, or how it should be followed and delivered. It also looks strictly at software.

DREAD (Damage Potential, Reproducibility, Exploitability, Affected Users, Discoverability). This risk-based approach to application threat modeling focuses on risk or asset-related themes that revolve around information loss or business impact of targeted assets. The DREAD analysis identifies the motives and intentions of the attacker and discovers security gaps in the application environment. Unlike software-centric approaches, DREAD does not address issues that relate to flawed or insecure coding and design practices.

TRIKE Threat Methodology. This acceptable-risk and asset focused approach identifies assets within the application environment, actors that interface with or within the application environment, related privileges, and underlying communication channels. TRIKE methodology allows to develop a risk model based on assets, roles, actions, and threat exposure. This methodology can be challenging to scale to larger system, because it requires a person to hold a complete view of the system to perform an attack surface analysis.

OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) is a practice-centric approach that focuses on assessing organizational risks. This methodology allows an organization’s information assets to be identified and datasets they contain to receive attributes based on the type of data stored.  However, OCTAVE lacks scalability and the documentation can become unmanageable as new users, functions, and assets are added.

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-based application threat modeling methodology. It begins with a phase for understanding key business objectives to be supported by the application threat modeling process and completes with a risk mitigation phase that provides the opportunity to mitigate any business risk issues that have been identified and qualified as a part of the threat modeling effort. PASTA’s seven stages provide a fundamental framework for an iterative threat modeling methodology. It might require some personnel training.

REVIEWING INPUT ARTIFACTS AND USE CASES

Prior to starting the threat modeling process, organizations need to review and have a clear understanding of the artifacts which will be used as inputs into the threat model.

Input artifacts help provide a full scope of the application development process and business objectives related to the application. The artifacts may include business impact and risk analysis, business and functional requirements, network diagrams and standards, architecture diagrams, use cases, users, roles, permissions, to name a few.

ENSURING COLLABORATION

A big advantage of threat modeling, unlike regular risk assessments where the strategy is “me vs them,” is that it invites everyone – from the application development to the business side – to contribute to the process, evaluate their side for potential risks, and incorporate them into the model. These collaborative efforts ensure thorough coverage of the operations, proper functioning of the threat model, and consequently, more effective cybersecurity posture.

This is one of the reasons why we, at VerSprite, advocate for the RACI model.

IDENTIFYING KEY PLAYERS – RACI MODEL

To ensure a successful collaboration between parties involved in development of the application and those on the side of running the business, it is important to have a clear understanding of the responsibilities, as well as the extent of involvement at the particular stages of SDLC.

A RACI model (Responsible, Accountable, Consulted, Informed) introduces the clarity into the threat modeling process and allows for the distribution of roles. VerSprite successfully employs it with the PASTA treat modeling process.