What Do You Need to Do After April 1?

January 31: I recently wrote a post that made the case that compliance after April 1 with CIP v5 (and v6) will be quite different from what compliance with CIP versions 1 through 3 was after their compliance dates. The post went on to describe how I thought NERC entities should approach compliance with v5. However, I decided that the second part of that post (the compliance approach) needed to be rewritten, which I’ve done here. I’ve also made some lesser changes to the first part. Thus, this post entirely replaces the previous one.

Introduction

What happens on April 1? My guess is you will give one of three answers:

1.    NERC CIP version 5 comes into effect;

2.    It’s April Fool’s Day; or

3.    Some combination of these two. 

My personal preference would be the third answer. CIP v5 does come into effect on April 1, but this time is very different from when previous CIP versions (or other NERC standards) have come into effect. What will entities need to do on (and after) April 1, that they didn’t need to do in previous CIP versions?

The reason CIP v5 (and when I say CIP v5, I mean v5 and v6) is so different is that there are many areas of uncertainty regarding what the requirements mean, and many entities are far behind where they should be in preparing for the compliance date – because they have been expecting/hoping for some clear guidance, which hasn’t shown up. Of course, I’ve been saying this since 2013, but here are three recent pieces of evidence:

First, I recently wrote a post discussing a recent article written by Lew Folkerth of RF on the idea of “implicit requirements” in CIP v5. Lew had stated last October at an RF meeting that he was going to work on a list of these implicit requirements. However, in his article he said, “My opinion is that we may never be able to achieve a complete list of implied requirements; the more we mature in our understanding of CIP Version 5, the more implied requirements we will find.”

Think about this. Lew has been saying for a while (and I picked up his banner) that there are a lot of things an entity needs to do to comply with CIP v5 that aren’t actually written in the standards. Now he’s saying that it will probably never be possible to produce a complete list of these items. In other words, there will probably never be a complete list of what an entity needs to do to comply with CIP version 5!

Second, in a recent post I republished a news article on the run-up to CIP v5. That article made a point that both Lew and I have made repeatedly for more than a year: For areas of the CIP v5 standards where there is ambiguity in the requirements or definitions, the only choice the entity has is to determine for themselves the right interpretation. But they need to document their interpretation and how they arrived at it – and they need especially to show they’ve considered whatever guidance NERC or their region has put out, even if they didn’t actually follow that guidance.

Third, on January 19 I listened to a NERC webinar on “Future CIP Standards Development”. NERC officially announced that a number of issues (more than eight) in CIP v5 will be referred to the current CIP v5 Revisions Standards Drafting Team for development of revised or new standards or definitions. This in itself wasn’t a surprise, since NERC has been saying this would happen for more than a month. What was surprising was that the drafting team will be addressing what I think are probably the three most fundamental areas of ambiguity in CIP v5:

1.    The definition of Cyber Asset, especially the meaning of “programmable”.[i] I have written a number of posts on this issue, but the one I like best is still the first one.

2.    The definition of BES Cyber Asset, and especially the meaning of “adverse impact” in that definition. I have written several posts on that topic, but the best is here.

3.    The concept of External Routable Connectivity. My last post on ERC was this one. However, just like with “programmable”, I no longer think there can ever be a dictionary-style definition of ERC that will address all of the current questions. There will need to be a list describing different cases (presumably with diagrams): “In case A, there is ERC; in case B, there isn’t ERC; in case C….etc.” This is similar to the discussion of LERC in the Guidance and Technical Basis section of CIP-003-6. 

So I’m happy that the SDT is actually going to address some of the basic problems[ii] in CIP v5. Of course, this means it will easily be three to four years before the new standards and definitions are drafted, approved by NERC and approved (maybe) by FERC. Until then, NERC entities will have to resolve each of the above areas of ambiguity to their own satisfaction and document how they resolved them. In addition, each entity will need to document that they considered all available NERC guidance in arriving at their own “definition”, and that this was applied consistently across their assets (for example, both Generation and T&D need to use the same “definition” of “programmable” in deciding which devices are Cyber Assets and which aren’t).

Let’s get back to my question above: What do entities need to do starting this April that is different from what they did to comply with previous CIP versions? As I’ve just shown, there are explicit and implicit requirements in v5. Let’s discuss these separately.

Addressing Explicit Requirements

Explicit requirements are ones that are stated in the CIP v5 (or v6) standards. If the requirement has a number like R1, R2 etc. in front of it, it’s an explicit requirement. However, there are two types of explicit requirements: clear and ambiguous. While the line between these two types isn’t a clear one, in general a clear requirement is one about which there is no fundamental debate. For example, CIP-007-6 R2 Patch Management is fairly clear in its concepts, although there is some disagreement around the edges. An entity that decides to take 60 days to evaluate new security patches for applicability, rather than the 35 days in the requirement, will most likely receive a PV. It would be very hard for them to argue that the requirement isn’t clear on this point.

An example of an ambiguous explicit requirement is CIP-002-5.1 R1. I have expended billions of perfectly good electrons discussing the problems with that requirement; a recent post is here. Another example is any requirement, like CIP-007-6 R1, where External Routable Connectivity is mentioned in the Applicability section. Since the definition of ERC has been turned over to the Standards Drafting Team to rewrite (presumably in CIP version 7), its ambiguity[iii] will never be resolved until that effort is completed and approved, easily 3-4 years from now.

For “clear” explicit requirements, you need to comply with them in the same way you did for requirements in CIP versions 1-3: Develop and document procedures for compliance, and make sure the procedures are applied to all of your cyber assets that are covered by the requirement in question. If you won’t be fully compliant with one of these requirements on April 1, you need to self-report a violation and work as quickly as possible to come into full compliance. A PV may be issued, whether you self-report a violation or it is discovered during an audit.

For ambiguous explicit requirements, you first have to develop and document how you have resolved the ambiguity. To use the example above, for CIP-002-5.1 R1 you need to develop and document your own methodology for identification and classification of BES assets and BES Cyber Systems. This needs to take advantage of whatever guidance has been provided by NERC or your region, but at the end of the day it is your entity that must make the decision on what is the best methodology, since the wording of the requirement itself (and Attachment 1) is ambiguous and contradictory. You also need to document that this methodology has been applied on a consistent basis across all of your assets.

If you have taken these steps by April 1, you don’t need to self-report anything. However, if you simply have not finished this methodology by April 1, and/or you haven’t finished applying it to all of your assets in scope, I believe you do need to self-report that you are in violation and work as quickly as possible to come into compliance. In other words, for requirements that are explicit but ambiguous, you need to resolve the ambiguity in some way and proceed with complying with the requirement. You won’t get a pass from your auditor if you say you just couldn’t figure the requirement out, so you didn’t do anything at all.

Addressing Implicit Requirements

It’s a different story for the implicit requirements. First, you need to identify them. How do you do this? You think about how you comply with each explicit requirement, and you look for steps you need to take that aren’t specifically stated in the requirement. For example, you may have noticed that, while the Applicability sections of many requirements list Protected Cyber Assets, EACMS, and PACS as devices to which they may apply, you are never required to identify these in the first place. So identifying them is an implicit requirement.[iv]

It would certainly help if there were a definitive list of implicit requirements. However, as I mentioned above, Lew Folkerth now says there can never be such a list; I agree with him.[v] It is up to each entity to identify implicit requirements and document how it dealt with each one. You can find implicit requirements discussed in many documents, such as the NERC Lessons Learned and in many of my posts. They aren’t usually identified as implicit requirements, but here is a rough “field guide” to some of the primary types:

1.       If you have to develop your own definition in order to comply with a requirement, doing so is an implicit requirement. Examples of this are the word “Programmable” in the Cyber Asset definition; “adverse impact on the BES” in the BES Cyber Asset definition; “External Routable Connectivity” when the communications stream to a device includes both routable and non-routable components; and “custom software” in CIP-010-2 R1. For all of these, you have to develop and document your own definition. In addition, you need to document that the definition was applied consistently across your assets. Keep in mind that the “definition” will often not be dictionary-style, but will probably be a procedure for identifying something, as in the “programmable” procedure discussed in this post.

2.       In other cases, the entity will have to develop a list, for example lists of PCAs, EACMS, and PACS. As I discussed above, even though many requirements apply to these cyber asset types, there is no requirement to actually identify and list them in the first place. That requirement is implicit.

3.        In a number of cases, the entity needs to develop and document a methodology. For example, there is no explicit requirement in CIP-002-5.1 to identify BES Cyber Systems, so the requirement itself provides no guidance on how you can do that. It’s up to you to read whatever you can about this (including the Guidance and Technical Basis for CIP-002-5.1, rogue blog posts like this one, and the Lesson Learned just released by NERC, which primarily relates to identifying Cyber Assets) and develop your own methodology. You also need to show that you applied that methodology consistently in identifying your BCS.

4.       Some implicit requirements follow from actual requirements by simply applying common sense. One good example (borrowed from an EnergySec webinar) is the fact that CIP-003-6 R1 requires an annual review of cyber security policies, but doesn’t require the entity to change a policy if the review finds the need for a change. Of course, common sense dictates you should make the change.

5.       There is a whole class of implicit requirements that deals with virtualization. Since virtualization wasn’t considered at all in developing the CIP v5 standards, the entity has to think about what makes the most sense if they have virtual machines or virtual switching. This is one of the topics that the drafting team will take up, so there will be no official word on this topic for years. However, NERC provided some “implicit guidance” in a recent document that I discussed in this post. If you have any virtualization within your ESPs, you need to address that in some way in CIP v5, not simply pretend it’s not there.                                                                                                            

So there is a lot of work that needs to be done to comply with the implicit requirements in CIP v5, starting with the fact that there is not now, and never will be, an official list of these requirements. I think there are at least 150 different types of documentation required for CIP v5, and my guess is half of these are due to implicit requirements. This is primarily why I say the paperwork burden for CIP v5 is greater by some factor (at least three or four, in some cases a lot more than that) than the burden for CIP v3, even when you allow for the fact that there are many more cyber assets in scope for v5 than for v3.

I don’t believe PVs will ever be issued directly for violation of implicit requirements. However, since an implicit requirement is always part of complying with an explicit requirement, you will almost always have to self-report a violation of the latter. For example, if your entity doesn’t develop a consistent methodology for identifying and classifying BES Cyber Systems (an implicit requirement), but instead lets each group in your organization determine for themselves how to do this, this would probably be interpreted as a violation of CIP-002-5.1 R1 - since your entity would be identifying BES Cyber Assets differently in different instances.

If you have complied with an implicit requirement but just have not yet documented that fact, you don’t need to self-report anything. Going back to the example of identifying PACS, EACMS and PCAs, you don’t have to self-report on April 1 if you haven’t documented your methodology for identifying these devices, since this is an implicit requirement. On the other hand, if you haven’t documented your methodology because you don’t have one and you have just been identifying these devices willy-nilly, you will need to self-report that, since you haven’t identified these three items consistently and this will affect your compliance with a number of explicit requirements.

Wrapping Up

The purpose of this post has been to show that the answer to the question “What do I have to do regarding CIP v5 after April 1, 2016?” is much more complex than it was with previous CIP versions. This is primarily because of the large number of ambiguous and implicit requirements in CIP v5, and the documentation needed to “comply” with them.

To summarize what I’ve said,

1.    “Clear” explicit requirements need to be treated as they always have been in previous CIP versions. Self-reports are required for any areas in which you know (or suspect) you aren’t compliant, and PVs may be issued.

2.     To be compliant with an ambiguous explicit requirement, you need to resolve the ambiguity to the best of your ability (e.g. by developing your own methodology for identifying BES Cyber Systems, since CIP-002-5.1 R1 doesn’t provide any guidance on that), document how you resolved the ambiguity, and make sure you have applied this consistently to all cyber assets. If you haven’t done this, you aren’t compliant with that requirement, and need to self-report.

2.     You need to document how you complied with an implicit requirement, although you don’t have to make a self-report if the documentation isn’t in place on April 1. However, if you haven’t fully complied with an implicit requirement, it is very likely you have violated an explicit one (as in the two examples above); you will need to self-report that.

Feb. 3: I felt I hadn't actually answered the question in the heading in this post, so I published a follow-on to this post here.

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

---

[i] I certainly hope the SDT doesn’t limit themselves to just defining Programmable. I think they should consider what would be the best definition of Cyber Asset, which might not even include that word. I also think that it will ultimately be impossible to come up with a “definition” of Cyber Asset in the dictionary sense of the word. The only approach that will work, in my opinion, is some sort of list, for example “Devices with one or more of the following characteristics are Cyber Assets.”

[ii] When I say “basic problems” here, you may wonder how this relates to my recent post where I said it was time to start dealing with the “fundamental problem” with the CIP standards – namely, that they are prescriptive, while cyber security is much better addressed with risk-based standards. I regret to say that the SDT’s efforts won’t address this fundamental problem; only a complete rewrite of CIP (in a form something like CIP-014) would do that. My preference would be that NERC (and I guess FERC) decide to do that complete rewrite now. However, other than my kids and my barber, I don’t know anyone who is wholly in agreement with this idea yet. It will take a while to build up a constituency for this change. If the CIP v5 framework will be around for a number of years (not my preference!), it is still important to try to get the foundation as solid as possible, so the work that the SDT will do is important.

[iii] When I say the ERC concept is ambiguous, I need to point out it is only ambiguous in the case where the communications stream between a Cyber Asset like a relay and the control center includes both routable and non-routable (serial) components. If the stream is entirely routable or entirely serial, there is no ambiguity. In the former case, there is ERC; in the latter, there isn’t.

[iv] For that matter, you are never required to identify BES Cyber Assets or BES Cyber Systems, either. Where the word “identify” is used in CIP-002-5.1 R1.1 – R1.3, it really means to classify them after they have been identified. In developing your CIP-002-5.1 R1 compliance methodology (discussed under explicit requirements), you will need to show how you will identify BCS in the first place. I have written a lot about this problem, including in this post.

[v] I have developed a list of implicit requirements over the last five or six months, and I am continually adding to it. We at Deloitte Advisory provide it as part of the free CIP v5 workshops we have done with a number of entities in the past few months – and are continuing to do now. If you might be interested in doing this, please email me at talrich@deloitte.com.