Rapid threat model prototyping: Introduction and overview

Threat modeling is a structured process cybersecurity professionals can use to identify, prioritize and mitigate security threats and vulnerabilities. While there are many different forms, each can bring its own level of complexity, structure and resource requirements that can make the practice seem overwhelming or difficult to implement.

However, when threat modeling is woven into the culture of an organization, applied alongside the implementation of new software and technology solutions and conducted at regular intervals during normal operations, the practice can help security teams ensure that the necessary controls are in place to address threats from across their enterprise. The practice can be used both incrementally to identify new potential security issues and holistically to measure risk across an organization.

The challenges of threat modeling can be more acute in an agile development, where fears of integrating security testing and mitigating activities into the process could slow down overall progress.

It is for these reasons that some organizations choose to utilize the rapid threat model prototyping (RTMP) to systematically identify, organize and mitigate potential risks.

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Rapid threat model prototyping overview

RTMP is based on traditional threat modeling approaches but is streamlined in very distinct ways to make the process more nimble and lean. To accomplish this, RTMP follows agile software development principles and software prototyping approaches that are further guided by the Pareto principle, where “80% of the threat model outcomes can be done with 20% of the effort of a normal threat model.” This allows the RTMP method to provide teams with just-in-time analysis when quick action and decisions are needed.

Key components of RTMP

Before diving into the RTMP approach it is important to understand several key foundational components of the model.

The role of requirements

Similar to agile software development, the RTMP approach is guided by business requirements or user stories that drive your operations. Similar to other cybersecurity concepts, security resources should focus first on those assets or operations that are the most critical to an organization while also finding a balance between providing property defense without deterring progress. Using business requirements helps your team to define a scope around your threat modeling efforts to focus on the intent of the systems in question.

Security architectural principles

The RTMP model advises users to think about the structure of security concepts, when implemented, using three architectural principles:

1. Secure in design: Security professionals should organize their system defenses around “zones of trust,” which follow the concept of defense in depth. (This will be explained further in a later section.)
2. Secure by default: These systems require user authentication for anything that interacts with them. The access control concept of least privilege also applies, restricting the amount of permission to be as limited as a business function requires.
3. Secure in deployment: Security professionals should identify the underlying system dependencies that could impact security, once implemented. These include identifying the points of access to the system, how systems will interact with one another, and the overall network topology that a system works within.

The zones of trust

Zones of trust “are numerical ranks of all of the elements in the threat model,” with a higher zone indicating a more critical element within the working model. RTMP considers the zones of trust to roughly equate to trust boundaries in other forms of threat modeling, but within this approach, the zones help to drive the overall analysis of risk.

Communication between zones of trust is allowed, but each zone will have its own requirements for the protection of data within their zone, access controls and rules for auditing and logging. 

Assigning zones

Use the following zone ranking for the processes and data within your organization’s threat model:

• Zone 0: An element that the modeling system does not control, such as external users or other systems.
• Zone 1: An element of a system or process designed to directly interact with a Zone 0 element. An example includes a web server. 
• Zone 2+: The higher the number, the higher the level of criticality of the system and the tighter the assigned controls. The higher the zone, the higher the target value for an attacker.
• Note: The figure below is a representation of the zone rankings applied to a system diagram.

Flows

A process or data flow within a system should be assigned the score of the system from which the process was initiated. 

Sources

A source, or input, should be considered if “generally considered to be outside the direct control of the modeled system and should be the lowest zone in the model.”

Sinks

The last stage of a process or data analysis, known as a sink within the RTMP approach, should be the highest zone of a model.

The RTMP approach

Step 1: Model the system

Either begin with an existing diagram of a system or create one if there is not one already in existence. During this documentation phase, capture:

• The business and technical requirements
• User stories or use cases, to help understand the function or role of the system
• Basic flows and processes
• Sources (where flows start)
• Sinks (where a system’s assets are stored post-processing)

The RTMP approach advises teams to follow the Pareto principle with the modeling phase, with a team putting in “the minimum amount of elements necessary for the model to make it reasonably complete (80%).”

With the system documented, teams can then designate the zones of trust, using the guidance provided in the earlier section. With the system diagram in place, the different parts of the process that require different access controls or that may have unique security issues should be more apparent.

Step 2: Analyze threats

The second step is to identify threats and assign threat values to them. To enable this, the RTMP approach uses the “STRIDE” mnemonic, which encompasses a “huge range of possible threat scenarios” to the data- and transaction-specific elements and uses the CIA Triad (confidentiality, integrity and availability) as a basic guideline to identify the impact if the threat is realized. STRIDE stands for:

• Spoofing
• Tampering
• Repudiation
• Information disclosure
• Denial of service
• Elevation of privilege

The STRIDE mnemonic overlays threats like information disclosure, tampering and denial of service.

Of all the threats, the RTMP model views the elevation of privilege as the most dangerous. If achieved, it can allow the opportunity to do any of the other attacks in the STRIDE model.

Given these risks, their potential impact if realized and the importance of discovering each type of threat, the RTMP advises teams to assign a risk score to the STRIDE values in the following order, noted adjacent to their zone ranking, as seen in the figure with its abbreviation:

1. Elevation of privilege 
2. Spoofing
3. Tampering
4. Repudiation
5. Information disclosure
6. Denial of service

Step 3: Analyze mitigations

After identifying the zone rankings and the STRIDE-related risks, it is time to analyze the potential mitigations to reduce the impact of a threat to the system.

RTMP advises that, for each STRIDE threat category assigned to the component of a system, there should be at least one mitigation mapped to it. 

To facilitate this process, one of the RTMP documents applied the OWASP Top 10 attack methods to the STRIDE elements to which it relates. The following table can assist in identifying potential mitigations to the top system risks based on their STRIDE-related vector:

The result should be a version of the system diagram for each STRIDE element, notated with its zone ranking applied and mapped to the OWASP threat(s) that could be realized, in order of probability to occur. The OWASP model, as well as other existing risk mitigation and cybersecurity best practices, can be used to identify security controls that can eliminate or lessen the potential or impact of the threat if realized.

Step 4: Validate

The final step is to validate all of the designations, scores, rankings, risks and mitigations identified. To do so, the security team should follow the below guide:

• Write a test that confirms the existence of the threat that can be given to the development or testing team. 
• If the threat is documented appropriately, the threat will be realized and the identified mitigation would be lacking. The development team can then determine their appropriate resolution.
• Perform a code review to verify that each identified and accepted mitigation selected for the system has been created and implemented into the final deployment. 

Following the testing, if the threat was not identified, was revealed to have a different impact or requires different mitigation, the RTMP diagrams for your system of process should be updated to reflect this information

Finally, as with all threat modeling, as components of a system change or how it is used within your organization is updated, the threat modeling exercise should be reevaluated to see if the threats, mitigations and probability of occurrence skill apply. 

Learn Threat Modeling

Get hands-on experience with six threat modeling courses covering defense-in-depth, frameworks like STRIDE and Rapid Threat Model Prototyping (RTMP), agile architecture and more.

Start Learning

Benefits of using threat modeling

Regardless of the form of threat modeling utilized, the practice is a powerful way for an organization to proactively discover security risks, identify a means to mitigate them and continuously monitor for changes in their security posture throughout their software ecosystem and enterprise infrastructure.

However, because the process can be time-intensive and complex for even experienced professionals, leveraging the open-source RTMP process can be a meaningful first step toward an organization adopting a stronger security posture, especially for those organizations comfortable with the agile and DevOps methodologies. If applied correctly, the RTMP approach can provide actionable information when development teams and stakeholders need it without significantly slowing down operations.

If you would like to dive deeper into the RTMP process, see step-by-step examples and walkthroughs of each step and learn how you can apply the model to your organization, Infosec Skills has a full-length course and pre-defined skill path designed and delivered by the founder of the approach, Geoffrey Hill. The course is just one of the hundreds of courses available with a monthly, annual or corporate subscription to the Infosec Skills learning platform.

Sources:

Threat meddling: 12 available methods, Software Engineering Institute

OWASP Top Ten, OWASP