Government agencies publish notices and directives all the time. Usually, these are only relevant to government departments, which means that nobody else really pays attention. It’s easy to see why you would assume that a directive from CISA just doesn’t relate to your organization.
But, in the instance of the latest CISA directive, that would be making a mistake. In this article, we explain why, even if you’re in the private or non-government sector, you should nonetheless take a close look at CISA Binding Operational Directive 22-01.
We outline why CISA was forced to issue this directive, and why that firm action has implications for all organizations – inside and outside of government. Acting on cybersecurity issues isn’t as simple as flicking a switch, of course, so keep reading to find out how you can address the core issue behind the CISA directive.
Okay, so what exactly is a CISA directive?
Let’s take a step back to gain some context. Just like any organization that uses technology, US government agencies – federal agencies – are constantly under cyberattack from malicious actors, from common criminals to enemy states.
As a result, the US Department of Homeland Security set up CISA, the Cybersecurity, and Infrastructure Security Agency, to help coordinate cybersecurity for federal agencies.
CISA says that it acts as the operational lead for federal cybersecurity, defending federal government networks. But each agency has its own operational and technology teams that are not under the direct control of CISA – and that’s where the CISA directives come in.
A CISA directive is intended to compel tech teams at federal agencies to take certain actions that CISA deems necessary to ensure safe cybersecurity operations. The directives generally deal with specific, high-risk vulnerabilities but some directives are more general, with BD 18-01, for example, outlining specific steps agencies should take to improve email security.
What does directive BD 22-01 say?
Binding operational directive 22-01 is one of the broader directives – in fact, it’s very broad, referring to over three hundred vulnerabilities. It’s a dramatic step for CISA to take – it’s not just another run-of-the-mill communications message.
With this directive, CISA presents a list of vulnerabilities that it thinks are the most commonly exploited within the larger field of tens of thousands of known vulnerabilities. Some of these vulnerabilities are quite old.
In this vulnerability catalog, each entry specifies a fixed date whereby federal agencies need to remediate the vulnerability. Within the directive itself are further detailed instructions and timelines – including establishing a process to regularly review the list attached to BD 22-01 – meaning this list will be expanded in the future.
Examples of vulnerabilities on the list
Let’s look at some examples of vulnerabilities on this list. CISA rounded up what are, in its view, the most serious, most exploited vulnerabilities – in other words, vulnerabilities that are most likely to lead to harm if not addressed.
The list covers a really wide scope, from infrastructure through to applications – including mobile apps – even covering some of the most trusted security solutions. It includes vendors such as Microsoft, SAP, and TrendMicro as well as popular open-source technology solutions including Linux and Apache.
One example of a vulnerability on the list relates to the Apache HTTP Server, where a range of release 2.4 versions is affected by a scoreboard vulnerability – CVE-2019-0211. It allows attackers to start an attack by running code in a less privileged process that manipulates the scoreboard, enabling the execution of arbitrary code with the permissions of the parent process.
Another example lies in Atlassian Confluence, the popular collaboration tool. Here, attackers can mount a remote code execution attack by injecting macro code into the Atlassian Widget Connector. Again, this vulnerability is listed by CISA because the organization deemed that it was commonly exploited.
Yes! This CISA directive applies to you too…
Okay, CISA’s directives can’t be enforced on technology teams outside of the US federal government, but that doesn’t mean there’s nothing to learn here.
To start, take a step back and think about CISA’s reasoning before you simply dismiss its latest directive. We know that cybersecurity attacks are commonplace and that the costs are enormous, whether you’re operating within a state or federal environment – or as a private enterprise.
CISA only published this list as a last resort. The agency became so exasperated with attackers frequently hitting government targets that it felt forced to issue a binding directive listing vulnerabilities that must be addressed. It did so simply because it is so common for known vulnerabilities to go unpatched.
These vulnerabilities are not unique to government services – any technology environment can be affected.
And here’s the rub: just like government technology environments, your technology estate may be full of vulnerabilities that need remediation. The CISA list would be an excellent place to start fixing things.
And to top it all off, these are not just -potentially- exploitable vulnerabilities.
If you read the directive attently, these are vulnerabilities -currently- being exploited in the wild, meaning that exploit code is either readily available for everyone or being distributed in the less savory corners of the Internet. Either way, these are not just a hypothetical threat anymore.
The hidden message of the CISA directive
It’s not that either you – or tech teams in government – are negligent, or ignorant. It’s just a matter of practical realities. And in practice, tech teams don’t get around to consistently remediating vulnerabilities. Big, obvious, known vulnerabilities such as those listed in the CISA directive can lie waiting for an attacker to exploit simply because tech teams never fixed it.
There are a variety of reasons why it happens, and neglect is rarely one of them. A lack of resources is arguably one of the biggest causes, as technology teams are simply too stretched to test, patch, and otherwise mitigate sufficiently.
There’s the disruption associated with patching too: urgent patches can quickly turn less pressing in the face of stakeholder pushback. So what the CISA directive is really saying is that practical realities mean that there’s an ocean of vulnerabilities that are simply not getting addressed and which are leading to successful exploits.
And, in response, CISA produced what you could call an emergency list simply because of the level of desperation with cybercrime. In other words, the situation is untenable – and the CISA directive is an emergency band-aid, a way to try and cauterize the damage.
Curb disruption and you also boost security
Starting to address the most critical, most exploited vulnerabilities is the obvious answer, and that’s what the CISA list is intended to accomplish. Close behind is throwing more resources at the problem – devoting more time to fixing vulnerabilities is a worthy step.
But these obvious steps quickly run into a wall: fixing and patching causes disruption, and finding a way forward is challenging. And without finding a way past these disruptive effects, the situation may continue to get so bad that we need steps like the CISA directive. Remodeling security operations is the answer.
What can tech teams do? It requires wholesale re-engineering in a way that minimizes patching-related disruption. Redundancy and high availability, for example, can help mitigate some of the worst disruptive effects of vulnerability management.
Utilizing the most advanced security technology also helps. Vulnerability scanners can highlight the most pressing issues to help with prioritization. Live patching by TuxCare is another great tool – because live patching completely removes the need to reboot, which means patching disruption can be essentially eliminated.
And that’s what the CISA directive really means…
Whether you’re in government or the private sector, a rethink is needed because vulnerabilities are piling up so rapidly. The CISA directive underlines how bad things have become. But simply applying more band-aid won’t work – you’ll remediate, and be back in the same situation you were in no time.
So, take the CISA directive as a warning sign. Yes, check whether you’re using any of the software and services on the list and patch accordingly. But, most importantly, think about how you can improve your SecOps – ensuring that you’re more responsive to vulnerabilities by remediating with less disruption. Patch faster with less disruption.
