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.

No, None of the Other Dates will Change

It seems like every other post I write nowadays starts with something I read in the weekly EnergySec newsletter. Today’s post was prompted by speculation in this week’s newsletter that, due to yesterday's FERC action pushing back the CIP v5 compliance date by three months, some other CIP compliance dates for the v5 or the v6 standards might be pushed back, thus leading to even more confusion than currently reigns (if indeed such a thing is possible!).

On reading this, I immediately noted that there is no way the v6 implementation dates will be affected by this move, since those dates don’t depend at all on v5, and FERC only moved the main v5 date. As for the v5 dates themselves, there were only two anyway (vs. about 12 compliance events in v6, which are clustered among three dates): April 1 (now July 1), 2016 for High and Medium requirements, and April 1, 2017 for the one Low impact requirement in v5, CIP-003-5 R2.

These two dates were set independently of each other in the v5 Implementation Plan, so the fact that the High/Medium date is moved back three months doesn’t mean anything for the Low date. In fact, the Low date for v5 is meaningless, since CIP-003-5 R2 will be superseded by CIP-003-6 R2 – which comes into effect the same date, April 1, 2017.

To reflect this new change, I have changed the post I did in December with a revised compliance schedule. That post was prompted by the fact that FERC hadn’t approved v6 in December, meaning the v6 date was moved back to July 1. Of course, it was because that date is now July 1 that FERC yesterday agreed to move the v5 date to coincide with it. I’m tempted to say this will be the last change in the v5/v6 compliance dates, but I would have said the same thing in December.

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

FERC Approves Moving the CIP V5 Compliance Date!

Today, FERC approved moving the compliance date for NERC CIP version 5 back by three months, from April 1 to July 1. This allows both v5 and v6 (aka “CIP v5 Revisions”) to take effect on the same day.

For those of you who haven’t been keeping score at home:

1. On Feb. 4, I reported that NERC was being lobbied by the trade associations to move the CIP v5 compliance date back. I assumed NERC would want to see this happen, and suggested they could make this happen either by going the “full Monty” route of petitioning FERC, or by the more subtle (but perhaps less effective) route of issuing auditing guidance that would effectively move the date back. I assumed the only question was which route NERC would choose. I also pointed out, as I have before, that I didn’t think CIP v5 would effectively be enforceable until 6-12 months after April 1 (and more likely 12 months).
2. The next day, I reported that the Trades had gone ahead and petitioned FERC on their own. I must have written that post very quickly, since I didn’t really consider the implications of this action (i.e. going ahead without NERC), and I didn’t question the reasoning that was provided to FERC. I did bet that FERC would approve the petition (although I didn’t put any money on it! I’ve looked all over the Internet for a FERC betting site, but I have yet to find one. My guess is this is because betting on what FERC will do is no better than betting on the next random number to come up).
3. On Feb. 6, I actually thought about what the Trades’ petition meant. First, I was surprised that they had petitioned FERC without NERC being on their side; I speculated this was because NERC wasn’t in agreement with them. Then I went on to look more closely at the Trades’ stated reason for petitioning FERC: that NERC entities would have to spend a lot of money and time putting in place a v5 compliance program, only to have to do the same thing for v6 three months later. I pointed out why this argument didn’t have much merit. I then stated the main reason why I thought the date should be pushed back (and why I’ve been saying that for more than a year, although I’ve been advocating the date be pushed back at least a year, not just three months): there has been so much confusion over the meaning of the v5 requirements, and NERC has pursued so many different aborted strategies to fix that confusion, that many entities never felt comfortable starting their v5 compliance programs until last year.
4. My most recent post on this topic was on Monday, Feb. 8, when I pointed out that NERC had – seemingly inexplicably – filed comments disputing what the Trades had asserted. I wasn’t surprised to see NERC had fairly easily refuted the trades’ argument.[i] But I reiterated that I thought the date should be moved back, and I added two new arguments: 1) the rush to comply on 4/1 was taking a huge toll on some organizations, for no particularly good reason (since CIP v5 won’t be effectively enforceable for 6-12 months from 4/1, regardless of whether the date is moved or not); and 2) if the v4 date stands, many entities would have to devote a huge amount of time to self-reporting non-compliance for the next three months, and not as much to actually becoming compliant.

So what happens next? Will entities use the extra three months wisely and become compliant on July 1? I think they will use the time wisely, but I’m fairly sure the majority of entities will still be a good way from fully compliant on July 1. They just won’t be as non-compliant as they would have been on April 1. But I’m not going to make the argument now that FERC should push the date back another six months, even though I believe that’s what they should do. Ya gotta know when to fold ‘em.

There’s one more issue: I know some of the NERC regions were also against moving the compliance date back, because it plays havoc with their audit schedules. They really can’t do CIP audits from April through June of this year, so what becomes of those audits? Audits are scheduled at least a couple years out, meaning it will be very hard to squeeze these back into the schedule before say 2018 or 2019.

While I have sympathy for the auditors, I do feel their inconvenience doesn’t outweigh the greater “inconvenience” the entities would feel if the date weren’t moved back.

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

---

[i] The Trades did file counter-arguments to NERC’s, but they weren’t terribly more impressive than the arguments from their first filing, which NERC refuted.

Ted Koppel’s Book

Let me state now that I’m not in the business of reviewing books. However, I recently read Ted Koppel’s book, Lights Out, and I wish to make a couple points about it.

First, this is a very important book. Regardless of what you think of it (and you really shouldn’t have an opinion on it before you’ve read it, should you?), I recommend you read it since I’m sure it’s going to have a lot of influence on public opinion, and especially on Congress. I do want to point out that suspicion of electric utilities is one of the few areas where Republicans and Democrats in Congress are in agreement.

Second, this book isn’t primarily about cyber security, despite what the book jacket says. It’s about what could happen if there were an extended power outage (i.e. more than a few days) that covered an extended region (say 5-10 states, especially if one or two major cities were included). What would happen? Chaos and death, that’s what. This is close to indisputable.

However, Koppel isn’t saying that a cyber attack is most likely to cause this type of outage. He discusses other events like EMP and solar storms that could be more devastating. The book’s main purpose is to document how there seems to have been just about zero planning on the national level (and little on the state or local level) for an outage of this magnitude and duration, no matter what the cause. And it issues a call to action to start that planning.

Of course, doing something like storing MREs for the entire city of New York will be very expensive; Koppel admits that. The point is that this type of outage (again, whatever the cause) would be devastating enough that there needs to be some preparation, no matter how small the probability that this could happen. Of course, the question of large transformers weighs heavily in both the problem and the solution (although Koppel doesn’t attempt to outline a solution, just give broad hints on what it might entail).

What does he say about NERC CIP? Very little (he doesn’t mention it by name), and what he says isn’t very accurate. Yet it doesn’t really matter for his argument. Even if CIP were the best-written, most-effective set of standards in history, the possibility of a serious cyber attack would never be reduced to zero. And even if the chance of a cyber attack were zero, there could always be a huge solar storm (in fact, we just narrowly missed one in 2012. And the 1859 Carrington Event would have been absolutely devastating had it hit in modern times).

However, even though a cyber attack isn’t really the focus of this book, it will almost certainly be perceived that way. My guess is many people in Congress will take the book as confirmation that the electric power industry just can’t be trusted writing its own cyber regulations. And this is why you need to read the book – to be prepared. 

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

CIP Version 7

In case you haven’t noticed, a new version of NERC CIP has just entered the gestation process. While it is certainly too early to head to the maternity ward, it isn’t too early to start thinking about a color for the baby’s room. Two new documents led to this happy event: NERC’s January webinar on “CIP Version 5 Revisions” and FERC’s Order 822. Each of these identified a number of items to be addressed by the Standards Drafting Team in v7. From the looks of it, they will have a lot to do! I will discuss both of these documents and what they have contributed to the SDT’s “inbox”.

First a few general points:

1. Rather than constitute a new drafting team, NERC plans to utilize the existing “CIP v5 Revisions” SDT[i]. These were the folks that developed CIP v6. I am fine with that, since this is a very competent team. However, I certainly hope that, with CIP v7, NERC won’t make the same mistake as with v6 and pretend this isn’t a new version. That has led to a lot of confusion, since entities now have to comply with three v5 and seven v6 standards, rather than ten v6 ones. If NERC does the same thing with v7, entities may conceivably be complying with three different versions at once. My advice: “rev” all of the CIP standards to v7, whether or not they need to be changed for any other reason.[ii]
2. I have to admit it isn’t 100% certain that there will only be one new CIP version, not two. The changes that NERC requested will not need a new Standards Authorization Request (SAR), since they fit into the current SDT’s “mandate” to address issues that come up in the CIP v5 implementation process. However, I believe the changes that FERC required in Order 822 will require a new SAR, since they obviously were a new mandate. I certainly hope these two efforts can be combined.
3. In Order 822, FERC didn’t mandate a new supply chain security standard, since they were waiting for the recent Technical Conference on that subject - and even though the conference happened a few weeks ago, I doubt an Order for that new standard will appear anytime soon. When and if FERC does order a supply chain standard, I would think its drafting would get added to the existing SDT’s plate, rather than handed to a new SDT. If this is a new standard (probably CIP-012), it will likely be considered part of v7, but it might not become enforceable with the rest of v7, since the SDT would have started work on it after the other v7 standards.

NERC’s Webinar

In the webinar, NERC listed a number of issues that need to be addressed by the SDT, including:

1. The definition of Cyber Asset (slide 8), and especially the word “programmable”. Note that this effort might be more than just a definition of the word “programmable”. The SDT may decide they like a different definition – without the “p”-word – altogether.

2. The definition of BES Cyber Asset. NERC listed (slide 8) three items that need clarification:

• “Focusing the definition so that it does not subsume all other cyber asset types” I honestly don’t know what they mean by this, so I won’t speculate.

• “Considering if there is a lower bound to the term ‘adverse’ in ‘adverse impact’” I assume this means they’re concerned that – as the definition now stands – anything that has the slightest impact on the BES could be considered a BCA. Correcting this is quite laudable, but how will it be done in practice? Will there be some sort of electrical criteria? And how will these be determined, if not by putting together a treatise that would be hundreds of pages long and comprehensible only to someone with an EE degree or two? I agree this is a problem, but I really don’t think it’s soluble. It may just be something the SDT needs to decide to live with; it certainly won’t be the only issue for which they’ll probably have to make that decision.

• “Clarify the double impact criteria (cyber asset affects a facility and that facility affects the reliable operation of the BES) such that ‘N-1 contingency’ is not a valid methodology that can eliminate an entire site and all of its Cyber Assets from scope” Of course, N-1 was a big problem with the RBAM in CIP v3, since invoking that contingency was a pretty sure-fire way to remove an asset from consideration as a Critical Asset. I hadn’t heard that entities were doing the same thing in the case of the BCA definition in v5, but if so this is a good example of the disconnect between how CIP-002-5.1 R1 reads and how it is actually being followed by most if not all entities.[iii] While there would be a way to address this issue, I think it would require a more fundamental rewriting of R1 than NERC is currently contemplating.

• Unfortunately, even if acceptable wording is found for all three of these items, it still won’t fix the BCA definition. The main problem with that definition is that, in my opinion, its wording doesn’t correspond at all with how NERC entities understand the BCA identification process to work; this means there is literally no way to properly identify BCA, except to literally disregard the current definition.   While I believe the SDT could still decide to open up the whole BCA definition and start from scratch, I doubt they will have the appetite or time to do that.

3. There are a number of issues (slides 9 and 10) regarding ESPs, ERC and Interactive Remote Access (IRA). The most important of these, in my opinion, are:

• The question of “demarcation”, when an entity owns one or more cyber assets located between two assets and at least one of those assets doesn’t have an ESP. This issue was addressed quite well in this Lesson Learned.

• “Review of the applicability of ERC including the concept of the term ‘directly’ used in the phrase ‘cannot be directly accessed through External Routable Connectivity’ within the Applicability section.” While I understand NERC’s concern about fixing the ERC definition, I suggest they’re trying to square the circle. I have written about ten posts on ERC, and I finally came to the conclusion that the concept is a black hole – there is no way to develop a dictionary-style definition of ERC that will apply to all the different situations found in substations. The only possible course is to develop a number of use cases (as was done in the Guidance section of CIP-003-6), indicating whether each has or doesn’t have ERC; I suggest the SDT just concentrate on doing that, and forget trying to find the perfect definition.

•  “Clarify the IRA definition to address the placement of the phrase ‘using a routable protocol’ in the definition” I agree with NERC here that the phrase in question is confusing, and should be clarified.

4. On slide 11, there are two items related to TO Control Centers that “perform the functional obligations of a TOP”. This is a big issue for a number of NERC entities, but I won’t rehash it here; the people it affects understand it much better than I do!

5. Slide 12 says “CIP V5 standards do not specifically address virtualization”. This is perhaps the most important of NERC’s “mandates” to the SDT. The basic problem isn’t that nobody knows how to address virtualized systems within CIP v5; people do know that. The problem is that the current wording doesn’t allow for virtualization. For example, it seems obvious that a virtual machine is a Cyber Asset and should be considered a possible BES Cyber Asset. Yet the definition of Cyber Asset is “Programmable electronic device…” (emphasis mine). A VM isn’t a device; it’s software. This means the definition of Cyber Asset needs to be revised (or perhaps there needs to be a new type of asset called “Virtual Cyber Asset”). There will need to be other changes like this as well.

FERC’s Mandates to the SDT

FERC’s Order 822, issued January 21, mandated that NERC address the following items in the next CIP version. Since I have dealt with each of these in some detail in this post, I won’t discuss them further here.

1. Transient electronic devices and removable media used at Low impact assets;

2. Data communicated between Control Centers;

3. Communications devices located between Control Centers;

4. “Data at rest” in Control Centers; and

5. The definition of Low impact External Routable Connectivity (LERC).

Conclusion (with Despairing Remarks)

As you can see from the above, the SDT will have a lot on its table for CIP v7. I don’t believe they’re forbidden to address other issues as well, but given their current workload I doubt they’ll be searching diligently for more requirements and definitions to rewrite.

And this is the problem. The fundamental issue with CIP v5 (and this applies to v6 as well) is that the asset identification process in CIP-002-5.1 R1 (and Attachment 1) is so fundamentally flawed that an entity can never be certain it has properly identified and classified its BES Cyber Systems. Unless the SDT has an appetite for a lot of philosophical arguments, and perhaps an additional year available to draft v7, I sincerely doubt they will want to take this problem on, especially because there is no clamor for it.

I don’t see this problem becoming huge for a while, because – as I discussed in this post – both the entities and the regions have a good idea of what needs to be done to comply with R1 (see this post for a discussion of how they’re doing that). However, the problem is that this idea doesn’t correspond with the actual wording of CIP-002, meaning that literally the only way to comply with the requirement is to ignore big parts of its wording.

However, at some point in the future, an entity will get a fine for CIP v5 or v6 violations that they think is unfair; they will then appeal it to the civil courts, since NERC standards are regulatory law and can be challenged in court. When that happens, I don’t think a judge will need to take ten minutes to read CIP-002, before he or she exclaims “What is this (stuff)?” and throws CIP-002 out the window. And at that point, I believe CIP-003 through CIP-011 will also suffer defenestration, as all those requirements depend on being able to properly identify BCS. This means there will literally be nothing left of CIP v5 and v6 (and probably of v7 as well), and the time and money spent on developing and complying with those standards will literally be for naught. What do we do then? Go back to CIP v3?...Drop CIP altogether and hope Congress doesn’t notice?... Move to rewarding careers in fast food?...The possibilities are endless.

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

---

[i] It seems there are now some openings on the SDT. If you are part of a NERC asset owner and would like to become a voting member of the SDT, contact NERC. Of course, literally anybody can observe and make comments at the drafting meetings – both face-to-face and phone meetings. You only have to be a user of electricity – and if you’re reading this post, my guess is you pass that test.

[ii] When FERC approved CIP v2 in the fall of 2009, they also asked for one change – a requirement for escorted physical access – in CIP-006. Even though that was the only standard that changed, the SDT changed all of the other standards so they were also v3. This is why the industry complied with eight v3 standards, rather than seven v2 and one v3. If it was the right thing to do then, it’s certainly the right thing to do now!

[iii] Since explaining why I think this would require a longer discussion than I have time or space for now, I will just point the interested reader to this post, which outlines a procedure that I believe properly describes how most entities think about the meaning of “adverse impact”. I believe this is the right approach, but it doesn’t correspond with the wording of R1 or the BCA definition.

NERC Replies to the Trades

This constitutes the fourth episode in the gripping saga of moving the CIP version 5 compliance date. The first episode is here. In the second episode, the electric power trade organizations filed a petition with FERC to push the v5 compliance date back to July 1, thus matching the v6 date. However, in my last post (the third one), I pointed out that I thought the trades had used the wrong argument for why this should happen.

The trades argued that not pushing the v5 date back would require they undertake a lot of needless paperwork and training. I think they should have instead emphasized that the great uncertainty about the meaning of some fundamental parts of CIP v5 – and NERC’s constantly-changing plans for dealing with this (which have culminated in NERC’s announcing recently that this uncertainty won’t be addressed until the next version of CIP, at least 3-4 years from now) – caused many entities to delay full implementation of their v5 programs, as they waited for what they thought would be more guidance from NERC.[i]

As I feared, the trades’ argument was fairly easily knocked down by NERC, who filed comments today on the trades’ petition. They simply stated that they’ve already announced they won’t audit on the “Identify, Assess and Correct” language in v5 if v6 is delayed. Since the only parts of v6 that will be affected by this delay are the parts that remove this language, NERC is effectively implementing those parts on April 1 anyway. If this is the only reason why the v5 date should be moved back, NERC has neutralized it.

Nevertheless, I feel the CIP v5 date should be moved back three months. There are many entities that are really scrambling to come into compliance on April 1, and a large number of them may not make it.[ii] Come April 1, they will have to divert a lot of their attention from the effort to become compliant to instead self-reporting their areas of non-compliance. This will do nobody any good, this will cause them to require even more time to become compliant. This self-reporting will be fairly meaningless, since nobody expects any PVs to be issued for many months after April 1 - and since I believe a lot of these entities will be able to come into close-to-full compliance by July 1.

I have also heard a number of stories about compliance and IT staffs pushing themselves to the breaking point in this effort – working weekends and weeknights, putting off vacations, etc. Their employers will bear the scars of this for years, since a lot of these people will undoubtedly seek other employment – and there are a lot of jobs to be had in the NERC CIP compliance and general cyber security fields nowadays[iii]!

If this effort were for some noble cause like a war effort, this might be justifiable. But – as I’ve said multiple times, most recently here – I don’t think CIP v5 will be enforceable in any real sense for six months to a year after April 1; delaying the compliance date until July won’t change that. So I don’t believe the grid will be any less secure if the date is pushed back. If anything, it will be more secure since as I said above, the entities won’t have to be diverted into an orgy of self-reporting after April 1 (and the auditors won’t have to drop what they’re doing to read all of these self-reports!).

As I also said in the last post, none of this excuses NERC entities from not being compliant April 1. That was clearly their responsibility, and they in theory could still make that date, given huge expenditures of money, time and psychological well-being of staff members. But is it really worth the country’s (and the ratepayers’) while for them to make these expenditures, when it will yield little if any increase in cyber security?

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

---

[i] My last post also mentions that some entities weren’t able to get budget for CIP v5 work until 2015, due to the fact that FERC approved v5 late in 2013, after many 2014 budgets were already set.

[ii] I’m not talking about being fully compliant, either. Given the many ambiguities and contradictions in CIP v5 – especially in the most fundamental part, identifying what is in scope in the first place – I don’t think any entity will be “fully compliant”. It is possible to be close-to-fully compliant, though. I suspect that many entities will be quite far from even that mark.

[iii] And for anyone who is looking, I hope you’ll seriously consider Deloitte! We have over 2,000 cyber security consultants in the US alone, and we are always scrambling to find more – good ones, of course.

The Real Reason Why the V5 Compliance Date Needs to be Postponed

Note: This post builds on the two previous posts, starting with this one. 

In my last two posts, I have been assuming that NERC would support the trade associations' of pushing back the CIP v5 compliance date three months, to match that of CIP v6 – July 1. However, I have now heard that they may be opposed to the idea. In fact, I’m willing to speculate that this may be why the trade associations decided to petition FERC two days ago – because they weren’t getting anywhere with NERC itself.

In their petition, the trades made the argument that the burden of having to comply with CIP version 5[i] for just three months, then switch to v6, would be large and would constitute a significant waste of resources and diversion of attention (rather than have one version switchover, they would have to conduct two switchovers within three months. This includes having two sets of processes, two sets of documentation, two sets of training programs, etc).

However, if you look at what exactly is involved here, this argument isn’t too compelling. While there are some significant additions to the requirements in CIP v6, these won’t come into effect until 2017 through 2019. The only change that will take place on July 1 is removal of the “Identify, Assess and Correct” language from 17 v5 requirements (with some rewriting of the requirements themselves to reflect this fact). All NERC entities have known this language would be removed for two years, and I believe all of the NERC regions (and NERC itself) said last year that, if v6 doesn’t come into effect on April 1, they will still audit the v5 standards with the assumption that entities are not required to comply with the IAC language. In other words, no entity should have to make any substantial switchover at all come July 1, since the seven v6 standards will effectively have been in place since April 1 – not their v5 counterparts.

However, there is an excellent reason for moving the CIP v5 compliance date back by three months; that is because there has been so much uncertainty about the meaning of the v5 requirements and definitions, and especially about the most fundamental requirements and definitions – those that tell you what cyber assets are in scope for CIP v5. This includes (but is certainly not limited to!) a) the word “Programmable” in the Cyber Asset definition; b) the words “adverse impact on the BES” in the BES Cyber Asset definition; c) the definition of External Routable Connectivity; and d) the many questions about how virtualized devices are to be handled, given that CIP v5 is silent on this issue and that the definition of Cyber Asset seems to exclude any virtual devices. All of these issues have been the subject of extensive debate and various assurances by NERC that they would be addressed. Here is a short, and certainly incomplete, synopsis of those discussions, as told in my posts:

1. In March 2014, I wrote a post summarizing what NERC was saying about fixing interpretation problems in CIP v5. They pointed to two sets of documents that would be coming out: the RSAWs and the results of the CIP v5 Implementation Study. I won’t go into details here, but neither of these ended up providing any sort of real guidance.
2. In this post from September 2014, I was quite excited that NERC was starting to put out guidance in the form of Lessons Learned documents, although I was skeptical they could address the many interpretation problems in v5 in time for entities to become fully compliant on April 1, 2016. At the time, I thought all substantial issues would have to be addressed by NERC before April 1, 2015. Otherwise, entities would never be ready for compliance on April 1, 2016, and the compliance date would need to be pushed back.
3. In December 2014, I wrote my first post calling for the compliance date to be moved back 6 to 12 months. My reasons? For one, some big entities weren’t going to receive their first dollar of CIP v5 compliance funding until 2015, since FERC hadn’t approved v5 until November 2013, after their 2014 budgets were set in stone.[ii] But the biggest reason was that many entities expected NERC to clarify most of the big interpretation issues (especially those having to do with scope), and they were waiting for this clarification before fully moving forward with their CIP v5 programs. I compared this to the two main characters in Samuel Beckett’s classic play “Waiting for Godot”. Those two gentlemen spend the whole play waiting for Godot to show up, despite the fact that they both know he never will.
4. In February 2015 I wrote about WECC’s CIP User Group meeting in January. I pointed out that Tobias Whitney of NERC had said there would be 15 Lessons Learned developed by April 1, 2015. Unfortunately, this was quite optimistic. In fact, as of today I believe there are only four finalized Lessons Learned. There have been a number of Lessons Learned (including one on “Programmable” that I thought was very good) that have been unceremoniously withdrawn.
5. In late April, NERC introduced five “Memoranda” that purported to provide “mandatory” guidance on various issues. Some of that guidance was actually good, in my opinion, but the idea that NERC staff could provide mandatory guidance, when there is no provision for that in the Rules of Procedure, was received very badly in the NERC community. NERC withdrew all of the Memoranda in early July, and since then has issued some Lessons Learned that, while quite good, only discuss different compliance approaches – they don’t choose which is the best among them.
6. At the December 2015 CIPC meeting, and again in a webinar in January, Tobias Whitney admitted that some important issues – including the four mentioned above – were being turned over to the standards drafting process. This is certainly the right way to address these issues; it would also be nice if this process had been started two years ago (as I was advocating at the time. I was given a flat "no" by Steve Noess of NERC when I asked this question at the Dec. 2013 CIPC meeting). It will take a bare minimum of 3-4 years for these changes to be developed and balloted (multiple times), approved by NERC and FERC, and come into effect (the SDT started developing CIP v5 in early 2011. It's now coming into effect mid 2016, 5 1/2 years later). What happens until then? It is up to the entities to determine how to deal with the various ambiguities, a process I call “roll your own”. I have discussed it in a number of posts, starting with this one.

As you can see, the entities have been whipsawed back and forth on these issues. Of course, none of this is to say that they aren’t ultimately responsible for their state of compliance, which they are. But I truly believe that a three-month reprieve in v5 compliance would be a godsend for many NERC entities, since as it stands now, after April 1 many of them might have to spend as much time writing self-reports as they do strengthening their CIP v5 compliance posture. It may be justice that they not get a reprieve, but I suggest that “tempering justice with mercy”[iii] is the appropriate course.

PS: I have heard that pushing the compliance date back may play havoc with the regional audit schedules, since audits scheduled for April through June will have to be somehow fit in at a later date (and the schedules are made up years in advance). I understand this problem, and hope it can be addressed in some way.

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

---

[i] Specifically, standards CIP-003-5, CIP-004-5, CIP-006-5, CIP-007-5, CIP-009-5, CIP-010-1 and CIP-011-1. If CIP v6 had come into effect on April 1, these would have been superseded by their v6 counterparts and therefore been stillborn. As it stands now, they will live on for three months in a kind of limbo state – the living dead, you might say.

[ii] Of course, I’m sure there were many entities whose CFO’s were able to look beyond the fact that CIP v5 hadn’t been officially approved and still put v5 money in the 2014 budget, given that there was little doubt v5 would be approved. However, there were also some entities that weren’t so fortunate.

[iii] While I don’t think he invented it, this phrase was used by the famous Chicago lawyer Clarence Darrow in his plea for mercy at the trial of Leopold and Loeb – who were on trial for a crime much more serious than violating NERC CIP!

The Trades Step In

Yesterday, I pointed out that NERC was being “lobbied” by “some organizations” to have the CIP v5 compliance date pushed back to July 1. I can now reveal who those organizations are; they are the electric power industry trade associations, and yesterday they filed a motion[i] with FERC to move the date back to July 1.

They pointed out in their filing that “the Commission acknowledged in Order No. 822 industry’s concern with respect to implementing two versions of certain CIP Reliability Standards within a short period of time and stated that it “is willing to consider a request to align the implementation dates of certain CIP Reliability Standards ….”

I had forgotten about this statement in Order 822, but I would say it’s a fairly good sign that FERC will approve this request. However, betting on what FERC will do is a wonderful way to lose money.

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

---

[i] I am grateful to an Interested Party who brought this motion to my attention. I want to point out that anyone can subscribe to receive FERC documents on a particular docket. The docket for CIP v6 is RM15-14.

Will April 1 be Postponed?

The above title is my homage to the great catcher Yogi Berra, who is known for his short quotations that don’t literally make sense but usually express a more profound meaning – such as “The future ain’t what it used to be.” In the same spirit, I realize the title doesn’t make sense; I can assure you that April 1 won’t be postponed! But will the CIP v5 compliance date, currently set for April 1, be postponed?

I’ve just heard that NERC is being lobbied by some organizations to move the v5 compliance date back to July 1. The ostensive reason for doing this is that it would avoid a funny three-month period during which the 17 CIP v5 requirements with the “Identify, Assess and Correct” language would be in force, even though that language will go away once v6 comes into effect. This is due to the fact that the seven CIP v6 standards won’t come into effect until July 1, rather than April 1 as originally planned.

Of course, the reason v6 implementation is delayed is because FERC didn’t approve CIP v6 in December; but that may have been inevitable. After FERC issued their NOPR last July, which said they intended to approve v6 but asked for comment on other questions, I wrote a post pointing out that they hadn’t left themselves much time to make a decision on these other questions, since the v6 compliance date would automatically move back if they didn’t approve those standards at the end of 2015 (comments were due in late September and were clearly going to be voluminous. Late December was really the earliest that FERC could have issued their Order, and even that would have been lightning-fast in FERC terms. It turns out they approved v6 on January 21).

I further speculated in the post that this might have been FERC’s intention – that is, to delay the v6 implementation schedule. You may ask why FERC would want to do that. I also speculated that they, like a lot of others, may have been concerned that the April 1 date for v5 implementation was too ambitious, due to the huge uncertainty over the meaning of some of the most important requirements and concepts in v5. Since just delaying the “Identify, Assess and Correct” language wouldn’t have made any difference for anybody’s actions (because no region or entity I know of believed that would be enforced anyway, even if v6 had never come into effect), FERC’s real intention may have been to get v5 moved back as well as v6.[i] And now it seems this may happen.

Of course, I’ve said for a while (most recently in this post) that I believe the effective enforcement date for CIP v5 will not be April 1. I speculated that it will be about one year from that date (i.e. around April, 2017) before auditors feel confident enough in their understanding of CIP v5 that they’ll be comfortable issuing PVs for anything other than egregious non-compliance.

So if the official date for v5 is pushed back to July 1, this means the awkward one-year interregnum will be reduced to nine months. Ideally, it would be reduced even further (I’d like to see it reduced to zero, meaning the v5/v6 compliance date would be officially pushed back a whole year to April 1, 2017), but three months is certainly substantial. The big effect of this is that NERC entities that aren’t close to being fully compliant on April 1 will have another three months to get their house in order before they have to start self-reporting violations. Since I believe there are a lot of entities that fall into this classification, pushing the date back will constitute an act of mercy by NERC.

How can NERC push the v5 date back? I suppose they can go the “full Monty” route, where they petition FERC to do this. But I would think there could simply be a general announcement by NERC and/or the regions saying that, due to the v6 enforcement delay, it really makes sense to delay v5 enforcement for three months as well.

Of course, we all know the real reason the date should be pushed back is that very little guidance has been made available on the many interpretation issues of CIP v5.[ii] But I’m fine if NERC wants to point to FERC’s delay as the reason this needs to be done. Any port in a storm is a good one.

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

---

[i] In the post, I was thinking FERC might delay approving v6 for more than a quarter, which would have led to an enforcement date of October 1 or even later. But even a three-month delay will be significant.

[ii] In my opinion, there was no way NERC could have provided real guidance, absent rewriting certain key parts of the v5 standards; it’s unfortunate they had to go down so many blind alleys until they came to that realization (although I admit that for a while I allowed myself to become hopeful they could pull this off). Of course, they are now ordering some rewriting to be done, but I’m almost certain the rewriting won’t be thorough enough to make CIP v5/6/7 fully enforceable, in the sense that a fine issued by FERC would be upheld if challenged in court – more on this topic soon. Even though the rewritten standards (which will be CIP v7) will be helpful, I believe it will be at least three to four years before they will be in force. I had hoped that FERC would order NERC to rewrite CIP-002 as part of their Order approving v5 (which was issued November 22, 2013). Had they done that, we would be at least two years closer to having a more usable set of CIP standards.