Good News, for a Change (Part I)

I have been accused of only writing about problems, not good things.  Of course, I take strong exception to this idea.  A recent Price Waterhouse study of my blog posts showed that only 99.45% of them were negative.  So there.

And to show you how really wrong the idea is, I have two pieces of good news, which I’ll deal with in two separate posts.  Here’s the first piece:

Some of you may have seen a very low-key email that was sent around to the current CIP SDT Plus List on Saturday, showing the ballot results for the second round of balloting on the “CIP v5 Revisions” (aka CIP version 6).  If you don’t have a life like me, you probably realize this round was very important because it represented the last chance for the two FERC-ordered changes still not approved – Transient Electronic Devices and the Low impact requirement – to be approved in time for them to be included in the filing to FERC, due by early February.

The other two changes mandated by FERC (in Order 791) were removal of the “Identify, Assess and Correct” language and protecting wiring between ESP devices that goes outside of a PSP.  They were approved on the first ballot, and the SDT was preparing to just submit those two changes to FERC by February – this is what the “-X” standards were there for (these were the only two changes that FERC had required by February.  The two changes just approved didn’t have a due date, although I know the last thing the SDT wanted was to have to drag the process out through more meetings and ballots.  They fervently wanted to just do one filing for FERC, with all four changes).   

So it was great that the email showed that both remaining changes passed.  What was odd was that the email didn’t say they had passed.  My first impression was they must have failed, since otherwise I was sure the email would be crowing about the success.  And crowing would be deserved, since the SDT has worked very hard and well to get these changes developed and approved (of course, by NERC rules there still has to be another ballot.  The SDT in theory could still tweak the standards a little before that ballot, but my guess is they’re not going to mess with success).  So good job, SDT!

But that isn’t the end of the story, since I just realized today what this vote really means – namely, that for literally the first time in four years, the industry actually knows what the course of CIP will be for the next two or three years (perhaps longer.  I really don’t see anyone even proposing a new version until v5 and v6 are at least fully implemented, and that won’t be until 2018).  You only have to read the most recent v6 Implementation Plan, combine that with the v5 plan, and you have your timeline for compliance with v5 and v6.[i] 

Of course, when I say “only”, I’m having trouble keeping a straight face, since it is quite complicated to figure out the true timeline.  This is partly thanks to the SDT’s decision not to “rev” all of the standards to v6.  Instead, entities will have to comply with 3 (I believe) of the v5 standards and 7 of the v6 ones.  Plus some of the requirements in v6 have separate compliance dates (and it’s even more complicated than that, if you look at the new plan). 

The result is that there are maybe 15-25 compliance dates that will be involved in coming into compliance with CIP v5 and v6[ii] (or as I called it in my June post on the implementation dates, CIP v5.5.  I need to rewrite that post, since it was based on the first draft of the v6 Implementation Plan, not the second).  And how many were there for CIP v2 and v3?  Just one each.[iii]

But leaving aside this small quibble, the fact remains that there is now – in principle – complete certainty on what an entity will have to comply with and when.  This is no small achievement, after years in which even the number of the next CIP version was very much in question.

Of course, there are still one or two questions (he says slyly) about the actual interpretation of the v5/v6 standards – I believe I've written about that in one or two (or 40) posts recently.

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

Note: There has been a further development in v6 that makes me have to amend what I have just said in this post.  See the next post for information on this.

---

[i] I am somewhat off the mark in saying there is complete certainty now, since the v6 compliance dates all are partly dependent on FERC’s approving v6 by at least the end of 2015; if they don’t, then most of these dates get pushed back.  However, given that these changes are what FERC ordered in the first place, I find it hard to believe they won’t approve them in 2015, when they’ll have them on their desk in February.

[ii] And that doesn’t take into account the Initial Performance of Periodic Requirements dates, found in the v5  Implementation Plan).

[iii] OK, so I did go negative in this post after all.  However, I think there are more positive than negative sentences, by a long shot.  Usually it’s the other way around.

Roll Your Own, Part IV: The News from GridSecCon

I have spent the entire week in San Antonio at GridSecCon.  As usual, it was a really excellent event – I highly recommend it to anyone involved in cyber security in the power industry.  While I knew there was at least one discussion on the CIP v5 transition planned, I didn’t think I would learn anything groundbreaking about CIP – since that is really not what GridSecCon is about.

But it’s hard to stay away from CIP when you’re at a NERC cyber security meeting and the attendees are people who have CIP responsibility at their entities (it’s safe to say that no cyber security professional at a NERC entity is not at least partially involved in CIP compliance), as well as regional auditors.  And I ended up getting surprising confirmation that I’m on the right track in my series of “Roll Your Own” posts. 

Actually, more than that.  When I did the first of these posts in September, I harbored the secret hope that I might start a revolution in the NERC community.  Little did I realize that I was actually only reporting on a revolution that has been in progress for a while.  Not only have the revolutionaries been laying their plans for insurrection, they’ve already stormed the presidential palace and taken photographs of themselves in the president’s office, weapons at their sides and muddy feet on his desk, while smoking his best cigars. 

In other words, the “roll your own” revolution has already happened, at least in a subset of NERC compliance professionals.  They didn’t set out to do this; they’re simply doing what they need to keep their companies from getting huge fines after April 1, 2016.  Here are three different conversations from GridSecCon that have led me to this conclusion:

Conversation 1: Tobias and Steve

On Thursday morning, there was a panel discussion on the CIP v5 transition.  Panelists were Jay Cribb of Southern Companies, Jeff Fuller of AES, and Steve Noess and Tobias Whitney of NERC.  I had to miss Jeff’s and Jay’s presentations, and came in for the beginning of Tobias’.  The highlight of this presentation, at least for me, was his listing of the initial documents that the CIP V5 Transition Stakeholders’ Group (which I wrote about in this post in September) is going to deliver.

These include guidance documents on a) how to demonstrate your systems are appropriately segregated to justify classification of BCS as Low impact under Criterion 2.1; b) the meaning of “programmable”; c) virtualization; d) serially connected BES Cyber Systems at Medium impact assets with external routable connectivity; and e) shared-ownership substations.  These are all important topics on which guidance is sorely needed, and I applaud them for this.

But here’s the deal: These are five problems (admittedly, all big ones) out of 4,786 problems with CIP v5, according to my latest count (and this doesn’t count the 500 or so new problems that I heard about while I was at GridSecCon).  From the sound of what Tobias said, addressing these five might take up the rest of the year for the Cv5TSG (in fact, I believe he said one or two of the documents might not appear until 2015).  Meanwhile, on October 1 we passed the 18-month mark until April 1, 2016, when entities have to be fully compliant.  What do the entities do about the remaining 4,781 problems?  And what if they needed answers to one or more of these five problems months ago, not sometime before the end of the year (as is the case for my friend in the first post in this series, who needed the “programmable” definition a couple months ago)?

I submitted a question, which was read.  It wasn’t one of the above questions, but it was something like “There are a lot of questions about the bright-line criteria.  Will the new team be providing guidance on these?”  And then the smoke machine started operating.  Tobias said something to the effect that, after all, some of the questions the Cv5TSG is addressing are ones that involve CIP-002-5.1 (no dispute on that here.  The “programmable” definition certainly fits that bill.  Also, I believe the team is working on an "official" statement on the "far-end relay" issue, although the whole NERC community already knows how they've "ruled" on that).  And Steve emphasized that the team was focusing on CIP-002-5.1, since they know that’s the most urgent current need (I won’t dispute that either, since until you can be sure you’ve properly identified your cyber assets in scope for CIP v5, you obviously can’t come into compliance with the remaining standards).

But of course, neither of these answers said anything about the BLC.  Steve and Tobias might have saved everybody some time and simply said the answer is “no”.[i]  Don’t look for any guidance on the BLC from the Cv5TSG, at least not anytime soon.  And guess when you need this guidance?  That’s right, you need it now: 3:14PM Central Time on October 17, 2014.

Look, I’m not trying to harass Steve and Tobias, whom I both like personally.  And I’m not saying that NERC or its affiliates, regions, vassals or lackeys has brought us to this difficult position – where entities need to have guidance on the various vague areas and inconsistencies in CIP v5 and it’s not forthcoming – by their own intention.  But the fact is that we’re here, and NERC simply refuses to acknowledge the situation.  Instead, they fill the air with happy talk about how they just have to put a few finishing touches on the v5 masterpiece, and it will be a complete work of art – ready for entities to build their compliance programs on a rock-solid foundation. 

And this is of course why some entities have decided they need to forge ahead with their own definitions and interpretations, where these aren’t now available from NERC or the regions; they have no choice if they’re going to be compliant on 4/1/2016.  I discussed in detail what one entity is doing in the first post in this series.  And I was surprised to hear of another case when Jeff Fuller of AES answered a question (and I honestly forget what the question was).

Conversation 2: Jeff Fuller

Jeff was quite blunt.  He sounded every bit like my friend in the first post.  Entities need to develop their own definitions and interpretations where NERC or their region hasn’t provided them (I believe he referred explicitly to one or more of the documents Tobias is promising – perhaps the “programmable” definition – saying it would be “too late”.  But I can’t remember for sure what he was saying would be “too late”, except that it had something to do with guidance on v5 questions). They need to document what they do, so they can show the auditors they did the best they could with whatever information was available at the time.  And I’m sure Jeff developed these opinions long before I put them in a blog post; he simply had no choice, if he was going to do his job.[ii]

Conversation 3: An Auditor

The third conversation was with an auditor.  Since he’s already agreed with me that “roll your own” is the correct approach to the problems with v5, we didn’t need to rehash that.  But he’s gone beyond that to think of the next problem – at least from his point of view.  He was clearly looking over the horizon much farther than I was, since the question hadn’t even occurred to me, let alone the answer.

His question was, how does an auditor audit in a new world where the compliance people at the entity are going to be themselves responsible for a lot of the definitions and interpretations they need for CIP v5 compliance?  You certainly can’t keep repeating the old bromide about “auditing to the letter of the requirement”.  This was never realistic with the previous CIP versions, and it is very far from realistic with v5. 

Now, I won’t say we had a long conversation on this, so that I can give you a lengthy and accurate rendition of his answer.  In fact, he is currently preparing an article for the November issue of his region’s newsletter, where he will address this question directly; he’s said he’ll provide me the article once it’s published, and I’ll republish it here.  But I can summarize my understanding thus:

Any CIP auditor needs to understand that many of the definitions and interpretations he may consider to be “official” at the time of the audit (say, in 2018) were not available to the entity at the time they needed them – as they were coming into compliance with CIP v5.  He certainly can’t simply ding them for noncompliance with what he or she considers to be the current “letter of the law”.[iii]

So how does the auditor judge whether the entity has correctly followed a requirement?  He or she needs to determine whether the entity[iv]

1. Applied all the “official” guidance available to them at the time (this includes the actual wording of the requirements and definitions, the Guidance and Technical Basis published with each standard, and any other guidance provided by NERC or the entity’s region – e.g. the Cv5TSG documents); and
2. Where the available guidance wasn’t enough, whether the entity used a reasonable process to fill in the gaps.  This could include using guidance developed by an industry group like EEI or the NATF or discerning the “intent” of the Standards Drafting Team[v].  Or it might be just drawing up their own definition or interpretation, as long as it’s reasonable and doesn’t seem to be torturing the words of the requirement simply to make the entity’s compliance burden easier.

This might seem simple on the face of it, but think about it: This is 180 degrees from what the auditors are taught from Day 1 of Auditor School, and certainly from everything that NERC and FERC envisioned when they developed (or mandated) NERC reliability standards.  What’s to keep an auditor having a bad hair day, during an audit in 2018, from deciding he or she is going to hold the entity to the current guidance on – say - the meaning of “Transmission Facility”, even if that guidance was just issued a month before the audit?  Or what’s going to keep an entity that really didn’t follow the “reasonableness” rules described above (say, they decided that, because a strict reading of Section 4.2.2 – where it says “All BES Facilities” is what is in scope for CIP-002-5.1 – leads to the conclusion that no control center could ever be in scope, as I wrote about in this post[vi], that their control center that runs the grid for a metropolitan area of 7 million souls isn’t in fact in scope for CIP at all) from appealing a penalty to the courts – where the strict wording of the standard might very well be what decides the outcome?

What indeed?  

  

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

---

[i] That was Steve’s answer to me – “No” - when I asked him at the December 2013 CIPC meeting whether NERC would require the new CIP v5 Revisions SDT to address problems with CIP-002-5.  While it wasn’t the answer I wanted to hear, it certainly didn’t waste anybody’s valuable time.

[ii] I do want to point out that both people I know of who have come up with the "roll your own" idea are part of a generation entity.  This makes sense, since these are the ones who need to start earliest on their CIP v5 compliance programs.  Any large plant – especially a coal plant – that hasn’t already started working in earnest on v5 compliance is probably in serious trouble.  My guess is that substations have more time, although that’s offset by the fact that there are so many substations that need to comply with CIP for the first time under v5.  Really, nobody with Medium or High impact assets should be sitting around at this point (although I know some are hamstrung because the money required simply won't be available 'til next year).

[iii] Obviously, he or she can ding the entity if they’re clearly in violation of the letter of a requirement, or they didn’t apply a definition that was available to the entity at the time they needed it for compliance.  Even then, the auditor has to be careful about things like the definition of Cyber Asset.  That is a current NERC definition, but it relies heavily on the definition of “programmable”, for which there is currently no official guidance.  So dinging an entity because they used the wrong definition of Cyber Asset - when the core of that definition wasn't available at the time they needed it, i.e. October 2014 - would be a big injustice.

[iv] At this point, I’m no longer summarizing what the auditor said, since as I said our conversation was brief.  I’m applying my own reasoning to the problem.  I’ll publish the auditor’s own article when it’s available.

[v] This was the auditor’s word.  As I’ve said previously, I don’t think it’s at all possible to discern the intent of the SDT; in fact, I think the term is meaningless in the strict sense.  But that doesn’t mean the entity can’t look at other requirements, other definitions, the Guidance and Technical Basis, etc. – and come up with something like the “intent”.  Hey, you gotta do what you gotta do.

[vi] Look for the italicized paragraphs that say “Note (August 27)”.  I really ought to do a separate post on this, since it’s a huge example of where the strict wording of the standard leads to a completely nonsensical result.  There is lots of other evidence in CIP-002-5.1 that control centers are very much in scope for CIP v5, yet nobody has even tried to show me how 4.2.2 could be read so that they were in scope.  I don’t think it can be done.

Roll Your Own, Part III: Another Auditor Agrees! (with caveats)

In my previous post, I described how an RFC auditor, Lew Folkerth, expressed opinions at last week’s CIP Workshop in Cleveland that agreed closely with what I had written the previous week in this post.  He had reached the same conclusion before I had reached it, so he certainly wasn’t repeating what he had read in some disreputable blog.  I won’t repeat what these two previous posts said, other than that I think the topic is quite important for any NERC entity that needs to comply with CIP version 5.

And now I’m pleased to report that another auditor from another region – who I thought might perhaps thoroughly disapprove of the idea of “rolling your own” CIP v5 definitions and requirements – seems to basically agree with the concept.  In fact, it also seems that he has been seeing entities doing this for a while.  So I may not actually be starting a revolution by advocating this approach, but merely reporting on one that is already in progress.

This second auditor does make one point about this whole idea that I may not have emphasized enough in the previous two posts (although I completely agree with it): He reminds NERC entities that, as they “roll their own” requirements and definitions, they need to make sure they are firmly rooted – as much as possible – in the actual wording of the current CIP v5 standards. 

This may seem obvious – it seems intuitive that nobody would simply make up a new requirement or definition to replace the current wording in CIP v5.  Yet, this auditor says that he has already seen “too many proposed compliance approaches already where the approach does not align with the language of the standard.”  He also says that often it seems the “proposed compliance approach” is from an allegedly reputable consulting organization that presumably “may not know how to put a solution into place that aligns with the requirement (or they may feel it is too expensive or otherwise not worth the effort) and cuts some corners.”  So caveat emptor.

Furthermore, the auditor points out “entities should also make sure perfection (or elegance) is not getting in the way of good enough.  I have seen two similarly sized and configured entities solve a problem and achieve compliance – one with a very expensive (to license and then to maintain) technical solution, and the other with an Excel spreadsheet.  A spreadsheet might not be ideal, but if it works and you only have 18 months to get something into place, it just might be the trick until you can do your process improvements further down the line.”

I’d like to expand on his last sentence.  What I think he’s saying is that it does no good to purchase an automated solution when you don’t properly understand the process on which it needs to be based.  And – as I’ve said repeatedly over the last year and a half – it is literally impossible to completely understand the processes required to comply with some of the requirements of CIP v5.  Each entity will need to develop its own definitions and interpretation of each requirement where there is ambiguity (this applies especially to CIP-002-5.1 R1, but also to other requirements where there are ambiguities but there is no longer enough time for NERC to address those in a comprehensive fashion).

By the same token, the developers of any automated solution have to develop their own interpretations as well.  The trick is for the entity (i.e. the purchaser of the automated solution) to figure out whether the “interpretations” at the basis of the automated solution in question are ones it agrees with or doesn’t.  You should never assume that, just because a vendor has spent a lot of time coding some software, that they must have some privileged knowledge of what the CIP v5 standards really mean; they don’t.

I guess the best way to summarize what this auditor says is that a lot of CIP v5 compliance money and effort are already being wasted, both on consultants who aren’t trying to adhere as closely to the v5 standards and definitions as possible, as well as on “elegant” purchased technical solutions that may end up not being as good as a spreadsheet-based approach.

The other takeaway, of course, is that this auditor does agree that, where there are ambiguities in the CIP v5 requirements and definitions, entities need to “roll their own” requirements and definitions, while keeping as close to the actual wording as possible[i].   There are certainly some requirements and definitions where there is no ambiguity, and these should be followed to the letter.

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

---

[i] The auditor elaborated on some cases where entities (or the consultants they had hired) were not adhering as closely as possible to the v5 wording.  He said, “I am seeing issues with ESP definitions, Interactive Remote Access, and the like.  I am also seeing entities argue that the standards apply to BES Cyber Systems (true) and therefore nothing can apply to a unique Cyber Asset itself (not so true – I have yet to see how you apply a security patch to a BES Cyber System that is comprised of Linux servers, Windows workstations, and Cisco networking devices, without getting into Cyber Asset granularity)."

He continues, "I am not so much saying “roll your own” as I am saying the entity needs to carefully read the requirements and do what the requirements say.  If you are supposed to have an encrypted tunnel between an external workstation and the Intermediate System (the requirement is to terminate the encrypted tunnel at the Intermediate Device), then terminating the encrypted tunnel at a VPN concentrator or firewall (the DMZ border) and then passing clear text traffic to the Intermediate System is not compliant.  Similarly, since the requirement is to have outbound rules for permitted traffic and deny everything else, having a full Class C outbound permit command to any port, anywhere, is not compliant unless you can justify why such broad permissions are needed."

Roll Your Own, Part II: An Auditor Agrees!

I was torn between calling this post the second in my Roll Your Own series (the first is here) and calling it the first post in my new series on “The News from RFC”.  I am going to do the latter series because I’m currently at RFC’s CIP v5 workshop (the first workshop they’ve had on CIP since CIP v1, according to one of the auditors) in Cleveland, which is turning out to be extremely interesting - with some great discussions among participants and the RFC and NERC staff members.  I have already been inspired to write about four posts on topics discussed just today, and there’s still another half day of the meeting tomorrow.  So you have some good posts to look for in the near future, to liven up your drab, uninteresting lives (as opposed to my jet-set life in the fast lane, although I did drive to Cleveland from Chicago).

But perhaps the most interesting part of today’s presentations was during the presentation on CIP-002-5.1 by Lew Folkerth, a veteran RFC CIP auditor (their first CIP auditor actually, although he’s just moved from the dark side to the light side, and is now doing CIP outreach to the RFC members, not auditing).

To set the background, I’m sure you’ve all read and probably memorized the first post in my Roll Your Own series.  But just in case it wasn’t crystal clear or you live in a state with legalized pot, here is my summary: After hoping against hope since FERC approved v5 last November that some entity would ride in on a white horse and clear up all the inconsistencies and ambiguities I see in v5 and especially in CIP-002-5.1 (and I have variously suggested NERC, FERC, the Regions, Barack Obama, God, Vladimir Putin, Godzilla, and Judge Judy for that role – but none of them have stepped up to it), I have come to the reluctant conclusion that NERC entities are simply going to have to roll their own interpretations and definitions. 

That is, while entities will get some help from NERC and the regions to clear up a few of the problems in CIP v5, they’re ultimately going to have to figure things out on their own.  And not really “ultimately” at all, but now – as in 7:49PM Eastern Time on October 2, 2014.  The knight in shining armor (whom I have also referred to as the play character Godot, although I wouldn’t exactly call him a white knight) isn’t coming after all.  Entities need to start doing what the Generation compliance person I described in my last post is doing – that is, coming up with their own definitions and interpretations to fill in the holes in CIP v5, and documenting what they’re doing.  But people need to get started now, not next week and certainly not when NERC gets around to addressing all of the issues in CIP-002-5.1 (which by my calculations will be long after our planet has turned into another Venus because of global warming, and we’ve all become Crispy Critters).[i]

To be honest, I just came to this conclusion last week, and I thought I was way ahead of most other people in the NERC world in this matter.  However, it turns out that Lew had already reached that conclusion before I did – and he stated it quite eloquently in his presentation today (you can find his presentation by going to this link, then dropping down the lists for 2014 and the CIP v5 workshop.  His presentation is the CIP-002-5 one, although the discussion below isn’t in the slides.  Tobias Whitney’s presentation on the CIP v5/v6 Implementation Plan was also quite interesting, and I’ll have at least a couple posts on discussions – nay, arguments - that occurred during that presentation).

I will summarize his argument thus (and I freely admit that some of this is my own interpolation, since Lew didn’t discuss every point below – even when he and I sat down later to drown our sorrows in cheap wine at a free hotel happy hour.  So Lew can’t be held responsible for every word below):

1. There are a lot of problems with the wording of CIP-002-5.1.  I have written over 30 posts on just this topic, so I agree with him wholeheartedly.
2. The last chance NERC and FERC had to address those problems in a definitive way was when NERC drew up the Standards Authorization Request (SAR) for the CIP v5 Revisions ordered by FERC in Order 791 last November.  FERC could have ordered a complete rewriting of CIP-002-5 R1 (and perhaps Attachment 1, although I don’t think that would have made a big difference[ii]), and NERC could have put that in the SAR even if FERC didn’t order it.  Of course, this would have been a huge distraction and would probably have resulted in NERC’s petitioning FERC to put off v5 compliance for a year or two.  As it is, v5 compliance will come on 4/1/2016 as scheduled, but with no certainty available from any source about what “compliance” actually means for CIP-002-5.1 (and if an entity isn’t sure if its identification of cyber assets in 002 R1 is correct, then it can’t be sure of anything in the other v5 – or v6 – standards as well). 
3. Since Requests for Interpretation will take a minimum of 2-3 years to be approved (and FERC remanded the last two CIP RFIs anyway), and since the Compliance Application Notices (CANs) have been put to a well-deserved death, there is now simply no mechanism for NERC or the regions to provide definitive answers to the wording problems in CIP v5.   The only avenue left to NERC is some kinda sorta interpretations (note the lower case i), such as the “Lessons Learned” documents that the new CIP v5 Transition Study Group will be putting out.  While I’m sure these will be well-written and helpful, they will be way too late (as of yesterday, there are 18 months until the v5 compliance date.  No entity that has potential High or Medium impact assets should still be waiting around to start their compliance program). 
4. Even more importantly, the Lessons Learned documents will be far too few.  I believe the Cv5TSG has maybe 5-10 documents on their docket right at the moment.  I would say there were at least ten other documents whose need was identified in conversations just at the meeting today (Tobias Whitney, to his credit, blew off his planned return home this afternoon – after his morning presentation - to stay through the full meeting today and tomorrow.  It is certainly a good sign that he realizes the depth of the issues that need to be addressed).  Multiply this by eight regions, as well as malcontent bloggers like me who have thrown other problems out there and have promised – one of these days – to put together a more comprehensive list for NERC, and you get a huge number of new interpretations (small i, again) that are needed.
5. Since I estimate that the Cv5TSG can do maybe one Lessons Learned document a month, I imagine it will be 5-10 years for them to address all of the problems that can reasonably be expected to be identified, say, this year.  But since, as people implement and then try to comply with v5 in earnest, I predict the identified problems will grow rapidly in future years (I’d be tempted to refer to a certain incipient epidemic in Africa as a metaphor here, but that is far more serious.  While a few CIP professionals may commit suicide because of the v5 problems, the death toll from ebola will be exponentially greater before it is contained).  Thus, the need for CIP v5 Lessons Learned won’t diminish until long after CIP v5 and v6 have been replaced by v7.  On the bright side, I suppose that’s one way to finally solve the problem.

Lew’s argument, then, is that NERC entities need to accept the fact that they will in the end be responsible for figuring out what the requirements and definitions of CIP v5/v6 actually mean.  He recommends that entities:

1. Take a “mainstream” approach to interpreting the v5 requirements (and definitions).  That is, don’t try to torture the requirement until it says exactly what you want it to say, like that your 3,000MW plant doesn’t actually meet criterion 2.1.
2. Document what you do, document what you do and document what you do (did I mention you should document what you do?).  When the auditor comes knocking, you need to be completely prepared to show him that – in the absence of definitive guidance from NERC or your region – you have done your best to come up with your own interpretation/definition of whatever question is at issue at the moment.  If the auditor really thinks you’re way off, you should ask him or her this question: Given the information I had available at the time I needed to do this particular compliance activity, what other choice did I have?  Your documentation will make the case that what you did was the most reasonable course under the circumstances.
3. In coming up with your own interpretations and definitions, you need to try to divine the “intent” of the standard.  By that, I don’t think Lew meant the actual intent of the v5 Standards Drafting Team (as I said in this post, divining that is an impossible task).  I think he meant the intent that can be gleaned from a close reading of all of CIP v5 (and the Guidance and Technical Basis sections included with the standards) – that is, what the SDT probably really wanted to do, but fell short of in various ways.  Of course, this is a very inexact exercise at best – but hey, that’s all that’s left to CIP compliance professionals in these dark times (I guess it’s not the only thing left.  As I’ve pointed out repeatedly, McDonald’s is still hiring, and I’ve heard the McDonald’s stores in Lewiston, ND – the heart of the fracking boom – are offering $20 an hour and a $500 signing bonus).
4. One thing that Lew didn’t say, but that was recommended by another auditor to me recently, is that entities need to pay close attention to the Lessons Learned documents as they come out from the Cv5TSG, as well as any guidance provided by the regions.  As I’ve said, all of these documents will be too little and too late to be of much help, but if you ignore them completely and they end up completely contradicting one or more of your “self-rolled”[iii] interpretations or definitions, you will have a much harder time justifying what you did to the auditor.   Of course, it may be that a particular Lesson Learned will have come out way too late for you to incorporate it into your program; in that case, you need to document that fact as well.
5. Lew did point out that audit teams don’t typically want to spend a huge amount of time going into minute detail on particular points, like whether your interpretation of Criterion 2.5 was a good one or not.  What you need to do is present a good management-level report that succinctly summarizes what you did and why you did it.

Of course, when you think about it, this is pretty sad.  We have a CIP auditor for one of the regions admitting in a public meeting that NERC entities won’t be able to fully comply with CIP v5 unless they step up and write their own definitions and interpretations.  This isn’t a great situation, given that the standards in question carry potential $1MM/day penalties for violations.  But it is what it is, I guess.

For the third post in this "Roll Your Own" series, go here.

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

---

[i] The only music I remember that played over the loudspeakers at today’s meeting was during one of the breaks, when an excerpt from Wagner’s opera Die Walkure (the second of four in his Ring series) suddenly started playing.  This excerpt was from the beginning of the long farewell sung by Wotan – the chief of the gods – at the end of the opera, as he says goodbye forever to his most beloved daughter and foretells the destruction of himself and all the other gods, as well as their home, Valhalla.  I wondered if this was a deliberate comment on the prospects of both NERC and CIP version 5, but I concluded it was just chance that it was played.

[ii] My basic take on Attachment 1’s problems is that I don’t think anybody short of God (and I’m not so sure about Him either) could have written a concise set of bright-line criteria that would have taken account of the tremendous variability in the electric power industry, where each utility is very different from its neighbors, each region is very different from the other regions, each ISO’s area has very different rules, etc.  It was FERC’s idea to have NERC develop the criteria in the first place.  While it was a good idea in theory, it will prove a disaster in practice.  I used to think that maybe a 30-40 page guide – like the excellent guide to identifying Critical Assets that NERC put out in 2009 – was what was needed to make the BLC usable. I now think a comprehensive guideline would easily run into the hundreds of pages or more, and I’m sure new problems would keep popping up anyway.    

[iii] I hereby propose two new NERC terms: 1) A “self-rolled” definition is one that an entity had to make up to fill a hole in the NERC glossary – such as the need for a definition of “programmable” discussed in my last post; 2) A “self-rolled” interpretation of a requirement is an entity’s rewriting of a requirement so it actually makes sense – as opposed to CIP-002-5.1 R1 for example.  I expect NERC to quickly move to add these to the Glossary, although I realize they will first need to be balloted.  You will support these, won’t you?