Thursday, April 28, 2016

Still a Few Bugs in the System


I attended the one-day NERC Technical Conference on CIP Revisions last week in Atlanta. It was an excellent event, and was quite revealing – both for what was said and what wasn’t said.  The slides are available here, although don’t be surprised at how short they are; there was lots of discussion that went well beyond the slides. Fortunately, the recording is available here.

The conference was called to discuss the Standards Authorization Request for the Standards Drafting Team drafting the next CIP version[i]; essentially, the SAR is the “agenda” for what the SDT will do. I wrote a post on what is in the SAR recently, so I won’t repeat this. I want to focus now on what’s not in the SAR.

Frankly, my biggest concern going into the meeting was that there would be no discussion allowed on anything not currently in the SAR (since the agenda didn’t have any place for “other business”). However, when I asked Tobias Whitney if the SDT would be limited to just dealing with the SAR items, he said no.

This was the best news I’ve heard in quite some time. I also recently wrote a post on what’s not in the SAR; it consists of 29 items, and is far from complete (in fact I’m going to discuss one of the items I didn’t include below. I’m sure I could sit in a room with three or four NERC CIP affindicios – essentially, people who don’t have a life - and identify well over 100 items that really should be on the SDT’s agenda).

Of course, there is simply no way the SDT could properly address every possible problem with CIP v5 and v6 in anything less than five or ten years, so I’m certainly not proposing that the agenda be hugely expanded now. But there is a cost associated with not addressing these issues: When CIP v7 rolls all nice and shiny off the assembly line in a few years, these items will be as unresolved as they are today.

This point was borne home to me by a Q&A discussion that started during Scott Mix’s presentation at the conference. It regarded an issue that I know is huge for a number of entities, and especially those in Florida: shared substations. The issue is, who is responsible for compliance when

  1. A substation (or a generating station) is owned by more than one NERC entity, or
  2. One entity owns BES Cyber Systems that are located at another entity’s substation?

The problem is that the CIP v5 and v6 standards (with CIP-002 being the most important for this question) don’t provide any clear guidance on this issue; moreover, it’s not in the SAR for v7. And my guess is that, despite the huge importance of this issue, it will not be addressed by the new SDT, because it will take a lot of time they simply don’t have. So, unless there is an RFI on this issue (and I’m not sure it is “RFI-able”), this problem will continue to fester until CIP is completely rewritten in some future version after v7.

What “guidance” is in CIP v5 and v6 now? The closest thing I can see is the first sentence of Section 4.2, which reads “For the purpose of the requirements contained herein, the following Facilities, systems, and equipment owned by each Responsible Entity in 4.1 above are those to which these requirements are applicable.” Does this shed light on the two questions listed above?

Regarding the first question about shared assets, it really doesn’t help. If a substation is jointly owned by two entities, it (usually) isn’t divided physically into one part owned by A and the other by B. So both parties “own” all the BCS in the substation, unless otherwise provided for.

Regarding the second question about BCS owned by one entity but located at another entity’s substation, I pointed out during this discussion at the conference that none of the three words “Facilities, systems and equipment” refer to a substation (Facilities is a NERC defined term that refers to the lines, transformers, etc. that may be located at a substation, but not to the substation itself. Neither systems nor equipment refers to a substation, either). However, a BCS would definitely be a “system”, so this might be taken to mean that ownership of the BCS is all that matters for compliance.

Nobody jumped up to declare this the final solution to the problem; nor had I expected anyone to do so. If you have to use reasoning like this, you’re relying on a pretty weak reed. This is because the problem really relates to what I have called the Original Sin of CIP v5 (in this post from 2014 - see the section titled “Have an Apple, Adam?”): the fact that CIP-002 R1 and Attachment 1 were written from two opposite points of view, and the contradictions were never resolved. For an explanation of why I say this is at the root of the ownership problem, see this end note.[ii]

At the meeting, Steve Noess of NERC tried to be helpful and point out that NERC (and the regions) will look at the wording of any joint operating agreement between the owners of the substation to determine who has compliance responsibility. This might help, assuming there is such an agreement and it does actually assign compliance responsibility for the BES Cyber Systems to a particular party. However, this statement has no legal force, and if an entity were fined on this basis and appealed to the courts, the fine would likely not be upheld.

So this problem really won’t be resolved unless the SDT takes it up; but as I’ve said, I doubt the SDT has time to deal with it, without delaying delivery of v7 by some months. This is just one of many problems that NERC entities are going to have to live with, until there is a complete rewrite of NERC CIP.


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


[i] And I sincerely hope NERC will simply admit that this will be CIP version 7, rather than continue to call this “CIP Revisions” - which was of course also the name of the SDT that drafted CIP version 6. Scott Mix’s presentation actually had the words “CIP Version 6” in the title. This is literally the first time I’ve ever seen an admission from NERC that there actually is a version 6. I also hope the v7 SDT doesn’t make the other mistake the v6 SDT did, which was not to revise the three v5 standards that weren’t actually changed in v6. The fact that entities will have to comply with seven v6 standards and three v5 ones has caused – and continues to cause – a great deal of confusion. This time, let’s call it v7 from the start and make sure every standard is revised, if nothing else just in its version number.

[ii] Technically, no assets – substations, generating stations or control centers – are “in scope” for CIP v5; there are only “assets that contain” High, Medium and Low BCS respectively, and it’s the BCS that are in scope. This means that the fact that a substation may be owned by two entities doesn’t mean anything; what should matter is who owns the BCS at the substation. Of course, if the BCS are jointly owned as well, then the problem remains.

On the other hand, assets clearly are in scope when it comes to Low impacts; there, what is in scope isn’t the BCS but the “asset containing Low impact BCS”.  So this means that, if CIP-002-5.1 is going to be consistent (!), “Facilities, systems and equipment” in Section 4.2 must somehow include assets (it would definitely include them if Facilities hadn’t been capitalized. That’s another issue that should be on the SDT’s agenda, and – unlike most of the others – is almost trivial to fix). So assets really are in scope, and therefore who owns a substation does matter. But of course this contradicts what I said in the previous paragraph….

As I’ve said a number of times, the wording of CIP-002 R1 and Attachment 1 is a hopeless mess that can only be fixed by a comprehensive rewrite, not tweaking a few words here and there. But this is another issue that I simply don’t think the SDT will feel it has time for, and I agree with them. It's something the NERC community will simply have to live with until CIP is completely rewritten; I hope that will be in a non-prescriptive, risk-based format.

1 comment:

  1. An auditor pointed out to me that I was wrong when I said near the end (discussing Steve Noess's comment) that a joint operating agreement would have no legal force. There is a 2010 NERC document describing how those will be used to assign responsibility for compliance. I apologize to Steve for the error.

    ReplyDelete