This blog written by Dror Avrahami
The Common Vulnerabilities and Exposures (CVE) repository is designed to provide a reference for a publicly known information security vulnerability. CVE identifiers, or CVEs, are formatted with the prefix “CVE” followed by the year and unique identifier - for example, the “log4j” vulnerability is referenced as CVE-2021-44228. CVEs are assigned by a CVE Numbering Authority (CNA). It should be noted that assigning a CVE does not automatically make it an official CVE entry, in order to avoid duplicating a previously reported CVE.
We have significantly revamped the way CVEs are displayed and stored as indicators within Cortex XSOAR Threat Intelligence Management (TIM). Our main goal was to store and make available as much data as possible to help you query and use CVEs whether in your incident investigations or as a tool aiding in vulnerability management in your system. In this blog, we will go over the changes made in XSOAR TIM and modifications to the CVE indicator layout to present data in a more intuitive way. We will also cover how to install these changes to your TIM module.
Fig 1: New CVE display layout in XSOAR TIM
The new layout presents an analyst with detailed information about a CVE and the system(s) it affects, making it easy to build queries and playbooks with rich CVE data.
The CVSS score is now displayed in its own section and is color coordinated according to the CVE CVSS score. The score will display the CVE indicator verdict and will adjust its icon accordingly. This will now be the case across all CVE indicators in XSOAR thanks to an updated reputation script (CveReputationV2) which sets the correct XSOAR score according to the CVSS score.
Fig 2: CVE score display in XSOAR TIM
When a CVE has no CVSS score, it will display as “N\A” and the text color will be adjusted according to the color scheme set by the user:
The CVSS score is stored in two different fields:
Another enhancement includes the Vulnerable Products section which is dedicated to Common Platform Enumerations (CPEs). In this section, the analyst can now find a full list of all the CPEs relevant to the CVE.
Fig 4: List of CPEs relevant to CVE
The CPEs are parsed according to the their format:
cpe:<cpe_version>:<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>
The following sections are parsed and exported:
The extraction will remove escape characters and capitalize the results.
Fig 6: Vulnerability tags
Those of you with a keen sense of sight will notice that the CVE also has a tag named NVD-CWE-Other. This tag is created when no Common Weakness Enumeration (CWE) is found. When a CWE is found, the tag will point to the correct CWE ID. The CWE provides additional details about the type of vulnerability in that specific CVE, including its name, description, likelihood of exploit, examples of vulnerabilities in which the weakness is used, detection methods, and more. For example, in the picture below we can see CWE-416 which is the ID of the vulnerability known as “Use After Free”.
Fig 7: CWE vulnerability details
Another section that got a small facelift is the CVSS Table. The section will now display the CVSS Version that was used to calculate the score, the full CVSS Vector and a table of the values used to calculate the score.
Fig 8: CVSS Table
The CVSS version is extracted according to the specific vector in order to avoid mistakes in the data. The table is flexible and contextual, so version changes such as CVSS 3.0, 3.1, and 4.0 changes will not affect what is displayed for CVSS 2.0.
Relevant publications can now be properly exported and these are available in the Additional Details tab under Publications.
Fig 9: Relevant publications
These changes will allow you to better incorporate CVE data into your various playbooks and workflow jobs. The additional data allows for better visibility into CVEs impacting your organization and provides more info for threat hunting and security updates.
As this is a big change, there are multiple content packs that need to be updated. Most can automatically be updated but the Common Type content packs need additional steps as described below.
When updating layouts and indicators in TIM, we have to update the Common Types content pack (where the indicator types and layouts are configured).
Be careful, do not use this method if you have configured custom mapping for any of your indicators!
The easiest way to update this pack is to delete the existing pack on your XSOAR instance and reinstall the latest version. This will automatically rebuild the mapping from the context to the correct indicator fields.
Use this method if you have changed indicators mappings in the past
Update your Common Types content pack and go to Settings \ Object Setup \ Indicators and select CVE. Press the Edit button and move to the second tab called Custom Fields. Now we will have to set the mapping manually, so TIM will be able to pull the enriched data from the CVE context in XSOAR:
Fig 10: Series of screenshot of the XSOAR UI
After configuring these fields press Save.
As some new fields were added to the CVE class Base needs to be updated to accommodate those. As this is just new content, go ahead and update the pack, No special care is needed here.
Since we are integrating a few new scripts (dynamic ones and a reputation script for CVEs), we must also update this pack. As this is new content, just go ahead and update the pack. No special care is needed here.
The only integration that supports all of these new features at the moment is CIRCL CVE Search (formerly known as CVE Search). You can download the pack and install the integration, no API Key is needed, this is a free Plug & Enrich enricher available as part of the TIM module.
