Archives For security development lifecycle

CWE has different views for different audiences and purposes. In the early stages of development, CWE only had one hierarchical representation, which originated the current Development Concepts View (or Development View). CWE is currently organized in two main views: Development Concepts (CWE-699), and Research Concepts (CWE-1000).

The Development View organizes weaknesses based on concepts frequently used in software development, and most of its categories and groups build upon well-known past taxonomies. However, the lack of mutually exclusiveness and the large number of categories and groups led to difficult maintenance and several inconsistencies being accidentally introduced during its evolution.

The Research View was developed to eliminate inconsistencies, identify research gaps, and easier maintenance. It is based only on weaknesses themselves and their abstractions, it has no categories, and explicitly models the relationships between weaknesses.

For the elements in the CWE coverage for Red Hat Customer Portal, we carefully selected abstractions with enough relevant information for developers to detect and mitigate all its related weaknesses.

While the preferred type of weakness for CWE assignments are weakness bases, weakness classes are used in cases that there are “research gaps,” and it turns out to be difficult to make consistent CWE assignments using related weakness bases.

One notable example is the “Improper Restriction of Operations within the Bounds of a Memory Buffer (CWE-119),” where its children clearly overlap and contain elements that are admittedly under-studied and under-reported, such as the “Out-of-bounds Read (CWE-125)” and its variants.

Sometimes used to identify signedness errors, another under-studied entry is “Integer Underflow (Wrap or Wraparound) (CWE-191),” which is neither used to identify signedness errors in this coverage, nor to identify incorrect calculations leading to lesser integer values wrapping into higher integer values (or “underflows”), as we do not consider the correctness of the term “underflow.” Such errors are identified by “Incorrect Calculation (CWE-682),” and “Integer Overflow or Wraparound (CWE-190)”—regardless if the wrapping occurs “downwards” or “upwards.”

CWE identifiers are assigned to Red Hat vulnerabilities using the present CWE coverage at the time of the vulnerability assessment. Thus, references to vulnerabilities are divided into “time slices” based on the date the vulnerability was assessed and the present CWE coverage at that time.

The present CWE coverage for Red Hat Customer Portal uses the CWE list version 2.2, is available in CSV format, and also in HTML format emphasized in both Development and Research views using the YUI TreeView Control for easier navigation and reference.

We strongly encourage other Linux vendors to use this coverage and also engage in the CWE Compatibility and Effectiveness Program.

We are currently engaged in the CWE Compatibility and Effectiveness Program and working towards fulfilling its requirements for using CWE in our own outside-in methodology for identifying and eliminating the most dangerous software errors and weaknesses in our products. The CWE Compatibility and Effectiveness Program is a formal review and evaluation process for declaring products and services as “CWE-Compatible” and “CWE-Effective.”

To understand how CWE identifiers are assigned to Red Hat vulnerabilities, you also need to understand some elements of CWE terminology. CWE identifiers—also known as CWE IDs or CWEs—are organized into four main types: Category, Compound Element, View, and Weakness.

  • Category IDs are assigned to sets of weaknesses sharing one or more common attributes.
  • Compound Element IDs are assigned to combinations of weaknesses (i.e., Composites and Named Chains—more on these later).
  • View IDs are assigned to predefined perspectives with which you might look at weaknesses.
  • Weakness IDs are assigned to the actual software weaknesses themselves.

Weaknesses are also organized into three main types: Class, Base, and Variant.

  • Class is the most abstract type of weakness.
  • Base is a more specific type of weakness that is still mostly independent of a specific resource or technology.
  • Variant is a weakness specific to a particular resource, technology, or context.

Due to the diverse nature of our products, the preferred type of weakness for CWE assignments are weakness bases. Weakness classes are used in cases that there are “research gaps”, and it turns out to be difficult to make consistent CWE assignments using related weakness bases.

Weaknesses IDs are assigned to Red Hat vulnerabilities in chains. A chain is a sequence of two or more weaknesses closely linked together. Where one weakness X, can directly create the conditions necessary to cause another weakness Y, resulting in a vulnerability. In such cases, CWE refers to X as “primary” to Y, and Y as “resultant” from X.

A named chain is a noted commonly recurring chain that have received its own CWE identifier. A composite is an inclusive combination of two or more weaknesses or chains that forms another named weakness or vulnerability.

Differently from what security assessment tools do—with a few exceptions, such as integer overflows and variants—vulnerabilities are commonly named and reported as its resultant weaknesses, with little or no additional research from the reporting party. Thus, it is up to Red Hat to construct the chain backwards for properly identifying the cause of the vulnerability.

In the last post, I will present and go through the reasons behind the decisions for the elements in the CWE coverage for Red Hat Customer Portal.

Outside-in vulnerability assessment for secure software development is a process for identifying and eliminating the most dangerous and potentially exploitable weaknesses in your products. Making your product achieving broad early adoption, positive reviews, and becoming reference on the industry not only for delivering what your clients need, but also for delivering it with an outstanding level of security.

The Security Development Lifecycle (SDL) is a proven secure software development process consisting of security practices grouped into phases, from training to response. However, you may have your main product already within the response phase, whereas its development was not done practicing SDL or any other secure software development methodology. This is mostly true for open source software vendors (i.e., Linux vendors), where training upstream developers for development of its own software is not always viable. This is where outside-in vulnerability assessment can help.

Even if you are not an open source software vendor and have in-house development of your software, outside-in vulnerability assessment complements any approach your team may be practicing for software development. You can not afford to withdrawn your product from the market, educate your developers, and start the development of your product from the scratch, nor you can do this for the next version of your product. You need to respond to whatever problem is identified in your product, immediately.

Currently, we have a team dedicated to vulnerability assessment, the Red Hat Security Response Team, which uses CVE identifiers and CVSS scores for identifying, coordinating, and prioritizing the correction of the vulnerabilities identified and reported in our products. In the future, the Red Hat Security Response Team will also use a common taxonomy for classifying, quantifying, and ranking the weaknesses that resulted in these vulnerabilities, which can also be understood by developers, and preferable also supported by security assessment tools. The language chosen by the Red Hat Product Security Team is the Common Weakness Enumeration (CWE).

In this first phase, we started assigning CWE identifiers, chains, and composites—more on this later—to past, current, and future Red Hat vulnerabilities with a CVSS v2 score higher than or equal to 7. Periodically, after classifying, quantifying, and ranking these weaknesses, we direct all our efforts into dealing with these weaknesses in our products as part of our assessment services, knowledge repositories, software development practices, and education offerings.

This approach is different from what other companies practice for software development, where CWE identifiers are used to track the issues that they have addressed during development of their software. The outside-in vulnerability assessment streamlines the efforts directly on recurring weaknesses resulting from programming practices that, consequently, tend to recur often.

In the next posts, I will go through the Red Hat engagement for CWE compatibility, how CWE identifiers are assigned to Red Hat vulnerabilities, and the reasons behind the decisions for the elements in the CWE subset chosen for the outside-in vulnerability assessment.