Weakness risk-patterns: A Red Hat way to identify poor software practices in the secure development lifecycle

Red Hat strives to get better at what we do, faster at how we do it, while maintaining high quality results. In modern software development, that means focusing on security as early as possible into our software development process, and continuously driving improvements by listening and acting upon early feedback in the Secure Development Lifecycle (SDL). One important tool toward that goal is the Common Weakness Enumeration (CWE), a community-developed taxonomy of flaws.

We use CWE classifications to gather intelligence and data to visualize clustering common weaknesses. We can then better inform risk patterns in Red Hat offerings, shifting the approach from reactive to proactive. These risk patterns can be used in risk reduction, feeding back into improving the SDL. This focuses training on and implementation of SDL security practices where they really matter: when software is developed by Red Hat and upstream communities and deployed by customers using Red Hat’s hardening guides.

Secure development lifecycle

Red Hat Product Security works with each product team to promote secure development practices and features, enabling us to build high quality software to better meet each customer’s business needs. Security architects from Red Hat Product Security engage engineering teams to review features, implement hardening, and respond appropriately to address vulnerabilities and weaknesses. In addition, as part of our SDL process, we conduct Threat Models, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Penetration Testing, and other heuristic tools. These tests, models, and reviews provide engineering teams with additional data on risks and potential considerations, which help to decrease risk and improve systems security functionality for an enterprise.

Weakness or vulnerability

The Common Weakness Enumeration (CWE) is a catalog of weaknesses that aims to enable better communication of weaknesses between systems or organizations. The catalog contains descriptions, consequences, the likelihood of exploits, and more (for example, Cross-Site Scripting (XSS) is identified as CWE-79: “Improper Neutralization of Input During Web Page Generation”).

On the other hand, the Common Vulnerabilities and Exposures (CVE) is a dictionary of publicly known information security vulnerabilities and exposures found in existing, implemented, and deployed systems. For example, the CVE entry CVE-2014-0160 is known by its popular name, “Heartbleed” (a specific input validation weakness applicable to certain versions of OpenSSL libraries when handling Heartbeat Extension packets).

The distinction between weaknesses and vulnerabilities is that before the implementation of software starts, there is no vulnerability that can be associated with the project. However, there might be weaknesses identified during SDL practices, such as threat modeling or SAST.

It is this distinction that drives Product Security to use a proactive instead of a reactive approach. By identifying weaknesses (hardening opportunities) during the development process, we seek to reduce risk of falling prey to a CVE and reduce the workload of future patches for engineering teams.

Finding a CWE

A proactive approach means that we map weaknesses found during the SDL process, working smarter and faster by focusing effort on common risk patterns early in development. Here are three example results that demonstrate the process:

CWEs in Threat Modeling: result example

Weakness

Description

Associated CWE

Lack of an audit trail for post-mortem analysis.

When security-critical events are not logged properly, or when the logs are unreliable, malicious behavior can be more difficult to detect and may hinder forensic analysis after a successful attack.

CWE 1210: Audit/Logging Errors

CWEs in SAST: gosec result example

Weakness

Description

Associated CWE

Use of a weak random number generator (math/rand instead of crypto/rand).

The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG’s algorithm is not cryptographically strong.

Gosec G404 (CWE-338)

CWEs in Penetration Testing: result example

Weakness

Description

Associated CWE

Over-Privileged Service Account Token.

Verified that the token obtained allows too many actions, some of them related to impersonation.

CWE-250: Execution with Unnecessary Privileges

Identified risk pattern example

An example of a weakness that was categorized and identified on several occasions to form a risk pattern was a weakness in an AWS (Amazon Web Services) RDS (Relational Database Service) deployment that was not enforcing encryption in transit. On investigation of why this was a common pattern, we were able to identify that the source of the weakness was a deployment “template.” Engineering teams were inheriting this weak deployment by default, which caused a one-to-many weakness mapping.

Sharing feedback on weaknesses

At Red Hat, the Product Security Secure Engineering team gathers metrics to formulate risk patterns using the top 25 CWEs found in different SDL phases. We focus on training that informs feedback to the knowledge base:

• Security training
• Hardening guides
  • Use case threat models deployment hardening guides
  • Best practice implementation
• Engineering teams learning from each other, driving improvements
• Security Testing, QA/QE improvements and better coverage, informed regression testing

Resources used to identify weaknesses

CWE focuses mainly on software development and not deployment. For this reason, operational aspects need to be considered separately. Not every CWE is as accurate as we would like it to be and it’s not always possible to find a CWE ID that perfectly describes what has been found.

That said, CWE is just one data source we use during our SDL security practices to create more accurate threat models and penetration tests. We also use:

• MITRE ATTACK to understand what can go wrong
• MITRE D3FEND: to plan how to migrate or mitigate
• Visualizing software architecture, using diagrams represented by the C4 Model that uses sequence diagrams, data flow diagrams, and architecture diagrams
• Data classification, and an understanding of how we gather, store, and use data
• Surveys to gather all the technology ingredients that each product encompasses

Conclusion

Developing software that maintains a greater security footprint is a complex task. Product Security works to stay ahead of the challenge by prioritizing our work to identify the risks unique to Red Hat offerings through collecting metrics, including CWE data, from every phase of the SDL and then analyzing data to make informed decisions, focusing our efforts on enhancing security measures where it really matters.