“We’ll Just Do the Right Thing”

At the recent NERC CIPC meeting in Atlanta, I had a good lunchtime conversation with a longtime CIP (and cyber security) professional whose opinions I respect greatly. We were discussing the fine points of some CIP v5 issue – I can’t remember which one – when he pointed out something to the effect of, “It’s not worthwhile arguing over the details. NERC entities want to do the right thing, and the Regional Entities know this. As long as I continue to do the right thing, I’m not going to run afoul of any CIP requirements.”

While this sounds wonderful on the surface, I definitely didn’t have a good feeling about it.  But – not being a lightning-fast thinker – I couldn’t say at the time what I found wrong.  Since that time, I’ve had more time to think about it. Here is my response:

What this person was describing was certainly the ideal regulatory situation: The regulator doesn’t try to prescribe a bunch of details about how the organization has to accomplish compliance; rather, the regulations leave it up to the organization to determine how it will do so. The regulator just needs to verify that compliance has been achieved, and not worry about details of how the organization achieved it.

Unfortunately, there are a couple problems with this. One is that it requires auditors that share this person’s attitude. Knowing something about his NERC region, I can see this might actually be the approach that region takes. But knowing some (probably most) of the other NERC regions, I’m sure that an entity who took that attitude and didn’t worry about details would get the book thrown at them.

But the bigger problem is: This just isn’t how NERC standards are written. Remember what NERC was founded to do: prevent cascading outages caused by preventable mistakes made by owners or operators of BES assets. That’s a great goal, but it won’t be achieved by a regulation regime like what my friend was describing; it will be achieved through detailed regulations and detailed enforcement of those regulations – that is, by exactly the sort of requirements that NERC puts out today.[i]

The real problem is that the NERC compliance regime doesn’t work well with cyber security. Cyber security isn’t implemented or enhanced through a small number of precise technical steps – as is the case with overall grid reliability. Rather, cyber security requires a broad spectrum of measures that are applied hundreds or even thousands of times every day, by a lot of different people in the organization. The chance that a single “miss” (e.g., a failure to renew a background check before exactly seven years have passed, or in a CIP v5 context, the failure to properly identify a BES Cyber System because you were confused over the methodology for BCS identification) will lead to an outage is infinitesimally small, but in theory that one miss has the same status for NERC as a failure to test a relay that results in half a state going dark[ii]. If an entity happens to have auditors who share my friend’s point of view, good for them – maybe a few misses like this one won’t be considered a big deal. For all the others, they’d better sweat the details, or face lots of PVs. That’s how it is in this cruel world.[iii]

Given that my friend’s point of view couldn’t be realized in the context of NERC CIP v5 as currently written, what kind of standard could realize it? And could it be a NERC standard?

Believe it or not, there is a NERC standard (in fact, it is a CIP standard) that is written in such a way that I think my friend would be happy if it were used as a template for the CIP cyber security standards; it’s CIP-014. That standard is written as a risk-based one. The entity just[iv] needs to:

1. Get an assessment – from a qualified source - of their vulnerabilities (in the case of CIP-014, this is vulnerability of a substation to physical attack); and
2. Mitigate or remove the vulnerabilities found in the report.

How did this standard make it into the NERC canon? FERC mandated it on an emergency basis; they didn’t have the luxury of waiting the two or three (at least) years that would normally be required for NERC to develop and approve a new security standard. If CIP-014 were a standard like the CIP-002 through CIP-011, there would have been endless debates over the height of fences, the amount of brush that needs to be cleared, etc. Instead, those details are left to the entity and the organization that assesses their physical security.

I really think this is how the CIP cyber security standards should be written. Unfortunately, I don’t see this happening anytime soon. In the meantime, NERC entities need to sweat the details. I see no other way.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte & Touche LLP.

---

[i] Various people have pointed out to me that the CIP standards shouldn’t be called “Reliability Standards”, but something like “Cyber Security Standards”. I agree on that point, but I always have to point out that Reliability is NERC’s middle name. These standards shouldn’t be under NERC’s purview in the first place; but they are.

[ii] Of course, there have been measures to mitigate this issue recently, such as FFT and now the RAI.   Of course, they provide only partial mitigation, and RAI in particular comes with some big costs of its own.

[iii] You may bring up the fact that NERC frequently touts the idea that they are moving toward “results-based standards”, and that CIP v5 is supposedly an example of that approach. I must admit I have no idea what this phrase means, when it comes to CIP. Does it mean the auditors will first look at your record of cyber incidents, and only issue a PV when there’s a cyber incident that results in loss of load? If so, there would have been exactly zero CIP violations so far, since there has never yet been a cyber incident in North America – that I have heard of – that resulted in loss of load. Does it mean the standards just prescribe general principles, like “appropriate firewall rules”? No, this doesn’t describe CIP v5 either. If you know what “results-based standard” means in the context of CIP v5, please let me know.

[iv] I’ll admit this is a simplified account of the standard, but not by a whole lot.