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.
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.
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.
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.
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:
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:
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