The Cybersecurity and Infrastructure Security Agency (CISA) has issued binding directive 22-01 titled Reducing the Significant Risk of Known Exploited Vulnerabilities. This directive applies to all software and hardware found on federal information systems managed on agency premises or hosted by third-parties on an agency’s behalf.
One of the most welcomed of the required actions set forth in the directive is that CISA will keep a catalog of vulnerabilities alongside timeframes in which they must be remediated. According to the plan, this catalog will list only the most important vulnerabilities that have proven to pose the biggest risks.
In the US, a binding operational directive is an instruction that federal, executive branch, departments and agencies have to follow. They also provide a strong indication of the kind of cybersecurity measures that CISA thinks are important, which other organizations may wish to follow. (It’s also easy to imagine that what’s required of federal agencies today may be required of the vast web of suppliers to federal agencies tomorrow.)
To that end, CISA strongly recommends that private businesses and state, local, tribal, and territorial (SLTT) governments review and monitor its catalog. CISA has done the hard work of identifying what should be patched first, and anyone who follows its guidance is likely to find their security and resilience posture improved.
It will come as no surprise that the continued cyberattacks against US entities are the reason for this directive: “The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy.”
Many of the attacks against US organizations rely on vulnerabilities that could have been patched months or even years ago, but haven’t been. For example, earlier this year CISA issued a joint advisory with the FBI and NSA urging US organizations to patch five old vulnerabilities from 2018 and 2019 that were regularly exploited by the Russian Foreign Intelligence Service.
The idea is that better patch management, supported by the prioritization provided by the CISA catalog, can prevent future attacks.
The required actions are pretty simple and straightforward—to read at least. Execution of the rules may prove to be more difficult. The rules are:
- Plan. Organizations have 60 days to come up with a vulnerability management plan.
- Execute. CISA is giving notice that the clock is running on vulnerabilities it cares about. The affected departments and agencies have six months to fix anything with a CVE issued before 2021, and two weeks to fix everything else.
- Report. Organizations have to report on the status of vulnerabilities through the Continuous Diagnostics and Mitigation (CDM) Federal Dashboard.
While 6 months may seem a long time for the CVE’s prior to 2021, that doesn’t mean they are less important than this year’s vulnerabilities. The grace period may reflect the difficulty that organizations have already had in fixing older bugs, or the fact that “everything prior to 2021” is just a much longer period of time than the ten months of 2021. After six months is up and all those vulnerabilities are fixed, presumably everyone will be on a much shorter lease, with just two weeks to fix anything CISA deems serious enough to put on its list.
In some cases the catalog already lists a vulnerability with a due date in the past, such as CVE-2019-11510. In August, 2019, scans performed by Bad Packets found a total of 14,528 Pulse Secure VPN endpoints vulnerable to CVE-2019-11510, four months after a patch became avaiable. Over 5,000 of those were in the US, including military, federal, state, and local government agencies—and this was after advisories have been issued by the NSA and the NCSC.
The notes column for this CVE references CISA’s ED 21-03 for further guidance and requirements. In that Emergency Directive you will find the due date of April 23rd of 2021. So, it was already required to be patched for organizations that are bound to follow emergency directives.
Because patch management has proven to be a challenge, having a catalog to fall back on when you are looking for prioritization rules can be very helpful. On the other hand, by telling organizations what needs to be done, inadvertently they may skip necessary patches, simply because they were not listed. Or worse, they were listed but the people responsible for patching didn’t find them.
Either way, if this is a first step in setting up a compliance program, where all the vulnerabilities that are used in the wild get patched within two weeks we will certainly welcome it. We have seen the impact of, for example, the disclosure rules set forth by Google’s Project Zero on the generally accepted rules for responsible disclosure, and would love to see this directive have a similar effect on the average patching speed.
Stay safe, everyone!