Headline
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
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.
Related news
In Bitcoin Core through 26.0 and Bitcoin Knots before 25.1.knots20231115, datacarrier size limits can be bypassed by obfuscating data as code (e.g., with OP_FALSE OP_IF), as exploited in the wild by Inscriptions in 2022 and 2023.
Scans of the Internet find that millions of computers, virtual machines, and containers are vulnerable to one or more of the hundreds of cyberattacks currently used in the wild, despite being patchable.
Organizations should update to the latest encryption (version 3.0.7) as soon as possible, but there's no need for Heartbleed-like panic, security experts say.
Is the new Heartbleed or just a bleeding distraction?
Zimbra Collaboration Open Source 8.8.15 does not encrypt the initial-login randomly created password (from the "zmprove ca" command). It is visible in cleartext on port UDP 514 (aka the syslog port).
Under certain circumstances, a vulnerability in Metasys ADS/ADX/OAS 10 versions prior to 10.1.5 and Metasys ADS/ADX/OAS 11 versions prior to 11.0.2 could allow a user to inject malicious code into the MUI Graphics web interface.
Bitcoin Core 0.20.0 allows remote denial of service.
Unspecified vulnerability in Oracle Java SE 6u75, 7u60, and 8u5 allows remote attackers to affect integrity via unknown vectors related to Deployment.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.5.37 and earlier, and 5.6.17 and earlier, allows remote authenticated users to affect integrity and availability via vectors related to SRCHAR.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.
native/unix/native/jsvc-unix.c in jsvc in the Daemon component 1.0.3 through 1.0.6 in Apache Commons, as used in Apache Tomcat 5.5.32 through 5.5.33, 6.0.30 through 6.0.32, and 7.0.x before 7.0.20 on Linux, does not drop capabilities, which allows remote attackers to bypass read permissions for files via a request to an application.