Saturday, March 22, 2014

Who Will Interpret CIP Version 5?

Warning: Reading this post may cause unintended side effects in NERC compliance professionals, including loss of sleep, depression, excessive consumption of alcoholic beverages, and thoughts of suicide.

I have attended a number of NERC and regional meetings dealing with CIP Version 5 lately, and I have talked with many CIP compliance professionals.  I haven’t been surprised to find that lots of people have questions about the meaning of particular parts of CIP v5, and about what seem to be unintended consequences of the wording of particular requirements.  This is to be expected, given that v5 is a complete rewrite of the CIP standards (it should really be called CIP 2.0, with CIP v1-3 being called v1.0, 1.1 and 1.2, or something like that.  Too late for that now, of course). 

The question becomes: Who answers these questions?  And what is the mechanism by which these interpretations can be made?  Let’s examine the usual suspects:

  1. Revise the Standards – Is it still possible to make changes to CIP Version 5?  Not any more.  I was hoping FERC would order NERC to open up the wording problems in CIP-002-5, to remove the inconsistencies and confusion in Requirement 1 and Attachment 1 of that standard (I even very helpfully rewrote the standard and submitted my version to FERC during the NOPR comment period); however, Order 791 came and went with ‘nary a word from FERC to that effect. 
You may point out that there is a new drafting team at work now, drafting the changes FERC ordered in Version 5.  Couldn’t they make clarifications where needed, even though FERC didn’t tell them to do so?  In theory they could.  However, their work is governed by their Standards Authorization Request (SAR), and that strictly limits them to addressing the four directives from Order 791.[i]   Therefore, I see about zero chance that there will be any revisions to Version 5, other than to meet the four directives.

  1. Request for Interpretation – Of course, there is a process for making interpretations to a requirement that has already been approved.  A NERC entity has to make a Request for Interpretation; this needs to be discussed by a team of NERC members, who will develop the interpretation; a NERC ballot body has to vote on the interpretation; the NERC Board of Trustees needs to approve it and submit it to FERC; finally, FERC needs to approve it, at which point it becomes part of the standard (you’ll notice some of the earlier standards have a letter like a or b after them.  These standards include one or more approved interpretations). 
You can probably see the biggest problem with this right away: all these steps take a long time.  In fact, I doubt any of the interpretations has come into effect much before two years after it was originally requested (and none have even been requested yet for V5; I’m not even sure NERC is set up to deal with it, were one to be requested).  Plus, FERC showed last year – when they remanded two interpretations on CIP – that they won’t necessarily approve everything that NERC shoves across their desk anyway.  So the Interpretations process clearly isn’t going to do NERC entities any good as they prepare for v5 compliance in two years.

  1. Can NERC interpret the standard in some other way?  That has certainly been tried.  The Compliance Application Notices (CANs) were an attempt to make something like an interpretation, without going through the Interpretations process.  And guess what? They haven’t worked, and NERC doesn’t plan to issue any more. 
The reason why they haven’t worked is pretty simple: NERC has a process for developing and revising standards.  It requires constituting an SDT, having them draft the standard, having it approved (or not) by a ballot body, having the B0T approve it, and finally having FERC approve it (or not).  There simply is no kosher way to interpret or revise a standard that doesn’t go through this process.

  1. How about the CIP v5 Implementation Study?  In this, six lucky entities are starting the transition to v5 now, and are discussing their experiences with NERC; NERC will in turn summarize and publish these lessons learned in June.  In fact, they have already published three documents on particular lessons learned.  And at the CIPC meeting in St. Louis in early March, various NERC spokespeople clearly implied that a lot of the ambiguities in CIP v5 would be cleared up through these lessons learned. 
Folks, if you believe this, you’re heading for a big disappointment.  The three lessons learned documents that have come out have certainly been useful, but none of them have addressed wording problems in any of the v5 requirements – and I sincerely doubt the final document will do much in that regard either. 

The fact is, there simply hasn’t been enough time for the six entities to come face to face with all of the requirements in CIP v5 and discover the tough problems that may be hiding there.  I’ve heard that some of the six entities are still in the throes of trying to figure out CIP-002-5 (as am I), and it’s unlikely they’ll learn a lot of lessons on the other standards by the end of the study (in fact, I’m also told that the study has actually already ended, with the effort at NERC between now and June going toward documenting the lessons learned).  I’m sure the final document will contain a lot of very interesting and useful points; however, it is highly unlikely it will contain interpretations that will definitively clear up any ambiguity in the wording of CIP Version 5.  There really is no way it could do that.

  1. RSAW’s – Hey, what about these?  Wasn’t NERC supposed to have those out by now?  No, they weren’t.  They were supposed to have them out by October 1 of last year.  They’re still not out, and they’re still “Coming Soon” according to the NERC website.  It will be nice when they come, but I certainly don’t advise anybody to put their CIP v5 compliance program on ice until the RSAW’s are available.  The RSAW’s are delayed, but I can assure you the April 1, 2016 compliance date won’t be. 
And I sincerely doubt the RSAW’s, when they are delivered, will do what many people are hoping they will do: interpret and clarify the language of the v5 requirements.  The RSAW’s for the previous versions of CIP did little more than rephrase the requirements and the measures.  NERC has said the v5 RSAW’s will be different, but I predict that – by the time the lawyers have their way with them – they won’t be much more helpful for interpreting the requirements than the previous ones were.  We’re running up against the same problem I discussed above: There simply is no good way for NERC to circumvent its own processes for revising or interpreting standards.

  1. How about the NERC CIPC?  After all, it was subcommittees of the CIPC that developed the two excellent guidance documents for CIP Versions 1-3: on identifying Critical Assets and Critical Cyber Assets.  Maybe the CIPC will ride to the rescue again? 
This might be a possibility, but I see absolutely no interest in the current CIPC in doing this.  And even if they decided at their next meeting that they would do this, they would first have to constitute the committee(s), develop their charters, have them do their work, approve it, and finally release it.  The Critical Asset guidelines didn’t come out until September2009, right before the December 31, 2009 CIP Version 1 compliance date for the majority of entities; the CCA guidelines came out in June 2010, six months after that date.  The situation would be similar here.[ii]

At this point, it may be clear that NERC itself can’t do interpretations – there is a fundamental structural problem, in that NERC is set up as a body in which the membership drafts and approves all standards and revisions thereto.  NERC can’t violate that process without ceasing to be NERC.  So who or what else could interpret CIP version 5?

  1. “How about FERC?,” you ask...You’re really asking that?  You can’t be serious.  FERC doesn’t interpret NERC standards; it merely approves or remands them. 
  1. How about Scott Mix?  After all he’s the Obi Wan Kenobi of CIP, having been involved with it since the beginning.  I know a lot of entities have called him for his advice.  And with his new grey beard, how could he be anything less than authoritative?  However, I can just about promise you – I haven’t tapped his phone lately, so I can’t be sure – that Scott will never even pretend to make an interpretation of a CIP standard.  He will helpfully point you to CAN’s, CAR’s, other NERC standards, etc. – anything that might shed light on your question.  But he isn’t going to give you an interpretation. 
  1. Here’s a good one: What about the intention of the Standards Drafting Team?  After all, in interpreting a law, Federal courts often look to the debate in Congress that accompanied its passage.  And in Constitutional questions, the parties will often bring up the debates at the Constitutional Convention, the Federalist Papers, etc.  Shouldn’t somebody be able to go through the minutes of the SDT meetings and figure out what led to the choice of wording for a particular requirement? 
That’s a nice idea, but it simply isn’t going to work.  The CSO 706 SDT met over four years, and the personnel changed markedly during that time.  The different issues were debated at different meetings, with different participants.  Most of the drafting of the actual requirements occurred in subcommittee meetings conducted by phone, for which I don’t think there were any minutes.  Even if there were detailed notes of what was said at the SDT meetings, it would be almost impossible to trace the different threads as they were discussed over four years.

More succinctly, the minutes of the CSO 706 SDT meetings were always fairly short and high-level, mostly consisting of statements like “X was discussed”, “Y was discussed”, etc.  Those minutes were simply never intended to provide any guidance when it came to interpret the standards.  This is partly because it would have been very expensive to try to produce a literal transcript of the meetings. 

More importantly, the minutes can’t be used for interpretation because of what I call the fundamental problem with NERC standards (and especially with CIP): The standards are written by engineers, but they’re interpreted by lawyers.  Engineers focus on solving a technical problem – in this case, writing a standard that the committee and the NERC ballot body will approve - and feel their job is done when that has been accomplished.  This means the SDT members – engineers and cyber security professionals – didn’t worry about recording how the wording came to be; they just wanted to come out with something that worked.[iii]  But in interpreting a standard, lawyers want to be able to discern why this particular wording was adopted.  They will get no help from the minutes.

Well, we’ve gone through these players: NERC, the CIPC, FERC, Scott Mix, the SDT…who have we left out?  I’ll give you a clue by asking you a few questions: Why do you want to find an authoritative interpreter of CIP v5, anyway?  It’s so you’ll be able to pass audits, right?  And who does those audits?  Bingo…it’s the regions.  Could they possibly be the ones who interpret CIP Version 5?

You’re so intelligent…Of course, it’s the regions that need to step up to the plate here.  And it seems at least some of them are already doing it.  WECC has already had two CIP v5 “road shows”, where auditors and enforcement staff discussed complying with each of the standards.[iv]  SPP has focused on CIP-002-5 R1 (certainly the most problematic of the v5 standards, IMHO), and provided both a webinar (materials available here) and an excellent hands-on workshop in Dallas that I attended.[v]  I’m sure there will be more interpretation from these two regions, as well as from the other regions.

Of course, the reason that the regions’ interpretations are important is that they’re the ones who will do the auditing.  If your region says this is how they interpret a particular requirement, you would be well advised to interpret the requirement in the same way.  However, there are three big caveats to this:

  1. None of the regions has come out with what I think is really needed: a comprehensive document that addresses the main wording issues in CIP-002-5 and provides an interpretation of each one.  Of course, nobody has come out yet with a list of what those issues are, but they are certainly starting to appear in various forums.  I have expended literally billions of electrons in documenting the wording problems in CIP-002-5 R1 and trying to develop a consistent interpretation; other groups including the North American Transmission Forum and the CIP user groups in FRCC, NPCC and MRO have as well (none published as of yet, however).  
Having spent so much time on CIP-002-5 R1, I would like to start focusing as much on the other standards[vi].   Various people have provided me with serious interpretation questions they have on the other standards.  I would also very much like to hear about questions that have been raised in your mind, and I’ll try to put them all in a post – or maybe a few posts (email me at  Maybe this can at least let the regions know the main issues that need to be addressed in an interpretation document.

  1. Probably the biggest problem with the regions doing the interpretation is consistency.  As you might guess, the WECC and SPP interpretations of CIP-002-5 R1 were worded quite differently (although I think they would both result in the same classification of BES Cyber Systems); I’m sure there will be many more differences as the other regions weigh in on this and the other v5 requirements. 
It really seems to me that the regions need to get together and agree on consistent interpretations of the requirements of CIP version 5.  Of course, inconsistency across the regions will be a huge problem for entities that span multiple regions.  But even for entities that are only audited by one region, it will always be galling to hear that another region has interpreted a particular requirement – which may be a sore spot for that entity – in a more advantageous way than their own region.  A house divided cannot stand, as I believe someone else from Illinois once said.

  1. And having the regions do the interpretation doesn’t solve the most fundamental problem: There really needs to be an interpretation that will stand up in a court of law.  The CIP standards, like all NERC standards, are regulatory law.  If an entity interprets a requirement one way, but ends up being fined because the Regional Entity and NERC interpret it another way, they can take this to court.  And what will the court base its decision on?  The wording of the requirement, nothing more.  So if the court finds the wording of the requirement to be ambiguous, they are likely to set aside the fine, and possibly invalidate that requirement.[vii]  But since I don’t see any other venue for interpretations other than the regions, this is just something that NERC will have to live with. 
On that happy note, I’ll end.  Be sure to send me your interpretation questions.

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

[i] At the initial meeting of the new SDT in Washington in February, Steve Noess of NERC did say that the team might address “no-brainer” problems with the v5 requirements.  He used an example of a word that was clearly the wrong one to use, where the team could decide to change that with just a couple minutes of discussion.  However, I’m not sure there are any of these – the CSO 706 SDT spent over two years drafting and re-drafting v5, and I’m afraid the problems that are in there aren’t simple ones, since the team would have caught them if so.  Yet the new SDT is under quite a time crunch to meet FERC’s deadline of February 2015 to return the changes (actually, the deadline only applies to two of the four FERC directives, but NERC has rightly decided that all the uncertainty about v5 needs to end at some point, so the team really wants to address all four directives by that deadline); I’ll agree that they simply don’t have time to enter into long debates on proper wording of requirements that were already debated by the previous SDT.

[ii] This isn’t to say that, should the CIPC decide to do guidance on – say – CIP-002-5 compliance, that this wouldn’t still be helpful, even though it wouldn’t come out until most Medium and High impact assets had already been brought into compliance.  I have been advocating for a couple years that they should come out with a guidance on the bright-line criteria (first for v4, now for v5).  This would of course be roughly equivalent to their guidance on identifying Critical Assets in the previous versions.  And they could also do a guidance on identifying Medium and High impact BES Cyber Systems. 

[iii] At an RFC compliance meeting last year, a story was told that illustrated very well the difference between lawyers and engineers (and also priests).  I don’t know whether it’s true or not, but it certainly has the ring of truth.  It seems that, in medieval times, a priest, a lawyer and an engineer were all sentenced to be guillotined together.  On the appointed day, the priest was first.  He put his head in the apparatus, the executioner pulled the cord, and the blade came down – but it stopped halfway down.  The priest looked up and exclaimed, “God has spoken!  He doesn’t want me to die.  You must free me!”  And they did.

The lawyer was next.  He put his head in the apparatus, the cord was pulled…and again, the blade stuck halfway down.  The lawyer exclaimed, “I was sentenced to have my head placed in the guillotine and have the cord pulled.  This has been done.  You cannot now repeat the process.  You must set me free!”  And they did.  Finally, the engineer came up.  He put his head in, the cord was pulled, the blade got stuck again.  He looked up, studied the apparatus for a minute and then exclaimed, “Aha.  I see your problem….”

[iv] I wrote about the first of those road shows, in Salt Lake City in early February, in this post.  However, the second road show occurred on March 18 and 19 in Marina del Rey, CA.  I didn’t attend that, but you can see the presentations here.  There was a huge improvement between the two road shows in how they distributed the presentations: At the first show, they combined them all in a single file of 33MB.  For the Marina del Rey show, they posted the individual presentations.  This makes downloading and reading them much easier.

[v] I hope to discuss both the webinar and workshop in an upcoming post on my favorite topic: CIP-002-5 R1.

[vi] I do still intend to have another big post or two on CIP-002-5 R1, since some transmission entities have convinced me that my methodology for compliance with that requirement – as well as the methodologies outlined by WECC and SPP – misses a very important aspect that makes a big difference for how BES Cyber Systems in substations are classified.  I’ll leave you in suspense until I get time to write this, but if you want to email me at, I’ll explain what I mean.

[vii] One of the reasons I have spent so much time harping about the wording problems in CIP-002-5 R1 is that this is the fundamental standard in CIP Version 5.  If a judge invalidated this requirement, it would make the rest of v5 invalid, IMHO.

Sunday, March 9, 2014

FERC Orders Physical Security Standards

On Friday March 7, FERC issued an Order directing NERC to develop one or more Reliability Standards for physical protection of certain critical Facilities in the Bulk Power System.  Here are some of the highlights of the Order:

  1. FERC is giving NERC only 90 days to develop these standards.  Folks, that ain’t much time at all.  There will be a lot of midnight oil burned to accomplish this.
  2. The Commission specifies three steps that must be included in the standards.  The first step is for owners and operators of the Bulk Power System[i] to identify their “Critical Facilities”.  FERC states that “A critical facility is one that, if rendered inoperable or damaged, could have a critical impact on the operation of the interconnection through instability, uncontrolled separation or cascading failures on the Bulk-Power System.”  Moreover, the Commission “expects that critical facilities generally will include, but not be limited to, critical substations and critical control centers.”
  3. The Order states, “The Commission is not requiring NERC to adopt a specific type of risk assessment, nor is the Commission requiring that a mandatory number of facilities be identified as critical facilities under the Reliability Standards.”  So they don’t want NERC to require an Risk Based Assessment Methodology like in CIP Versions 1-3; nor do they want bright-line criteria as in CIP Versions 4 and 5.
  4. They do want grid owners and operators to “consider resilience of the grid” when identifying critical facilities.  They also want them to consider “the elements that make up those facilities, such as transformers that typically require significant time to repair or replace.”
  5. The second step should require owners and operators to “to evaluate the potential threats and vulnerabilities to those identified facilities.”   FERC makes very clear that those threats and vulnerabilities will vary greatly from facility to facility, and they don’t even want NERC to try to figure out what the common threats are to all critical facilities.
  6. In the third step, the owners and operators of critical facilities should be required to “develop and implement a security plan designed to protect against attacks to those identified critical facilities based on the assessment of the potential threats and vulnerabilities to their physical security.”   
  7. So the whole approach of NERC CIP – that all Critical Assets (in v1-3) face similar cyber threats and should apply the same controls, or that all High, Medium and Low impact assets face similar threats and require the same controls (as in v4 and v5) – is out the window.  Been there, done that, got the T-shirt.  We’re now in a purely risk-based standards world.[ii]
  8. They state in a few places they are not expecting that a large number of facilities will be identified as critical. 
  9. They direct NERC to develop a procedure so that compliance information remains confidential, yet is still shared among those who need to see it at NERC, FERC, and the Regional Entities.
  10. They further require that what an entity does for each of the three steps should be reviewed by “NERC, the relevant Regional Entity, a Reliability Coordinator, or another entity.”  This is of course interesting because NERC and the RE’s will be playing two roles here: they will be auditing compliance with the new requirements, but they will also be providing advice to the entities on how they might improve their identification of critical facilities and threats and vulnerabilities to those facilities, as well as improve their mitigation plans.  This of course is very different from CIP (I’m not sure how it compares to the other NERC standards), where NERC and the RE’s bend over backwards not to give any specific compliance advice to individual entities.  I think FERC feels the threat here is much too serious to start taking a rigorous compliance mindset, which will definitely greatly slow down the whole process of making the grid more physically secure.
  11. I recommend you read Commissioner Norris’ separate statement, which is attached to the end of the Order.  He makes three very good points – while still concurring with the Order.  Since I want to get this posted, I won’t restate those points here.

March 12: I heard from a couple parties this week that the 90-day timeline FERC gave to NERC for developing the new standard(s) isn't realistic, since an SDT needs to be constituted and then meet to draw up the standards.  These then need to be reviewed by NERC, posted for ballot, and hopefully approved on the first ballot. Finally, the NERC Board of Trustees needs to approve them, before they are sent to FERC.  How could all of this possibly be accomplished in 90 days?

First off, there is a precedent for this.  When FERC approved v2 in 2009, they ordered NERC to make one change - adding a requirement for continuous escorting of visitors within the PSP - and come back with that in 90 days.  NERC went through all of the above steps, and came back with the change (in a new set of standards called CIP v3) on time (this of course was a less controversial step than what FERC is now asking for, which is a completely new standard).

More importantly, when NERC is under a FERC deadline to do something, as they are now, they have to do it – period.  If you read sections 309 and 321 of the NERC Rules of Procedure, you will see that, if a standard ordered be FERC isn’t drafted and approved in a ballot on time, the Board can simply order the staff to write it, then approve it and send it to FERC.  So if anybody wants to bet me that the physical security standards won’t be approved and sent to FERC by the 90-day deadline (and that may mean 90 days after publication in the Federal Register, not 90 days after the order was issued), let me know.  This is almost as sure a bet as that the Cubs won’t win the World Series this year or that the world will stop spinning on its axis, which come to think of it would probably happen if the Cubs did win the Series.

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

[i] FERC always refers to the Bulk Power System, while NERC refers to the Bulk Electric System.  I’m sure there are wonderful reasons why this is the case, but I’ve decided that learning why this is the case doesn’t have to be one of my priorities in life.

[ii] Those of you familiar with CFATS will recognize this approach: first decide what are the critical facilities, then identify the threats to those facilities, then mitigate those threats.  I’m not saying this would be a better approach for cyber security standards, or even that FERC wouldn’t want NERC to use the prescriptive CIP approach if they felt they had the time that would be required to develop prescriptive standards.  But FERC clearly feels they are under the gun (no pun intended) here, and the gun is of course the Metcalf substation attack in California.  They want standards to be developed quickly, and this is really the only way to do it.