CIP v7 and the Final (?) Compliance Schedule for CIP v6.3940

Today, NERC posted five revised CIP standards (and the related Implementation Plan and Definitions documents) for comment.  These will constitute CIP v7, and will be balloted Dec. 30 – Jan. 8. 

My initial birth announcement for CIP v7 only referred to twins – that is, at the time it looked like only two CIP v6 standards would be revised to v7, CIP-003-6 and CIP-010-2; they will now be CIP-003-7 and CIP-010-3.  However, in their never-ending quest for perfection, the SDT decided that three other requirements also needed to be revised: CIP-004-6, CIP-007-6 and CIP-011-2; these will now become CIP-004-7, CIP-007-7 and CIP-011-3.[i]  In addition, the Implementation Plan and two Definitions documents (for the Low impact requirement changes) are also changing.  This means there are now eight documents that need to be approved for CIP v7; instead of giving birth to twins, NERC is the Octomom.  We’ll all have to pray for a successful delivery.

First Things First

The first thing I want to do in this post is to update my recent post in which I designated the new compliance version of CIP – that is, the version you’ll actually have to comply with – to be v5.7879 (there was actually an infinitely repeating decimal, 5.78787878….  I decided this wouldn’t work too well in compliance documentation, so I rounded it off).  Little did I know that less than three weeks later I would have to change that number.

I can’t use the same algorithm to compute the new number, since that assumed there were only going to be two versions of the CIP standards to comply with at one time.  Silly me, I once again underestimated NERC’s ability to make everything as complicated as possible – as you can see, the industry now has three versions to implement simultaneously.[ii] 

So I’ve come up with a new algorithm: I multiply the number of requirements in each version (7 in v5, 6 in v6 and 20 in v7) by the version number (5, 6 or 7) and divide their sum by the total number of requirements (33).  This yields 6.39393939…, which I’ll round off to 6.3940 just because I’m that kind of guy.  So this is the new compliance version: 6.3940!  I won’t be so bold as to say this time that this isn’t likely to change, since I thought that before.  I wouldn’t be at all surprised if some new glitch causes the SDT to have to revise one or more of the v7 standards; that will yield – are you sitting down? – CIP v8!  Speaking of which, maybe I’ll have a V8™ now.

What Has Changed?

The second thing I want to do is discuss the changes that are in the new v7 standards and the other three documents.  Briefly (or as brief as I can be, which isn’t saying much), here are the substantive changes (you can find the documents here):

Implementation Plan:  The substantive change here is that the compliance date for CIP-003-7 Attachment 1 Section 2 (physical access controls for Low impact assets) has been pushed back from April 1, 2018 to Sept. 1, 2018.

CIP-003-7:  The changes from v6 are some wording changes in Attachments 1 and 2, and a lot of changes in the Guidance; of course, there are more substantial changes from v5, since this standard now includes the Low impact requirement changes ordered by FERC.

CIP-004-7:  There has been a change in one requirement part, minor VSL changes, and a few new sentences in the Guidelines and Technical Basis section.  All of these changes are related to the new requirement for Transient Electronic Devices and Removable Media.

CIP-007-7:  There are small VSL changes and two sentences in the Guidance (again, all related to Transients).

CIP-010-3:  From v6, there are changes in the VSLs, Attachments 1 and 2, and the Guidance.  The big change from v5 is the requirement for Transient Electronic Devices and Removable Media, CIP-010-3 R4.

CIP-011-3:  The only change in this standard is in the Guidance section.

Definitions:  CIP v6 had two documents with new Definitions, related to the new Low impact requirement.  These definitions have been tweaked some.

The New Implementation Schedule

As I mentioned above, there has been one change to the implementation schedule.  Therefore I revised my recent post on the schedule for CIP v5.7879, which I'm now calling 6.3940 of course.  So please go there to get the Final (???) implementation schedule for CIP v6.3940.

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

---

[i] This leaves only two standards proudly bearing the CIP v6 designation: CIP-006-6 and CIP-009-6; this is down from eight v6 standards a week ago.  My, how the great have fallen!

[ii] I’ve come to believe that some NERC managers’ bonuses are based on their ability to make things as complicated as possible.  This would perhaps explain why we’re seeing this sudden flurry of complicating activity toward the end of the year – the managers are panicking as they suddenly realize NERC CIP compliance isn’t quite as complicated as it could possibly be.  I must say, if my suspicion is true, these managers have richly deserved their bonuses this year!  I never thought it could be this complicated.

Follow-Up to Last Week’s Serial Post (not Post Cereal)

In my post on serially-connected devices last week, I discussed the question whether devices (usually in substations) that are serially connected to an RTU or similar intermediate device[i] that participates in external routable connectivity (ERC) do themselves participate in ERC for the purpose of CIP v5.  My personal opinion[ii] is that, if the end device communicates externally through that intermediate device (as described in the CIP v1 CCA Identification guidance document I referenced), then it does have ERC.  If it doesn’t so communicate, it doesn’t have ERC.

Of course, then the discussion becomes what “communicates externally” means.  There’s a lot of room for debate on that topic – as I found out from a few other parties in emails last week. One distinction that seems to be important is whether the intermediate device simply translates the incoming routable messages into a serial protocol for the end device, or whether the intermediate device does something like polling of the end device, meaning that incoming routable messages aren’t passed on in any way.  A terminal server might be an example of the first device, while an RTU might be an example of the second.

However, this distinction would go away if it were possible to hack through the RTU to the end device – because in that case the end device would be able to communicate externally (not by intention of course, but that’s not the issue in cyber security).  In the post, I state that I’m assuming “If someone were to hack the RTU through the external routable connection, they couldn’t access the connected device directly.”  A footnote to this sentence says that the entity that decides to use my “guideline” for ERC, and therefore excludes serial devices connected to an RTU that communicates routably outside the facility, probably needs to be prepared to convince the auditor that it isn’t likely this hack can occur.

So guess what happened?  You’re right…The next day I got an email from a cyber security professional at a large IOU, providing an example in which it would be possible to do exactly that – namely, to hack a routable connection to a remote RTU, that is itself connected serially to one or more local devices, and attack one of those serial devices.  Here is what he said, although I have removed the manufacturer and model name to protect the guilty (and to save my a__ from getting sued):  “You can remotely communicate directly with any relays connected serially to a (particular manufacturer/model), log in to the serial device and reprogram or (do) anything you could do to it if (physically) connected directly through the serial connection (port), if it is not properly configured.”

The moral of this story is that, if you’re going to claim that a serial device – set up with an intermediate device as discussed above – doesn’t participate in ERC, you need to convince the auditor that it’s very unlikely the device could actually be attacked.[iii] 

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

---

[i] This isn’t to be confused with the Intermediate System – a new NERC defined term – that forms the basis of the new requirement for Interactive Remote Access, CIP-005-5.1 R2.

[ii] There is supposed to be a NERC Lessons Learned document coming out soon (in draft form) on this issue, but you can’t count on it to a) provide a definitive answer or b) be finalized in time for you to start your substation compliance work (and you definitely can’t count on it having the same status as an Interpretation arrived at through the normal 2-3 year RFI process).  If you need an answer now, you should consider the “Roll Your Own” approach that I have been discussing lately, starting with this post.

[iii] You might do this by demonstrating that there haven’t been any such vulnerabilities identified by ICS-CERT or similar organizations.

“The Intent of the SDT” and other Just-So Stories

In arguments over the finer points of CIP Version 5, people will often bring up something called “the intent of the Standards Drafting Team” to justify their opinions.  I have been skeptical of such arguments for some time, but this was really brought home to me this week as I discussed – via email – the transfer-trip relay issue (which turns out to be a lot more complicated than I’d thought – or than I believe NERC thought – a few months ago.  But I don’t think there’s ever been a NERC CIP issue I’ve looked at that didn’t turn out to be more complicated than I’d realized at first. I will do a new post when I think I know what this discussion is all about).

The email discussion was with two quite knowledgeable and respected actors in the NERC CIP world.  They were arguing on completely different sides of the issue at hand.  Both were making quite persuasive arguments, and both were invoking the “intent of the SDT”.  One referred to conversations he’d had with a couple of the principal SDT members; the other referred to minutes from a couple of the SDT meetings.

So how could you decide which of these two people better understood the intent of the SDT?  You probably guessed the answer: you can’t.  There is simply no good way to discern the intent of the SDT other than in the two records they have provided us: the CIP v5 standards themselves and the “Guidance and Technical Basis” sections included with each standard.  These were voted on and approved both by the SDT members and the NERC ballot body.  If the members of the SDT didn’t make their intent clearly known in these documents, they don’t now get a second chance to “clarify” what they said.  That ship has sailed.

Someone may point out that courts examine the intent of Congress all the time when ruling on the meaning of a law.  What’s different about the SDT?  The difference is that the debates[i] in Congress are recorded word-for-word, and a record is made of how each Congressman or Senator voted on each bill.  If I want to discern the intent of Congress regarding a particular bill, I just need to look at what each person said who ended up voting for that bill.  This of course wasn’t done for SDT meetings; there wasn’t even a summary of what each person said, or of the differing opinions that were offered on a particular topic. 

This isn’t to say that someone did something wrong; I don’t think other NERC meetings (other than perhaps the Board of Trustees meetings) are recorded any differently.  It just means that the meeting minutes were never intended to be used as a record in a legal sense; it also means that people can’t come back now and mine those minutes for compliance guidelines.  Furthermore, it means that SDT members can’t now pontificate on what the SDT meant.  How could one ever discern whether they are right or not?

Moreover, consider the following[ii]:

1. The CSO 706 SDT (the official name of the v5 SDT) met over four years, and the personnel changed markedly during that time.  The different issues were debated at different meetings, with different participants (the makeup of the SDT changed substantially over the four years, including the Chairman and Vice-Chairman).  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 at all.  And 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, by a changing cast of characters.

2. 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 produce a literal transcript of the meetings. 

3. Most 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.

4. Of course, talking to individual members of the SDT – no matter how high-ranking they were – also doesn’t do any good.  They are simply individual members and their opinions are their own.  The SDT members finished their work in 2012.  If they want to influence current debates, let them do so – but their opinions shouldn’t be given any more weight than mine or yours.

You might ask why this is so important.  If the SDT members want to give us their advice now, however unofficial it is, what harm is there in that?  My answer is: There’s no harm, as long as you don’t attribute any more significance to that advice than what you read in my posts, or what someone from the utility next door tells you; in other words, as long as you don’t treat this advice like you would advice that’s coming from NERC or your region.  But there certainly would be harm if an auditor tried to issue a PV based on a claim that he/she knows “the intent of the SDT”.  If that happens, you need to raise a big red flag immediately.

Of course, we now come back to the question of how the various ambiguities or inconsistencies in CIP v5 do get resolved, absent some sort of action by NERC.  Folks, that’s what my “Roll Your Own” posts are about.   As I’ve said many times, this isn’t a wonderful situation – where entities need to come up with their own interpretations of the meaning of requirements that can potentially result in $1 million/day penalties if violated – but that’s the way it is.

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

---

[i] I’m engaging in a quaint old idea – that Congress “debates” bills.  Nowadays, members make statements for the media.  I think it has been many years since there was a real debate in Congress.

[ii] In the next few paragraphs, I’m restating an argument I made in this post from last March.  The author gave me permission to do this, albeit grudgingly.

[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 fell – 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, and the blade got stuck again.  He looked up, studied the apparatus for a minute and then exclaimed, “Aha.  I see your problem….”

Roll Your Own, Part V: Serial (killers?)

If you haven’t read at least the first post in this series, I recommend you go back and do that..... But in case you didn’t listen to what I just said, here is the premise of this series:

1. There are many ambiguous areas in CIP Version 5 – definitions that are missing, requirements that aren’t clearly written or are outright contradictory, etc.[i]
2. NERC is trying to plug some of these gaps, but they’re running around like the little Dutch boy, sticking their fingers in as many holes as they can, while new ones appear every day.
3. Meanwhile, entities need answers to these issues now – more to the point, they really needed them many months ago.  The April 1, 2016 compliance date for Highs and Mediums isn’t going away – in fact, by my calculations it gets one day closer every day.[ii]
4. That is why it seems a number of entities have independently hit on the same solution to this problem: They’re developing their own definitions or interpretations to fill the gaps that they run into.  However, they’re also making sure to document their work, as well as justify their interpretations in the light of any other guidance that might currently be available.  As shown in this and this post, I’ve gotten support from auditors for this stance, as well as other NERC entities.

So today I wish to address another area where I think NERC entities should consider “rolling their own”.  First, I’ll tell you why I’m bringing this up.

I’ve started to do “CIP Version 5 Workshops” for several entities, and have more lined up.  In these, I spend a few days to a week onsite, going over whatever they always wanted to know about CIP Versions 5 and 6 (and now 7!) but were afraid to ask.[iii]  I recently did workshops for two different Transmission entities in two weeks, and was struck by how similar their issues were.

To be specific, both of them had the same top two concerns about CIP v5.  The first is the transfer-trip relay issue.  I’ve written about that in a couple posts (including this one).  I thought the question was pretty settled, but I now realize there’s still misunderstanding about what NERC’s “ruling” applies to and what it doesn’t, plus disagreement over whether NERC’s reasoning was valid at all. But that’s for another post.

The second concern has to do with serially-connected devices in substations, connected to a device like an RTU that might or might not have external routable connectivity.  However, there are really three questions people have about the status of these devices, and it’s important to keep them straight.  While in my opinion the first two questions have straightforward yes/no answers, the third question requires either rolling your own interpretation or waiting for NERC to maybe (or maybe not) kinda sorta address the problem in their upcoming Lessons Learned document.  The choice is yours.

The first question people ask is, “Can a serially-connected device in a substation (a digital relay, etc) be a BES Cyber Asset?”  And the answer to that is an unequivocal yes.  If you’ll go back to the BCA definition, you’ll see it nowhere makes reference to the device’s connectivity, only to whether its loss or misuse can impact the BES within 15 minutes (when needed).  If it does impact the BES in 15 minutes, it’s a BCA; if not, it’s not.  Whether it’s serially or routably connected, or not connected at all, doesn’t matter.

Next question: Given that the serially-connected Cyber Asset is a BCA, does it need to be within an ESP?  This is a good question, since in CIP Versions 1-3 it would have had to be within an ESP if it was a Critical Cyber Asset.[iv]  But CIP-005-5.1 R1 says nothing about BCAs or BCSs having to be within an ESP.  An ESP has to include any routably connected Cyber Assets[v], but doesn’t have to include anything else.  So our serially-connected relay doesn’t have to be in an ESP.  Practically speaking, it’s kind of hard to understand what it would mean to say that the relay did have to be within an ESP, since the definition of ESP (balloted with the v5 standards) refers only to devices that are routably connected.

Now we come to the real question: What if the serial relay is connected to an RTU that is itself routably connected to the outside world?  Does it now itself participate in external routable connectivity (which I’ll abbreviate ERC from now on)?  Of course, this is a big deal, since the number of requirements that a BES Cyber System will have to satisfy is much larger if it participates in ERC than if it doesn’t.

This is quite a different question.  NERC does have it on their list of “Planned Lessons Learned”, so there will presumably be something out on it in the future.[vi]  And if you’re not in a big hurry, you might just want to wait for that (however, keep in mind that the Lessons Learned documents don’t have the status of true Interpretations - which take several years to produce since they have to be balloted by NERC and approved by FERC.  And also keep in mind that the first posting will just be a draft for comment, so the final LL document won’t be out for another month or so after that.  And lastly, keep in mind that the document may not take a definite stance on this issue anyway, either yes or no).

But let’s say you’ve been spooked by my saying there are only 332 compliance days left and you want to finalize your BES Cyber System identification in your substations now - so you can then go on to figure out what you actually have to do to comply by April 1, 2016.  This means you do need to roll your own answer to this question.  Where can you turn to at least get started on this?

Fortunately, there is a well-written NERC document that can provide some help on this question.  It’s the guideline on identifying Critical Cyber Assets that NERC published in 2010, that applied to CIP v1-4.    I refer you to page 28, where – in a section titled “Serial Cyber Assets that are Accessible via Routable Protocol” - it states “..serially connected Cyber Assets can meet the qualifying connectivity criterion in Requirement 3.1, if a routable connection is used to communicate outside the preliminary ESP.”[vii]  R3.1 is the provision, in CIP v1-3, that a cyber asset must participate in ERC to be a CCA.

I must admit that for the last four years I’ve been interpreting this to mean, “If the RTU has external routable connectivity, then any device attached either serially or routably to it does itself have ERC.”  However, a customer recently convinced me otherwise by pointing to the clause “if a routable connection is used to communicate outside the preliminary ESP.”  He pointed out that, at least for the RTU’s that his entity uses in their substations, the devices connected to the RTU don’t actually communicate with the external world.  All the RTU does is poll the device and pass those results up to the SCADA or EMS system.  If someone were to hack the RTU through the external routable connection, they couldn’t access the connected device directly.[viii]

I’m not going to tell you how to roll your own interpretation of this issue.  But this might be something you want to use: “If a BES Cyber System is connected serially to an RTU (or similar device) with ERC, it only participates in ERC if it communicates with devices outside the substation[ix].”[x]

December 13: This post turned into a series of four, with some good "guest speakers" weighing in. The second in the series is here, and the final post, which tries to summarize the discussion, is here. But they're all worth reading.

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

---

[i] I’m not saying that v5 is totally unique in this regard, since v1-v3 both had a lot of ambiguity.  I think it’s more serious in v5, primarily because CIP-002-5.1 is really written from two different points of view, which never seem to get along or even try to reconcile with each other.  A lot like Congress these days.

[ii] In fact, there are 332 working days between today (Nov. 16, 2014) and April 1, 2016.  I considered putting a standard header on all my posts from now on, showing the working days left ‘til compliance.  But I decided that might get boring – as well as depressing.  Nobody would want to open up a post.

[iii] I started doing these because I realized some entities weren’t moving on v5 yet – or were just making faint stabs in that direction – because they were in effect paralyzed by the questions in their minds.  I don’t pretend to have the answers for what a particular entity needs to do; that’s up to them in the end.  But I can help facilitate the discussion among the different groups involved, and make sure it’s based on the latest facts about the new standards, their interpretations, their implementation schedules, etc.  If you’re interested in this for your entity, please email me at talrich@hotmail.com.

[iv] I’m gliding over a point here, which was that, without external routable connectivity, there wouldn’t be any CCAs at the asset in CIP versions 1-3.  But a cyber asset could have ERC and still be serially connected, as we’ll see in a moment.

[v] Remember, this requirement is talking about a local routable network, not external routable connectivity.

[vi] NERC phrases the question quite well: “Are serial based systems with local serial connections considered to have External Routable Connectivity if they are remotely accessible via routable protocol?”

[vii] I do recommend you read the entire section of the document.  It’s just four paragraphs, for heaven’s sake.

[viii] Of course, the key here is whether the customer is actually right that there is no way to hack the connected device – the relay, etc. – through the RTU.  I simply don’t know enough to say whether that’s the case or not; I’m sure there could be cases where this could happen.  So anyone rolling their own serial definition should make sure they have an answer to this question, if the auditor asks it.  And documenting that answer would be a great idea.

[ix] I’d say it’s likely that almost all of the devices to which this question applies will be in substations.

[x] Note I’m not saying “outside the ESP” as in the V1 guidance.  As has been noted, a serially-connected BCS doesn’t itself have to be included in the ESP.

Welcome CIP Version 7!

This post will make a lot more sense if you read yesterday's post.  To the extent that any of this makes sense, of course.

It's not every day that I get to announce a new birth, but I'm pleased to announce that an email from the CIP v5 Revisions Standards Drafting Team today made it official: the two standards - formerly part of v6 - that they are revising now in preparation for hopefully final approval by the NERC ballot body and the Board of Trustees will be called Version 7!

However, it's possible the paternity is in doubt, because the birth announcement didn't actually use the phrase "CIP Version 7".  Instead, it pointed out that "the SDT will use -7 and -3 for the posting of the revisions addressing the low impact and transient devices directives."

Now that's NERC-speak.  Since I have become a fluent translator of that arcane language, here is what it means in English: "Since we submitted to the BoT (on Nov. 10) a complete set of CIP Version 6 standards, including standards labelled CIP-003-6 and CIP-010-2, we can't use those same numbers for the revised versions of CIP-003 and CIP-010 that we're working on now. Therefore, we need to call these new versions CIP-003-7 and CIP-010-3.  And that means that these are the first (and probably only) standards in the CIP Version 7 family!  We'll have a cake in the lunchroom at noon."

But there is a more serious implication of this.  Just last week, I calculated the exact CIP version number that NERC entities will have to comply with over the next few years: v5.7879.  I regret that number now needs to be revised, since there will be two fewer v6 standards in the compliance mix, plus two new v7 standards.

Unfortunately, the algorithm I used to compute the version number didn't contemplate that there could be three versions to be complied with at the same time, so I need to develop a new algorithm.  I will of course consult with the best mathematicians on this, but if anyone wishes to send me what they think the correct algorithm should be, I would like to see that.  Of course, all royalties from its use will go to you, the inventor.  I calculate you should be able to afford a pretty nice Snickers bar, although you may have to add a dime or two to make up the cost.

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

As if You Weren’t Confused Enough….

Nov. 11:  An email from the SDT today showed that I needed to adjust items 13 and 14 below, to show that CIP v7 is now officially upon us, not just a theoretical possibility.  I've done so.

My two most recent posts, on CIP version 5.7879 and its complicated compliance schedule, have drawn a lot of interest – although I might call it morbid fascination, since I think a lot of people just realized that compliance with CIP versions 5 and 6 is (even) more convoluted than they had thought.  But it turns out that I was in fact leaving a lot of complication out.  If you’ve heard enough about NERC complications for a while, I suggest you not continue with this post.  If you continue anyway, I wish to point out that I am not responsible for any heart attacks, suicides, etc.  You’ve been warned.

Some of you may have noted my second footnote in the second post (on the compliance schedule), where I showed people where to download the v6 standards, but said they should ignore the “-X” standards, since that just introduces a lot more complication into the discussion.  I said this because I wanted readers to download the standards that are closest to what they will ultimately have to comply with, not the stalking horses that bear the “-X” suffix.

However, the SDT today sent out a nice email saying that the v6 standards (or the “CIP Version 5 Revisions”, as the SDT keeps calling v6, presumably as a way of showing they have a sense of humor) were all approved in the most recent (the third) ballot, and they would be sent on to the NERC Board of Trustees for approval.  They listed the standards that had been approved, and of course none of them had “-X” after them.

This prompted one knowledgeable friend to email me saying something to the effect of “WTF?” (which I believe stands for Western Transmission Forum).  His point was that I’d just said in the post that two of the v6 standards, CIP-003-6 and CIP-010-2, were not going to be submitted to FERC now, since the SDT wanted to revise them due to the comments they’d received at the last posting.  However, here was the SDT saying they were going to submit all the v6 standards, including those two, to the BoT right away! 

The reason he was confused was quite understandable, and it has to do with the “-X” standards that I didn’t want to discuss in the post yesterday.  Here is what led to those standards being developed and posted:

1. In Order 791, FERC gave NERC four mandates for changes to CIP v5:
1. Remove “Identify, Assess and Correct” from the 17 requirements where it was found;
2. Provide protection for “communication networks”, referring specifically to cabling and things like hubs that connect devices within the ESP, but are themselves outside of a PSP;
3. Provide protection for “Transient Electronic Devices”; and
4. Provide more specific requirements for Low impact assets.
2. For the first two changes, they specified a deadline, which turned out to be February 3, 2015; FERC didn’t set a deadline for the third and fourth changes.
3. The SDT developed the revised standards, and the first draft was balloted in July.  The standards with the IAC and communications networks revisions passed; CIP-010-2 (containing the Transients requirement) and CIP-003-6 (containing the Lows requirement) did not.
4. The second drafts of CIP-010-2 and CIP-003-6 were posted for comment in September, and balloted in October.  However, the SDT didn’t just post these two standards; it also posted five standards labeled CIP-003-X, CIP-004-X, CIP-007-X, CIP-010-X, and CIP-011-X.  It asked NERC entities to vote on all seven standards (plus some other documents you can see on the v6 web page).
5. The reason for posting these was that the SDT was concerned that CIP-010-2 and CIP-003-6 might not pass on the second ballot.  They would then require revisions and a third ballot; if they passed that, it would still be followed by the mandatory Final ballot (formerly called the “Recirculation ballot”), where hopefully all the standards would pass a final time.
6. The problem was that all of this might delay BoT approval until after February, meaning that NERC would have missed FERC’s deadline for the first two mandates.
7. So the SDT came up with the “-X” strategy, in which it would post versions of the standards that didn’t have any of the language related to the Transient and Low impact requirements, and ask NERC entities to approve these.[i]  That way, if CIP-003-6 and/or CIP-010-2 went down to defeat, NERC would still have a consistent set of v6 standards ready for FERC by the Feb. 3 deadline.[ii]
8. But it gets more complicated here (I’m sure you’re glad to hear that).  It turns out CIP-003-6 and CIP-010-2 did pass the October ballot; yet the SDT recently decided they needed to be balloted again anyway (see the second part of this post from last week).  Why did they do that?  Because they felt that some of the comments they’d received in the September-October posting were worth considering for changes to CIP-003-6 and CIP-010-2; therefore, they thought it was worthwhile to take the time (and another ballot) required to improve them.  They are currently working on just that.
9. This is why the CIP-003, -004, -007, -010 and -011 standards posted for the “Final” ballot (Oct. 28 – Nov. 6) included the “-X” versions, not the v6 versions; there wouldn’t have been a consistent set of standards any other way.  These standards will be approved by the BoT this month and packaged up with a bow, awaiting the decision to send them to FERC.
10. However, the BoT will not send them to FERC right away.  This isn’t because NERC worries they’ll get lost in the Christmas snail mail rush.  Rather, NERC and the SDT are hoping that the revised  CIP-003 and CIP-010 will easily pass the next ballot.  At that point, the “-X” standards will be tossed in the trash (recycled, I hope) and these two standards will be reunited with their siblings that passed the first ballot, namely CIP-004-6, CIP-006-6, CIP-007-6, CIP-009-6, and CIP-011-2.  The whole family will then be balloted for another “Final” ballot[iii], quickly approved by the BoT, and sent over to FERC by a courier jumping on the next Metro train in DC (OK, maybe he’ll take a cab; they’re pretty cheap in DC).  And this should all happen pretty easily by Feb. 3.
11. However, let’s consider: What if the NERC ballot body decides they don’t like the new CIP-003-6 and CIP-010-2, and rejects them on the next ballot?  Then the SDT needs to consider the new comments, convene a few meetings, and come up with new versions for the fourth regular ballot.  And if that doesn’t work, they’ll keep repeating the process until it does work.
12. However, this will likely occur too late for NERC still to make the Feb. 3 filing deadline.  This means the BoT will have to go back to the set of standards they will approve this month (i.e. the ones including the “-X” versions) and send those over to FERC as CIP v6. 
13. Of course, it’s still certain that the revised CIP-003 and CIP-010 will finally be passed by the NERC ballot body, approved by the BoT, and sent to FERC.  Now, here’s the punch line (and the extra credit quiz): What version will these two standards be called?  
14. If you answered “CIP version 7”, you get a gold star to stick on your forehead and show Mommy (she’ll be very proud).  An email to the SDT Plus List on Nov. 11 confirmed that these two standards will be balloted as CIP-003-7 and CIP-010-3.  These will of course replace CIP-003-6 and CIP-010-2 in the set of CIP standards that need to be complied with.  And this, boys and girls, means entities will have to comply simultaneously with three different CIP versions!  Now, doesn’t that sound like fun?
15. And what does this mean the next version of CIP will be?  Oh, you’re so smart…It will be v8!  Hopefully we'll get a few years before we have to worry about that.

There must be an easier way to make a living than writing about NERC…Oh wait, this isn’t how I make my living!

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

---

[i] It should be clear why CIP-003-X and CIP-010-X were posted, since those are the two standards where the Transient and Low impact requirements reside.  But the SDT also posted CIP-004-X, CIP-007-X and CIP-011-X.  It seems all three of these standards (which had already passed on the first ballot in their “-6” versions) contained small pieces of language related to the new Transient requirement; so they also needed to be “cleansed” of their Transient language, in case CIP-010-2 didn’t pass.  These three standards were in version 6 in the first place because they contained “Identify, Assess and Correct” language that was taken out to meet FERC’s first mandate.

[ii] Remember that the Transient and Low mandates didn’t have a deadline, but the other two mandates did.

[iii] Although I’m not sure how you can have two Final ballots for one version of the standards.  This is clearly beyond my pay grade.

The Compliance Schedule for CIP Version 5.5

Jan. 21, 2016: Because FERC didn't approve the CIP v6 standards by the end of 2015 but instead approved them today, the CIP v6 dates are mostly moved back by one quarter. Therefore, please see this post for the revised schedule (although the first part of the post below is still accurate, including the four "complications" listed. These complications still apply - as if the compliance schedule needed further complication!

Feb. 16, 2015: This post originally updated the post I did in July that addressed the timeline for compliance with CIP versions 5 and 6, which I called “Version 5.5” at that time.  I have just updated the original version of this post from November, since that included compliance with standards that were part of CIP v7 (I had renamed it "v6.3940" to reflect that fact).   The text of NERC's filing of the v5 revisions with FERC on Feb. 13 makes it clear that v7 is gone, and all of the "v5 revisions" now bear v6 suffixes (i.e. "-6" or "-2"), as they all did before last November.  So I'm going back to "v5.5" as the designation of the CIP "version" that entities will have to comply with in the coming three years.

In other words, here is a comprehensive list of the CIP standards that NERC entities will have to comply with, replacing CIP v3.  The rest of this post outlines the very complicated schedule for implementing these standards.

v5:
CIP-002-5.1
CIP-005-5
CIP-008-5

v6:
CIP-006-6
CIP-009-6
CIP-003-6

CIP-004-6
CIP-007-6
CIP-010-2
CIP-011-2

The sharp-eyed reader may have noticed from the title that I’m no longer calling this a discussion of a timeline, but rather of a schedule; this is because I think the word “timeline” is no longer very helpful in describing when NERC entities will need to comply with the new CIP versions.  Let’s go back to ancient history:  In the CIP v5 Implementation Plan, there were two dates, one for compliance with all of the requirements in all of the standards except CIP-003-5 R2, the other for compliance with that requirement (the former date was the “High/Medium” impact date; the latter the “Low” date).  Due to when FERC approved v5, the formulas yielded April 1, 2016 for Highs and Mediums and April 1, 2017 for Lows.  Even this structure was more complicated than it was for CIP versions 2 and 3, where there was a single compliance date.[i]

So how many compliance dates are there in CIP version 5.5?  There are now five, but saying that still greatly understates the complexity of the schedule.  This is because, while there was only one compliance item tied to each of the two dates in v5 (i.e. a total of two items), there are now between one and eight items corresponding to each of the v5.5 dates, for a total of fifteen compliance items in all.  That’s why, instead of providing a timeline (which would be a mess to display), I now prefer simply grouping under each date the items that have to be complied with on that date.  That is what I will present below.

There are four further complications in the v5.5 plan.  I will leave these out of the discussion of the compliance schedule, but want to point them out:

1. The v5 plan included dates for “Initial Performance of Certain Periodic Requirements”; these are the dates by which you need to perform each of the annual (i.e. 15-month) or quarterly requirements.  Since these are in the v5 Implementation Plan, they refer just to the v5 standards; however, the v6 Implementation Plan (which is the same as the one linked, although it no longer contains any references to v7 standards - I don't think NERC has released the "new" v6 plan, although it is included in the v6 filing.  Since that filing is 3300 pages, I wouldn't recommend to my worst enemy that they download the file to find the Implementation Plan buried in it) simply refers to the v5 plan for the Initial Performance dates.  This means that, to determine these dates for the v6 plan, you have to go back to the v5 plan and fill in the appropriate v5.5 standard numbers (e.g. CIP-002-5.1, CIP-003-6, etc. as I listed them above). 
2. In the v5 plan, there’s a table for “Planned or Unplanned Changes Resulting in a Higher Categorization”; this refers mainly to new assets that are acquired or commissioned.  Again, the v6 plan simply refers you back to the v5 plan for this.  There was a similar provision for versions 2 and 3, contained in a separate document whose acronym was “IPFNICCANRE”.
3. The v6 plan includes a section (consisting of a single sentence) providing for “Unplanned Changes Resulting in Low Impact Categorization”.  This is a new concept in CIP v6; it didn’t appear at all in the v5 plan, perhaps because complying for new Low impact assets wasn’t a big deal under v5 given what was required (or not required) by CIP-003-5 R2.
4. Of course, the implementation schedules for Canada are different than for the US.  Those vary by province and not all the provinces are implementing v5 (at least not yet).  Even the ones implementing it are implementing different versions (since the FERC-approved standards have no force in Canada, each province is free to modify or ignore any NERC standards, or not implement them at all) – except for probably Ontario and maybe New Brunswick, which tend to follow the FERC-approved standards almost to the letter.

Before I lay out the implementation schedule for v5.5, here is a caveat: Most of the rules in the v6 plan say something like “April 1, 2016 or the first day of the first calendar quarter that is three calendar months after the date that the standard is approved by an applicable governmental authority…”  In the schedule below, I have always taken just the fixed date from these rules, since the only way the other condition could happen would be if FERC delayed approving v6 for maybe nine months after NERC submits it (which will be before Feb. 2015).  Since FERC asked for these new requirements and has been closely following their development, I think it’s likely they’ll approve them fairly quickly once they receive them from NERC.

So finally, here are the five compliance dates and what you have to comply with on each date, along with short explanations of the different items – that is, assuming I understand why they’re there (there's at least one that I simply don't understand).

April 1, 2016

For Mediums and Highs, this is the date for compliance with:

•          CIP-002-5.1, CIP-005-5 and CIP-008-5 – Highs and Mediums have to comply with these three standards in full (Ryan Strom ponted out in a comment below that Lows have to comply with just CIP-002-5.1 - but nothing else - on this date).

•          CIP-003-6 - except for R1.2, R2 and Attachment 1 (Lows)^[iii] – Since CIP-003-6 is essentially the same as CIP-003-5.1 except for R1.2, R2 and Attachment 1, this means you have to comply with the Medium and High parts of the standard and leave the Low impact parts for later.  The Low impact parts are R1.2 (which is the same as R2 in CIP-003-5) and R2/Attachment 1, which is the enhanced requirement for Low impact assets (ordered by FERC in Order 791).

•          CIP-004-6 – Compliance with this standard in full.

•          CIP-006-6 - except for BCS at Control Centers that weren’t CCAs under v3, and for R1.10 – As with CIP-003-6, this basically says you need to comply with the “v5” requirements in CIP-006, and leave the new stuff (R1.10) for later.  R1.10 was ordered by FERC in Order 791, and says that cabling between ESP devices, that itself goes outside a PSP, needs to be physically or logically protected.  In addition, Control Centers that weren’t Critical Assets under v3 are given more time to comply.

•          CIP-007-6 – This standard needs to be complied with in full, but there is an exception for certain devices under R1.2; compliance for these devices is due at a later date.  I don’t understand why this exception is there; if anyone does, please tell me.

•          CIP-009-6 – Compliance with this standard in full.

•          CIP-010-2 except for R4 -  Since R4 is the new requirement for Transient Electronic Devices (another item required by FERC in Order 791), this just means you have to comply with the “v5” requirements in this standard on this date.

•          CIP-011-2 – Compliance with this standard in full. 

January 1, 2017

For Mediums and Highs, this is the date for compliance with:

•          CIP-006-6 – for BES Cyber Systems at Control Centers that weren’t Critical Cyber Assets under v3

•          CIP-006-6 R1.10 (ESP cabling outside a PSP)

•          CIP-007-6 R1.2 for certain devices

•          CIP-010-2 R4 (transient devices)

April 1, 2017

• CIP-003-6 R1.2, R2 and Attachment 1 – These are the requirements that apply to Low impact assets in v6 (R1.2 is the same as R2 in CIP-003-5; the new R2 is the one that addresses FERC’s mandate in Order 791 for specific requirements for Lows.  Attachment 1 provides the detail for R2).  However, entities only have to comply with the first and fourth elements of Attachment 1 on this date; these are the security awareness policy and incident response plan.  Elements two and three – physical and electronic access controls – need to have policies developed (due to R1.2) on this date, but the policies don’t have to be implemented ‘til later.  I swear, I’m not making this up; there’s no way I could think of something so complicated on my own.  I’m not sure even Rube Goldberg could have.

September 1, 2018

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

  

There you have it.  This is the complete implementation plan for CIP v5.5, subject of course to the four complications and two caveats I’ve listed above.  I suggest you blow this schedule up and mount it on the wall of your palatial office (or your cube, whichever is applicable).  And what should be the title?  I suggest “Simplified Compliance Schedule for CIP version 5.5”.

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

---

[i] However, CIP version 1 had a very complicated structure for determining compliance dates.

[ii] If you’re not familiar with the V6 standards, you can find them here.  You need to download the most recent draft of each standard.

[iii] Yes, there is now an Attachment 1 in CIP-003-6.  There’s also an Attachment 1 in CIP-010-2.  In both cases, the attachment made it much easier to understand the new requirement (i.e. the requirement itself would have been very long and wordy if all the detail were included in it), so I don’t argue with the need for it.  Of course, the question then becomes why the requirements are so complicated in the first place.  My only answer to that is, “You see, this is NERC…”