Saturday, December 14, 2013

Dialog from EnergySec LinkedIn Group

Following are some of the posts from an interesting discussion about CIP Version 5 that occurred this week on EnergySec's LinkedIn group, in response to my post about Order 791.  I haven’t quoted every contribution to the discussion, since some of the posts were duplicative or weren’t essential to the discussion thread (they were all good, though). The main topic was whether an inventory is needed for Low impact cyber assets, although we get into some asset identification questions toward the end.

By the way, if you’re not participating in the LinkedIn groups related to NERC CIP compliance (as well as other topics like SCADA security and Smart Grid security), you’re missing a good source of information.  I won’t say all discussions are consistently good, but some of them are excellent (such as this one).  EnergySec’s group has some especially good discussions.

(I started the discussion by announcing my post on Order 791)

Stacy Bresler, EnergySec
You state "They state clearly on page 65 of the Order that they don’t think it would be a good idea to require an inventory for the Lows."

I'm not sure I read that the same way as you do. I understand that FERC isn't agreeing that a requirement be made to develop a list for Low Impact BES Cyber Assets; however, they do say " entity must have the ability to identify the nature and location of all Low Impact assets that it owns or controls for audit and compliance purposes." That certainly sounds like an inventory to me - not a list mind you - but an inventory ;-) I suppose that could come in the form of a list or be contained in a database or an asset management system. In the end, the compliance evidence that will be requested is most likely going to be "a list" of sorts.

Thanks, Stacy. I agree that you could interpret FERC's words as you say, although I think a better interpretation is that by "assets" they mean the "big iron" - substations, control centers, etc. An entity definitely needs a list of those. 

However, it doesn't matter how we interpret that statement. The compliance evidence that will be required of NERC entities subject to CIP V5 can only come from the requirements themselves, not from a statement FERC makes in their Order. They didn't order NERC to write a requirement for an inventory of Lows, nor did they ask that it remove the two instances where CIP-005's wording says that an inventory isn't required. I don't see any way that an entity can be required to have an inventory/list/whatever of Low impact cyber assets.

The Responsible Entity (RE) is not currently required by the CIP standards to present a completed spreadsheet to the auditors that details a personnel timeline regarding completed training dates, PRA dates, PRA contents,authorized cyber access and authorized unescorted cyber access. However, they do so because that is what the auditors need to see in order to substantiate compliance with CIP-004-3a requirements (see ReliabilityFirst's Attachment C-CIP spreadsheet here - ).

The compliance evidence shall end up being what is needed to demonstrate compliance under the current performance based audit approach. The CIP requirements do not detail all the evidence that must be brought to bear...we must all be aware of that fact. When it comes to evidencing the facts about Low Impact BES Cyber Systems I can see no other way for an auditor to review that requirement without seeing an inventory of the assets that make up that category of systems (assuming the RE has Low Impact Cyber Systems).

To me this is no different than counting the coins in your piggybank. You certainly wouldn't say you know the exact amount of money you have saved if you didn't count the nickels and pennies in your calculations. How can an auditor or an RE determine if they have everything accounted for (i.e. low impact policies applied) if they haven't counted (inventoried) the Low Impact BES Cyber Assets?

Stacy, when you say "evidencing the facts about Low Impact BCS", what requirement in CIP Version 5 are you referring to? The only requirement that currently references Lows in CIP-003-5 R2, and I don't see how that would require an inventory - especially since it explicitly says it doesn't. 

Of course, FERC has ordered that there be more specific requirements for Lows. It's possible (but not likely) the SDT will draft requirements that do lead to a need for an inventory, but that isn't what we're talking about here.

I understand that CIP-002-5.1 R1.3 states that there is not a requirement for a discrete list of Low Impact BCS' but that doesn't negate the fact that an auditor is going to need a list of the Low Impact BES Cyber Assets in order to audit the requirement. How can an auditor know for sure that the Responsible Entity has properly categorized it's High, Medium and/or Low Impact BES Cyber Systems without seeing a list of what they all are? And for CIP-003-5 R2, how is it that an auditor is going to be able to determine if the drafted cyber security policies have been applied to Low Impact BES Cyber Assets (systems) if there isn't an inventory to review? I know CIP-003-5 R2 doesn't use the term "implemented" but it is a long standing principle that an entities CIP-related policies, plans, procedures, processes, etc must be followed as written. These are performance audits and the best way for an auditor to determine performance is to sample a set of assets. Without an inventory, how would they create a sample set? (yes...control-based audits is the apparent goal but we do not yet have a control-based mandate. a control-based audit there is going to be a performance "test" applied to validate the control).

We also can't dismiss the fact that there are likely to be modifications to the low impact requirements in the assumed Version 6. One has to imagine that by increasing scope based on FERCs suggestions would require an inventory of sorts to carry this out. Given that there is a possibility for some attribute assignments to be placed on low impact BES systems then I would suggest that utilities start creating a list of their Low Impact BES Assets ASAP.

Putting the CIP requirements aside for a moment, I can't fathom how one can state they are managing something if they don't know what it is they are managing (or can't produce a "list" of what it is they are managing). An asset inventory is basic technology management 101. I'm sure it isn't easy to do as a retrofit but still...don't most TO/TOPs have a very robust inventory of all their poles and wires? In Corporate America there are companies with hundreds of thousands of employees and they have personnel records of each employee with many, many specific attributes. I'm ranting a little of course but to make the point - if the electric sector is the most critical of all critical infrastructures should we not expect that the cyber assets participating in those infrastructures (high, medium and lows) be inventoried?

Chris Humphreys, The Anfield Group
You both bring up valid points. This lack of clarity with the Lows is just one example of exactly why, from an audit perspective, Version 5 is going to be even more subjective than Version 3. Without a list (i.e inventory) what other mechanism can an entity utilize to demonstrate that they've 1. accounted for the Lows and 2. Low, Medium, and High classifications are accurate? I think, once again, the audit approach for Ver 5 wasn't effectively considered by the SDT throughout the development of the standards.

Steve Parker, EnergySec
In version 5, many of the documentation requirements were removed, not because the SDT felt documentation was not needed or required, rather, because they felt the need for documentation was implicit in the need to provide evidence of compliance. So, documentation is necessary to show compliance, but is not a requirement in and of itself. 

I think we're going to see a similar situation with asset inventories. It will be difficult to demonstrate compliance without also demonstrating a knowledge of the assets that are in-scope. This is likely to take the form of a discrete inventory list, although perhaps an entity may get away with simply describing the kinds of assets they have in some circumstances. For example, if they have a standard substation design, they might reference the standard firewall/router/IDS/log server/etc at each location without having the exact serial numbers or device names. I would not advocate that, but it is a plausible position. 

What is more interesting to me is FERC's order to develop objective criteria by which the effectiveness of controls for low-impact assets can be assessed. That clearly shows that FERC believes audits should examine the IMPLEMENTATION of policies, something that has really not been audited yet with the current versions. That could greatly increase the scope of audits as well as the documentation and evidence burden for low-impact assets. It will be interesting to watch this play out.

Michael Toecker, Digital Bond
I'm coming down on Steve's side, with the addition of technical requirements there is an implicit requirement to have an inventory of your BES Cyber System and likely the cyber assets that make up the BES cyber system. And honestly, this is just a good practice anyway.

I had this conversation back when I worked for an entity, basically any technical requirements (firewalls, AV, etc) requires that an entity know what is being protected. An inventory was necessary before even starting the project. Otherwise, how would you assign cost for a project to secure it? I think the accountants would have a problem with buying 200 licenses of $vendorproduct without a clear knowledge of where it was going and what it was protecting. And, how could you demonstrate to an auditor that you were covering your assets without an inventory? I'm with Steve.

What makes the lack of a requirement beneficial (well, for an entity) is that minor inaccuracies, mistakes, good-faith omissions, etc might not be punishable by fines because the existence of a list is not a requirement. Considering all the time spent slaving over a spreadsheet from a plant 2000 miles away to make it as error free as possible rather than spending extra effort on actual cyber security, this is probably a good thing.

In conclusion as a LOW asset, maybe the federal government and NERC can't say you HAVE TO have a list. But if you want to do efficient CIP compliance, you'll have one, it will be accurate, and you'll be pulling it out in any future audit to demonstrate you know what you're doing.

Thanks Stacey, Chris and Steve. I agree this is a good discussion. My $.02:

First, where were you guys when I needed you? I had a couple fairly heated arguments with the SDT in 2011, trying to dissuade them from putting that notice about an inventory of Lows not being required in the standards. To no avail, of course (you can read the details in footnote 2 of this post: ).

However, in the SDT’s defense, they were between a rock and a hard place. The first draft of Version 5 was resoundingly rejected by the ballot body, in large part because it had one requirement for Lows (for changing vendor passwords) that couldn’t be audited without an inventory. They knew they wouldn’t get a positive vote on the third ballot (which was their last chance) with a clear requirement for an inventory in there.

They all agreed with me that:
  1. It is good practice to have an inventory, and
  2. FERC might later order specific requirements that would require an inventory.
I believe they were really saying to FERC, “Please save us from ourselves. We know an inventory of Lows is a good idea, but you are going to have to order NERC to include it – we are powerless to do this on our own.” Perhaps not the most far-seeing stance they could have taken, but that is sometimes how things work in democracies (see the current US Congress for more on the subject of extreme near-sightedness).

So I think you guys are vastly underestimating the resistance there will be if the SDT comes up with requirements for Lows that require an inventory for auditing. It will be quite ugly. I suggest you all come to the new SDT meetings (as I plan to, at least a few of them) to argue your case. I will point out that a positive vote isn’t so important in this new case, since the NERC BoT will approve the new standards regardless of whether the membership does or not – they have to, since this is a FERC order.

Chris, the SDT did address auditing of the standards. In fact, they had one meeting in 2011 where they invited auditors from all the regions to discuss auditing V5.

Stacey, I agree with you totally that some of the wording in CIP-002-5 can be read as requiring a list. Other wording can be read as not requiring it (and I’m not talking just about the specific statement that an inventory isn’t required). This is one of a number of examples of what I’ve been calling the Wars of Religion in CIP-002-5. I think there are at least 5 other areas (like the BES Reliability Operating Services) where rational people could draw two completely opposite conclusions from the wording of CIP-002-5 (I hope to do a post soon to summarize all of them in one place, rather than being scattered through a bunch of posts).

I don’t believe there is any other way to fix these multiple problems in CIP-002-5, other than to rewrite that standard (although the first step would be for someone to figure out what the standard wants to be when it grows up. The reason it’s so ambiguous is there were differing views of the asset identification process on the SDT, and no adult able to force a consensus on one of these views). I was very disappointed when FERC didn’t require that in Order 791, but I’m hoping NERC will decide it needs to be done anyway. I simply don’t believe CIP-002-5 can be consistently followed or audited with the current wording; not a good recipe for success, for a standard with fines of $1 million a day.

Stacey and Steve, I definitely don’t think audits of CIP-003-5 R2 would require entities to have an inventory of Lows. And I also don’t think FERC really wants NERC to develop Low requirements that end up needing an inventory. Two of the three options they gave NERC really won’t require an inventory. I find it hard to believe the SDT won’t choose one of those options. But as I said, attend the new SDT meetings!

Dennis Steffani, Silicon Valley Power
I have a very simple question that goes beyond (or below) LOW evaluated assets; Is it possible to evaluate your Bulk Electric Assets and come to the conclusion there is NO impact, in essence entering a 4th possible rating outcome to which there is no reference for keeping any information. Or is it that if you have Bulk Electric System assets (greater than 100kV) if you are not HIGH or MEDIUM, then you are by default LOW, ie: there is never a NO impact rating for BES assets?

Steve Parker
The latter. Sort of. This is a bit of a trick question. The bright line criteria do not contain the concept of "no impact", every applicable BES facility will be either high, medium, or low. Where it gets tricky is in the definition of BES Cyber Assets and Systems. The bright line criteria are used to determine the impact rating of BES Cyber Systems, which by definition are groupings of BES Cyber Assets, which by definition are capable of having an impact.

So, it is possible that some Cyber Assets may have no impact, but at that point they would not meet the definition of BES Cyber Asset, and therefore would never make it to the bright line criteria evaluation stage.

Dennis, this is one of the few things that I think is fairly straightforward in CIP-002-5:

1. If your entity has one or more NERC functional designations listed in Section 4.1 of CIP-002-5; and
2. If your entity has BES Facilities as described in Section 4.2 (and in practice this means if your entity has any Facilities that fall within the BES definition. Of course, since that's changing, I think you'll need to base this on your guess as to what the BES definition will be on April 1, 2016, but I may be wrong on this); then
3. Each of those Facilities will be at least a Low impact. So there isn't such a thing as a No Impact rating for BES Facilities.

Now, when you get to BES Cyber Assets, there are folks that believe there can be No Impact BCA's (and therefore BCS's) at BES Facilities - so the Facility could be Low, Medium or High, and the cyber asset could be no impact.

An example of this is Criterion 2.1 of Attachment 1, which says that BES Cyber Systems at a 1500MW+ generating station (which is Medium impact), that don't themselves control 1500MW, aren't Medium impact. So what are they? I believe they're Low impact, but I know perfectly rational people who, while perfectly sober, say these BCS aren't even Low - they're just out of scope.

That's the nice thing about CIP-002-5. You can make almost any interpretation you want and find a way to justify it with the wording of the standard [Irony Alert].

While I was writing this, Steve's comment appeared. I agree with him that the wording of Attachment 1 makes it sound like you're classifying BES Cyber Systems there. However, if you look at requirement parts R1.1, R1.2 and R1.3 - which direct the entity to Attachment 1 in the first place - they seem to make it clear that you are going there to classify BES assets (i.e. Facilities), not BES Cyber Systems. So it seems the BCS should really simply take the rating of the Facility - and in my opinion this is what the SDT intended.

Again, this is a question that rational people can disagree on, given the current wording of CIP-002-5. I strongly believe this standard needs to be rewritten, as it is going to lead to endless interpretation disputes - with no good answers available - if it isn't rewritten. That might be good for lawyers and consultants, but it won't be good for NERC entities and the poor auditors who have to try to make sense of this.

Tom - I think we agree. The facility gets the rating, then the BES Cyber Systems that are associated with the facility take that impact rating. The wording is confusing.

My other point was that there is also a filter for cyber assets within the definitions. So, though it is improbable that a BES facility would have no BES Cyber Assets (or more specifically, that all Cyber Assets would fail the definition of BES Cyber Asset), it is possible, and that would be the only scenario in which "no-impact" made sense.

Thanks, Steve. Even though we agree on this point, there are others who don't, including at least one influential auditor. They believe there can be multiple levels of BCS at a single facility. For instance, a Low facility could have Medium impact BCS, and a Medium facility could have Lows (there is only one case where I'll concede this is possible, which is for cyber assets that aren't networked with a BCS controlling more than 1500MW in an Appendix 2.1 plant. Those cyber assets would be Lows, even though the BCS in question would be Mediums).

But there really isn't any way to settle this issue (and about 4 or 5 others), given the sloppy wording of CIP-002-5. At the NERC CIPC meeting tomorrow, I'm hoping to get NERC staff members to agree that the new SDT - addressing the Order 791 directives - should also rewrite CIP-002-5 so the wording is consistent and understandable. I see nothing but trouble if that doesn't happen.

Regarding your other point about no-impact, the facility would still be a Low impact, regardless of whether or not it had BCS. And given the current wording of CIP V5, it doesn't matter whether or not a Low facility has any BCS; it still has to implement four policies applying to the entire facility (in fact, I think "Low impact BCS" is kind of an oxymoron, like "Jewish Pope"). As you know, that could change when the SDT addresses FERC's directives for Lows.

Matt Davis, Ernst & Young
Let's put CIP aside for a moment. What boggles my mind if that entities are basically stating that they don't have intentory of assets that were implemented for some reason. That seems problematic for just regular business operations like O&M. I guess that means they can't/don't have insurance for those assets. If the asset fails, their may not know and may have a tough time fixing it. I could keep going, but it just seems to smack of bad business practices. As a COO, I would think there is some enterprise risk here that I wouldn't like at all. The industry needs to want inventory rather than us argue about the need for it during an audit.

Kevin Perry, SPP
As a friendly, benevolent auditor, I would love to see a complete list, inventory, what have you, of every BES Cyber Asset, including the Lows. After all, how does an entity demonstrate that all of the high and medium BES Cyber Assets/Systems have been properly classified as such if there is no visibilty of what is left after the nominated Highs and Mediums are identified. But...the standards say that no list of Low impact systems is required and FERC approved the standard.

So, what do I anticipate with respect to auditing Low impact systems? I anticipate that the auditor will have to take a Facility-wide view of the application of controls. The Registered Entity will have a "bunch of stuff" at their Facility that need to be protected per the four policies, the four policies will be broadly defined to encompass the Facility overall, and in doing so will cover the "bunch of stuff." The entity is welcome to be more granular if they want, with multiple sets of system-specific policies, but that is not required. I expect that after NERC and the to-be-stood-up SDT get done, the four policies will only require basic Security-101 protections that can be broadly applied at the Facility level.

And how do you audit the "bunch of stuff" that is being protected per these SEC101 policies? I propose that you sample a set of low impact devices within that facility using a....wait for it....list of low impact devices the utility provides.

I really think the excuses I've heard for not managing a list of low impact BES Cyber Assets amount to just not wanting to do it. Like Matt said...if I were the COO and you couldn't "account" for these cyber assets we then I think we'd have a serious business problem.

The auditor is prohibited from demanding a list of Low impacting BES Cyber Assets - the entity will rightfully protest that they are not required to maintain a list. But the audit team can certainly ask if there is a list available - no harm, no foul if one is not forthcoming. The audit team can and likely will inquire as to how the entity derived its list of High and Medium impacting BES Cyber Assets. The audit team can have a discussion about the types of systems found at the Facility (Generating plants will be the most challenging) and the audit team can certainly don their PPE and tour the Facility, asking about Cyber Assets they see. The auditor may also ask for physical security plans and processes, along with evidence of performance to compare againt the required policy document. The auditor may ask for communication network diagrams to aid in the evaluation of the electronic security policy. Audtiing of Low impacting BES Cyber Assets can be done without having to start with a list to sample from (and how do you know the list is complete without validating it somehow...).

I agree that there are many business reasons for maintaining an inventory of Cyber Assets, including asset management, risk management, cost management, fill in the blanks. If an entity has no idea what Cyber Assets are deployed at a Facility, they have much more aggregious issues than cyber security from a reliability perspective. But, the CIP standards themselves do not require the maintenance of a list. It serves no purpose to continue to argue the perceived deficiency in the CIP standard - either accept reality or attempt to change reality through the standards development process. In the mean time, the auditors will be identifying approaches for auditing and the entities need to be identifying ways to demonstrate compliance -- and that could include maintaining a list of Low impacting BES Cyber Assets - for business reasons of course...

@Kevin. Of course, you make a good point. The auditors can't find non-compliance because a list doesn't exist. That said, there are a lot of things that the auditors request that are not required (e.g., spreadsheets like RFC's infamous Attachment C-CIP.xls, etc).

The difference here is, obviously, that there is a statement in an approved standard that says "a discrete list of low impact BES Cyber Systems is not required". Plenty of different ways to go about getting to the facts as you mentioned. But I dare seems like we are playing games rather than just doing the right thing again <- not directed at anyone in particular.

@Responsible Entity. Creating a list (inventory) of your Low Impact BES Cyber Systems/Assets is good business IMO. Why not do it and save yourself from auditor work arounds to get to the same results (or as close as they need to "see" compliance"). The exercise may yield other unrelated facts that could save you from potential PVs in other CIP requirements ;-) I can't tell you how many times I was told that we don't have any of those widgets in our plant only to find one or two within a couple minutes into a physical inspection of the facility. Also...I'm not convinced that this "no list" statement for low impact BES Cyber Systems will survive the test of time. Getting ahead of the game can have its benefits as well. 

So Stacy let me take your premise one step further before your done with lists, I am assuming then that you would recommend a complete list of Cyber Assets/Systems (what good business does not have this?) even if they are a NO impact Asset/System so you can be ready to explain the NO impact? I think the alternative sounds like if on physical inspection an auditor sees a Cyber Asset in a particular facility and would like to know how that determination was made, that evaluation (which needed to be performed by the Entity at some point) would be handy to have around. Even though it may not be evidentiary, is there a need to prove/demonstrate NO impact?

Of course I am still not completely clear on the possible NO impact scenario. In the Background Section 6, the standard states "The scope of the CIP Cyber Security Standards is restricted to BES Cyber Systems that would impact the reliable operation of the BES." Doesn't this imply then that some would not? Is it then possible, for example, that a TO/TOP Control Center SCADA System be considered a NO impact? And if so, what mechanism exists in the V5 Standard to properly apply and demonstrate that?

Dennis, there is definitely no "No Impact" category for Facilities in CIP Version 5. This is because all BES facilities are in scope (per Section 4.2), and those that aren't High or Medium impact are Low impact (by Attachment 1). I agree it's more problematic whether or not there are No Impact BES Cyber Systems; the sentence you quote certainly implies that (and the wording of Attachment 1 actually implies it as well, although R1.1-1.3 contradict it).

This is - as I've said many times before - a huge problem with CIP-002-5: the wording is imprecise and self-contradictory, so that reasonable people can have completely divergent views on each of a number of questions, including this one. I don't see this changing, either.

All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.

The News from Atlanta

I attended the NERC CIPC meeting in Atlanta this week, and it was one of the best I’ve attended.  I was looking forward to it as a way to get clarification – both through official pronouncements and unofficial conversations – on some of the questions that remain about FERC Order 791.  I can say without hesitation that some questions were clarified – while at least one very important question remains unanswered.

This post is an update to my previous close-to-book-length post on Order 791 itself.  I recommend you read that (although it may require a can or two of Red Bull to get through it), but it won’t be included in the quiz at the end.

What Happens Now?
FERC ordered NERC to do five important things in Order 791:

  1. Remove the “Identify, Assess and Correct” language from 17 requirements in CIP Version 5;
  2. Develop standard(s) for communications networks;
  3. Conduct a survey to determine the impact of possibly removing the “within 15 minutes” language from the definition of BES Cyber Asset;
  4. Require specific controls for Low impact assets; and
  5. Develop separate requirements for “transient” devices.

The first three items have a specific due date: one year from the effective date of CIP Version 5.  Since we now know that date will be February 3, 2014, this means these items are due on February 3, 2015 (I don’t know whether there’s any significance to the fact that this is the day after Groundhog Day.  With all the different CIP versions coming and going, NERC and FERC staff members may have felt they were in that movie).

However, the fourth and fifth items don’t have any due date attached to them.  I at first thought this was a pure mistake (although I didn’t notice it until a couple people pointed this out to me), but that doesn’t seem to be the case.  It seems FERC knows these two items may take longer than the other two, so they’re allowing NERC a little more time if needed (I personally don’t think item 2 is going to be any piece of cake, either.  But it has its deadline all set in stone now).

How does NERC address these five directives?  Through the standards development process, of course (although this doesn’t apply to the survey.  NERC staff members will conduct that).  Here is some information on what will happen:

  1. I had wondered if the CSO706 SDT – which developed CIP versions 2 through 5 – would be called back one last time, but the answer is no; a new SDT will be constituted (and I hereby guess it may be called the CSO791 SDT.  Remember, you heard it here first).  This isn’t too surprising since many of the CSO706 team are no longer available to serve, and those that are probably feel that toiling four years in the vineyards of CIP standards development is enough punishment to expiate whatever sins led them to be selected in the first place.
  2. I didn’t quite catch what was said, but it seems there’s a NERC direction now to shrink the size of SDT’s.  The new SDT will have between six and ten members (as opposed to around 15-18 on the old one).
  3. Most importantly, it is possible there will be two SDT’s, not one, since meeting these directives (especially 2, 4 and 5) will require a huge effort.  It would make sense to have two teams – one to address the two items with the one-year deadline, the other for items 4 and 5, which don’t have a fixed deadline.
  4. However, Scott Mix made it clear that NERC really wants to have all four standards drafting efforts done in a year, so they can present them all in a nice package for FERC (in fact, he really said he hoped they could be done by the end of next summer.  I think this isn’t realistic).  I really can’t see this happening without two SDT’s (given that more than half the year will be taken up by getting the drafting team in place, balloting, legal review, BoT approval, etc.  Remember, we’re talking about developing what will probably be three new standards[i], plus doing major surgery – removing IAC – on 5 or 6 of the other standards in CIP V5).  NERC will soon be soliciting nominations for the SDT members.

FERC really ordered two things regarding communications.  The first was the new standard(s) for “non-programmable aspects of communications networks”.  Does this strike you as odd?  Why would they focus on the “non-programmable” parts – i.e. the physical hardware and cabling?  That’s because the programmable parts – i.e. the switches, routers, etc. that are subject to cyber attacks – are already covered by CIP.  FERC is really asking for a physical network protection standard here.

Consider how this directive came about.  In the NOPR, FERC expressed surprise that NERC had taken “communications networks” out of the definition of Cyber Asset, when it had been in that definition up until that point.  They pointed out that Paragraph 215 of the 2005 Federal Power Act (which set the whole FERC/NERC regulatory apparatus in motion, for better or worse) implies that communications networks pose as much of a risk as the cyber assets themselves.  They sounded like they might require NERC to develop standards for securing these networks (although I honestly didn’t think they would).

While the comments FERC received on the NOPR were mostly against requiring standards for communications networks, FERC obviously wasn’t persuaded they shouldn’t do this.  Accordingly, NERC has a year to develop these requirements (I presume they will cover things like conduit for cabling, appropriate shielding, etc). 

So now the physical network infrastructure is being protected, along with the network devices (which have been protected since CIP Version 1).  What’s left?  How about the data being transferred on those networks?  What about protecting it?  Of course, if we’re talking about protecting data, we’re often talking about encryption.

FERC also addressed that question in their NOPR, and has re-addressed it in order 791, in the “Other Technical Issues” section starting with paragraph 211.  While they don’t require that NERC develop requirements for protecting “data in motion”, this is one of three topics that will be addressed in a technical conference that FERC staff will organize within the next 180 days

What new was said about this at the CIPC meeting?  I was quite surprised to hear Scott Mix say that we “shouldn’t be surprised” if, after the conference, FERC orders a new standard be developed to protect data in motion; this is worth noting.  This conference should be quite interesting, with probably a lot of heated – but principled - discussion on both sides.  I suggest that FERC invite members of Congress, since it’s been a long time since they had a principled debate, as opposed to a recitation of media talking points.  But in any case, I hope they get a big room for it.

There has been some speculation on LinkedIn recently that FERC really wants NERC to develop requirements applicable to individual Low impact BES Cyber Systems[ii] - which would then also require an inventory of all Low impact cyber assets.  The speakers from NERC at the CIPC were unanimous that a) FERC isn’t requiring this (and I agree with that statement, as discussed in my post on Order 791) and b) the Low impact requirements NERC develops will not apply to specific cyber assets.

What will be the Low requirements?  You can look at my 791 post for a discussion of that.  You can also plan on attending the new SDT meetings, or perhaps even joining the team if you’re employed by a NERC asset owner.  Scott Mix said NERC will make sure the SDT meetings are held in rooms large enough to handle a big crowd of observers (and of course they will be webcast).

One note about the compliance date for the new Low requirements (which I think will be contained in a separate standard, perhaps called CIP-012-1): several people have asked me whether compliance with these new requirements will be due on the date that the Lows need to comply with CIP-003-5 R2 (the one requirement in the current Version 5 that applies to Lows), namely April 1, 2017. 

The answer to that question is almost surely no.  The new standard(s) that NERC presents to FERC for Lows (as well as the new standards for protecting communications networks and transient devices) will almost surely have separate implementation timelines.  I’m fairly sure Lows will have three years to implement whatever requirements are decided on, starting from the date of FERC approval (which I’m guessing will be mid-2015).  FERC has already conceded that is a good timeline for Lows (the rationale being that few if any Low impact assets were Critical Assets under CIP v1-3, so they will all be starting from scratch in implementing whatever is required).
V5 Transition
Regarding the transition to CIP Version 5, there was unanimous agreement from the NERC speakers that this needs to be a real transition – nobody is going to be able to remain completely CIP Version 3 compliant up until midnight on March 31, 2016, then be V5 compliant a second later.  I expect there will be a lot of guidance published on how this can be effected.  And I’m sure FERC agrees with this.

Regarding FERC’s directive to remove “Identify, Assess and Correct” language from 17 requirements in V5, NERC seems to have no appetite for challenging that directive by providing alternative language that would meet their objections.  The reason for this is pretty simple: there is no language NERC could propose for CIP V5 that would meet FERC’s objections.  FERC is objecting to the very idea of trying to implement an internal controls-based compliance approach in the standards themselves.  Rather, they make it clear that NERC’s Reliability Assurance Initiative is probably the right way to do this.  So expect NERC to keep pursuing that approach.[iii]

Being who I am, I asked the question that I think is as important as any other regarding CIP Version 5: Will the new SDT be addressing the many serious wording problems in CIP-002-5, which I believe can ultimately result in the standards being invalidated by a court?  And guess what?  Steve Noess (the NERC staff member who directed the last two years of the V5 development effort) gave a long answer – which I confirmed with him meant “No”.

I can’t say I was surprised by this.  The new SDT will have a big job on its hands just complying with FERC’s Order 791 directives; it would be a huge effort to add this can of worms to the mix.  Of course, if FERC had actually made fixing this problem one of their directives, there would be no question that NERC needed to address it.  But they didn’t, and the SDT won’t address this.

Those of you who have been reading this blog for a while (and if you haven’t, the posts are all out there to read) know that I have been pursuing the wording problems in CIP-002-5 with all the gusto of Captain Ahab pursuing Moby Dick.  I’m sure I’ve written well over 100 pages on the subject, and I’m not done, because I keep finding new problems.  I would like to put out an uber post summarizing all of these problems, but I can’t do that until I’ve reached the bottom.  It’s like trying to dig a new building foundation in Rome: with every few feet of digging, you come on a new set of ancient ruins you have to excavate.

Comparing myself to Ahab isn’t entirely facetious; I’m sure there are some that consider this a similar case of monomania (although hopefully not one that will result in my death and those of my colleagues, as in the case of Ahab).  All I can say to them is that I simply don’t see how CIP Version 5 can be a success – or ultimately survive as regulatory law – when perfectly rational people (entities and auditors) can come up with completely opposite conclusions on a number of aspects of the asset identification process (which of course is what is addressed in CIP-002-5).  And if the asset identification process isn’t clear and agreed on, nothing else in CIP V5 will be clear and agreed on either.

In replying to my questions at the CIPC meeting, Scott Mix said something that I’m sure he now regrets, since he is a very intelligent person.  He tried to make the diversity of possible interpretations of CIP-002-5 into a virtue, saying that one of the goals of the CIP process is not to have requirements that rigidly dictate one way of complying with them. 

I agree this is a worthwhile goal.  However, it assumes that the meaning of the requirements is clear.  It is precisely the fact that there can be no univocal interpretation of CIP-002-5 R1 (i.e. there can be no interpretation that isn’t contradicted by some of the wording in that requirement or in Attachment 1, which is called by R1) that is the problem here.  And the fact that this is the asset identification requirement – rather than one of the control requirements, such as CIP-007-5 R1 for Ports and Services – means that this ambiguity threatens the entire CIP V5 structure.

I will say that, with the help of a couple readers, I have identified at least one very clear contradiction in CIP-002-5, whose interpretation one way or the other will mean a big discrepancy in the number of BES Cyber Systems some entities will identify; I will describe it in one of my next few posts.  I know that one of the readers is already planning on using the narrower interpretation as justification for greatly minimizing their CIP V5 compliance footprint.  And who can blame them?  Will NERC and FERC automatically accept the fact that this entity will have far fewer BES Cyber Systems than an entity that took the other interpretation?  No harm, no foul?  I tend to doubt it.[iv]

 All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.

[i] I’m guessing that the requirements for Low impact assets, transient devices, and communications networks will be in separate new CIP standards, perhaps called CIP-012 through CIP-014.

[ii] I regard the phrase “Low impact BCS” as an oxymoron, like “Jewish Pope” or “British cuisine”.  Of course, CIP-002-5 specifically refers in one or two places to Low impact BCS – and this has led some people to conclude that an inventory of Lows is required.  Otherwise, how could you distinguish your Low impact BCS from other cyber assets at Low facilities?  And those people are absolutely right, of course.  This is just another example of the serious wording problems in CIP-002-5.

[iii] There was a lot of discussion of RAI at the CIPC meeting, and this is really moving ahead at NERC.  I can fairly confidently predict that, by the time CIP V5 compliance comes due on April 1, 2016, RAI will be in place in all NERC regions.  This means that entities will essentially get the benefits of IAC – perhaps more – when they have to comply with V5.  In addition, they’ll get those same benefits for all of the other NERC standards as well, since RAI will apply to all of them, not just the CIP family.

I was very surprised to find, when I attended MRO’s compliance workshop in St. Paul, MN two weeks ago, that MRO has essentially already implemented RAI for their whole footprint.  They have already conducted a successful test with one entity, and are now rolling it out to everyone else.  They didn’t exactly stand up and announce this fact, but once I heard about the new procedure changes they were implementing, it became quite clear this is what they are doing (they appear to be phasing it in, so that the difference is not huge for an MRO entity being audited today).  I would like to write a whole post on RAI and the death of IAC (I even thought of a catchy title: “IAC, RAI…Is NERC SOL?”), but I’m afraid that isn’t at the top of the queue.

[iv] Part of the answer to my question at the CIPC was that NERC’s transition guidance, which will be updated based on the experiences of the six (no longer seven, for some reason) entities that are participating in the V5 transition pilot, will provide some sort of guidance on whatever methodologies these entities have come up with for asset identification.

Let me be clear: I have absolutely no doubt that entities can come up with a methodology for CIP V5 asset identification (one NERC CIP manager for a large generation entity told me, “I’m an engineer.  Figuring out a way to make things work is what I do”).  I could, too.  In fact, I could come up with 5-10 pretty good methodologies, all different but all supported by some of the wording of CIP-002-5 (I may do that in a future post).  But how do you know which is the right one?

And don’t tell me that NERC’s transition guidance – or any other guidance document they may write – is the way to deal with this problem.  None of these documents has the legal standing of the wording of the standards themselves.  The only way there can be a clear interpretation of a standard is through the Request for Interpretation process, in which an entity requests an interpretation, NERC provides it, and FERC ratifies it (or doesn’t, as was the case with two NERC Interpretations earlier this year).  This process takes at least two years, so even if an RFI were filed on Feb. 3 (when Order 791 comes into effect), this isn't exactly going to provide a lot of help to entities as they struggle to comply now with V5.  More importantly, an interpretation is over a narrow question on the meaning of wording.  Given the problems with the wording in CIP-002-5, and the fact that they're very intertwined, I don't think 10 or 15 interpretations could clear up that standard; it needs to be rewritten, and there's still opportunity to do it with the new SDT(s).

I’m guessing that, if CIP-002-5 isn’t changed, the way this problem will be finally dealt with (not solved) is through the Regional Entities taking it upon themselves to develop their own interpretations.  These won’t have any more force than a NERC interpretation, but since the RE’s are the ones who do the auditing, it is far more likely the registered entities will follow the lead of their region.  However, were a registered entity to take this to court, the regional interpretations would still have no legal force.  And, given the discrepancies I see in the number of BES Cyber Systems identified with different interpretations, it isn't at all likely that NERC entities will choose one interpretation - sanctioned by their RE - over another one that might literally save them millions  of dollars in compliance costs.

Regardless of all this, it is clear (to me anyway) that, if the wording in CIP-002-5 isn’t corrected while there is still time to do so, it will be finally "corrected" at huge cost through Potential Violations, fines, recrimination, lawsuits, etc.   Sounds like a great way to deal with the problem to me.

Sunday, December 8, 2013

The Ten Effective Dates of CIP Version 5

If you are like me and haven’t paid much attention to the details of the CIP Version 5 implementation plan, you may have forgotten – as I did – that there are more than the two implementation dates that everyone has been focusing on: April 1, 2016 for Medium/High impact and April 1, 2017 for Lows. 

However, Carter Manucy of the Florida Municipal Power Agency has been paying attention to the plan, and he pointed out to me that there are in fact ten effective dates: the two just mentioned, and eight listed in the section entitled “Initial Performance of Certain Periodic Requirements”. 

Fortunately, Carter has saved us all some time by putting all these dates on a timeline – along with the dates of the various events in the development and approval of CIP Versions 4 and 5.  He does point out that he can't guarantee this is right, so don't blame him if it isn't.  However, if you find a problem with it, let him know!  He's at

(!2/12: The diagram below has been updated to correct a small typo in the original)

Tuesday, December 3, 2013


This blog has just surpassed 25,000 hits since it was started in February.  I'm not sure whether that's a good or bad number, but I think it's significant - and I thank all of you for looking here for....what? Information, amusement, schadenfreude?  Maybe a mixture of all of them.

In any case, given all the uncertainty still in the air, as well as the continuing changes ahead in CIP Version 5 / 6, I don't think I'll find myself with nothing to write about anytime soon.


Sunday, November 24, 2013

FERC Order 791

Dec. 15: For an update to this post, based on information from the NERC CIPC meeting in Atlanta last week, see this new post.

FERC issued Order 791 on Friday November 22, approving NERC CIP Version 5.  If you’re looking for my rating, I guess I give it 1 ½ thumbs up.  What it does, it does well.  However, it doesn’t do everything I had hoped it would do.  For more on this, read on.  Note that page numbers below refer to the page numbers in the Order itself, not what Adobe Reader™ will show you when you read the PDF version.

As I and others have suspected for a while, FERC is requiring that NERC develop a new version of CIP, even though in the Order they always speak in terms of changes to Version 5.  However, they can’t both approve Version 5 and order it changed.  The changes have to appear in a new version, which will be based on V5.  I believe that version will be called CIP Version 6. 

NERC is to deliver the new version within one calendar year of the effective date of CIP Version 5 (meaning it has to be drafted, balloted by the NERC membership and approved by the Board of Trustees).  On page 145 of the Order, FERC says the effective date will be 60 days after publication of their Order in the Federal Registry.  Since orders are usually published in a few days, this means the effective date of the Order will be in late January, 2014.  So FERC wants the new version by January, 2015.  

FERC directed that NERC include several changes in the new version, which I discuss in sections 1 through 3 below.  The remaining sections of this post discuss other directives (or in two cases, non-directives) in Order 791.

  1.  “Identify, Assess and Correct”
The Identify, Assess and Correct language (hereinafter IAC) was one of the signature features of CIP Version 5 when it was approved by NERC.  In their NOPR of last April and again in Order 791, FERC expressed grave misgivings about that language (which is found in 17 requirements in V5).  They made it very clear they find too many ambiguities in the whole idea, and they feel that NERC hasn’t adequately explained how the IAC process will work.  The discussion is quite interesting and worth reading, but I won’t discuss the details here (it starts on page 25 of the Order).

Of course, a lot of people are going to be disappointed by the death of IAC (although they shouldn’t be surprised that it happened, if they read my post in September as well as a couple previous ones).  But I actually think FERC’s discussion should give them more than a few rays of hope.  This is because FERC makes a point of talking nicely about the NERC Reliability Assurance Initiative (on page 42 of the Order).  They say “..the Reliability Assurance Initiative process when fully developed may afford a consistent, informed approach that provides incentives for entities to develop robust internal control programs.”

Briefly, the RAI will essentially do what IAC was intended to do – move the enforcement process from being based on zero tolerance for even the slightest, most insignificant infraction to making sure the entity has a robust program for compliance.  It will not require changes to the standards at all (and it will ultimately apply to all the NERC standards, not just CIP) but rather to the CMEP, which is NERC’s Bible for monitoring and enforcement of compliance.  As far as I know, this is the first time FERC has provided encouraging words about RAI (they mentioned it, although not by name, in the V5 NOPR, but there really wasn’t much information on RAI available last April.  A lot of information has since come out, and a few of the regions are already piloting RAI).

So here’s the hope: If RAI is implemented for CIP before the implementation date for V5, then it really doesn’t matter that IAC isn’t in the language.  You’ll effectively be audited based on IAC anyway.  Of course, there is still a lot of possibility for slippage in this scenario, so I’m not going to place the go-for-broke $5 bet that I normally place when I am quite certain something will happen.[i]

One other interesting point from the IAC discussion: FERC clearly thought NERC didn’t fight hard enough for IAC.  And I have to agree with them.  I was very surprised, when I read NERC’s comments on the NOPR submitted in June, that they were proposing to clear up the enforcement questions that FERC raised in the NOPR - six months after FERC approves V5!  In essence, they were telling FERC, “We admit there are a lot of things that need to be cleared up.  First you approve V5 (with IAC of course), then we’ll clear them up.” 

Such a deal – does anyone wonder why FERC didn’t take it?  If NERC had been really serious about this, they would have busted a__ to clear up the ambiguities this summer, so FERC could have had that information before they made their decision; did they really think that FERC would just trust that NERC had the enforcement all figured out, and just didn’t have the time to write it down before FERC approved V5?  It really seems as if NERC had given up on IAC (perhaps because RAI was moving forward), and didn’t think it would do any good to make much of an effort to change FERC’s mind on it.  They may well have been right, of course; I for one think that, given FERC’s language in the NOPR, there wasn’t much chance of saving IAC.

The bottom line is FERC didn’t change their mind about IAC.  They state on page 40 (paragraph 70), using the driest of humor, “NERC’s proposal that the Commission approve this language in numerous requirements of the CIP version 5 Standards, while postponing a detailed explanation regarding the understanding, compliance implications and proper implementation of the proposed language to a future time, is an inadequate approach.” 

  1. The Lows
I had the most admiration for FERC in the way they dealt with Low impact assets.  I thought they a) listened carefully to the comments on their NOPR statements about Lows and adjusted their position accordingly, and b) came up with a solution that makes clear what they want but allows NERC a lot of flexibility in how they achieve that.

FERC said two important things about Low impact assets in their NOPR.  The second (but easier to deal with, so I’ll discuss it first) was their questioning of the language in CIP-002-5 and CIP-003-5 saying that an inventory of cyber assets at Low impact facilities isn’t required.  FERC clearly thought in April that an inventory was needed to protect the Bulk Electric System (or the Bulk Power System, since FERC always uses that term). 

However, the comments they received in June were overwhelmingly against this, because of the huge effort it would take to conduct this inventory (at least for some entities, such as the large government entity that said at a WECC meeting that they had potentially 350,000 cyber assets that would have to be inventoried.  I also know other entities that have had this inventory all along, as a matter of good security and asset management practice).  FERC listened to those comments, and changed their mind.  They state clearly on page 65 of the Order that they don’t think it would be a good idea to require an inventory for the Lows.

The second proposal FERC made about Lows in their NOPR (page 38) was “we propose to direct NERC to develop a modification to CIP-003-5, Requirement R2, to require responsible entities to adopt specific, technically-supported cyber security controls for Low Impact assets, as opposed to the proposed unspecified policies.”  Of course, the comments about this proposal were as negative as they were about inventory.  It’s interesting to see how FERC dealt with this.

Note that, in the NOPR, they were looking for specific controls; I and most people interpreted that to mean they were going to ask NERC to write some specific requirements for Lows (I thought they would be pretty basic, like requirements for a firewall, for locks on the doors, etc).  But that doesn’t seem to be what FERC had in mind (or at least, it’s not what they have in mind now.  It’s not worth using up perfectly good electrons worrying whether or not this constitutes a change in their opinion since the NOPR).

In the Order, (starting on page 61), FERC says “…while we do not require NERC to develop specific controls for Low Impact facilities, we do require NERC to address the lack of objective criteria against which NERC and the Commission can evaluate the sufficiency of an entity’s protections for Low Impact assets.”  So the problem now is having criteria by which NERC and FERC can judge whether an entity is actually protecting its Lows properly.  FERC gives three options to NERC, although they say that other approaches might work as well.

The first option (page 64) is that NERC could define a set of “control objectives” for Lows, but not specific controls.  I believe an example of this might be requiring that the entity take steps to protect the PSP without requiring specific technologies like card readers or specific procedures like escorting of visitors.

The second option is that NERC could require specific controls that would apply to particular sub-categories of Low impact systems (so there might now be Low-Low, Medium-Low and High-Low systems, with specific controls perhaps only being applied to the latter).  I don’t think this option will get a warm reception at NERC, since it’s hard to see how it could be audited without requiring a cyber asset inventory.

The third option is that NERC could “define with greater specificity the processes that responsible entities must have for Low Impact facilities under CIP-003-5, Requirement R2.”  In other words, rather than simply require entities to draw up and implement four policies (with no specification of what is in them, as is the case in CIP-003-5 R2 now), NERC could be more specific about the processes that entities need to require in those policies.[ii]

Note that both the first and third options would not require controls that apply to particular cyber assets, which is the big show-stopper for NERC.  As long as controls (or criteria) are just on the site level, I think some can be found that will be acceptable to the membership.[iii]

That being said, I see this whole discussion about Lows as being the most important that will occur as NERC drafts the new CIP version, one which will generate (no pun intended) a lot of interest among the membership.  I think the new SDT meetings on Version 6 may have to be held in Madison Square Garden.  They will certainly be very interesting.

  1. “Transient Devices”
The definition of BES Cyber Asset now includes the following parenthetical expression: “(A Cyber Asset is not a BES Cyber Asset if, for 30 consecutive calendar days or less, it is directly connected to a network within an ESP, a Cyber Asset within an ESP, or to a BES Cyber Asset, and it is used for data transfer, vulnerability assessment, maintenance, or troubleshooting purposes.)”.  I don’t need to remind you that the definition of BES Cyber Asset is fundamental to CIP Version 5, and the Definitions document that contains it is part of the V5 standards, and has to be approved by FERC.

FERC questioned the wisdom of this provision in their NOPR, and they haven’t backed down from that position.  They point out (starting on page 74) that devices like laptops that are used, no matter how temporarily, within the ESP can cause all sorts of havoc if they introduce viruses and worms into the ESP.  I won’t go into the discussion here, but it’s worth reading all the arguments in this section. 

Even with these concerns, FERC didn’t direct that the language be removed.  If they had, this would have imposed a big burden on NERC entities, since every device that might ever be used – even for ten minutes – within an ESP would have to be forever protected as a BES Cyber Asset/System (or at least a Protected Cyber Asset). 

However, they did direct NERC to develop a new (or modified) standard that provides for cyber security of transient devices (p.80).  I’m guessing NERC will decide to include this in CIP Version 6 (so it might be called CIP-012-1) – I would think this would be preferable to developing a whole new set of standards. 

  1. CIP Version 4
The remaining sections of this post deal with statements included in the Order which aren’t changes to be included in the next CIP version.  One of these statements will hopefully put to rest a longstanding bugaboo: FERC makes it clear that CIP Version 4 sleeps with the fishes.  Of course, simply by approving the Version 5 implementation plan, FERC put V4 to rest.  But they made sure to drive the point home on page 6: “CIP-002-4 through CIP-009-4 will not become effective, and CIP-002-3 through CIP-009-3 will remain in effect until the effective date of the CIP version 5 Standards. I hope this will be enough evidence for the legal departments at some large IOU’s to let their compliance people stop working on compliance with CIP Version 4 and start working on Version 5. 

  1. Got 15 minutes?
The definition of BES Cyber Asset begins, “ A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non-operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System.” 

In their NOPR, FERC seriously questioned why “15 minutes” is in the BCA definition, since it presumably excludes a lot of cyber assets that can affect a Facility but don’t do so within 15 minutes.  You may know the answer to that question: “15 minutes” is really a proxy for “real-time”.  The SDT wanted to only include devices that immediately affect the Facility but couldn’t find appropriate wording, so they decided to be safe and include everything that could affect it within 15 minutes.

Of course, this shows that no good deed goes unpunished, since FERC then seized on the 15 minutes as the problem – implying that devices that may take 3 or 4 days to affect the Facility should also be defined as BES Cyber Assets.  There were a large number of comments stating that the 15 minute provision absolutely needed to be left in the BCA definition.

And guess what: FERC listened!  They didn’t order that this provision be removed.  However, they did order NERC to undertake a survey to determine how this provision will actually be used, and the impact it might have (including how many cyber assets would be excluded or included through leaving it in).  This survey is due within a year, at exactly the same time as NERC will need to submit Version 6 to FERC.[iv]

  1. Just what we needed…a new standard!
In their NOPR, FERC had raised the issue of communications.  The previous NERC definition of cyber asset had included “communications networks” as well as “programmable electronic devices”.  In Version 5, the SDT removed those networks from the definition.  In their NOPR, FERC questioned why this was done, and whether it was putting the BES at any risk.[v]

FERC has now decided that communications networks need to be protected by NERC Reliability Standards – but they’re not ordering that these protections be included in NERC CIP.  Instead, FERC orders NERC (pages 86-87) to develop or modify standards for this.

Unlike with transient devices, I don’t think NERC will include this new standard in CIP Version 6.  Transient devices are computers, and CIP is for protecting computers.  But communications networks are quite different, and I believe NERC will decide to address this in a separate standard, or perhaps as part of the existing COM standards.

  1. Mark your calendars
FERC raised three issues in the NOPR that they don’t want to drop, but also don’t want to use to order changes to CIP.  These include “communications security” (which here means communications between devices within a Facility, and whether they should be encrypted or not), “remote access” (specifically whether the provisions in the current CIP Version 5 are adequate or not), and whether CIP Version 5 adequately addresses FERC’s provision in Order 706 to adopt as much of the NIST Risk Management Framework as possible.

It’s not surprising that the comments regarding these three items varied widely.  So FERC has decided (p. 122) to have NERC call a conference within 180 days to discuss these three items – and in a comprehensive manner, as opposed to piecemeal.  The question will be whether these three items need to be included in CIP going forward or not, and perhaps more generally how they can be addressed to protect the BES.

  1. I’ve left the best for last
The big question on a lot of people’s minds is the implementation dates for CIP Version 5 (and 6).  When will High, Medium and Low impact Facilities have to comply?[vi]  Well guess what…it isn’t simple.  But when was there anything about NERC compliance that was simple?

What is simple is the timeline for Version 5.  All of the V5 standards say that V5 will become effective “on the later of July 1, 2015, or the first calendar day of the ninth calendar quarter after the effective date of the order providing applicable regulatory approval.”[vii]  Here we go:

  1. As I’ve already mentioned, the effective date for V5 is 60 days after publication in the Federal Register, which means sometime in late January 2014.
  2. The first day of the ninth calendar quarter after that is April 1, 2016.  This is the date that Highs and Mediums will have to comply with V5.
  3. Since the Low date is a year later, Lows have to comply on April 1, 2017.
That’s simple, right?  The real question is, what about Version 6?  Will it supersede V5 (just like V5 has superseded V4), or will V5 come into effect, followed by V6?  And will its implementation plan have the same timeline as the V5 one – 24 months for High and Mediums and 36 months for Lows?

I was expecting FERC to say something about the implementation plan for the new version in the Order, but it is silent on that.[viii]  So let’s assume that Version 6’s implementation plan is just like Version 5’s, except it doesn’t say anything about superseding an earlier plan.  What’s that timeline?

  1. FERC has ordered V6 to be delivered to it by January 2015. 
  2. Let’s assume FERC takes just less than two quarters to approve V6 (which is reasonable since most of V6 will be the same as V5) – let’s say they approve it on June 30, 2015 (and I know they approved at least a couple CIP versions on the last day of a calendar quarter, which of course meant the effective date was three months earlier than if FERC had waited ‘til the next day – the first day of a new quarter – to approve it).
  3. The first day of the ninth calendar quarter after June 30, 2015 is July 1, 2017.  So that would be the compliance date for Highs and Mediums for Version 6.
  4. A year later than that would be the Low date, or July 1, 2018.
So think about it.  In this scenario, High and Medium Facilities will have to comply with CIP Version 5 on April 1, 2016, and with Version 6 on July 1, 2017.  What does that mean?  For one thing, it means the entity has to put together a whole compliance program based on Identify, Assess and Correct (remember, FERC just approved Version 5 without change, since that’s the only way they can approve standards); then 18 months later, they have to go back to a “zero-tolerance” program.  Think about what that would entail, in terms of documentation, training, etc.  Sounds like a lot of fun, right?

There’s more.  From the auditors’ point of view, on April 1, 2016 they will need to allow transient devices to be used for up to 30 days within the ESP without any cyber security standards applying to them – even though they know these will be in place the following year and they know what they will be (since V6 will have been approved in 2015).  They will also need to just audit Low facilities based on the four policies required by CIP-003-5 R2, rather than the presumably beefed-up requirements of CIP Version 6.

I realize there are ways these problems can be mitigated.  For example, NERC could say they simply wouldn’t audit based on IAC, and instead would use the old “zero-tolerance” approach.  But what about an entity that thought its compliance program was wonderful and they wanted to be audited to the exact wording of the 17 requirements that have IAC in V5?  NERC would obviously have to accommodate them.  But that would cause a lot more work for the auditors, since they would have to have two different auditing regimes – one for V5 without IAC, one with.

It seems to me that NERC will want to have Version 6 do the same thing to V5 as V5 has now done to V4: send it to sleep with the fishes once FERC approves V6.  Of course, since (in my timelines above), V6 would be approved on June 30, 2015 and V5 wouldn’t become effective until April 1, 2016, this would be perfectly doable.

Does this mean that CIP Version 3 will remain in effect until July 1, 2017?  Well, here you get into politics and game theory.  My guess is that, should NERC decide to have V6 supersede V5, they will also shorten the implementation timeline for V6 so that the compliance dates were approximately what they would have been had V5 come into effect.  Why would they do this?  Because otherwise, Papa FERC (although “Mama FERC” might be more appropriate, since Chairman Wellinghoff made the surprise announcement on Thursday that he will step down next week and Commissioner LaFleur will step in as interim Chairwoman.  Congratulations to Commissioner LaFleur!  I’m sure she’ll do an excellent job; she certainly seems to have a good understanding of the issues surrounding NERC CIP.  And that’s all that matters for FERC, right?) might be unhappy.  They thought they were doing NERC a big favor by not shortening the V5 timeline as they’d hinted in the NOPR; now they will find it effectively being lengthened by a year and a half, unless NERC proactively shortens the V6 timeline.

The bottom line on this: NERC entities need to prepare for compliance with CIP Version 5 or 6 on April 1, 2016 for High and Medium impact Facilities, and a year later for Lows.  You might end up getting a quarter or two more to comply (although you won’t know if this is going to happen for probably a year and a half from now).  But you’re risking big problems if you don’t aim for these dates as of now.

A few of you may have noticed that I’ve spilled a few electrons this year (in fact, about ten whole posts) writing about problems with the wording in CIP-002-5, and suggesting that these problems really need to be fixed in order for CIP Version 5 / 6 to have a firm foundation; you may also know I actually rewrote CIP-002-5 and submitted that version to FERC during the NOPR comment period.   And you may not know – but it is true - that I have a lot of readers among the staff at FERC.  So…what did the FERC Commissioners say about this issue in Order 791?

I’ll break the suspense: they said nothing about it.  What does that mean for this idea?  Will NERC still want to rewrite CIP-002 as part of the Version 6 drafting effort?  Well, I highly doubt NERC is going to feel overly motivated to include that in the SDT’s marching orders for Version 6, since those folks will have all the FERC mandates on their plates, and a short deadline to address them all.  I also suspect that NERC couldn’t address these issues in V6 even if they wanted to, since Version 6 will be a compliance filing – its purpose is to address the specific directives in FERC Order 791, not go off on some wild tangents not ordered by FERC.

So maybe the answer is a guidance document?  After all, I think I’ve mentioned that about 100 times since I got on this kick right after the NOPR was issued.  Well, I would still like to see a guidance document, but let’s face it: a guidance from NERC can’t override the wording of a standard.  Let’s say someone interprets CIP-002-5 in a way that seems justified (and given the ambiguities in it, all sorts of interpretations would be justified), but gets a fine because their interpretation didn’t match the guidance.  They can take it to court (since NERC standards are regulatory law); the judge will look at the entity’s actions, agree they were plausible within the wording of CIP-002-5, ask if the NERC guidance document had any legal force (which it wouldn’t), and give them a get out of jail free card.

I continue to see this as a problem, whether or not the FERC Commissioners do.  And I don’t see any good way to address it, other than rewriting CIP-002 as part of the V6 drafting effort (Interpretations carry legal force, but they take a couple years to be approved, and in any case they focus on very narrow issues.  IMHO, there are so many problems with CIP-002-5 that no single Interpretation could fix that standard.  And of course CAN’s have been abandoned).

I’m not at all sure what the solution to this is, to be honest.  I guess sometimes there aren’t solutions.  To quote the philosopher Jimmy Carter, “Life is unfair”.

Here ends my story.  I’d love to hear any and all comments on this.  You can either post them below or email them to me at

All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.

[i] FERC actually said on page 43 that modifying the CMEP would be one way for NERC to effectively get IAC without modifying the standards – that’s what RAI would do, although I guess there could be an interim modification just for CIP (i.e. a “partial RAI”), to make sure that was in place before the enforcement date for V5.  In any case, FERC is clearly encouraging NERC along the CMEP path, but also doesn’t think including this language in the standards themselves (like NERC tried to do with IAC) is at all workable.

[ii] I have joked that, the way CIP-003-5 R2 reads now, an entity could have the following as any of the four policies (say the physical security controls policy): “In order to protect physical security, we will provide ice cream to all employees on Thursdays.”  So as long as the entity actually provided ice cream on Thursdays, they would be fulfilling the policy and couldn’t be found non-compliant.

[iii] Not that being acceptable to the NERC membership really is a gating factor here.  NERC has to provide FERC with a new CIP version that includes what FERC wants, period.  If the membership votes down whatever gets drafted, the Board is empowered – in fact obligated – to override the membership.  The Federal Power Act of 2005 leaves FERC holding all the cards here.

[iv] I don’t want to take implications out too far, but it is interesting that both V6 and the survey results are due at the same time.  This means that, if FERC were to look at the survey results and decide a change were needed – perhaps changing the 15 minutes to 15 hours, or eliminating it altogether – NERC wouldn’t be able to include that in V6.  Assuming FERC approves V6, they would need to order a new compliance filing with this change, which would be V7.  And NERC would have to deliver that next….But this way lies madness.  I’m not going to think about this anymore.

[v] In practice, the fact that communications networks were included in the cyber asset definition was meaningless in CIP Versions 1-3, since they were excluded from being covered by the standards.

[vi] As Carter Manucy of FMPA reminded me a couple months ago, there are actually about 8 compliance dates for V5, not just the two I’m accustomed to thinking of: one for Highs and Mediums and the other for Lows.  This is because the V5 Implementation Plan lists separate “initial performance dates” for specific periodic requirements. We agreed that I’ll post his complete timeline, but only after the FERC Order on V5, so it can be more than hypothetical.  I should have this up fairly soon.

[vii] Scott Smith of Portland General Electric pointed something interesting out to me: On page 11 of the Order, FERC quotes NERC’s V5 Petition (which was submitted on Jan. 31, 2013, requesting approval of V5) as saying the standards will be effective on “the first day of the eighth calendar quarter after a Final Rule is issued in this docket.”  NERC obviously hadn’t read their own standards when they wrote this, since every one of the ten CIP Version 5 standards refers to the ninth quarter.  However, since FERC is approving the V5 standards in Order 791, not the Petition, I don’t see this as a legal problem – just some bad proofreading on NERC’s part.

Interestingly enough, NERC made this mistake once before, and it had more important consequences then.  In Scott Mix’s August presentation on V5 before TRE, he mentioned that the V4 standards officially said eight, not nine calendar quarters; so the compliance date for V4 ended up being April 1 2014 rather than July 1. This was a mistake, since the SDT had really intended for the date to be the first day of the ninth quarter.  Scott said the SDT had now learned how to count (which isn’t a bad thing, since half the SDT are engineers).  But it seems the proofreaders still have to learn to read; they obviously didn’t look at the V5 standards when they mentioned eight quarters.

[viii] In fact, the Order always refers to changes in Version 5, even though that can’t happen.  I assume this is some sort of FERC-speak, because they certainly know the rules.  I did go back and review the Order approving Version 2, since that did the same thing as Order 791 does: it approved V2 but ordered a new version with a few changes (much more minor than in this case.  They also gave NERC just 90 days to come back with the new version).  That Order also talked about changes to V2, even though what came back was V3, not a changed V2.