You’re in for a big treat
today. This post actually contains two posts, but it’s available at the usual
low low price of Tom Alrich’s blog!
Bad things happen when government
agencies try to take the easy route, rather than the right one, to achieve
their goals. And if the agency is trying to get private organizations to do
something that they just know is the right thing for them to do, they’re
even more tempted than normally to take the easy route. After all, their goals
are righteous! How can anybody complain if they’re just doing everything they
can to achieve those goals?
Thus, it was with a shudder of
recognition that I read in the Washington Post last Friday a story about
a “background[i]
press briefing” conducted Tuesday evening by the White House. The briefing was titled “Improving Cybersecurity of U.S. Critical
Infrastructure”. What more worthy goal could there be than that? The article
included this quotation from the briefing:
These may be voluntary, but we hope
and expect that all responsible critical infrastructure owners and operators
will apply them. We can’t stress it enough that they owe that to the
Americans that they serve for these critical services to have more resilience.
The briefing also included this
sentence:
The President is essentially
saying, “We expect responsible owners and operators to meet these performance
goals. We will look to you to implement this.”
The
message is quite clear: “We’re talking about voluntary regulations for critical
infrastructure, but if you know what’s good for you, Mr./MS Critical
Infrastructure Operator, you’ll comply with these regulations.”
George
Orwell couldn’t have said it any better:
“War is
peace.”
“Slavery
is freedom.”
“Ignorance
is strength.”
“Voluntary
is compulsory.”
Et tu, NIST?
So, what are the mandatory “voluntary
performance
goals” that the “senior administration official”, who was probably Jen
Easterly, outlined in the “background briefing”, a verbatim transcript of which
was published the next day?[ii] On hearing that these goals
were a NIST product, I would normally have thought they’d be what NIST always
publishes: compliance frameworks (like SP 800-53 or the CSF) that don’t
prescribe any particular actions, but which require federal agencies to consider
the risks they face in particular areas and identify controls they can
implement to mitigate those risks. At the same time, the agency is free to allocate resources
among the risks in a way that will result in the maximum possible risk
reduction, given the available resources.
I like that approach, since IMO it’s
axiomatic that the best way to regulate cybersecurity is to require the organization
to take into account all the important cyber risks they face, then decide for
themselves how to allocate their limited human and financial resources (I have
yet to learn of any organization, outside possibly the 3-letter agencies, that
has unlimited funds available for cybersecurity, or anything else, for that
matter) so that the greatest possible amount of risk is mitigated, given the available
resources.
However, while the “performance
goals” that are listed are all individually good, they’re not presented as part
of a framework, like what I just described. Rather, they’re a set of
prescriptive requirements. While the organization does have some discretion in
how they implement each requirement, they don’t have any discretion in whether
or not they implement it – even if it makes no sense in their environment.
A good example of this is item 1.1
on page 3:
System-enforced policy that
prevents future logins (for some minimum time, or until re-enabled by a
privileged user) after 5 or fewer failed login attempts. This configuration
should be enabled when available on an asset.
In IT environments, this might
seem like a perfectly reasonable requirement. If someone can’t remember their
password and can’t login after five failed attempts, they should be
locked out. It may be inconvenient for them, but hopefully they’ll learn their
lesson after this experience.
However, OT networks for critical
infrastructure (which these goals are aimed at, of course) can’t afford to
teach a lesson to somebody who is suffering temporary memory loss due to a
stressful situation (like alarms going off left and right in a control center);
they need to maintain operations. Often, the most critical systems in a control
center don’t even have passwords (or it will be a shared password that all of
the operators know).
Another good example is item 3.2
on page 8:
All data in transit and at rest are
encrypted by an appropriately strong algorithm
- No critical data should be stored
in plain text.
- Utilization of transport layer
security (TLS) to protect data in transit when technically feasible.
- Prioritize for upgrade or
replacement of assets that do not support modern symmetric encryption (AES)
This would be a great requirement
for an IT network at a bank. But OT networks aren’t used to store data, other
than the data required to maintain the critical process that the organization is
responsible for (the uninterrupted flow of natural gas in a pipeline, the
continued operation of an automobile manufacturing line, etc.). If those data
are encrypted and the control room operators need to first remember complex
passwords in order to decrypt the data needed to control operations, it’s very possible
that an emergency will turn into a disaster.
From my experience with the power
industry, I know that, even in some of the most secure control centers, systems
are usually not encrypted, unless they’re not needed for real-time operations. While
there is a new NERC CIP standard that requires encryption of data transmitted
between control centers, there is no requirement for encrypting data at rest in
control centers (although the Federal Energy Regulatory Commission did try to
require exactly that in Order 822,
which led to NERC CIP version 6. They were later talked out of that idea).
It's unfortunate that NIST – which
I’ve always thought to be the most important advocate of the idea of taking a
controls framework approach to cybersecurity – now seems to be trying out the
cookie-cutter one-size-fits-all approach to cybersecurity regulation. My, how
the great have fallen.
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.
[i] The word “background” alone should have clued me in to the fact that something unusual was afoot in this briefing. The Director of CISA is announcing a major new program, yet she has to disguise herself as if she were leaking some deep, dark secrets. I wonder if she wore a false mustache?
[ii]
You may note that all of the items in quotes in this sentence are lies.
The sources you reference are a collection of government double-speak based on the written facts from CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) Common Baseline: Controls List page 2 which states quote "The CPGs are not: ... Compulsory" . That leads me to think -
ReplyDeletewhy should we care?