Lew Folkerth Discusses Implicit Requirements in CIP v5

I have mentioned in at least a few posts the idea of “implicit requirements” in CIP v5 – that is, things an entity needs to do to comply with the written requirements, that aren’t actually stated as requirements. I believe I have also acknowledged (at least I hope I have) that this idea wasn’t mine but that of Lew Folkerth, Principal Reliability Consultant with RF.

Even though I may not always have identified them as such, my posts on CIP v5 have been loaded with implicit requirements – to identify Cyber Assets, BES Cyber Assets and BES Cyber Systems in CIP-005-5.1 R1; to develop and document a methodology for determining whether there is External Routable Connectivity for substation relays that are connected to a device like an RTU which is then connected through IP to a control center; etc. I have even put together a document listing all of the implicit requirements I have so far identified in v5 (it is growing all the time, of course).[i]

At RF’s CIP v5 workshop in Cleveland on October 1, 2015, Lew – in response to a question – said he would “look into” preparing a list of implicit requirements in v5. He published an article in the most recent RF newsletter (pages 8 and 9) in which he discusses what he found when he did look into this. As with everything else Lew writes on CIP, I strongly recommend you read this article, whether or not you’re in RF (there is nothing in it that just pertains to RF. In fact, I don’t recall anything he’s written on v5 that doesn’t apply to all NERC entities, no matter which Regional Entity they’re part of. I believe you can find the archived newsletters on the RF site; Lew’s articles are always under the heading “The Lighthouse”).

Lew admits up front that he doesn’t have a list of implicit requirements to provide. Moreover, he admits he will not be providing one in the future, either. This is because “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.”

You may wonder why Lew can’t provide at least an incomplete list – after all, wouldn’t it be better to have a partial list of implied requirements than no list at all? I believe the answer to this question (although I haven’t discussed it with Lew) is that, if someone in NERC (and of course, the Regional Entities are all part of NERC, or the “ERO Enterprise”) provides a partial list of implied requirements, entities will complain if they are later cited for missing an implied requirement that isn’t on that list. There is really no way he can provide this list, given his current job responsibilities.

I find the above statement of Lew’s to be very significant for another reason: I think it raises serious doubts about whether NERC CIP version 5 can ever be “enforceable” in the strict sense of being upheld in the US court system. I will have more to say on this point (a lot more, in fact) in one of my next posts. However, I also do have a few comments on Lew’s article, which I’ll discuss now.

Lew states close to the beginning of his article that “Implied requirements are a consequence of writing CIP Version 5 as results-based Standards.” This is an interesting idea, but I believe it’s contradicted in the section titled “Sources of Implied Requirements”. In that section, he lists four cases in which implied requirements can arise. I agree with everything he says in this section, but note that the second of these four cases is “Results-Based Specification”. If this is only one of four ways in which implied requirements arise, how can Lew’s initial statement that implied requirements arise from “results-based standards” be true, since it clearly is meant to apply to all implicit requirements? My personal opinion is that the only general statement that can be made about all implicit requirements in CIP v5 is what I said in the first sentence of this post - they are things an entity must do to comply with one or more v5 requirements, which are not themselves stated in a requirement.[ii]

As I said, I do completely agree with the section entitled “Sources of Implied Requirements”. Lew wrote this section to give entities a way to identify implied requirements on their own. Since he can’t provide them with his own list, this is obviously the next best thing that he can do. I think all of the four “sources of implied requirements” he lists can definitely lead to implicit requirements, although I would think there are some implicit requirements that don’t spring from one of these sources.[iii]

However, I don’t agree with the next section of the article, “Failure to Comply with an Implied Requirement”. It states in part “If an implied requirement is violated, an audit team will return a finding for the Requirement that is supported by the implied requirement. Since an implied requirement may support multiple Requirements, a violation of the implied requirement may result in multiple audit findings. An example of this would be the failure to identify and protect an EACMS associated with a high impact BES Cyber System. Failure to identify and protect each EACMS could potentially result in an audit finding in 64 Parts of 18 different Requirements.”

I agree that there are some implied requirements – like the implied requirement to identify all EACMS associated with high BCS – which are quite evident. If you’re not required to identify your EACMS, how could you possibly comply with all the requirements that apply to EACMS? If you don’t identify your EACMS out of pure stubbornness, I can see a PV is justified. But there are other implicit requirements that are not clearly implied at all.

For example, I think every Regional Entity will require that an entity being audited present a list of “Medium impact” substations, or more correctly “substations that contain at least one Medium impact BES Cyber System”. This is an implied requirement, but it is also not one that can be easily identified from the wording of CIP-002-5.1 R1 or Attachment 1 (in fact, I believe it can’t be identified from that wording[iv]).

In a case like this, I think it would be very hard for an auditor to actually issue a PV for violating that implicit requirement. My guess is, if the entity doesn’t have the list of Medium substations, the auditor will simply ask them to draw one up.

And going back to Lew’s example of an entity that failed to identify one or more EACMS and thus didn’t comply with 64 parts of 18 requirements, I find it very hard to believe they would receive any PVs at all because of this – unless they had simply pretended that they didn’t have to identify any EACMS and therefore none of the requirements that apply to EACMS applied to them. Except in that extreme case, I think most failures to identify EACMS will be caused by confusion over what exactly the definition applies to (or perhaps whether or not ERC is present); and as I’ve said in several posts including this recent one, I don’t think any PVs will be issued for these cases until there is general agreement in the NERC community on the many areas of ambiguity in v5 – which will probably be at least a year after April 1, 2016.[v]

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

---

[i] Deloitte Advisory provides this document to entities that decide to take advantage of the free CIP v5 Quick Check, described in this post.

[ii] I also disagree with the example Lew uses to illustrate a “results-based specification”. It is CIP-002-5.1 R1. I disagree that this requirement is “results-based”. As I discussed in this post from 2014 (in the section labelled “Issue 4”), because of the ambiguities and missing definitions in R1, there can never be a definitive statement of what results are required by R1, other than to get into a curious argument: a) R1 requires the entity to properly identify and classify its BES Cyber Systems. How does the auditor determine whether or not the entity has done this properly?; b) The auditor needs to determine whether they have properly followed the procedure described in the requirement; c) But Lew has just said that much of what is required by R1 is implicit – how can the auditor possibly say they have followed the correct procedure or not, other than to use his or her own personal judgment?

I followed up the 2014 post with this post, which made the point that calling CIP-002-5.1 R1 a “results-based” requirement leads to a completely circular argument, where a correct “result” of the requirement can only be determined by whether or not the requirement has been “properly” followed – and the only way to determine whether it has been properly followed is to know what the result should be!

[iii] My guess is some implicit requirements are implicit simply because the Standards Drafting Team didn’t think to include them; there is simply no further reason. Someday I would like to go through my list to see which implicit requirements are due to one of Lew’s “sources of implied requirements”, and which ones are simply there because of SDT error.

[iv] The reason this is the case is that the criteria that apply to substations – 2.4 through 2.8 – all use the word Facilities as their subject. A Facility is a line, transformer, etc. – but not the substation itself. Literally every entity or auditor that I have talked to either a) thinks “Facility” means the substation or b) knows that it doesn’t, but is choosing to treat it that way because of the complications of trying to classify BCS in a substation according to the Facility they’re associated with, not the substation itself. Effectively, these criteria do apply to substations, and a list of Medium substations is implicitly required. On the other hand, this isn’t what the wording says.

[v] There is another consideration here: I believe there has been some sort of unofficial doctrine in place among the CIP auditors since CIP v3, to the effect that a failure to identify a particular cyber asset in scope (e.g. a Critical Cyber Asset under v3 or a BCS under v5) will at most lead to a PV for violating the original identification requirement (CIP-002-3 R3 or CIP-002-5.1 R1), but not to PV’s for missing other requirements due to not having identified that cyber asset as in scope. If that is the case, then at worst the entity would receive a single PV for not having identified an EACMS – and frankly, even that is hard to support since there is no requirement that even implies EACMS need to be identified. If a PV is issued for not identifying an EACMS, what requirement would it apply to?

NERC Interprets CIP v5 (and 6)!

I have been saying for close to two years that NERC (or perhaps the regions) needs to come up with an informal “interpretation” of the many ambiguous (or contradictory) areas in the wording of CIP v5. It can’t be an official Interpretation, since that can only be triggered by a Request for Interpretation and that process takes a couple years at least.[i] So NERC can’t produce anything that’s binding, but I have always wanted them – or somebody – to provide some non-binding interpretations of the ambiguous areas in the v5 wording.

NERC has produced some Lessons Learned, but they are deliberately not interpretations of the wording – rather, they provide helpful guidance on how other NERC entities are addressing different CIP v5 challenges. Whenever NERC has tried to take a stand on what particular wording means, this hasn't worked (as was the case with the five Memoranda that they released in April and withdrew in July).

I decided a while ago that NERC would never provide little-“i” interpretations, and therefore it was completely up to the entities to come up with (and document) their interpretation of each of the ambiguous areas in v5 – “programmable”, ERC, “adverse impact on the BES”, etc.

I still believe this is the case. However, I was pleasantly surprised to see that NERC has identified one vehicle by which they can provide some little-“i” interpretations. I’m referring to their “CIP Version 5 Evidence Request User Guide” that was published on December 15, 2015.[ii] Of course, NERC doesn’t tout this document as one that interprets ambiguities in v5; instead, it is meant as a supplement to the RSAWs, which – according to the document – have been described as lacking in detail by “industry representatives”.

The actual Evidence Request is an online tool; the Guide is simply that – a guide to using the tool. However, I find it provides some useful interpretation information, since there is no way anyone could write evidence requests for requirements in v5 that are ambiguously worded, without in the process taking some position on what that wording actually means.

This post tries to “reverse engineer” the questions in the Guide to identify the interpretations that were used to generate them. This is a pretty roundabout way to glean NERC’s interpretations, but – hey, you can’t be choosy when it comes to finding interpretations of CIP version 5! The Guide is divided into sections with short acronyms; my post is divided the same way (although I don’t address all of the sections in the Guide; just the ones where I found something interesting that should be reported).

I do want to say that my main criticism of this document is that it doesn’t address more than maybe 1/10^th of the major interpretation issues in v5. However, at least it does something, and that’s a help. Its biggest achievement is acknowledging for the first time that virtualization needs to be accommodated by the v5 standards, even though it is nowhere mentioned in the standards themselves.

BES Assets

As with almost all presentations on CIP-002-5.1 R1 (that I have seen or read), the first section of the Guide deals with the “big iron” – the assets that house the Cyber Assets in scope for CIP v5. What I say in this section will be more understandable if you reread this post.

1.       The first item in this section is “Asset Type” (page 4). This means the entity should start by identifying its assets in scope for CIP v5, confining their list to assets that meet one of the six types listed in R1. As I said in the above-referenced post, this is how virtually all auditors and entities understand R1 to read; so it should be followed. However, this isn’t how the requirement (or Attachment 1) actually reads.

2.       Two items at the bottom of page 4 read “Contains BES Cyber System – High Impact” and “Contains BES Cyber System – Medium Impact”. As I discussed in footnote ii of the previous post, using this wording rather than “High Impact Asset” and “Medium Impact Asset” fits a little more closely with the wording of R1 and Attachment 1, but less closely with how NERC entities and auditors actually understand the R1 process. Virtually every entity (and every auditor) that I have ever heard present or talked with starts with classifying their assets, not their BCS; it would be better not to pretend this isn’t really what they’re doing, and just refer to High and Medium impact assets – which then lead to High and Medium BCS.[iii]

CA

This is the first official NERC document I’ve seen that recognizes that virtualization is now a big part of many computing environments subject to NERC CIP. The paragraph titled “Cyber Asset Function” on page 7 allows for identifying a Cyber Asset as a “Virtual Host”.

VM

Even more striking than the mention of Virtual Hosts is the fact that there is an entire section on Virtual Machines (VMs). In this section, you identify and provide information on your VMs in a similar (although not identical) manner to how you had to enter your Cyber Assets in the previous section (that section makes clear that only physical devices can be Cyber Assets, which is why VMs have to be handled separately).

The first paragraph of this section (page 9) immediately recognizes an important fact: that there can be multiple hosts capable of running a particular VM. This means that each host should be protected appropriately for all VMs that are capable of running on it (for example, if all the VMs capable of running on a host are Low impact, the host itself only needs to be protected by the Low requirements. But if one High VM could potentially be run on this host, then it has to be treated as a High from the start – not just when that high VM is actually moved to it. This is not stated in the Guide itself, but I believe this is a reasonable inference from it).

BCS

I’ve stated in a couple of posts (here and here) that CIP v5 allows entities to group BES Cyber Assets differently into BES Cyber Systems for different requirements. However, this conclusion just came from the fact that this isn’t actually prohibited in CIP-002-5.1 R1.

Now NERC has provided a positive acknowledgement of this idea in the second paragraph of the BCS section (page 10), which states “If all BES Cyber Systems are used to meet the obligations of all CIP Standards, Requirements, Parts, and Attachment Sections, then the ‘BCS’ tab should be used.” Furthermore, there is another tab - “BCSdetail” - that can be used to enter information on BES Cyber Assets that are included in more than one BCS, depending on the requirement.

CABCS

The first paragraph of this section (page 12) reads “The ‘CABCS’ tab is used to logically group Cyber Assets into one or more BES Cyber Systems, and to associate supporting Cyber Assets with BES Cyber Systems. For each Cyber Asset, specify the BES Cyber System into which it has been logically grouped or with which it is associated. Provide one row for each Cyber Asset/BES Cyber System grouping or association. Indicate the type of the association (‘Member of BCS’ or ‘Associated with BCS’).”

I must admit that I haven’t previously seen the distinction that is being made here, between a Cyber Asset being a “member of a BCS” and being “associated with a BCS”. Of course, the meaning of membership in a BCS is quite straightforward. The definition of BES Cyber Asset includes this sentence: “Each BES Cyber Asset is included in one or more BES Cyber Systems.” That is what “membership” means.

But what does “associated with a BCS” mean? The only meaning I can think of is that EACMS and PACS are “associated with” BCS in the “Applicability” column of some requirements. If that’s the case, this only applies to those two categories of Cyber Asset, not to all BCAs. Yet this question implies that all BES Cyber Assets are either a member of a BCS or associated with one – but that doesn’t make sense either, since EACMS and PACS aren’t necessarily BCAs, meaning they wouldn’t normally even encounter this question in the first place.

This also doesn’t refer to Protected Cyber Assets, since the user has already identified these in the CA section. Did someone get confused by the fact that Section 2 of Attachment 1 describes Medium impact BCS as those “associated with” one of the Medium impact criteria? This of course refers to an association with an asset, not with another BCS.

Since I don’t see this idea recurring anywhere else in the document, I guess it doesn’t do any harm, other than confuse people. If anybody has an idea what it means for a BES Cyber Asset to be “associated with” a BCS, please let me know, and I’ll share it with my devoted readers.

ESP

One of the paragraphs in this section (page 13) reads “Is External Routable Connectivity Permitted into the ESP? This column contains a pull-down list. TRUE should be selected if this ESP contains a Cyber Asset with External Routable Connectivity. Otherwise leave blank.” This alludes to a point that Lew Folkerth of RFC made in an RFC newsletter, which I reported in this post: If ERC is allowed for at least one Cyber Asset within an ESP, all of the other Cyber Assets (whether they be PCAs, BCAs, or just Cyber Assets) will ipso facto also have ERC.

EAP

One finer point that people often forget about (at least I do!) is that an Electronic Access Point isn’t a device like a firewall, but an interface on that device. This section (page 14) makes that point clear, as well as the fact that the device that contains the EAP will always be an EACMS (but the converse isn’t true. Other devices like AD servers can be EACMS even if they don’t contain an EAP).

TCA and TCA Non-RE

There are good sections describing information required for Transient Cyber Assets (page 15) and TCAs that are managed by a third party and thus treated differently in CIP-010-2 R4 (page 16).

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

---

[i] It has previously taken at least two years for NERC (really, an Interpretations Drafting Team) to develop an Interpretation, submit it to a few votes by the NERC ballot body, get NERC Board approval, submit it to FERC for them to ponder for a while, then wait to see whether or not FERC approves it (they rejected the last two Interpretations for CIP v3 in 2012).

EnergySec reported in their Dec. 23 NERC CIP Newsletter that the NERC Standards Committee Process Subcommittee (SCPS, for those keeping score at home) had decided this process needs to be streamlined. That’s the good news. The bad news is that they will take 12 months just to recommend changes; these will of course have to be debated and voted on by the NERC membership, etc. EnergySec also reported that the full Standards Committee has decided that all work on the two RFIs that were accepted in September should be put off until at least next April 1, and that it should be coordinated with the re-drafting of certain standards that the current Standards Drafting Team is starting to undertake now. Bottom line: Don’t look for finalized CIP v5 Interpretations with a capital “I” for years.

[ii] I learned of this document through EnergySec’s NERC CIP Newsletter of Dec. 23. Would you like to get the newsletter? Join EnergySec!

[iii] You may have noticed that I always capitalize High, Medium and Low in the context of classification of assets and BCS, even though the CIP v5 requirements all use lower case; I have had more than one person point out to me that I shouldn’t capitalize common words that aren’t defined in the NERC Glossary. I do this for a reason: I have seen a number of people (including one who presented on the asset identification process at a regional meeting) misunderstand these terms to mean that the entity should simply make their own judgment on whether the asset or BCS has a high, medium or low impact on the BES. While there is some support for this idea in the wording of CIP-002 (the problem is that there is support for a number of contradictory ideas in that standard!), it is definitely not the case that this is a matter of the entity’s judgment. For better or for worse, it is a matter solely of the meaning of the Attachment 1 criteria. Judgment has nothing to do with it, except that the criteria themselves require a fair amount of judgment to interpret. But that’s another post.

A Revised Compliance Schedule for CIPs v5 and v6

January 21, 2016: FERC approved CIP v6 today. However, the effective date of the Order is 65 days after publication in the Federal Registry. This means it needs to be published in the FR by next Wednesday, in order for the dates below to be valid. Otherwise, the effective date will be in Q2, and some (but not all) of the dates below will move back a quarter. In any case, they won't move back any further than that.

February 26, 2016: I have revised this post to reflect the fact that FERC just moved back the compliance date for all the CIP v5 requirements that affect High and Medium impact BES Cyber Systems to July 1. As I explain in this post, none of the other dates are changed by this action.

On November 8, 2014, I published a post listing the incredibly complicated set of compliance events for CIP versions 5 and 6. This was based on the CIP v5 Implementation Plan (which was of course set in stone with FERC’s approval of v5 in 2013) and the v6 Implementation Plan (which was at the time in its final draft form and seemed very likely to be approved by the NERC ballot body, by the NERC Board of Trustees, and finally by FERC).

Until less than two weeks ago, I saw no need to revise this schedule, and I’ve referred to it constantly in my posts as the current compliance schedule for v5 and v6. However, last week I wrote a post pointing out that FERC’s failure to approve CIP v6 in December 2015 meant that the v6 compliance dates would be pushed back by at least three months. Even with that, I didn’t think I needed to do anything more than put a note to this effect on the original post, and keep referring to that post when I needed to reference the compliance timeline.

However, a few days ago Michael Wilson of Tri-State Generation and Transmission wrote in to question a few of the v6 dates I had in the original post. He also pointed me to a WECC webinar in which one or two compliance dates were listed that aren’t even in the v6 Implementation Plan – and therefore weren’t in my original post (I suppose these could be called “implicit effective dates”, just as there are “implicit requirements” in v5 and v6).[i]

At this point, I decided I really needed to rewrite the original post; Michael collaborated with me to make sure this one was complete and accurate. So here is my new compliance schedule for CIPs v5 and v6. Note one big caveat: The dates below are based on the assumption that FERC will approve v6 before April 1, 2016 – meaning the dates in the v6 Implementation Plan will be pushed back three months. If they go beyond that date, some of the dates will be pushed back two quarters, and possibly more depending on when FERC approves v6.[ii]

One note: You may notice that this plan is even more complicated than what was in my original post (mainly because I left out some of the finer points and of course missed the “implicit effective dates”). I wish to emphasize that I’m not making this up; this is what’s in the v6 Implementation Plan. I originally considered the v5 plan to be complicated because it had two dates, one for Highs/Mediums and one for Lows. That plan now seems like the paragon of simplicity compared to the v6 plan, which has separate effective dates not only for individual standards, but for individual requirements, individual requirement parts, and even particular applicability categories within a single requirement part.[iii]

July 1, 2016

This is the date both the v5 and v6 standards become effective. As is shown below, the actual compliance dates for many v6 requirements and requirement parts are later.

CIP-002-5.1, CIP-005-5 and CIP-008-5: Highs and Mediums have to comply with these three standards in full. In addition, Lows have to comply with only CIP-002-5.1 R1 and R2 (i.e. they have to identify their “assets containing Low impact BES Cyber Systems” and have the CIP Senior Manager approve the list).

CIP-003-6 - except for R1.2, R2 and Attachment 1 (Lows): The three items listed are all for Lows, and they have other compliance dates. 

CIP-004-6: Entities must comply with this standard in full. 

CIP-006-6 (except for R1.10, for Control Centers that weren’t Critical Assets with CCAs under v3): R1.10 was ordered by FERC in Order 791, and says that cabling between ESP devices, that itself goes outside a PSP, needs to be physically or logically protected.  This requirement part becomes effective on this date, except that Control Centers that weren’t Critical Assets under v3 are given more time to comply.[v] Once again, folks, I'm not making this stuff up! There's no way I could dream up something so complicated; indeed, I think Rube Goldberg himself would doff his cap in admiration of how complicated the v6 implementation plan is.

CIP-007-6: This standard needs to be complied with in full, but there is an exception for certain devices under R1.2; compliance for these devices is due at a later date.  These devices are “Nonprogrammable communication components located inside both a PSP and an ESP,” which is a new item added to the Applicability section of R1.2 in the v6 version of the standard (this is also the first time NERC CIP requirements have applied to devices that are not Cyber Assets).

CIP-009-6: Entities must comply with this standard in full. 

CIP-010-2 except for R4

CIP-011-2: Entities must comply with this standard in full. 

  

April 1, 2017

CIP-006-6 R1.10: For Control Centers that weren’t Critical Assets (with CCAs) under v3, R1.10 now becomes effective.

CIP-007-6 R1.2 for certain devices: See the discussion of CIP-007-6 above.

CIP-010-2 R4: This is the requirement for transient devices.

CIP-003-6 R1.2, R2 and Attachment 1 – These are the Requirements that apply to Low impact assets in v6. R1.2 – which requires four policies, without specifying their content - is the same as R2 in CIP-003-5 (which is superseded by its v6 counterpart). The new R2 is the one that addresses FERC’s mandate in Order 791 for specific requirements for Lows. There are essentially two parts to this Requirement. First, the Requirement itself calls for a plan to address the four areas in Attachment 1; this plan must be in place on April 1, 2017.

The other part of R2 is contained in Attachment 1, which provides the detail on what is required for those four areas, each in its own section.  However, entities only have to comply with the first and fourth sections of Attachment 1 on April 1, 2017; these are the security awareness policy and incident response plan.  For sections two and three – physical and electronic access controls – entities need to have policies developed (due to R1.2) on April 1, 2017, but the controls themselves don’t have to be implemented until later. 

  

September 1, 2018

On this date, Lows have to implement Sections 2 and 3 of CIP-003-6 Attachment 1.  These sections mandate physical and electronic access controls. 

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

---

[i] I had also made a mistake by stating that FERC’s non-action in December, 2015 meant that all of the v6 compliance dates will be moved back at least three months. The Low impact requirements in v6 will still become effective on the same dates as previously - April 1, 2017 or Sept. 1, 2018.

[ii] My original post started with the following four caveats. These still apply:

1)       The v5 plan included dates for “Initial Performance of Certain Periodic Requirements”; these are the dates by which you need to perform each of the annual (i.e. 15-month) or quarterly requirements.  Since these are in the v5 Implementation Plan, they refer just to the v5 standards; however, the v6 Implementation Plan simply refers to the v5 plan for the Initial Performance dates [I’m not linking the final version of this plan because it’s buried in the 3300-page filing for v6. If you would like me to send you the copy I’m working with – the draft prepared for the final NERC ballot (although it refers to v7 as well as v6 - long story) - email me at talrich@deloitte.com.].  This means that, to determine these dates for the v6 plan, you have to go back to the v5 plan and fill in the appropriate v5 or v6 standard numbers (e.g. CIP-002-5.1, CIP-003-6, etc.).

2)       In the v5 plan, there’s a table for “Planned or Unplanned Changes Resulting in a Higher Categorization”; this refers mainly to new assets that are acquired or commissioned.  Again, the v6 plan simply refers you back to the v5 plan for this.  There was a similar provision for versions 2 and 3, contained in a separate document whose acronym was “IPFNICCANRE”. However, that document is no longer valid once v5 comes into effect in April.

3)       The v6 plan includes a section (consisting of a single sentence) providing for “Unplanned Changes Resulting in Low Impact Categorization”.  This is a new concept in CIP v6; it didn’t appear at all in the v5 plan, perhaps because complying for new Low impact assets wasn’t a big deal under v5 given what was required (or not required) by CIP-003-5 R2.

4)       Of course, the implementation schedules for Canada are different than for the US.  Those vary by province and not all the provinces are implementing v5 (at least not yet).  Even the ones implementing it may be implementing slightly different versions (since the FERC-approved standards have no force in Canada, each province is free to modify any NERC standards as they see fit, or not implement them at all) – except for probably Ontario, New Brunswick and perhaps Nova Scotia, which tend to follow the FERC-approved standards almost to the letter.

[iii] There’s also a separate date based on whether the facility had Critical Cyber Assets under CIP v3 – which of course isn’t in any way related to the v5 or v6 standards themselves. I’m surprised there aren’t also separate dates that depend on whether the person implementing v5 compliance is left- or right-handed - although I should be careful what I say, for fear the v7 implementation plan may contain such a provision!

[iv] This exception isn’t in the v6 implementation plan, but was pointed out by WECC in a recent webinar; Michael called my attention to this.

[v] Note I got this wrong in my original post. I thought that R1.10 compliance was postponed for everybody, but Michael pointed out it is just for these specific Control Centers.

Will CIP v5 Enforcement Be Postponed?

It has come to my attention that some NERC entities are asking whether the enforcement date for CIP v5 will be postponed beyond April 1, 2016. I have gone back over certain posts over the past year, and see that I have gone through four different stages on this issue. Since I think a discussion of these will shed light on what may happen in the future regarding CIP v5, I want to outline them.

1)      I first advocated for pushing back the compliance date in December, 2014. I always realized it would take an extraordinary amount of commitment by NERC and FERC for this to happen (I believe NERC would have to petition FERC, and they would have to approve the petition). But I felt – and still feel – that this is the right way to deal with the problem caused by the large amount of uncertainty[i] felt my many NERC entities regarding interpretation of the CIP v5 standards.

2)      This past July, I wrote another post advocating that the “Compliant” date for CIP v5 remain 4/1/16, but that an “Auditably Compliant” date be set for one year later – meaning no Potential Violations (PVs) would be issued until that date, assuming the entity was making a good faith effort to comply. This suggestion was also met with thunderous silence (although I acknowledged this would also take a huge amount of commitment by NERC, FERC and the NERC community, so it was always quite a long shot).

3)      I officially threw in the towel on the idea of the compliance date being officially pushed back in this post at the end of August, 2015. That was when I started talking about the “effective compliance date” – that is, the date (or rather dates) that the regions would feel comfortable enough with the interpretation of the v5 standards to start issuing PVs[ii]. While I was prepared to have this be a completely unofficial process (i.e., each auditor would decide for him/herself when they could start issuing PVs), I did say it would be much better if there were some sort of informal agreement among NERC, the Regions and the NERC entities to the effect that PVs wouldn’t be issued until after X date. The other provision of this agreement would be that all parties would make a concerted effort to clarify the biggest issues with CIP V5, like the meaning of “programmable”, ERC, etc. This clarification wouldn’t constitute anything binding [like an actual Request for Interpretation would, or a Standards Authorization Request (SAR) – both of which will take years to bear fruit], but it would at least provide a common framework for entities to finalize their compliance with v5, and for the Regions to start auditing and issuing PVs six months or a year after 4/1/16.

4)      My most recent post on this question was in October, 2015, when I threw in the towel on the idea that there was any way the effective enforcement date for any of the CIP v5 standards would be earlier than October 1, 2016, and very possibly much later. I brought up something (in my footnote v) that I’d said early in 2015, to the effect that the standards couldn’t be effectively enforced until a year after enough guidance had been provided so that reasonable “interpretations” were available - from NERC and/or the regions – on all of the major issues in CIP v5; since I wrote this post in October, I was implicitly saying it was already too late for v5 to be effectively enforceable even on 10/1/16. Moreover, this also implied that only if NERC started an aggressive drive to clear up the ambiguities and contradictions in CIP v5 immediately would there be any real possibility that the standards might effectively be enforceable on even 4/1/17.[iii]

I don’t think it will surprise you greatly when I say I see no sign that NERC is making any sort of effort – aggressive or otherwise – to clarify the many interpretation issues that remain in CIP v5. In fact, in a NERC webinar on Friday, December 4, 2015, Tobias Whitney said that the only Lesson Learned still planned is on patch management (he also stated this in a presentation at the NERC CIPC meeting in Atlanta on December 15). He also stated that some issues, including virtualization, External Routable Connectivity and Interactive Remote Access, will probably go into the SAR process – meaning it will be literally years before these are addressed. Thus, I have to now say it’s very possible there will be no meaningful clarification on most of the major issues in CIP v5 until one or more standards are rewritten and approved by the NERC ballot body and FERC. I don’t believe this process will take anything less than three years, and possibly longer than that.[iv]

So now we come back to my one-year rule. If, as I believe, the standards will not effectively be enforceable until a year after fairly definitive guidance on major issues has been provided to the NERC community, and if it doesn’t look like there will be any major guidance until some standards or requirements (and a few definitions) are rewritten, this means CIP v5 (and v6) will not be enforceable for at least several years, right?

To be honest, I don’t think v5 will go several years without being enforceable, even if there is no more guidance provided. I think that, after maybe a year of audits where mainly Areas of Concern (not PVs) are issued, both the auditors and the entities may have developed a pretty good understanding of what the v5 standards mean, even if this understanding is never codified in any document put out by NERC or the Regions. 

Let me summarize what I’m saying:

I’m definitely not saying that PVs won’t be issued soon after 4/1/16 to entities that for whatever reason haven’t made a real effort to comply with parts of CIP v5. For example, I realize there are a lot of questions on how to identify and classify BES Cyber Systems, but there are many cases where it should be pretty obvious that something is a Medium or High BCS – let’s say a relay controlling a 500kV line or the EMS in a High control center. If an entity doesn’t make such a designation, they might be the recipient of a PV. Another example: If an entity has decided they’re not going to comply with say CIP-007-6 R2 (patch management) for some of the BCS they’ve identified, I’d say they are likely to get a PV or two for that. Or if an entity has decided that a substation that clearly has 3,000 points under Criterion 2.5 isn’t in fact Medium impact, they will also have a lot of explaining to do, even if it’s on April 2, 2016.

On the other hand, if an entity has interpreted the phrase “External Routable Connectivity” in such a way that the relays in a particular substation – connected serially to an RTU that then connects routably to the control center – do not have ERC, and if an auditor doesn’t agree with them on this when they’re audited in say November 2016, I don’t believe the auditor will issue them a PV because his opinion on this very contentious issue isn’t the same as theirs. He/she will probably call this an Area of Concern, but until the auditor feels there is a consensus across the NERC community on what exactly constitutes and doesn’t constitute ERC, they won't issue a PV. I’m guessing (maybe “hoping” is a better word) that around 4/1/17 there will be consensus on ERC and other major issues. So if that same entity gets audited say in June, 2017 and the same discrepancy is found, it’s very possible they would receive one or more PVs for this.[v]

So let’s say you know of a few entities – and I’m sure you’re not one of them (wink, wink) – that will still be deficient in CIP v5 compliance on April 1, 2016, despite their best efforts over the past couple of years. What happens to those entities? Are they just off the hook, in the same way as the entity who is almost completely compliant (I don’t think any entities will be 100% compliant, since nobody knows now what that term even means, given the remaining uncertainties)?

Definitely not. They’ll still need to self-report every requirement – that they know of – for which they’re non-compliant. On the other hand, I can’t believe they would need to self-report that they had used the wrong definition of “programmable”, since there is no agreed-upon definition (they do need to document the definition they used, show how they derived it, and show that it was consistently applied across all of their assets. See this and subsequent posts for discussion of my “roll your own” approach). And these entities obviously need to continue their work to come into compliance as soon as possible after 4/1/16.

There was one significant development after my October post on enforceability: the news that FERC will start doing some CIP v5 audits themselves next year. What does this mean for the above discussion? Specifically, will FERC be able to effectively make the v5 standards enforceable before 4/1/17 (since I’m guessing this will be the effective date if just NERC and the Regions are doing audits)? I don’t think so, unless FERC makes an effort to provide guidance on the many profound interpretation issues in v5. Without guidance, how could an auditor – NERC, FERC, or Regional - possibly assess a violation when there is a simple difference of opinion on an ambiguous requirement or definition? In other words, I don’t think the fact that FERC has entered the auditing picture makes any difference for when CIP v5 will be enforceable.

                                                                     

Before I go, I want to make one further point: This post has discussed one meaning of the word “enforceable” when applied to NERC standards – that is, “enforceable” in the sense that auditors will write PVs and entities will generally accept them. My conclusion was that CIP v5 will be enforceable in that sense around 4/1/17. But there is a stronger meaning of the word, namely that a violation and fine are likely to be upheld if appealed to the court system (which is always a recourse for any NERC entity that feels it has been unfairly penalized). Will CIP v5 ever be enforceable in this sense? I will soon have a post out on this question.

P.S.  A well-known auditor for one of the NERC Regional Entities wishes to add the comment below. It doesn’t contradict what I said above, but it does provide a better idea of what a “good faith effort to comply” would entail. One thing he mentions, that I have mentioned in other posts but not in this one, is that the entity needs to show that, in cases where a requirement is ambiguous, they considered all available guidance from NERC and their region; and if they decided they didn’t think the guidance was appropriate, they will need to document why.

The auditor says, “CIP V5 audits will begin in early April.  As far as any guidance to the Regional auditors regarding how to handle vague requirements (such as application of auditor discretion), I will yield to NERC to publicly publish whatever guidance they may have or will provide to the auditors.

“What I will say is that the entity will have to tell a compelling story at audit.  My team, at least, will not go into an audit with a pre-determined expectation of what represents compliance unless there is an explicit expectation stated in the requirement.  But the entity will not be able to simply lay a document before us and declare it meets compliance, expecting the auditor to accept the document at face value.  We are all aware of the discussions within the V5TAG, the issues being brought to the Standards Drafting Team, and the guidance issued by NERC (Lessons Learned, FAQs, etc.) and will certainly consider that background information when evaluating an entity’s compliance.  What my team and I will never do is “guarantee” that we will treat something as an Area of Concern as opposed to something else like a possible violation.  Our determination of a finding must be based upon the facts and circumstances presented at the time of the compliance monitoring activity.  What we will do, up through the end of March, is provide our entities as much outreach as we can, including answering questions and conducting site visits.  After April 1, we will still conduct extensive outreach for Low Impact BCS.  It is up to the entity to take advantage of our outreach, which we have not been bashful about encouraging every opportunity we have.”

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

---

[i] A recent Bridge Energy Group Utility Industry Survey found that 68 percent of utilities believe their organization is “not well prepared” for CIP v5 compliance. And a WECC survey of their members, discussed by Dr. Joe Baugh of WECC at the NERC CIPC meeting in Atlanta on December 15, showed that confusion over the meaning of the standards was the number one CIP v5 compliance problem (by a large margin) cited by respondents.

[ii] This applies to cases where the violation is caused by a genuine difference of opinion between the auditor and the entity over something that is unclear or undefined in CIP v5, such as the definition of “programmable”.

[iii] The reasoning for this is that an aggressive effort of interpretation of issues like ERC, “programmable” and the meaning of the BCA definition would require a lot of meetings with the industry and the regions, and would take at a minimum six months.

[iv] You may point out that, besides the SAR process, there is the Request for Interpretation process, which can also provide definitive guidance. The RFI process is shorter. I think the few successful RFI’s for CIP v3 took around two years to come into effect, including development of the Interpretation by the Interpretations Drafting Team, voting on it by the NERC membership, submittal to FERC, and FERC’s ultimate approval (although FERC remanded the last two v3 RFIs that were submitted to it). However, RFIs by definition have to focus just on an interpretation of a narrow bit of wording in one requirement. They don’t address issues like missing definitions or anything that requires rewriting a requirement. The big issues in v5 are all not addressable through RFIs.

[v] As I’ve already said, Tobias Whitney of NERC has listed several areas of ambiguity, including ERC, that will be the subject of Standards Authorization Requests (SARs); in other words, NERC has decided the only way these can be addressed is by rewriting one or more requirements (in the case of ERC, this would require rewriting the definition to clarify when there is ERC, and when not, when there are both routable and serial communications in a particular communications stream). I asked him whether PVs would be issued for these areas, pending this rewriting. While he definitely didn’t rule that out (and I’m sure there could be instances where it is clear that the entity has deliberately misinterpreted ERC, in which case there would be PVs), he did say that the main emphasis would be on designating Areas of Concern.

FERC Doesn’t do Something! Here’s the Full Story…

In one of the most famous Sherlock Holmes stories, the sleuth solves the mystery of a suspicious death by keying on the fact that a dog didn’t bark when an intruder supposedly entered a home to commit a crime. The fact that it didn’t bark meant a member of the household was the criminal. In the same way, the fact that FERC didn’t do something on December 10, 2015, that they were expected to do, has almost as much importance as if they had taken an affirmative action.

Those keeping score at home know that FERC still hasn’t approved CIP version 6. CIP v6 was submitted to them by NERC last February[i], and FERC issued a Notice of Proposed Rulemaking (NOPR) in July, indicating they intended to approve it. Even the fact that they issued a NOPR rather than an order approving v6 surprised many in the industry, including me, as I noted at the time.

The NOPR asked for comments on several issues, which you can read about in the post I just linked and in its sequel, Part II. The comments were about a few areas that FERC might like to have NERC improve, such as developing a transient electronic device requirement for Low impact assets. As always when FERC solicit comments, there was a cutoff date for receiving them – in this case late September.

When NERC submitted v6 they also submitted an implementation plan[ii], as they always do with new or revised standards. The plan had specific dates for different parts of v6 (in fact, it had a plethora of dates. See this post for the complete set of v5 and v6 implementation dates, although also read the note I just put on that post). However, each effective date listed in the plan is followed by the words “or the first day of the first calendar quarter that is three calendar months after the date that the standard is approved by an applicable governmental authority.”

In the US, the “applicable governmental authority” is of course FERC. Since a number of the v6 standards come due on April 1, 2016 (at which point they’ll replace their v5 counterparts), and since the dates for other standards or requirements (or in some cases, requirement parts!) are all based on the 4/1/16 date, this means that if FERC doesn’t approve v6 this month, literally all of the dates in the v6 compliance plan will move back one quarter – although that assumes that FERC will approve v6 by March, 2016. If they don’t do that, all the dates go back another quarter. And if they still don’t approve v6 by June 2016, the date goes back yet another quarter…etc.

So what’s the dog that didn’t bark in this case? If FERC were going to approve v6 this month, they would have to do so at their monthly “Sunshine Meeting” (don’t you just love that term? Only in Washington could they think up something like that) on December 17. But for them to even take up v6, it would have to be on the meeting agenda. The agenda was released on December 10 and guess what? V6 wasn’t on it. Therefore, v6 won’t be approved in Q4 2015.

This means the compliance dates for all of the v6 standards are now officially pushed back at least three months.[iii] Assuming FERC approves v6 before April 2016, here are the new dates for some of the more important standards/requirements:

• The date for CIP-010-2 R4 – for Transient Electronic Devices – will move from 1/1/17 to 4/1/17.
• The due date for the security awareness policy and the incident response plan required for Low impact assets by CIP-003-6 R2 will move from 4/1/17 to 7/1/17.
• However, the due date for the four policies for Low impact assets mandated in CIP-003-6 R1.2, will not move. This is because CIP-003-6 R1.2 is identical to CIP-003-5 R2 – which was always scheduled to come into effect on 4/1/17. The latter requirement would have been superseded by CIP-003-6 R1.2 had v6 gone into effect on that date. Now, it won’t be superseded until v6 does actually come into effect. But since the two requirements are identical, the four policies will still be due on 4/1/17.
• The last compliance date in the v6 Implementation Plan is September 1, 2018, when the physical and electronic access controls for Low impact assets, mandated by CIP-003-6 R2, come due. This date will also be moved back, but by four months rather than three. Why four, you ask? Well, it’s pretty simple: As Scott Mix of NERC admitted at a recent NERC meeting, the CIP v5 Revisions Standards Drafting Team made a mistake when they assigned the 9/1/18 date. They seem to have forgotten that the first day of the fourth quarter is October 1, not September 1. Since the Implementation Plan doesn’t say “three months after…(FERC approval)”, but rather the language in the fourth paragraph above, this means this date will move to January 1, 2019. Now you know.

The discussion so far has been all mechanics. How about the human element? First, why is FERC taking this action – or more correctly, not taking this action? The only explanation I can think of (and I want to thank a longtime FERC observer for sharing her thoughts on this with me) is that the FERC staff is finding it more difficult than they originally thought to make a decision on the questions for which they solicited comments.

When the NOPR came out, I noted in this post that the amount of time between the due date for comments (near the end of September 2015), and the date FERC had to issue their order in time not to force the v6 compliance dates to move back, was pretty short – less than three months. However, since I and most others believed FERC didn’t want the v6 dates moved back, it seemed logical to assume they were sure they could complete their considerations in time to be able to approve v6 in December.

However, it seems somebody miscalculated at FERC – or perhaps they were surprised by the volume of comments and perhaps the level of opposition expressed – and they have decided they simply need more time in approving v6.[iv]

You might wonder – given that I’ve said various times that I see no possibility FERC will simply reject v6 (and I certainly still believe that) – why approving v6 should require so much consideration. However, FERC’s hesitation isn’t over the question of whether or not to approve v6. It is actually due to the changes they may order – i.e. the different questions they asked for comments on in the NOPR.

Remember that NERC’s rules say a standard can’t be changed once it has been approved by the NERC Board of Trustees; this step is taken before the standard is even submitted to FERC. So when FERC orders changes to v6 at the same time that it approves the standards, these changes won’t appear in the v6 standards. Instead, whatever changes FERC decides it wants will have to be part of new standards – in other words, CIP v7. Once FERC enters its Order approving v6 and (perhaps) ordering some changes, NERC will need to constitute a drafting team (it could consist of the members of the CIP v5 Revisions SDT that drafted v6, but it might also be a new team), then have them go through a drafting and balloting process similar to what happened with v6 (since v6 was developed because of four changes FERC ordered when they approved v5 in 2013). In other words, v6 will almost certainly go into effect sometime in 2016 or early 2017, followed by v7 about two years later.

In my post in which I raised the possibility that FERC wouldn’t approve CIP v6 in time for the compliance schedule to remain on its original timeline, I went further than that. I also speculated that FERC might actually want to see the v6 compliance dates moved back. The reason for this is that it shouldn’t be hard for FERC staff members to see that the CIP v5 standards won’t be “enforceable” on 4/1/16 – in the sense that they’ll be well enough understood in the NERC community that auditors will feel comfortable writing Potential Violations for requirements about which serious interpretation issues exist (unfortunately, this applies to a lot of requirements in v5). And if they haven’t discovered this on their own, they’ve seen it in my blog posts, including this one. I wondered in the post – and I still wonder – whether FERC thinks they might be able to help the v5 “enforceability” problem by delaying the implementation of v6.

But how would FERC’s delaying the v6 implementation date (by not approving v6 until say May or June 2016) help with the “enforceability” problem with CIP v5? After all, CIP v5 will come into effect on 4/1/16 no matter what happens with v6[v]. Let’s be clear: I don’t think v5 will be any more or less enforceable because of the v6 delay. However, I do think that, if FERC delays v6 approval until say next May or June (and thus delays v6 implementation by six months), NERC may decide they want to announce that v5 enforcement will be delayed by the same amount of time.

Of course, this would amount to making a virtue of necessity, since as I’ve already said I don’t think v6 will be effectively enforceable before 10/1/17 at the earliest – and one of my next posts will state that I don’t believe v5 will be effectively enforceable until approximately 4/1/17. But if NERC were to actually state this, it would remove a lot of uncertainty – since I believe there are still a few people in the NERC community that don’t take everything I say in my posts to be the gospel truth.

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

---

[i] In fact, it was Friday, February 13. I believe this explains a lot.

[ii] You may notice the plan linked has a “-7” after some standards, and a “-3” after CIP-010 and -011. This is because when the “CIP Version 5 Revisions” were finally passed by the NERC ballot body it included some v6 and some v7 standards. However, to somewhat mitigate the version confusion, the standards actually approved by the NERC Board of Trustees all had version 6 suffixes (“-6” and “-2”). This is discussed in the first post linked above. I swear I’m not making this stuff up. I could never dream of creating anything as complicated as the “CIP v5/then v6/then v7/then v6 again” saga – except perhaps the “CIP v4/no, v5/no, v4/no, v5” saga.

[iii] In this discussion, I’m assuming that FERC, when they finally approve v6, won’t also order NERC to revise the implementation plan so compliance would still be due on the original schedule. While I’m sure that’s theoretically possible, I don’t think it’s likely they’d do that.

[iv] A couple people wondered if FERC might be delaying approval of v6 specifically because of the supply chain security issue that they asked for comments on in the NOPR. FERC has now scheduled a Technical Meeting on January 28, 2016, and it is quite understandable they wouldn’t want to make a decision on this topic until after that meeting. However, just because FERC asked for comments on this issue in the v6 NOPR doesn’t mean they need to do something one way or the other on it when they approve v6. They could issue a separate order once they have finished their considerations on this topic (and that would make a lot of sense, since supply chain security is a completely new direction for the CIP standards, like CIP-014 was).

[v] You may wonder what happens with the “Identify, Assess and Correct” language in 17 of the CIP v5 requirements, which will be removed in their v6 counterparts. If all of v5 ends up coming into effect on 4/1/16 (rather than three v5 standards and seven v6 ones, which would have happened had FERC approved v6 in December), that language will supposedly be enforceable. Yet I believe literally all NERC entities are implementing v5 compliance under the assumption that they won’t have to comply with that language. They are safe in continuing on this course, since I believe all of the NERC Regions have formally or informally announced that “IAC” won’t be enforced regardless of what happens with v6, and perhaps NERC has stated this as well. If you haven’t seen or heard an announcement from your Region, just call them.