Threat Modeling: A Comprehensive Guide

Threat modeling forms a pivotal part of identifying and curtailing potential risks threatening an organization’s information and systems. A systematic analysis of threats allows organizations to proactively introduce security measures to safeguard their assets.

This article will delve into the VerSprite-developed, which depicts who is Responsible, Accountable, Consulted, and/or Informed as part of the overall threat modeling process. We will unpack the customized RACI model to align with the PASTA threat modeling methodology to bring clarity and a better understanding of where the responsibilities lie across an organization. RACI is a role distribution diagram that helps companies adopt threat modeling while leveraging the roles within an organization and its InfoSec department. It is a straightforward visual to save your team time and resources.

‍

Understanding a Threat Modeling Example

Threat models are a proactive method of identifying and mitigating potential security threats and vulnerabilities in software systems or applications. It involves a systematic analysis and assessment of the security risks associated with a system to safeguard it against potential attacks.

Threat models enable organizations to comprehend and prioritize potential threats, thus allowing them to make informed decisions about security measures and resource allocation. By pinpointing potential vulnerabilities early in the development process, organizations can introduce appropriate security controls and minimize the risk of security breaches.

‍

Why is RACI Important in Threat Modeling?

RACI is important in threat modeling to build a workflow where there are multiple beneficiaries and stakeholders in a threat modeling process. The risk-centric threat modeling approach of PASTA goes through seven stages where multiple stakeholders will contribute or receive deliverables/ inputs from each stage.  This helps to ensure that the process is both meaningful and effective in building a model of threats for a given application or product.  When everyone involved understands their role in security and how they can contribute, it makes the threat modeling implementation and sustaining more effective.

In a recent video, Tony UcedaVelez, VerSprite’s CEO and Founder, expands on the importance of the role distribution in cybersecurity:

“It’s surprising to see that no other approach in application threat modeling has constructed a RACI model for other types of approach (e.g. – security-centric, software-centric, etc.).  VerSprite has spent time developing the RACI model based upon its interactions with product development teams across various industries.”

RACI Use Cases in PASTA

The security of the application does not just rely on code itself. It relies on design, the infrastructure, and the platform or frameworks that it is running on. Oftentimes, threat modeling conversations do not factor in all these different components, especially the people who have jurisdiction or stewardship over those technologies or efforts.

For example, in threat modeling, during dataflow diagramming exercise, you have developers that call out dataflows that are part of the software model. However, the architects, engineers, business analysts, or even the project managers, that are involved early on in defining requirements for the business are often not factored in. This is why it is so important to make application threat modeling very collaborative and to be an effort that many people can come to the table on.

Quality assurance engineers typically focus on functional testing. With the role distribution RACI offers, many of them now have an opportunity to also run security unit tests, especially as part of sprints. This becomes important because quality assurance engineers can run some security scripts that are developed by, for example, a DevSecOps group.

One important role that oftentimes gets overlooked is the architect, who is responsible for architecting the overall design and patterns to be used and abided by the software product.

Many developers are not architects, and they simply focus on developing software that relates to the modular component of the product. The architect is responsible for overseeing the process and understanding what types of permission roles, dataflows, requirements by the business, and compliance laws should be supported for the overall application model. Not inviting the architect is a major oversight, and in many threat-modeling activities and methodologies, you don’t have the inclusion of the architect at all.

Key Threat Modeling Roles That Should be Established

• System Architect: The system architect provides insights into the system’s design, infrastructure, and functionality. They collaborate with the threat modeler to understand the system’s components and potential attack vectors.
• Threat Modeler: The threat modeler is responsible for leading the threat modeling process. They are skilled in identifying potential threats and vulnerabilities in systems and applications.
• Security Analyst: The security analyst brings expertise in security best practices and helps identify potential security weaknesses. They work closely with the threat modeler to analyze and prioritize identified threats.

Each role has specific responsibilities within the threat modeling process:

• The system architect collaborates with the threat modeler to identify potential threats and validate the system’s design against security requirements.
• The threat modeler is responsible for facilitating threat modeling sessions, documenting threats, and providing guidance to the team.
• The security analyst conducts risk assessments, analyzes threats, and provides recommendations for mitigating identified risks.

Effective communication and coordination between the threat modeling team members are crucial for a successful outcome. Regular meetings and updates ensure that everyone is aligned and working towards the same goals. Clear communication channels should be established to address any questions or concerns that arise during the threat modeling process.

Planning the Threat Modeling Schedule and Resources

Proper planning is essential when it comes to threat modeling to ensure the process’s efficiency and effectiveness. By estimating the time and resources required, allocating them appropriately, and planning the schedule throughout the software development cycle, organizations can enhance the security of their systems.

Estimating the time and resources for threat modeling is crucial to allocate them effectively. This involves considering the complexity of the system, the level of detail required, and the expertise of the team. By accurately estimating these factors, organizations can ensure that they have the necessary resources in place to conduct a thorough threat modeling exercise.

Once the resources are estimated, it is important to allocate them appropriately. This includes assigning the right individuals with the necessary skills and knowledge to perform threat modeling activities. By leveraging the expertise of the team members, organizations can maximize the effectiveness of the threat modeling process.

Planning the threat modeling schedule throughout the software development cycle is vital to ensure that it is integrated seamlessly into the overall development process. This involves identifying the key milestones and phases where threat modeling should be conducted. By aligning the threat modeling activities with the development process, organizations can address potential threats at the earliest stages and minimize their impact on the final product.

Tracking and managing identified threats and mitigations is crucial to ensure that they are effectively addressed. This involves maintaining a centralized repository of identified threats, their associated risks, and the corresponding mitigations. By actively managing and monitoring these threats, organizations can proactively address potential vulnerabilities and strengthen the security posture of their systems.

Final Thoughts  and Prescriptive Advice on Threat Models

It should be mentioned that it is not an obligation to have this community of individuals come together and build a threat model. That would be time-consuming. The advantage of using RACI is having a set and efficient way to get either byproduct from each of these constituents, roles, and responsibilities to be used and leveraged or to get their direct input into the threat model.

The overall participation of some of these individuals makes for a better threat model. The better the input, the better the values that go into the understanding of flows, dependencies, the attack surfaces, threats, or threat intel. Many pieces of information can be derived by individuals in security operations, engineering, and development in other groups.

At the same time, many roles have limited involvement in building the threat model. Some of the roles are consulted or informed. This drastically reduces the amount of time and effort required to build an effective threat model while closing important informational gaps.

VerSprite’s RACI diagram is now made available for free on our GitHub page or directly from our website.

Learn more about the importance and implementation of threat models here.