While only Federal Civilian Executive Branch Agencies (FCEB) must adhere to BOD 22-01’s remediation and reporting requirements, many organizations in the private sector are including the KEV Catalog in their workloads. Since the initial publication, the list has been routinely updated with new vulnerabilities and we expect this to be a continuing trend.
3 directives for vulnerability management
For those unfamiliar with BOD 22-01, Risk Based Security published a detailed article covering its creation, purpose, and concerns. To summarize, there are three specific points involving vulnerability management that organizations should know:
Beholden organizations must establish and detail an ongoing remediation process for the vulnerabilities that CISA identifies. If asked by CISA, federal enterprises must provide a copy of their process.
Each vulnerability listed in the Known Exploited Vulnerabilities Catalog must be remediated within its specified timeline, which may vary.
Organizations required to comply with BOD 22-01 will be required to report on the status of vulnerabilities listed in the repository.
Over 8,500+ high to critical vulnerabilities last year
The Known Exploited Vulnerabilities Catalog is a major shift from the traditional views of vulnerability management (VM). Most VM frameworks place emphasis on CVSS scores, however, severity scores provide no context into whether an issue has actually been exploited or used in the wild.
While the KEV catalog addresses this shortcoming it does not lessen the existing workload for security teams. Rather, it increases it. BOD 22-01 is meant to supplement federal enterprise and the private sector’s vulnerability management efforts, but it does not replace Binding Operational Directive 19-02 which still requires federal enterprises to remediate high and critical vulnerabilities within 30 and 15 days respectively. Last year there were 8,500+ vulnerabilities with a CVSSv2 score of 7.0 to 10.0, so FCEB agencies will need a detailed and flexible VM process to remediate those issues and KEV Catalog vulnerabilities at the same time.
What should be prioritized—exploitability or high severity?
There can be conflicts in regards to prioritization and remediation if BOD 19-02 and 22-01 are compared side-by-side. If federal enterprises are expected to triage and remediate 8,500+ vulnerabilities as they appear, should they focus on those or the KEV Catalog?
Vulnerability remediation timeline
But even if organizations intend to remediate these issues, they may not have enough time to comply with CISA. Depending on the vulnerability remediation tools and data at their disposal, adhering to BOD 22-01’s short timelines may be near impossible. When the KEV Catalog was first announced, 100 of its initial 292 entries were due in two weeks. And over the following months, many more vulnerabilities have been published sporadically with the same remediation requirement. Now, CISA has disclosed 95 vulnerabilities with the same remediation timeframe.
Having only 14 days to resolve an issue is extremely difficult, since multiple steps need to take place before an issue can be fixed or mitigated. Before remediation can take place, organizations will need to research what is needed to patch, test the patch on development systems, and before that, security teams will have to know if their systems even contain those vulnerabilities. For most enterprises, the go-to method for that is scanning. However, reliance on this tool is one of the main reasons that enterprises often fail to meet CISA’s requirements.
Limitations of vulnerability scanning
When used alone, vulnerability scanners can be a detriment to your Vulnerability Management Program. This is because nothing can be done until the scanning vendor provides a signature and this process can take days or weeks.
Unfortunately, organizations will likely experience this delay often. A considerable number of KEV Catalog vulnerabilities have NVD assigned CVSSv2 scores that fall below 5.0. This is significant for three reasons.
Issues scored beneath 5.0 are viewed as “moderate” or even “low” risk
Even a CVSSv2 5.0 issue can be serious (see: Heartbleed)
Scanning vendors do not fully map to CVE
Most providers do not actually provide complete coverage, so what they opt to do instead is create signatures for issues that have high to critical severity scores and focus on issues that receive considerable attention. This means that it is highly likely that many lower-scored KEV Catalog entries did not have signatures at the time of its release.
In the case of zero-day or n-day vulnerabilities, this delay will last even longer. It isn’t a secret that many scanning vendors base their signatures on CVE/NVD data. So for issues like CVE-2022-22620, the Apple Webkit zero-day, CVE will designate them as RESERVED status, signifying that MITRE is in the process of aggregating information, or waiting on a researcher or vendor to provide them details. However, until that data is compiled the entry will contain no details. This means that NVD is also likely to be empty, since it is dependent on CVE. Once it is published, another delay can occur during the time it takes for NVD to analyze and then assign a CVSS score.
The Apple Webkit zero-day was added to the KEV Catalog on February 11 and had a due date of February 25. FCEB agencies will have already been required to remediate it, but CVE has had it classified as RESERVED for over two weeks preventing scanning vendors from deriving a signature for it.
Several other issues shared the same fate. Added back in October, the entries CVE-2021-38003 and CVE-2021-38000 had also been in RESERVED status for a lengthy period of time. The good news is that their CVE and NVD entries are now populated. The bad news is that both issues were published by NIST on November 23, 2021, after CISA’s due date of November 11, 2021. Worse yet is that according to NVD, CVE-2021-38000 is currently being reanalyzed, meaning that its current entry is out-of-date. At this time, the reanalysis process has lasted over a month:
In these situations, how long will triaging, researching, and remediation be delayed? If it is taking over two weeks for CVE/NVD to populate their data, how long will it then take scanning vendors to create corresponding signatures? On top of that, simply running the scan can be expensive and time consuming, so perhaps it will be pushed to the next monthly, or quarterly network scan. This doesn’t even account for the research that will then be required, since base CVE/NVD entries are often unactionable.
CISA’s ongoing reporting requirements
Organizations strictly relying on publicly sourced data or scanning technologies are at a disadvantage. BOD 22-01 is designed to put both federal agencies and the private sector on the path to proactively address risk. But if the data and tools at their disposal are unable to allow them to remediate or mitigate those issues in a timely manner, the needle won’t move forward.
Regardless of their resources or tools used, FCEB agencies are still required to report on the status of unpatched KEV Catalog vulnerabilities. And if Log4Shell is any indication of how long remediation processes actually take, then chances are many agencies are begrudgingly reporting numerous unpatched vulnerabilities, or are reporting many slowdowns in the remediation process. Timely vulnerability management not only improves the image of the organization, but it also allows BOD 22-01 to fulfill its purpose of strengthening the United States digital infrastructure against cyberattacks.
Detect, prioritize, and remediate risks faster
In order to remediate effectively, organizations need comprehensive and actionable vulnerability intelligence. Many of CVE/NVD’s deficiencies result from their inability to proactively seek out newly disclosed and updated vulnerabilities. Now that we’ve joined forces with Risk Based Security, organizations now have access to over 289,000 vulnerabilities, and are aware of new issues 21 days faster on average compared to NVD. Get a free trial to see how Flashpoint revamps vulnerability management capabilities.