Evolving OVAL

Red Hat has been heavily involved in providing our customers and the open source community with access to clear security data since 2002. We were a founding board member of Open Vulnerability and Assessment Language (OVAL) in 2002, and officially made a declaration of OVAL compatibility in 2006. Even before the newer standards of OVAL and Common Vulnerability Reporting Format (CVRF) came to be, Red Hat Product Security has had a heritage of transparency around security as demonstrated through our publicly sharing security advisories and Common Vulnerability Enumeration (CVE) pages so system admins, security professionals, and consumers could understand how Red Hat products are affected by security vulnerabilities.

While OVAL has evolved significantly over those 17 years, so to has the threat landscape that IT organizations must survive and thrive in. Business solutions have rapidly moved from distributed/client-server-based apps to complex (micro-)services-based composite applications that span multiple technological architectures. System administrators and security practitioners need to manage complex stacks where each component could introduce risk due to potential vulnerabilities in the attack surface.

In the days of yore (2006 to be more precise), Red Hat started publishing OVAL data. That data feed has been the cornerstone of sharing what vulnerabilities were addressed in Red Hat Enterprise Linux (RHEL) and, more recently, our layered products that ship Red Hat Packet Managers (RPMs). The use of OVAL has spread to our open source scanning tool, OpenSCAP, and by many third-party scanning vendors.

The details around Red Hat’s use of OVAL have been publicly documented for years; to cite the OVAL FAQ:

“Red Hat updates OVAL definitions each time a Red Hat Security Advisory (RHSA) for an OVAL-compatible product (see above) is released. OVAL content provided by Red Hat can be used to detect security updates which have been released by Red Hat, but not applied to a particular system.”

The current OVAL-feed describes issues that have been fixed through a Red Hat Advisory (a Red Hat Security Advisory (RHSA), or if a CVE is attached to a Red Hat Enhancement Advisory (RHEA) or a Red Hat Bug Advisory (RHBA)) in RHEL and other Red Hat add-on products.

While data around fixed vulnerabilities and available patches is extremely useful, it is not sufficient for many end-users to understand their entire threat-profile. Red Hat Product Security has long provided a comprehensive list of impacted Red Hat products by CVE and component through other mechanisms, but the greatly expanded scope of information included in OVAL and consumed in third-party scanners gives us the opportunity to change how we provide that information and deliver authoritative content to these consumers.

OVAL evolution 2.0: Streams

The nature of RPM and open source repositories present some unique challenges to how we solve this problem. RPM versions are not comparable outside of a given repository. As an example:

In RHEL Extended Update Support the “base” version of the RPMs is frozen, and then as updates are backported, an additional versioning number is added. This means that if RHEL 7.3 contained “kernel-1.2.3-4.el7”, RHEL 7.3 EUS might additionally contain “kernel-1.2.3-4.1.el7_3” and “kernel-1.2.3-4.2.el7_3” when things are backported, whereas RHEL 7.4 would contain “kernel-1.2.3-5.el7”.

Most of our products leverage a technique called backporting to ingest upstream fixes. We talked about this process in an earlier blog for those curious. The RPM versions in an OVAL file generated for RHEL 7.4 will therefore always return ‘vulnerable’ results if applied against a RHEL 7.3 EUS system, since the installed kernel version will always be “a lower version than” the version in which the OVAL file says the CVE was fixed. The same can be true for other non-RHEL “layered products.”

To support non-base-RHEL products with OVAL files, it becomes necessary to generate OVAL “streams” by product and version. These streams are available now as compressed files. A system running RHEL 7 base and Red Hat Satellite 6.4, for example, would want to use those streams, and those streams only, to make the applicable OVAL data available.

We highly encourage everyone to migrate to using the appropriate OVAL streams in the v2 directory instead of consuming the historical OVAL files in the directory one level higher. The traditional “v1” OVAL files are still accurate, only if you exclusively care about base RHEL, which is what they were designed / generated for, so are not as useful in determining other factors like impacted but not fixed.

Evolving security data and OVAL for the future

As noted above, currently the v1 and v2 OVAL files describe issues where Red Hat has already released RHSAs. This means, however, that based purely off of the OVAL feed there is no way to know about issues that Red Hat has decided not to fix or is currently in the process of fixing. Today, there are several available options to address these potential challenges for concerned end-users. Red Hat Product Security has been publishing details on vulnerabilities and the state of remediation of these issues since 2002. Depending on what type of end-user you are, there are multiple paths to get this more comprehensive data. Let’s take a tour through the history of our security data through the ages….

Precambrian data - DaysOfRisk

(Definitely NOT for GUI-clickers)

Security data gets posted directly on to the Red Hat Customer Portal. The Security Data page has historically been a popular destination for those curious about diving into Red Hat’s vulnerability data more deeply. Data-enthusiasts of all types can find a veritable Wonka-esque variety of data here, as this page contains numerous data feeds and insightful examples on how to use them. To point out a few highlights:

Daysofrisk.pl: the venerable “Days of Risk” script that helps analyze reams of data with one quick perl script. This script helps answer the question “what was fixed, and when?”

The Days of Risk script is driven by three data files:

• CVE Dates [cve_dates.txt]: contains all of the CVEs along with the dates they were made public and the Red Hat CVSS scoring and impact rating

• RHSA Dates [release_dates.txt]: contains the RHSAs that were released along with the date of release

• RHSA to CVE Mapping [rhsamapcpe.txt]: contains data that maps the CVEs to the impacted products and the RHSA that resolved it

By downloading the following script and the associated data files (that are updated twice daily!) you could learn about all of the issues for all products that were fixed in any severity level for a date-range:

$ perl daysofrisk.pl --dates 20190101-20191231 --severity CIML --cpe all

There are a lot of different ways this data can be sliced and diced to show precisely what you’re looking for. Now, to understand what’s potentially vulnerable, we still have some other options here.

In addition to running the script itself, the data files can be useful for finding information, such as public dates, affected products and what CVEs were included in an RHSA. For example:

To find the public date, reported date, impact and Red Hat CVSS score for CVE-2019-5791:

$ grep -i CVE-2019-5791 cve_dates.txt

CVE-2019-5791 impact=important,public=20190312,reported=20190313,source=internet, cvss3=8.8/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

To find the date and time RHSA-2019:1624 was released:

$ grep -i RHSA-2019:1624 release_dates.txt

RHSA-2019:1624 20190627:1016 (cdn)

To find the products, versions and packages affected (via CPE) by CVE-2019-5842 and the RHSA(s) that addressed it:

$ grep -i CVE-2019-5842 rhsamapcpe.txt

RHSA-2019:1492 CVE-2018-5743 cpe:/o:redhat:enterprise_linux:6::client/bind,cpe:/o:redhat:enterprise_linux:6::computenode/bind,cpe:/o:redhat:enterprise_linux:6::server/bind,cpe:/o:redhat:enterprise_linux:6::workstation/bind

RHSA-2019:1294 CVE-2018-5743 cpe:/o:redhat:enterprise_linux:7::client/bind,cpe:/o:redhat:enterprise_linux:7::computenode/bind,cpe:/o:redhat:enterprise_linux:7::server/bind,cpe:/o:redhat:enterprise_linux:7::workstation/bind

RHSA-2019:1145 CVE-2018-5743 cpe:/a:redhat:enterprise_linux:8::appstream/bind,cpe:/o:redhat:enterprise_linux:8::baseos/bind

Mesozoic data - RHSA-announce-list

(You’ve got Mail!)

Every time security fixes are released, we publish a Red Hat Security Advisory with the changes. We push this data out through several methods:

• RSS

• Twitter

• The Red Hat Customer Portal

• And more, including straight to Red Hat Satellite deployments tool!

The simplest way, however, is by subscribing to our mailing list. This will send an exciting stream of emails to your inbox as security-related bugs are fixed.

Jurassic data - CVE and advisories on the web

(So easy my child could do it!)

Along the lines of the previously-mentioned mailing lists, you can get a similar, very simple and clean experience viewing that same data on the Red Hat Customer Portal. The Security Advisories page gives a rich web-experience highlighting additional details of the flaws, affected products and the state of available patches. There’s even a link at the top of the table to adjust your Notification Preferences and have our portal send you mails as new RHSAs are added.

The sister-page of the Security Advisory pages is the Red Hat CVE Database. This is THE authoritative place for all CVEs that impact the packages and files within our portfolio of product offerings. Here you can find things like links to bugzillas or a description of the issue using Common Weakness Enumeration (CWE) that describe the actual coding flaw that creates the vulnerability, as well as any pertinent statements and mitigations that may be applicable.

Cretaceous data - Red Hat OVAL v1

(2006 called, they want their data back)

As mentioned previously, Red Hat has been a long supporter and contributor to the OVAL efforts within the industry. The OVAL data resides on our Customer Portal on our Security Data Page. Many commonly used scanners, like OpenSCAP, can use that data. Red Hat started publishing OVAL data for Red Hat Enterprise Linux in 2006, and made a change to our output earlier in 2019 (the v2 changes mentioned above).

Renaissance data - CVRF

(...but with data, not paintings or marble statues)

Realising that standards and requirements change in technology, Red Hat joined the Common Vulnerability Reporting Framework (CVRF) working group in 2011 to provide our data in a different format to our constituents. At its core, OVAL and CVRF share the same data, but the CVRF format is based upon an XML-format and is intended to provide an alternative machine-readable version of all our security advisories. We continue to work with our industry peers on standardizing data formats and helping to facilitate the accurate flow of vulnerability information.

Modern Data - the Red Hat Security Data API

(Because we’re living in a modern world, and I’m a modern person)

Our next evolution was to help our partners and customers that had different needs for our data and capabilities actually consume it. In 2016 we introduced the Red Hat Security Vulnerability Data API for public use. This consolidates all of our assorted output formats into one easily query-able interface. The API is flexible, allowing for the data to be pulled and manipulated in a myriad of ways, letting users zero-in on exactly what they are seeking.

We understand that not everyone has a team of developers that can help automate the collection of this data, so to simplify how end users work with the Vulnerability API, one of our engineers has created a tool, rhsecapi, for anyone to use, extend and submit enhancements. We’ve created detailed documentation to assist subscribers and partners in using rhsecapi as well.

$ rhsecapi CVE-2013-4113

[NOTICE ] rhsda: Found 4 CVEs on cmdline

[NOTICE ] rhsda: Valid Red Hat CVE results retrieved: 3 of 4

CVE-2013-4113

SEVERITY : Critical Impact

DATE : 2013-07-11

BUGZILLA : 983689

FIXED_RELEASES :

Red Hat Enterprise Linux 5: [php-5.1.6-40.el5_9] via RHSA-2013:1049 (2013-07-12)

Red Hat Enterprise Linux 5: [php53-5.3.3-13.el5_9.1] via RHSA-2013:1050 (2013-07-12)

Red Hat Enterprise Linux 6: [php-5.3.3-23.el6_4] via RHSA-2013:1049 (2013-07-12)

Red Hat Enterprise Linux Extended Lifecycle Support 3: [php-4.3.2-56.ent] via RHSA-2013:1063 (2013-07-15)

Red Hat Enterprise Linux Extended Lifecycle Support 4: [php-4.3.9-3.37.el4] via RHSA-2013:1063 (2013-07-15)

Red Hat Enterprise Linux EUS (v. 5.6 server): [php-5.1.6-27.el5_6.5] via RHSA-2013:1061 (2013-07-15)

Red Hat Enterprise Linux EUS (v. 5.6 server): [php53-5.3.3-1.el5_6.3] via RHSA-2013:1062 (2013-07-15)

Red Hat Enterprise Linux Extended Update Support 6.2: [php-5.3.3-3.el6_2.10] via RHSA-2013:1061 (2013-07-15)

Red Hat Enterprise Linux Extended Update Support 6.3: [php-5.3.3-14.el6_3.1] via RHSA-2013:1061 (2013-07-15)

Red Hat Enterprise Linux Long Life (v. 5.3 server): [php-5.1.6-23.4.el5_3] via RHSA-2013:1061 (2013-07-15)

FIX_STATES :

Not affected: Red Hat Enterprise Linux 7 [php]

The Data API easily unlocks the status of our CVE remediation, clearly showing what has been addressed by an RHSA, when products are unaffected by a particular issue or when we decide to not fix or defer an issue for future remediation.

Post-modern data - Red Hat OVAL v2

(Scott Bradlee would be proud of this data)

In 2019, Red Hat tackled another interesting problem with our OVAL data: While it was awesome if you were a RHEL user, we had a lot of gaps in talking about layered products that sat on top of it or other platforms. This technically complex problem was overcome, and by mid-year we started releasing OVAL data for layered products to much rejoicing. The above paragraph “OVAL Evolution 2.0” summarizes the state of those efforts.

Silver spacesuit data - Red Hat OVAL v3 and CVE pages 3.0

(To Infinity and BEYOND!)

Recognizing that simply “talking” about solved problems does not meet all the business demands of our modern era, we are not sitting on our haunches. Our track record as a product security team has been one of constant evolution and change (how VERY open source of us!). Starting soon, Red Hat plans to include more data in the v2 streams to include all CVEs as soon as they become public if they impact a product. This will be the dawn of a new era for our data, OVAL v3. We’ve offered this data for years through other mechanisms, but we feel that adding this and changing the scope of our OVAL feeds is the right thing to do to help our partners and customers.

In parallel to the OVAL efforts, Product Security is planning a major overhaul of our much-viewed CVE pages. Based on customer feedback, we’re adding many new data elements that our customers have asked for and a few ideas of our own to help more clearly describe vulnerabilities in the open source packages that comprise our products. These changes are slated to be released later this year and will be reviewed more in-depth in a future blog.

This change, combined with the expectation that customers will consume the OVAL streams for base and layered products relevant to their systems, will enable customers to generate a holistic view of their systems’ collective security state, bringing our security data into the future with unicorns, rainbows, flying cars and silver spacesuits.