BOD 22-01
  • November 18, 2021
  • Dave Farquhar
  • 0

CISA BOD 22-01 introduces the directive for federal agencies and systems to mitigate 292 CVE IDs, or 301 vulnerabilities, 100 of them within a short timeframe. That sounds like a lot of work, and for some organizations, it may be more work – scheduled in a much shorter time frame – than they’re used to. Here’s how to use Nucleus to catch up and get compliant with BOD 22-01, and more importantly, how to stay ahead of it and not have to scramble to get into compliance on a short deadline again.

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. Cybersecurity directives from CISA are infrequent, the last being issued on September 2, 2020, and they tend to be rather high level. BOD 22-01 is different, because it instructs agencies to remediate a specific list of vulnerabilities, and it attaches strict deadlines. Importantly, this directive is a requirement, and not simply guidance or a recommended best practice.

The target for this BOD is government organizations. However, it is not at all uncommon for private industry to adopt government standards once they become aware of them. Organizations with significant government contracts in their book of business would do well to comply, and be able to prove compliance upon demand. Nucleus simplifies compliance. If you’re a security professional not used to fixing vulnerabilities in bulk on a short deadline, here’s how to use Nucleus to find the vulnerabilities in BOD 22-01 in your network, prioritize them, assign the work, and prove compliance.

Where the List in BOD 22-01 Came From

We have already started getting questions about BOD 22-01 and how to use Nucleus to get into compliance. While our customers know there’s no place in Nucleus to enter 292 CVEs and have Nucleus tell you what to do, it’s possible to use vulnerability management expertise and reverse engineer the list in Nucleus. By defining policies within Nucleus, you will both arrive at a list of things to do to get in compliance with BOD-22-01. More importantly, Nucleus will then help you stay out in front of this and future directives. While there is no guarantee there will be a sequel to BOD 22-01, the expectation is there will be future similar directives. If not, this is a reasonable standard to use going forward and can readily become part of your unified VM program. Historically, the problem with prioritization is the lack of a north star – a standard to follow. With BOD 22-01, we now have that standard.

But I still haven’t told you where this list came from.

BOD 22-01 is nothing more than a list of exploitable vulnerabilities with two deadlines attached. If the vulnerability dates to the year 2020 or earlier, you have two weeks to fix it. If the vulnerability is from 2021, you have six months to fix it.

To translate this into requirements that you can incorporate into your own internal vulnerability management policy, use the following definitions:

  • if a vulnerability is exploitable and more than a year old, it must be fixed within 14 days
  • if a vulnerability is exploitable and identified in the current year, it must be fixed within six months

Some analysts have observed that the list and deadlines appear rather arbitrary, noting vulnerabilities on the short two-week deadline that are less severe than vulnerabilities that are on the long six-month deadline. There is actually a good reason for this approach – it has to do with risk, and I’m not talking about the risk that comes from attackers.

Every change to computer code risks introducing new bugs, and in some cases, the new bug is worse than the one it fixed. In my professional experience as a System Administrator who specialized in patching, those problems become apparent soon after the release date. Usually, people start talking about them within a few days – certainly within two weeks. Once an update is more than about a month old, new problems rarely surface and it can be generally assumed to be safe. Maybe not as safe and benign as a sugar pill, but probably comparable to the risk associated with ibuprofen. Problems will be rare, and isolated. Patches from the prior year can generally be assumed to be time tested and safe for general use, especially by government standards.

What about the six-month deadline, then? Is that too generous?

A deadline of six months accomplishes several things. First, it provides ample time for testing. Second, in the case of difficult technologies like Java for example, it provides time for the vendors of software written in Java to release updates to their code to fix any compatibility issues with that patch. Without this deadline to stand on, when I was working on government contracts, I had to write a six-month Plan of Action and Milestones (POAM)—the equivalent of a risk acceptance–every time a Java update came out. Attaching a six-month deadline cuts down on the paperwork and red tape.

Yes, sometimes an update comes out with a note attached saying the vulnerability is already being exploited in the wild. But such updates are infrequent enough that they can be handled on a case-by-case basis. If anyone is used to doing that, it’s the United States Government.

If you are able to eradicate new vulnerabilities from your network faster than six months, by all means keep doing it. The intent of directives like this is to get everyone to that level, not to slow high achievers down. Strange as it may seem, some people do need to be reminded that a deadline doesn’t mean to do something on that date. It means to do something by that date.

While none of us at Nucleus have insider knowledge, several of us have years of experience working in patch management and vulnerability management on government contracts. We’re using that experience to infer CISA’s intent. While our inference may not be exact, it will be close enough to make compliance with future directives much easier.

So that’s where the deadlines appear to have come from and context for the timeframes. But what about the list?

Your vulnerability scanner – if you use one of the big three – includes exploitability information. It helps to know that the dominant vulnerability scanner vendor in the government space is Tenable. If you also use a Tenable product, you should be able to duplicate the list in BOD 22-1 exactly. But if you use Qualys and/or Rapid 7, your source data will be very close.

When you pull your scan data into Nucleus, we automatically assign an exploitability attribute based on your scan data.

Why Prioritize Exploitable Vulnerabilities?

Why use exploitable vulnerabilities as your selection criteria? When a vulnerability is not exploitable, that means there is no known code that attacks that particular vulnerability. While there may be unknown code that exploits it, theory says to first concentrate on things you know have known threats associated with them before you fix the things that have potential threats. It is, in essence, a crude and very inexpensive form of threat intelligence, and the government can reasonably assume that anyone reading this order has a vulnerability scanner that can find and flag exploitable vulnerabilities.

In essence, what BOD 22-01 does is create a lowest common denominator for prioritization.

There are other ways to prioritize, and if you are successfully remediating vulnerabilities using some other prioritization method, you will likely find that your method fixed a large number of the vulnerabilities in this subset. Remediating whatever vulnerabilities remain on this list that your prioritization method missed will probably not be difficult.

But not everyone is at that point in their journey. In the last eight years or so that I’ve been talking to customers of vulnerability management products and services, far and away the most common complaint I hear is that people don’t know where to start. There were 18,358 CVEs reported in 2020 alone. In essence, we now have a starting point – the government has decreed that fixing these 301 vulnerabilities are where you should start.

How to comply with BOD 22-01 using Nucleus

You can get a high-level idea of how you’re doing in a matter of seconds. Log into Nucleus, choose your relevant project from your dropdown, then click project dashboard. Near the top of the screen, take a look at the vulnerability overview. In the middle of that list, there is a section labeled Unique Exploitable. If that number is lower than 301, guess what? You’ve already started complying with this directive without even knowing it.

To dive deeper, click Vulnerabilities, then select Active. On the right-hand side, you’ll see a button labeled Filter. Click the button, then check the box labeled Exploit Available.

BOD 22-01 1

You now have a list of exploitable vulnerabilities in your network, regardless of source. If you only want network security vulnerabilities, click Filter again, and under Source, choose your network scanner, which will probably be Nessus (Tenable), Nexpose (Rapid7), or Qualys.

BOD 22-01 2

After making my selections in the example above, I have on 109 vulnerabilities in my demo instance. Your count will vary of course, but this shows how quickly you can translate a directive containing a static list into something actionable based on your live data.

At this point, you can click Export to generate a list of the vulnerabilities that are in scope for this directive, and save it for your records.

Setting Due Dates

Nucleus does not have rules to comply with the letter of the law here, so you can start with the existing functionality to come close. Click on Automation, then click Vulnerability Processing Rules. Click Add rule. We’ll be creating two rules.

Under Rule Name, enter a descriptive rule name that you will remember. I use BOD 22-01 14 days. Click the plus button under Vulnerability Criteria and select Vulnerability Discovered. Select greater than under the criteria, then enter the value 365. Click the plus button again and select Vulnerability Exploitable, and choose the option labeled is Exploitable.

BOD 22-01 3

Click Next. On the next screen, click Set due date, and choose a due date of 14 days from the discovered date.

BOD 22-01 4

Click Save & Finish.

To create the second rule, click Add Rule again. Under Rule Name, enter a descriptive rule name that you will remember. I use BOD 22-01 6 months. Click the plus button under vulnerability criteria and select Vulnerability Discovered. Select greater than under the criteria, then enter the value 365. Click the plus button again and select Vulnerability Exploitable, then choose is exploitable. Click Actions, then click Set due date, and choose a due date of 6 months from the discovered date. Click Save & Finish.

Now you have two rules that approximate the spirit of BOD 22-01, even if they don’t quite meet the letter of the law. These two rules will get you close, so you can be working on meeting the deadlines while Nucleus works to add the ability to create rules based on date of publication as a new platform feature.

If you have an integration with your ticketing system setup in Nucleus, you can use a similar process to create ticketing rules for vulnerabilities that meet these criteria.

Proving Compliance with BOD 22-01

Once all of your hard work is finished, how do you prove you are compliant? Within the Nucleus UI, navigate to Vulnerabilities > Active. On the right-hand side, you’ll see a button labeled Filter. Click the button, then check the box labeled Exploit Available. Now sort on the discovered date.

When you see 1) no dates in red, and 2) no dates older than the current year, you can be reasonably sure you’re meeting the standard, and are well-positioned to meet any future directive based on BOD 22-01.

To prove compliance, I recommend you create an option profile (Qualys), scan template (Rapid 7), or scan policy (Tenable) containing the relevant subset of the 301 CVEs, then scan your network using that policy, using authentication. Provide a copy of the empty scan results, along with a screenshot of the criteria within your scan policy to the agency requesting evidence. This allows you to prove compliance while also not disclosing any sensitive information.

Nucleus is already working on adding functionality specific to BOD 22-01. Stay tuned for future announcements. In the meantime, this directive gives rare insight into the way the United States government handles vulnerability management. Being able to institute something similar within Nucleus gives you an opportunity to measure your program against this directive, and adjust it if necessary.