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[1], for example, outlining
specific steps agencies should take to improve email security.

What does directive BD 22-01 say?

Binding operational directive
22-01
[2] 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[3]. 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[4] 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.

References

  1. ^
    BD 18-01
    (cyber.dhs.gov)
  2. ^
    Binding operational directive 22-01
    (cyber.dhs.gov)
  3. ^
    CVE-2019-0211
    (nvd.nist.gov)
  4. ^
    Live
    patching by TuxCare
    (tuxcare.com)

Read more