A Collaborative Security Assessment Method

As security breaches become more present in society, Red Hat recognizes the need to incorporate security measures early in the software development life cycle (SDLC). Our effort in Red Hat Product Security needs to decrease the software-based risks of Red Hat corporate open source while providing the many benefits only open source can give.

Shifting left in Security

Red Hat invests much in open-source software maintenance throughout the life of each product. We take on the responsibility of not only supporting the software we ship but also resolving concerns, such as security. “Shifting left” to introduce security checks and work during the early development and management phases is essential to our success.

As part of this, engineering teams can use the threat modeling technique to discover security flaws during the design phase of their projects. When implemented early, this allows for quick discovery and mitigation of vulnerabilities, therefore boosting the security of a product at a lower cost.

Security: What is threat modeling?

As defined by OWASP, threat modeling is a process in which potential risks are discovered, graded for severity, and potential mitigations addressed. Threat modeling occurs less formally when you consider each action made in a given system and extrapolate how these may affect its security profile, either now or in the future.

It is important to emphasize that threat modeling is a process, not a tool. While tools can make the process more efficient (for example, by offering visualization, tracking changes over time, or identifying modifications to the software that are more likely to affect its threat model), technologies cannot presently replace humans thinking about how other humans would attack a system.

Modeling threats as a “team sport”

Our team considers threat modeling to be a “team sport,” since we feel it is most effective when so many stakeholders, including developers, architects, and quality engineers, as well as security specialists, work together to examine a system from a few perspectives. The talk can start with a simple overview of how the system is utilized, how it is meant to work, and how it actually works. Security experts ask questions in order to gain a better understanding of the security measures in place, with the goal of ensuring that everyone departs with a greater knowledge of the risks that affect the product.

An illustration of collaborative threat modeling

The team behind Red Hat OpenShift Streams for Apache Kafka is a recent successful example of how taking a collaborative approach to threat modeling between engineering and security teams may be seen. During the product’s design and development phase, the engineering team took a “team sport” approach. Their goal was to create a more secure solution for public evaluation while also focusing their engineering efforts, saving valuable team time and resources in the long run.

Want to know more about Red Hat OpenShift?. Visit our course now.

Avoiding and discovering security bugs in Red Hat’s managed products necessitates knowledge of common risks as well as a thorough understanding of vulnerabilities and their exploitation. To build an effective threat model, the development team’s in-depth knowledge of the service, paired with the Product Security team’s security focus, was required.

The development team spearheaded these efforts and used this knowledge to create a tale that informed readers about how each component of the service was used and the security controls. This includes examples of how the service is handled with:

• Authentication
• Authorization
• Data security
• Logging/auditing
• Resilience
• Network configuration
• Input (or data) validation
• Exception/error handling

How Should Threat Modeling Be Approached?

One of the reasons the Red Hat OpenShift Streams for the Apache Kafka team was successful throughout the threat modeling process was that they divided the task into smaller segments, as described in How to Approach Threat Modeling. This required concentrating on a feature produced by each team rather than developing a single threat model for the entire workload. This method had many great advantages:

• Smaller chunks of work allow for more granular progress tracking, which matches well with agile-style delivery teams and provides leadership with a consistent perspective of progress.
• This method produces more complex threat models, which leads to the identification of more findings.
• Decomposing the threat model, or breaking it down into features, allows 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, a single threat may have different mitigations at the total workload level, resulting in better resilience against those threats.
• Issues with a single threat model, such as an untreated critical threat, do not become launch-blocking for the full workload, but rather for the individual feature.
• Aligning the boundaries of a threat model with the scope of each team meant that the team regarded components built by other teams within Red Hat OpenShift Streams for Apache Kafka as “external systems” that needed to be protected against, suggesting that the threat models thoroughly examined the natural inter-team communication difficulties.

The product security team was given a thorough overview of the feature/component at the start of each threat model and could assist the engineers on what Red Hat would consider a secure footprint for a Red Hat-managed solution.

The threat model was built collaboratively in an agile way over some weeks, during which probing questions were presented to the engineering team and the answers they supplied were verified and reviewed against Red Hat’s security requirements.

Those that could not be fully answered were labeled as “Potential Flaws” and ranked according to the risk associated with the service. The security validation stage, when completed properly, can aid in accounting for known and new risks and attacks.

When the threat model was nearly finished, it was shared with the entire team for a comprehensive assessment, and all team members were encouraged to contribute any additional possible threats they had identified.

With the guidance of the security team, this form of collaborative effort provides the development team complete ownership of the service’s security posture.

Discover more about a Collaborative Security Assessment Method. Just visit us here.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com