Getting Off the Treadmill

By all rights, I should have been quite happy when it became clear that there would be a CIP version 7. After all, I really enjoyed attending some of the Standards Drafting Team meetings when CIP versions 4 and 5 were being developed and engaging in spirited conversations (usually over beer) with team members about arcane points in the standards being drafted. I’m sure I’ll have just as good a time when I can attend the v7 meetings, which I imagine will begin within 3-6 months.

I should have been even happier when I saw that the v7 SDT will need to address some very interesting topics, such as virtualization, protection of data at rest and in motion, ERC and LERC, etc. This ensures a lot of good arguments at drafting team meetings – and even more beer. After all, arguments are what I live for. How could I not be happy?

I’ll say right now that I do hope to attend at least some of the drafting team meetings and contribute to the discussion if possible. But my participation will be tinged by two big considerations.

First Consideration: Can CIP v5/6/7 Ever Be Enforceable?

I’ve realized for a while that CIP v5/v6 can never be enforceable in the strict sense until CIP-002 is rewritten and some definitions are added or revised (programmable, ERC, etc)[i]. What I mean by “strict sense” is that, if an entity receives a fine for not properly identifying assets in scope and appeals it to the civil courts (which is their right, since NERC standards are regulatory law), I don’t think it will take a judge more than ten minutes to read CIP-002-5.1 R1 and Attachment 1 and rule they are unsuitable to be part of mandatory standards, since they’re filled with missing definitions, vague language and outright contradictions. And it’s hard to believe that the rest of CIP v5/6 will stand once CIP-002 R1 is thrown out, since all of the other standards depend on the entity’s properly identifying its assets in R1 in the first place.

So now NERC has referred R1 to the Standards Drafting Team to revise. Why aren’t I overjoyed that this has happened? After all, just a few months ago I was saying this was essential, if CIP v5 is ever to be strictly enforceable.  However, NERC’s instructions to the SDT (detailed in their January webinar) make clear that NERC is just asking the SDT to tinker around the edges of the CIP-002 R1/Attachment 1 problem, not address its roots. As discussed in this post, NERC is only requesting that the SDT address two definitions related to R1: the definitions of Cyber Asset and of BES Cyber Asset.

While both of these definitions need to be fixed, they aren’t the biggest problem in CIP-002 R1 (and Attachment 1). The biggest problem is that this requirement is written from two differing points of view, as discussed in this post. One point of view is that the entity first classifies assets as High, Medium or Low impact, then identifies BES Cyber Systems associated with those assets and gives them the same classification. The other point of view is that the entity first looks at all of its cyber assets, then from those identifies BES Cyber Assets and BCS; finally, the entity classifies those BCS using the Attachment 1 criteria. Since both points of view are represented in the wording of CIP-002-5.1, it is literally impossible to comply with all of the wording of CIP-002; you need to decide which side you’re on and assume that all the wording supports you, even though some of it doesn’t[ii]. You literally have to violate a lot of the wording of R1 in order to comply with it.

So assuming the SDT limits themselves to following NERC’s request regarding CIP-002, they won’t be fixing the fundamental problem with that standard and it still won’t be enforceable in the strict sense, even when it is re-released as CIP-002-7. This means that CIP v7 won’t ever be any more enforceable in the strict sense than v5 is now.

But this doesn’t mean the SDT members can’t go ahead and address the big problem anyway - I don’t think NERC can constrain what the SDT looks at, as long as it has to do with CIP-002-5.1 R1. So am I going to go to the drafting meetings and raise holy h___ until the SDT does address the most fundamental problem in CIP-002? No, I won’t. Trying to do that would involve some very serious discussions that will frankly take up a lot of time, and might occupy the SDT for six months or more. Three months ago, I would have said they need to do this no matter how long it takes, since v5 will never be strictly enforceable otherwise. However, I no longer think it’s worth the effort to do this; see the next section for why I think this is the case.

Even though the SDT won’t solve the fundamental problem in CIP-002-5.1 R1 in CIP v7, it will certainly help if they can develop clearer definitions of Cyber Asset and BES Cyber Asset; if the SDT can accomplish just those two things (along with addressing the other areas in NERC’s and FERC’s “mandates”), that will be quite an achievement. It will make CIP v5 more enforceable in the narrow sense of whether or not the regions will be able to assess violations. However, v5 and v6 will be no more enforceable in the strict sense than they are now.

Second Consideration: Is CIP v5/v6/v7 Sustainable?

This might seem like an odd question to ask. I’m certainly not asking whether NERC CIP is dolphin-safe or if it will deplete the ozone layer. Here’s what concerns me:

1. CIP v5 marked a big expansion in scope from versions 1-3, specifically because of the great increase in assets that were covered (primarily substations). Because of that and other reasons, I know there are some large entities that spent probably twenty times or more on compliance with v5 than they did with v3.
2. Now look at what will be added in v7: encryption of communications between control centers and protection of the devices that facilitate those communications, controls for data at rest in control centers, specific controls for virtualized devices (and an expansion in scope to cover them in the first place), transient devices at Low assets, supply chain controls, and probably more. I don’t know what the new multiple will be, but I’m sure there will again be entities for whom the v7 effort will be some integer multiple of their v5 effort (and most of us thought that the v5 effort would be a one-time thing, since it would put in place a framework that wouldn’t have to be changed much going forward. It was a nice idea, anyway).
3. Will v7 be the end? Hardly. There are many more areas of cyber security controls that should be addressed in CIP. For example, the Ukrainian attack started with a phishing email. In fact, a lot of the big attacks in all sectors in recent years have started that way. How does CIP address phishing? Just with a requirement for a security awareness campaign (and no specification for what that campaign will cover) at least every three months, and only every 15 months for Lows. Given the danger posed by phishing, I think phishing awareness should be enforced almost weekly; plus there are technical means of addressing phishing that should also be considered.  And each of you can probably think of another security area that should be addressed as well (software code security comes to mind for me). Needless to say, whenever CIP is expanded to include a new area, there will be a lot of new compliance costs.
4. There’s also the whole matter of the Distribution grid. A paper published by the California Public Utility Commission in 2012 stated[iii] that 80 to 90% of grid assets were entirely Distribution ones, and therefore completely out of scope for NERC CIP. So guess what kind of substations were attacked in the Ukraine? You got it – Distribution. Shouldn’t Distribution substations have some sort of cyber regulation? Of course, the problem here is that NERC and FERC have no jurisdiction over Distribution, although I did note that NERC’s Alert related to the Ukraine attack applies to Distribution substations as well. In any case, even if it requires an act of Congress – which it probably will – I believe there needs to be some cyber regulation of Distribution assets.[iv]

However, none of these are what I believe is the biggest problem with NERC CIP, namely: I have asked a small number of compliance people for NERC entities what percentage of every dollar they spent on CIP compliance actually went to cyber security and what percentage went to the paperwork required to prove compliance. Of course, there is no objective way to measure this, but the estimates I have received range from 35 percent to 70 percent. Maybe the average is 50 percent, but’s let’s assume my small sample is biased downward and the average is closer to 70 percent. Even this figure means that 30% of every dollar spent on CIP is only spent to prove compliance, not to improve cyber security. To phrase it differently, if we could figure out a way to get the percentage of spending that goes to security up to 90%, we would in principle have up to a 20% increase in security without having to spend a single additional dollar.

Remember, every time a new area is addressed in CIP, there is an expansion in the actions or technologies required for compliance. For example, for protection of communications between control centers, entities will have to buy encryption software, as well as spend a lot of money testing, installing and maintaining it. And of course, they will need to develop policies and procedures around encryption.

But beyond that, each expansion of CIP will bring a hefty new dose of required paperwork. To continue with this example, the entities will have to document that they purchased, tested, installed, and trained on the encryption software, and that all communications between control centers (whether owned by the same entity or different entities) are now encrypted. More than that, they will have to document every X number of months that all such communications are still being encrypted, as well as that any new devices that communicate externally also apply encryption. And there’s probably more paperwork I haven’t thought of in this two-minute exercise.

At a recent Deloitte client event, a respected utility cyber security manager was incredulous when I said that one of the big items on the SDT’s plate was virtualization. “Do you mean we’ll have to do a lot of documentation on all of our VMs and VLANs?” he asked.[v] I put on my pontification hat and explained to him – in soothing tones, of course – that entities were already applying CIP to their virtualized systems, but there is currently no way for them to be held accountable for anything since CIP v5 is completely silent on virtualization[vi]. His response was something like “Why can’t we just be trusted to do the right thing, rather than have to spend a huge amount of time documenting our compliance for virtualized systems?”

Before I could reply to this question, I checked myself. It seemed to me that his question was a very good one – and ironically, I already agreed with him. Why can’t there be some trust in the compliance process, rather than have to require the huge amount of compliance paperwork that CIP does? More importantly, as CIP expands to address each of these new areas – and the paperwork burden expands proportionately – where is the stopping point for all this? Do we just continue expanding the standards until expenditures for NERC CIP compliance take up something approaching the entire US GDP? Or is there a more sustainable way to protect the grid from cyber attack, but not at the same time drown utilities in compliance costs and paperwork?

Folks, the electric power industry is now on a treadmill of ever-expanding and ever-more-expensive cyber security regulations; we need to get off it onto a sustainable approach that will increase protection of the grid, but in a much more cost-effective manner than NERC CIP does now.  I am currently putting together my ideas on what would be a sustainable way to provide cyber security regulation of entities that own and operate electric grid assets. These ideas will most likely appear in a book (probably with a co-author) at a later date, although I intend to start bringing them out – and soliciting comments of course – in this blog very soon.

So far, the only “statement” of my ideas is the presentation I gave at Digital Bond’s S4 conference in Miami Beach in early January. The presentation was videotaped, but the videos haven’t been posted yet because of technical problems. If you would like to see my slides (which are quite entertaining, as was the presentation itself), email me at talrich@deloitte.com and I’ll send them to you.

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

---

[i] I do think CIP v5 will be enforceable in a looser sense by about one year after the compliance date. See this post for more details on that.

[ii] And as I’ve said in a post already referenced, virtually every NERC entity and regional auditor subscribes to the first point of view; in fact, most of them believe that this is what the words of CIP-002 say. In fact, it is what some of the words say, but it’s contradicted by a lot of the other words.

[iii] The document is no longer available on the CPUC web site, but if you want to email me at talrich@deloitte.com, I’ll send it to you.

[iv] Of course, the state PUCs have authority to approve rates for IOUs in their states, and this authority can be used as a back-door way to impose cyber regulation; a few states have already done this in a limited way. However, there are a couple big problems with this. First, the PUCs have no direct authority over coops, municipals, and other non-IOU utilities. Second, it will never work to have 48 sets of state cyber regulations for the grid (neither Alaska nor Hawaii is part of the US continental grid, of course), since so many entities cross state boundaries - in many cases lots of boundaries.

[v] I admit I can’t remember his exact words, so I’m paraphrasing.

[vi] And also because the definition of Cyber Asset, “Programmable electronic device”, doesn’t cover software, which is of course what a VM is. It’s definitely not a device.