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.

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.

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.

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

The aim of the hackathon organized by the Swiss Association for the Blind and Visually Impaired and Red Hat was to create new solutions that make everyday life easier for blind and visually impaired individuals. At the event, blind, visually impaired, and visible technology professionals collaborated closely on a variety of initiatives, ranging from obstacle detection to autonomously detecting the expiry date of supermarket products.

The Swiss Association for the Blind and Visually Impaired (SBV) organized a hackathon for blind, visually impaired, and sighted individuals in partnership with technology partner Red Hat and sponsors VSHN and Tech Data. Around 30 programmers and IT professionals gathered at the Sheraton Hotel in Zurich to collaborate on practical solutions to assist blind and visually impaired individuals in their daily lives.

The two project’s initiators, Luciano Butera, Head of the Technology and Innovation Department at SBV, and Dominik Wotruba, Head of TechSales, Switzerland at Red Hat, greeted them at the ceremony. They also presented the project ideas that had been submitted in advance of the event. Five of them were eventually chosen for the final round. Especially, applications for:

• identifying food expiration dates
• identify possible obstacles
• discovering tandems for activities
• menu reading in restaurants
• asking the status of the train station’s lifts and escalators, including the indoor route

Open source projects

Following that, the participants were separated into five different projects. The majority of these come from Red Hat or SBV, although some came from customers and partners as well. “Small communities grew up around the concepts – very similar to open source projects,” Dominik Wotruba observes. “Everyone was allowed to pitch in their expertise and so contribute to the project’s success,” he continues.

The teams then had to create a working prototype in the smallest amount of time. VSHN provided each team with its cloud operating platform APPUiO, which is based on Red Hat OpenShift, while Tech Data donated its AI solution Tech Lab. Red Hat programmers also built fundamental frameworks for constructing solutions, known as skeletons, to make it easier for project members to get started. This was quickly followed by frantic thinking and coding. “The participants worked concentrated —- nearly nonstop, and you could feel that individuals were on a mission,” Luciano Butera explains.

Menus are accessible via a smartphone app

The teams had to present their answer to a jury of four at the end of the hackathon. In addition to Luciano Butera and Dominik Wotruba, the applications were analyzed and examined by Jonas Janz, a Red Hat solution architect, and René Jaun, an editor at the publishing business Netzmedien.

The “MENUista” project by Selamet Aydogdu, Dominique Hofstetter, Lars Jenzer, Alexey Loubyansky, and Erik Jan de Wit received special praise from the jury. During the hackathon, they created a smartphone app that displays the menus of neighboring restaurants. Blind and visually impaired people can then have these read to them directly and are no longer reliant on sighted companions.

According to Luciano Butera, the benefits of the solution, the project’s progress, and the presentation were all important factors in the evaluation. According to him, “MENUista” looked impressive in all areas. “The app is simple to use and does exactly what it should,” says the hackathon’s co-initiator. “As far as the team was able to design the solution during the hackathon, it delivers the most advantage to the consumers.” He is also sure that automatically compiling menus from adjacent eateries is often helpful. “The winning product is a good illustration of how software for the blind and visually disabled may also be useful for the sighted,” says Luciano Butera.

“Outstanding example of customer-centric work”

When asked to summarize the hackathon, the response was unanimously positive. Aarno Aukia, Co-Founder of the sponsor VSHN, provided advice to the hackathon teams. “When finding their way around the event area, the blind and visually impaired participants were sometimes delighted to have assistance,” he observed, “but as soon as everyone sat down at the laptop and started working, suddenly there was no difference at all.”

Christopher Schmidt, a participant at the event and a Red Hat partner innoQ Schweiz GmbH, compliments the “open, almost friendship-like attitude” that prevailed on site. “One of the pleasures of the two days was the opportunity to hear directly from the individuals who are affected by the difficulties daily and to figure out solutions,” he writes in his report.

“For the teams, it was important to develop solutions that are precisely tailored to the needs of the users,” says Dominik Wotruba. “It was therefore absolutely crucial to respond to the input of the blind and visually impaired participants, and the hackathon was a prime example of customer-centered work.”

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