A collaborative approach to threat modeling

At Red Hat, we recognise the importance of implementing security measures early in the software development life cycle (SDLC), as breaches are becoming more evident in today's society. Our work in Red Hat Product Security is to help minimize the software-based risks of enterprise open source from Red Hat , while affording the many benefits that only open source can provide.

Shifting left in security

Red Hat invests significantly in the maintenance of open source software throughout the life of every product. For supported software we ship, we take on the responsibility of not just supporting it but also addressing issues of significant concern, such as security. “Shifting left” to introduce security checks and work during the early development and management phases is inherent to being successful in the work that we do. 

As part of this, the threat modeling process is an approach engineering teams can adopt to help identify security weaknesses in the design phase of their projects. When adopted early this allows for a more expedient identification and mitigation of threats, cost-effectively increasing the security of a product.

What is threat modeling?

Formally, threat modeling, outlined by OWASP, is a process by which potential threats are identified and rated for severity and possible mitigations are discussed. Less formally, threat modeling happens when you think about each decision made in a given system and extrapolate how these may affect its security profile, either immediately or in the future. 

It is important to stress that threat modeling is a process, not a tool. While tools can help the process be more efficient (e.g., by providing visualization, tracking changes over time, or identifying changes to software that would more likely affect its threat model), tools by themselves cannot currently take the place of humans reasoning about how other humans would attack a system.

Threat modeling as a “team sport”

Our team views threat modeling as a “team sport,” as we believe it is most effective when multiple stakeholders come together to look at a system from different angles: developers, architects and quality engineers, along with security specialists. The discussion can be as simple as walking through how the system is used, how it is supposed to work and how it actually works. Security specialists ask questions to get a better understanding of the security controls in place, the goal being that everyone leaves with a better understanding of the risks that affect the product.

An example of collaborative threat modeling

A recent successful example of how adopting a collaborative approach to threat modeling between engineering teams and security teams can be seen with the team behind Red Hat OpenShift Streams for Apache Kafka. The engineering team adopted this “team sport” approach during the product’s design and development phase. Their goal was to deliver an offering for public evaluation with greater security posture while also focusing their engineering efforts, saving valuable team time and budget, in the long term.   

Avoidance and discovery of security vulnerabilities in Red Hat’s managed offerings requires awareness of typical risks and a good understanding of vulnerabilities and their exploitations. The combination of the development team’s deeper knowledge of the service combined with the security focus provided by the Product Security team was required to complete a successful threat model. 

The development team drove these efforts and used this knowledge to construct a story that told readers about how each component within the service was being used and the respective security controls in place. This included examples about how the service handled:

• Authentication

• Authorization

• Data security

• Logging/auditing

• Resilience

• Network configuration

• Input (or data) validation

• Exception/error handling

How to approach threat modeling

One of the reasons the Red Hat OpenShift Streams for Apache Kafka team was successful during the threat modeling process was that they broke the threat modeling task into smaller parts as outlined in How to approach threat modeling. This meant focusing on a feature that was being developed by each team, rather than creating a single threat model for the entire workload. This approach had a number of key benefits:

• Smaller chunks of work allow for more granular progress tracking, which aligns well with development teams that are following agile-style delivery and gives leadership a constant view of progress.

• This approach tends to create threat models that are more detailed, which results in more findings being identified.

• Decomposition, or breaking down the threat model by features, opens up the opportunity for the threat model to be reused as a dependency for other workload features that use the same components.

• By considering threat mitigations for each component this means that, at the overall workload level a single threat may have multiple mitigations, resulting in an improved resilience against those threats.

• Issues with a single threat model, for example a critical threat that is not yet mitigated, do not become launch-blocking for the entire workload, but rather just for the individual feature.

• Aligning the boundaries of a threat model with the scope of each team meant that the team considered components built by other teams within Red Hat OpenShift Streams for Apache Kafka as “external systems” that needed to be protected against, meaning that the natural inter-team communication difficulties were well examined by the threat models.

At the start of each threat model the product security team was given a full overview of the feature/component and had the opportunity to guide the engineers on what Red Hat would consider to be a secure footprint for a Red Hat managed offering.  

The threat model was jointly completed in an agile manner over a number of weeks, where probing questions were asked of the engineering team and the answers they provided went through a security validation and were assessed against Red Hat’s security standards.

Those that could not be answered satisfactorily were noted as “Potential Flaws” and rated in accordance to the risk against the service. When done successfully, the security validation stage can help account for known and emerging threats and risks. 

Once the threat model was near completion it was shared with the wider team for a thorough review, and all team members were invited to add any other potential threats they had perceived.  

This type of team effort gives full ownership of the security posture of the service to the development team, with the guidance of the security team. 

Red Hat OpenShift Streams for Apache Kafka engineer's experience

“Threat modeling is a great tool for engaging software development teams early in the development cycle. It’s particularly well suited for building services, as it focuses on how data flows between processes and data stores, and on those who interact with the data.

Threat models are created by reasoning about the components that make up your service, locating potential flaws, determining the severity and determining the potential mitigations. Threat models focus on the security of the design (e.g., did you encrypt the data?, did you authorize access to the data? etc.) rather than the implementation (e.g., have you implemented the authorization checks without inadvertently introducing a flaw?).

Threat models have clear and tangible benefits for a product or a service — they provide a list of threats, ranked by severity, that the product team can start to work on and that security analysts can use to test the product prior to release. 

Threat models make the development team think carefully about whether their design is secure, and whether changes to the design can mitigate any risks identified. If teams do this early enough (during design and prototyping) then the cost of making changes to the design is normally low. 

However, for me, the ‘side effect’ of threat modeling, particularly when done early on, is distinctly more valuable. It makes the development team think about designing secure systems from day one. This means that your system is more secure when it is in production.”

If you want to learn more about the practice of threat modeling visit the Open Practice Library.

Learn more

• The OWASP Top 10 list describing the ten biggest Web Application Security Risks 2021

• 2022 CWE Top 25 Most Dangerous Software Weaknesses