You MUST comply with this voluntary cyber regulation!  (plus, Et tu, NIST?)

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 to identify controls they can implement to mitigate those risks, while feeling 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.