Shortly after FERC issued their NOPR saying they would approve CIP v5 in April 2013, I set out to do a series of posts that would create a road map for what an entity should do to comply with v5. Since the beginning is a good place to start, my first post was on CIP-002. But a funny thing happened on the way to the road map: I realized there was a fundamental “You can’t get there from here” flaw in the logic of CIP-002-5 R1. If an entity were going to try to follow the logic of the requirement in order to identify and classify their High and Medium impact BES Cyber Systems, as well as their “assets containing Low impact BCS”, they would simply run into a wall and never get where they wanted to go. Since then, I—and others—have identified many more problems with CIP-002 R1 and Attachment 1, as well as certain definitions, like “Cyber Asset”, that are necessary to comply with this requirement but that are missing or ambiguous.
However, I was surprised to see that this has not stopped NERC, the regions and the NERC entities from coming up with a generally-accepted “interpretation” of how to comply with CIP-002 R1 by first classifying “assets” as High, Medium or Low using Attachment 1, and then identifying BES Cyber Systems using a criterion something like the one used in CIP v1-3 to identify Critical Cyber Assets: those Cyber Assets that are “essential to the operation of” a Critical Asset (of course, that criterion is really used to identify BES Cyber Assets; then these are aggregated to BCS).
I’m quite happy with this development, since I didn’t want to see CIP v5 implementation stop dead in its tracks because of the problems I was writing about. But there remains one big problem: The methodology that NERC entities are using to comply with CIP-002-5.1 R1, and that the regions (and even NERC) are for the most part advocating as proper, is almost completely incompatible with the requirement (and Attachment 1) as written. In other words, assuming nobody makes the entities radically shift how they comply with R1, not a single entity will be in compliance with the literal wording of CIP-002 R1! This obviously isn’t something that is good for CIP, or for NERC for that matter. It means CIP-002-5.1 will never be enforceable, and perhaps this contagion will spread to the other CIP standards as well – since they all depend on the entity correctly complying with CIP-002-5.1 R1.
Of course, there are two ways to change this situation. One would be to beat into everybody’s head – the entities, the regions and NERC itself – what the real R1 compliance methodology is (or to state it better, the methodology that comes closest to following the words of R1 and Attachment 1). I don’t think this is a good idea, because I believe the methodology that people are adopting is far superior to the one that is found in the words of CIP-002. Plus enforcing this would be impossible in any case.
The second way to make the practice and the words compatible is to change the words – i.e., rewrite CIP-002. I have been saying for a while that this is the only possible way to make v5 enforceable, even though it will take several years (or more) for a new version to be approved and enforceable. Despite that fact, simply leaving CIP-002 in place as it is should not be acceptable. In my opinion, it’s likely to lead sooner or later to all of v5 (and v6, and perhaps future versions as well) being unenforceable. If the foundation is rotten, sooner or later the house will fall. CIP-002 is the foundation of CIP v5 and v6, and it can’t be allowed to exist forever in its current state.
This is why I say CIP-002 should be rewritten. In the next three or four posts, I will lay out the problems I see with the current CIP-002. I will conclude with a discussion of what might be done during the three or more years it will take to draft, ballot and have FERC approve the new version – given that CIP v5 and v6 will be effective in some way or other starting next April, whatever the status of CIP-002-5.1 on that date.
I divide the problems in CIP-002 into four types, each of which will have its own section in these posts (but not necessarily its own post). The sections are:
- “Spot” Problems
- Problems Caused by Excessive Brevity
- The Fundamental Problem with CIP-002
- Problems Dependent on Resolution of the Fundamental Problem
- What to do while CIP-002 is being Rewritten
I. “Spot” Problems
There are a number of problems that are confined to particular sentences or phrases, as well as a missing definition or two; I’m calling these “spot problems”. Unlike the remaining problems discussed in this document, these problems can be dealt with through relatively small wording changes.
Before I begin, I want to point out that there is a large class of spot problems that I won’t be discussing here: These are problems with the Attachment 1 criteria. I’m referring here to technical issues that have come up with application of the criteria in practice[i] – and that can be foreseen to continue to come up as the criteria are further applied to real-world situations. I see the potential technical issues as almost unlimited in number.
To be honest, I don’t think these technical issues can be addressed through rewriting the criteria; I think the criteria are pretty good already – or at least as good as they could ever be. The problem is with the whole idea of bright-line criteria being applied to an industry as incredibly diverse as this one in the first place; I don’t think God Himself could write a set of short criteria that wouldn’t lead to an almost infinite number of questions (and I don’t believe God was on the SDT in any case). I first wrote about this problem on a different blog in 2012, but I recreated that post here in 2013.
I think the best solution to the issue of the bright-line criteria is a kind of “Supreme Court of BLC” – a panel of experts from the industry that will consider disputes regarding the criteria and provide guidance. I also know that the worst solution is to handle all of these disputes through the enforcement process. This will be very expensive for NERC entities, the regions, and for NERC and FERC. And to be clear, there will never be an end to BLC issues. It’s like whack-a-mole: as soon as one issue is dealt with, a couple more pop up. In my opinion, my court idea would have to be dealt with outside of the standard – based on some consensus among NERC, FERC, the regions and the entities, but not relying on a rewrite of NERC’s Rules of Procedure, which would take forever.
So here are the spot problems that I see in CIP-002-5.1, other than technical ones involving the BLC:
a) Section 4.2: “Facilities” – The title of Section 4.2, which is about the scope of CIP v5, is incomplete. Some of the “big iron” in scope for CIP v5 is indeed Facilities – i.e., lines, buses, transformers, etc. - per the NERC definition. But some of it is “assets”. This is an undefined term that is “defined” for purposes of CIP-002 by the list of six asset types in R1. I think “Facilities” in the title of 4.2 should be replaced with “Facilities and assets”; the reasons for this will be made clearer in c) below. In addition, Section 4.2 refers several times to “Facilities, systems and equipment”; the same phrase appears in the BES Cyber Asset definition. For the life of me, I can’t figure out why this phrase is here, or what it means[ii]. Is the entity supposed to start out with a list of each Facility, system, or piece of equipment it owns, to see what’s in scope for v5? Do “systems” include desktop PCs used in Accounting? Does “equipment” include monkey wrenches? And since, per the Glossary definition, an asset like a control center or substation can’t be a Facility (and assets obviously aren’t systems or equipment either), are control centers and substations therefore not subject to CIP v5 at all? I think it would be much better to simply replace “Facilities, systems and equipment” with “assets or Facilities”[iii] everywhere it is found.
b) Section 4.2: “owned” – This section also says that the requirements only apply to FSE that are owned by a Responsible Entity. What if an entity does a sale/leaseback deal to raise cash and transfers ownership of the systems in a control center to a finance company? Do the requirements no longer apply to these systems? Obviously, that shouldn’t be the case. But I don’t see how it’s prohibited by the current wording.[iv]
c) Section 4.2.2: “All BES Facilities” – This section – which is of course found in each CIP v5 and v6 standard – states what is in scope for all Responsible Entities except DP’s. According to the Glossary definition, no substation or control center is a Facility. And since in the Generation environment a Facility will usually be a single unit, most generating plants won’t be Facilities either. So a literal application of this wording could possibly eliminate close to 95% or more of the assets in North America from CIP v5 compliance. The solution to this problem is simple: use a lower case “f” so that the general meaning of “facilities” will apply.
d) Section 188.8.131.52: “discrete Electronic Security Perimeters” – The problem with this wording was discussed quite eloquently in the Memorandum on “Network and Externally Accessible Devices” published in April (and rescinded in July). It seems the SDT forgot that there can now be BES Cyber Systems that are only serially connected and therefore don’t have an ESP; but they will still have external communications. NERC recently put out a Lesson Learned that does a good job of addressing this issue; it can form the basis for a rewrite of this section.
e) Definition of “Programmable electronic device” – There has, of course, been a lot of controversy on this, as well as failed attempts to address the issue. Clearly, there will be no agreement until a definition is drafted and balloted. Perhaps there shouldn’t be a definition of PED, but the Cyber Asset definition should be rewritten to eliminate the undefined term. Either way, this needs to be addressed.[v]
f) Attachment 1, Criterion 2.6 – This criterion reads “Generation….and Transmission Facilities..” Taken literally, the fact that this doesn’t say “Generation Facilities…” means that an entire plant is Medium impact, even if only one of its units is designated as critical to IROLs; although with a substation, only particular lines, transformers or other Facilities are in scope. However, in the Guidance the SDT did refer to Generation Facilities; plus NERC took it to mean this in their Memorandum in April. So I think it’s safe to say that this should really read “Generation Facilities and Transmission Facilities”.
For Part II of this series, go here.
For Part II of this series, go here.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.
[i] There is one issue of wording with the Attachment 1 criteria that I will address in this document. But all the other issues I know of are technical ones relating to industry structure, engineering considerations, etc. As you will see, I’m saying they really need to be dealt with in a court-like setting.
[ii] Since I originally wrote this sentence – while writing Part III of these posts – I discovered where this phrase came from – a Concept Paper the SDT wrote in 2009 that provided much of the intellectual foundation of CIP v5. On the other hand, I still don’t understand why it is used in CIP v5, since the standards clearly don’t apply to “Facilities, systems and equipment”.
[iii] The other place where “Facilities, systems and equipment” is found is in the BES Cyber Asset definition. As will be seen in the remaining Parts of this series of posts, I am recommending rewriting that definition in a way that will eliminate FSE, although that isn’t the purpose of the rewriting. But even if the definition weren’t rewritten for other reasons, I would still recommend that FSE be removed, since I think it’s just as useless and misleading as it is in Section 4.2.
[iv] I’m told there are some smaller Control Centers where the operator of the Control Center literally does not own the equipment. So this isn’t a completely academic question.
[v] On September 9, 2015, NERC released a Lesson Learned that discusses this issue (and others related to CIP-002). In that, they frankly admitted that entities need to figure out for themselves what “Programmable” means, and there are all sorts of possible ways of doing this. Of course, this discussion of “Programmable” doesn’t constitute a definition at all, although I believe this document is as good as could be done; it is now up to each entity to develop their own definition or methodology for identifying Cyber Assets. While this is clearly the only thing that can be done in the short term, since “Programmable” is quite literally the foundation for the entire scoping process of CIP v5 and v6 (and probably for several versions after v6 as well), this situation can’t be allowed to stand in the long run. There needs to be some kind of definition of “Programmable” – or perhaps the definition of Cyber Asset needs to be revised to clarify exactly how an entity identifies “Programmable electronic devices”.