CISA’s BOD 22-01: How to Prioritize 100 Vulnerabilities in Two Weeks

[This was originally published on riskbasedsecurity.com, and had considerable edits/enhancements done by Curtis Kang.]


CISA BOD 22-01 introduces the directive for government vendors to mitigate 292 CVE IDs, or 301 vulnerabilities, 100 of them within a short timeframe. It is well-meaning and brings potentially valuable focus, but it will put pressure on teams working with incomplete data. Risk Based Security clients have a head start of 21 days, on average, but prioritization remains key. Here, we break down what BOD 22-01 includes, the likely impact, and how teams can respond to remain compliant and meet the deadline.

What is BOD 22-01?

On November 3, 2021, the Cybersecurity and Infrastructure Security Agency (CISA), a branch of the U.S. Department of Homeland Security (DHS), released Binding Operational Directive (BOD) 22-01. This is a significant directive that has garnered media attention and impacts many organizations; especially those that support US government agencies. Cybersecurity Directives from CISA are infrequent, the last being issued on September 2, 2020. Despite this, they tend to be high-level and high-impact, potentially helping organizations that follow CISA’s guidance. However, BOD 22-01 is unusually direct, instructing federal, executive branch, departments, and agencies to mitigate a specific list of vulnerabilities in a strict time frame.

Although this BOD is aimed towards the government, organizations outside scope will likely expect their Vulnerability Management teams to also address these issues. For security professionals caught in this situation, how will you start to prioritize 292 entries, with 100 due in two weeks?

Directives for Vulnerability Management

CISA BOD 22-01 has three lines specific to patching requirements:

  1. Remediate each vulnerability according to the timelines set forth in the CISA-managed vulnerability catalog.
  2. The catalog will list exploited vulnerabilities that carry significant risk to the federal enterprise with the requirement to remediate within six months for vulnerabilities with a Common Vulnerabilities and Exposures (CVE) ID assigned prior to 2021 and within two weeks for all other vulnerabilities.
  3. These default timelines may be adjusted in the case of grave risk to the Federal Enterprise.

Overall, this seems to follow patching guidances many commercial entities already use. But one point that sticks out to us is that organizations must remediate vulnerabilities with an ID assigned prior to 2021 within six months.

This particular directive has two elements that makes the six month deadline seem strange:

  1. Some highly severe vulnerabilities have a six month deadline despite missing the 2021 cutoff by a few days.
  2. Vulnerabilities that have been exploited for years are given a six month deadline compared to less severe vulnerabilities published somewhat recently.

Consider CVE-2020-10148 (VulnDB ID 245663), covering “SolarWinds Orion Platform API PathInfo Parameter Handling Remote Authentication Bypass” (AKA ‘Supernova’ and ‘Sunburst’). That CVE was made public just two days before the 2021 cutoff. Given BOD 22-01, this vulnerability has a deadline of six months. However, it was discovered and was exploited in the wild and is likely much more severe than other issues published and assigned in 2021.

Caveats like these highlight the imperfections of BOD 22-01. It goes against conventional wisdom to place more emphasis on newer, less severe vulnerabilities published in the last few months rather than issues that have been widely exploited for years. Organizations using BOD 22-01 as a guide to protect themselves will need to make their own prioritization decisions, rather than blindly following CISA’s directives.

Starting the Prioritization Process

This BOD was initially published with 292 entries on the list. Over time it will be updated, but as of now we don’t know when or how often. A few facts about the vulnerabilities:

  • There are 292 CVE IDs on the list, but they actually represent 301 distinct vulnerabilities according to VulnDB and the Risk Based Security Platform
  • The first issue was disclosed on 2010-12-14 and the most recent on 2021-10-28
  • The CVSSv2 scores range from 1.2 to 10.0
  • 83 entries are scored CVSSv2 10.0, representing unauthenticated remote code execution
  • Two of the vulnerabilities have a CVE assignment, but they are still RESERVED with no details on that site

There are several vendors we expect to see, and they represent about one third of BOD 22-01:

But when it comes to the November 17 deadline, there are 100 vulnerabilities from the following vendors:

If your security team receives a directive from up on high, how would you start to prioritize? Even by reducing the number of vulnerabilities from 292 to 100, there is still a lot of work to be done. How can you best spend your time and resources to patch? That is where vulnerability metadata can come in handy. With more context and rich analysis, specific aspects of each disclosure can make your life easier.

CVE Lacks Critical Metadata

If your goal is to prioritize and remediate these vulnerabilities by the deadline, CVE will not provide the necessary context to do so. The Common Vulnerabilities and Exposures (CVE) project, paid for by DHS but run by MITRE, is the cornerstone of all CISA vulnerability content. From ICS-CERT advisories to NCAS Alerts to US-CERT weekly bulletins, all of them use CVE IDs to refer to a specific vulnerability.

Unfortunately, the CVE program has many shortcomings, which extend to BOD 22-01 as well. For those who want to use the list to learn more about a vulnerability in a meaningful way, you will be forced to use the National Vulnerability Database (NVD), run by NIST, and you will likely have more questions than answers.

If you use NVD as your main source of vulnerability metadata, you will likely struggle to understand the real impact of vulnerabilities in the BOD. Using ProxyLogon as an example, looking at its four CVE IDs will leave you underwhelmed. For most vulnerabilities, CISA advises users to “apply updates per vendor instructions”, but even then analysts will be hard pressed to find useful information. Applying that advice, The ProxyLogon website only mentions two out of four vulnerabilities, the Wikipedia page doesn’t mention any until you get to a footnote, and depending which source you can find, various exploits and news articles may list all four.

These are not the only ones either. Looking at CVE-2021-27059, CVE-2021-27085, CVE-2021-26411, CVE-2021-1732, CVE-2021-1647 and others will reveal similar inconsistencies and a shortage of actionable information. Even worse, the most recent two vulnerabilities on the list are CVE-2021-38003 from October 28 and CVE-2021-38000 from October 15 and at time of writing both of these vulnerabilities are in RESERVED status and contain no details at all. In regards to details and timeliness CVE/NVD is simply not enough.

The Importance of Comprehensive and Actionable Intelligence

In order to remediate 100 vulnerabilities in a timely fashion, organizations will need comprehensive and actionable vulnerability intelligence. Risk Based Security has previously reported and continues to update the BOD’s entire vulnerability catalog. When it comes to BOD 22-01 vulnerabilities, our clients had access to those vulnerabilities 21 days faster, on average, than organizations relying on NVD, and we note a 53% scoring discrepancy in CVSSv2 (and 39% for CVSSv3).That’s 21 days of extra time to prioritize and remediate based on scores that closely follow the CVSS specifications.

Many of NVD’s metadata deficiencies can be attributed to CVE’s reactive aggregation process, wherein MITRE relies on CVE Numbering Authorities (CNAs), vendors, and researchers to submit vulnerabilities. Risk Based Security researchers independently and proactively seek out newly disclosed and updated vulnerabilities on a continuous basis, which results in more comprehensive coverage and metadata that provides deeper insights.

Deal With the Attackers At Your Door

In the grand scheme of things, it would be helpful to know which of these vulnerabilities being exploited in the wild were originally discovered in the wild. Such zero-day attacks often represent high-end exploits that are used by serious threat actors, nation states, and/or sold on the grey market for tens or hundreds of thousands of dollars. Identifying these types of vulnerabilities could serve as a short list of issues to patch immediately.

This is just one instance showcasing the importance of better data. 125 BOD entries were discovered in the wild, which is over one third of the list! While alarming, compare that number to other vulnerability tracking services and databases, many of which do not even track that point of data.

Google’s Project Zero team maintains their own “0day in the Wild” sheet to track such exploits, which is updated in a fairly timely manner. At the time of this article, their list contains 196 entries with some metadata. Compare that to the Risk Based Security Platform and VulnDB, which currently have 754 vulnerabilities flagged as “discovered in the wild” and provide all known details. The delta between these sources may put the importance of metadata into perspective. Having a timely view into all these vulnerabilities, including the BOD’s 100, is a  significant benefit to a security team working to triage an otherwise overwhelming number of issues.

Timeliness is critical, especially if your organization’s goal is to proactively address vulnerabilities that have public exploits. While BOD 22-01 does include vulnerabilities that need to be addressed, it does not include all publicly-known exploitable issues:

It is impossible to know or predict exactly which vulnerabilities will be exploited by threat actors and nation states. However, organizations that are aware of all known vulnerabilities with public exploits are in a much better place than those who rely on publicly-sourced data. By having that data, organizations can perform the next step in prioritization: contextualizing vulnerabilities to their assets.

Create an Asset Inventory to Save Time and Resources

Triaging the BOD 100 could kick-start the process of building an asset inventory. Use this as an opportunity to ensure that your list is updated and accurate, which will enable more efficient vulnerability management in the future. The days of relying on network vulnerability scanning alone to assess an entire corporate network are over, and slowdowns caused by those tools could cause you to miss the November 17 deadline.

Instead, using a comprehensive asset inventory along with comprehensive vulnerability intelligence allows a team to swiftly identify which systems are vulnerable without relying on weekly or even monthly scans (assuming their vulnerability scanner even detects a given issue). With the idea of an asset list in mind, ask yourself whether you even run all the software in the BOD. Odds are you run a significant amount, but not all of it.

Having an inventory quickly rules out the vulnerabilities that don’t apply to you, and may cut the list down to make it more palatable. While some vulnerabilities may be the most often exploited, it doesn’t mean the software is the most often run. For example, do you run any of the following? BillQuick Web Suite, Serv-U Secure FTP / Serv-U Managed File Transfer Server, FreeType, Tenda AC15 Router, Duplicator Plugin for WordPress, or DrayTek Vigor? If not, congratulations, you no longer have to remediate over a dozen vulnerabilities. Eliminating irrelevant entries will lessen your current workload now, and as the BOD’s “Known Exploited Vulnerabilities Catalog” grows, it may also save valuable resources in the future.

Check the Software Bill of Materials (SBOM)

Astute readers may have read the examples we provided and thought, “Of course I know what FreeType is!” That’s great, but do you know if it is integrated into any of your software? This highlights the benefit of development teams maintaining a Software Bill of Materials (SBOM) so they can more easily determine if vulnerable third-party libraries might impact them.

That, in turn, leads to the question of whether your vulnerability intelligence provider has comprehensive third-party library coverage or not. Unfortunately for many, CVE/NVD do not.

Strike Issues With No Solution

Next, eliminate any issues on the list that apparently have no solution, despite the directive generically saying to “Apply updates per vendor instructions.” Based on a quick examination in VulnDB, it appears that nine of the 291 listed remain unpatched, with the first going back to CVE-2018-14558 (VulnDB 191694 – Tenda Multiple Products /goform/setUsbUnload deviceName Parameter Remote Command Injection Weakness).

After performing these steps, your remediation queue should not only be less intensive, but also tailored towards your actual risk profile. This way, even if your team happens to miss the November deadline, your organization won’t be unnecessarily vulnerable since you have a plan that will deal with the most relevant and impactful issues first.

Using the BOD 22-01 in the Future

We hope that this article has been helpful in your efforts to deal with those 100 vulnerabilities. But if you’re still in the process, or preparing for the remainder due in six months, how can you use the list to move forward?

Start building or improving your asset inventory. Use the remaining BOD vulnerabilities as an opportunity to ensure that your list is updated and accurate. Get the relevant vulnerabilities in the hands of each team responsible for mitigation. Do not overwhelm them by sending the entire list and making them sort through it themselves.

Repeat the same procedure using vulnerabilities designated “Patch by May 3, 2022”. While that is a very generous timeframe, the security of your organization may be at stake. With ransomware infections at an all-time high, your team must patch these sooner than later.

Moving Forward and Staying Ahead

But once the list is addressed, what’s next? We’re left with two big questions that will dictate how your team has to continue to respond to it:

  1. How often will the list be updated?
  2. Do we know what vulnerabilities are more likely to appear on it?

It will be hard to know for sure how often CISA will update the BOD since the last directive was published nearly two years ago. Regardless, our research team will be monitoring it daily, keeping tabs to see when it changes. When a new vulnerability is added, we’ll ensure it is covered in both The Platform and VulnDB and add every CISA link to make it more easily found in a search.

For the second question, it is nearly impossible to predict exactly which vulnerabilities will appear in the future. However, we can predict with some accuracy, where they might appear before the CISA BOD list. As mentioned, Google’s Project Zero 0day tracking sheet is a good resource. Vulnerabilities that appear on that list are a lot more likely to appear in the BOD.

For our customers, keeping an eye on the broader list of vulnerabilities discovered in the wild we track is  a great predictor as well. The top vendors listed in the previous section will certainly continue to appear on the list. Making sure to stay on top of the big vendors that represent significant portions of your assets is the easiest way to stay ahead of the curve.

Make Better Prioritization Decisions With Better Data

Having access to a comprehensive, actionable, and timely source of vulnerability intelligence is key when remediating issues in a short time frame. Without proper metadata, organizations will be hard pressed to understand the issues they are being told to fix. But with the Risk Based Security Platform, security teams get all known details regarding BOD vulnerabilities while also becoming aware of every other disclosed publicly exploitable issue.

At this time, there are over 100,000 vulnerabilities with public exploits beyond those identified in the BOD catalog. The Platform provides visibility into those issues and more, covering over 268,000 vulnerabilities in IT, OT, IoT, and third-party libraries and dependencies. Make better prioritization decisions with better data.

Leave a Reply

%d bloggers like this: