ServiceNow NVD Integration [Part 1]

[Abi Adesanya]

Vulnerability Industry Standard

ServiceNow ingests vulnerability data from various third-party tools and is used in the remediation processes. This article focuses on the types of vulnerability data brought in by the National Vulnerability Database (NVD) & Common Weakness Enumeration (CWE) integrations. These vulnerability data are security standards, referred to as enumerations with unique identifiers and descriptions. They are characterised by having: 

• community-based consensus,
• a common identifier for cross-referencing,
• are publicly available, and
• use a standard format. 

In the Vulnerability analysis context, these standards provide benefits that enable faster, more accurate correlation, facilitate information exchange, and increase automation.There are a few of these standards, but the most prevalently used ones are:  

1. Common Vulnerabilities and Exposures (CVE) are publicly disclosed computer security flaws
2. Common Platform Enumeration (CPE) are a structured naming scheme for IT systems, software, and packages
3. Common Weakness Enumeration (CWE) are weaknesses found in software and hardware systems that lead to security issues
4. Common Configuration Enumeration (CCE) are security-related software-based configuration issues

CVE/CWE as a Reference

CVEs and CWEs have been a core part of ServiceNow Vulnerability Response since its inception. Still, in my opinion, they never seemed to get the respect or value one would expect when imported into the Platform. At best, they are primarily being used for reference on an ad-hoc basis. 

One reason could be attributed to its visibility and accessibility on the Platform. Most Third-Party SIEMS integrated with Vulnerability Response come with their own set of Vulnerability libraries stored in the Third-Party Vulnerabilities Entries table. And quite rightly so, these documented Third-Party Vulnerability libraries are worth their weight in gold as they are augmented CVEs rebranded with Vendor-specific unique identifiers. With proprietary IDs, the advantage of having a common identifier for cross-referencing across multiple teams and tools becomes a challenge. However, these vendor-specific vulnerabilities still refer to the original CVEs/CWEs.

In ServiceNow, these actual CVEs/CWEs, might not be easily accessible without knowledge of the table structure and a couple of clicks depending on the User's starting point of analysis. In most cases, it would involve drilling down or dot walking through the Third-Party Vulnerabilities Entries table from the Vulnerable Item (VIT) record.

Another reason might have been how the former NVD integration (Prior to V13.0) worked. Users were required to update the NVD data feeds when new releases are announced annually and prone to failures due to server overloads. This caught many users off-guard to the extent that it could take some time before the User realises the NVD integration no longer works.Thankfully, the regular updates required for the integrations to keep working is now a thing of the past with the current integration. 

Then there was the Software Asset Management (SAM) NVD feature, which used SAM discovered applications with CWEs for detecting Vulnerable Applications. This had a significant flaw as it required an exact match between the two data sources, resulting in skewed VITs – either none or loads of false positives. Also, there was an issue with the timing when CWE’s were released. This meant you’d never get an accurate view of your vulnerability attack landscape using this deprecated feature.There are other alternatives present today in ServiceNow that can be used.

Stay tuned for Part 2 as I will be sharing the current state of NVD & CWE integrations, addressing the challenges mentioned, also looking at CPE’s, what they are and their use cases.

[qcj3]

You accurately outline the challenges we see today with the NVD.