January 31: I realized this post had missed the boat in several important ways, so I rewrote it here. I don't believe in removing posts, but there is no longer any reason to read this one.
I think anybody who reads this blog will answer the question in the title in one of three ways:
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 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 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. Again, there will need to be a list: “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 the basic problems[ii] in CIP v5. Of course, this means it will be easily 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 treat all of the above areas of ambiguity as implicit requirements for the entity to resolve to its own satisfaction, and to document how it resolved them.
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
I call requirements explicit when there isn’t any fundamental ambiguity in them. For example, CIP-007-6 R2 lays out a process the entity needs to follow for patch management. I won’t say it’s crystal clear, and I know there has been a lot of discussion at regional meetings about what it means. But I believe the parameters are clear enough (35 days, etc) that entities have a good road map on how to comply. I believe the majority of the requirements in CIP v5 are quite clear, and don’t implicitly require any unstated “requirements”.
So for explicit requirements, I believe the entity needs to have all of their procedures in place and documented on April 1. If they don’t, they will need to submit a self-report and try as quickly as possible to develop and document their procedures. In other words, they need to do what they had to do with previous CIP versions, as well as with other NERC standards.
If an entity hasn’t complied with an explicit requirement of CIP v5, I believe a PV might be issued, just as in previous CIP versions.
Addressing Implicit Requirements
It’s a different story for the implicit requirements. For all of these (and I realize I’m not providing a list here, since as Lew says there can be no complete list. I have discussed a lot of these in blog posts over the past three years, although I haven’t usually referred to them as implicit requirements), it is up to the entity to decide how to address each one. For example:
1. Sometimes the entity will have to develop their own “definition” (like for “Programmable”, ERC, “custom software” in CIP-010-2 R1, etc), in order to comply with an implicit requirement.
2. In other cases, the entity will have to develop a list, for example lists of PCAs, EACMS, EAPs and PACS. 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 still other cases, the entity will need to document how they are interpreting a particular phrase, like “adverse impact on the BES” in the BES Cyber Asset definition. Again, this doesn’t have to be a dictionary-type interpretation, but could be a procedure for determining whether or not there is adverse impact. You also need to document that you applied this procedure consistently in identifying your BCAs.
4. 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 in the first place, 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 rogue blog posts like this one) and develop your own methodology. You also need to show that you applied it consistently in identifying your BCS.
5. 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.
6. 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 with 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) than the burden for CIP v3.
However, I don’t believe PVs will ever be issued for violation of implicit requirements – unless that leads to a violation of an explicit requirement. For example, if your entity doesn’t develop a consistent definition of “programmable” but instead lets each group determine for themselves what this word means, this could possibly be interpreted as a violation of CIP-002-5.1 R1 because your entity would be identifying BES Cyber Assets differently in different instances.
Of course, there is no requirement to self-report a violation of an implicit requirement unless it leads to a violation of an explicit requirement, as I’ve just discussed. For example, this means the entity doesn’t have to self-report that it doesn’t have its definition of “programmable” documented on April 1. However, the entity still has to apply that definition consistently across all its High and Medium assets, and document that it has done so.
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 implicit requirements in CIP v5, and the documentation needed to “comply” with them.
To summarize what I’ve said,
1. 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. Implicit requirements will not generally lead to PVs or self-reports, except in the case where violation of an implicit requirement leads to violation of an explicit one. However, they need to be complied with and documented before an audit, and the entity needs to show that any definitions or methodologies shown were applied consistently.
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 the SDT decided 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 important to try to get the foundation as solid as possible, so the work that the SDT will do is important.