The Timeline for CIP Versions 5 and 6

July 28, 2014: I noticed a lot of people have been going to this post recently.  I think this may be referrals from my recent update of this topic, but if you don't know about that update, please go here.

I attended the first meeting of the NERC CIP Version 5 Revisions Standards Drafting Team in Washington DC February 19-21.  I was glad I did, since it provided a very good perspective on what we can expect to happen with CIP going forward (to the extent that anyone knows, of course – there are a lot of unknowns).  And it was good to be able to discuss various issues with the drafting team members and the observers (there were about 30-35 attendees in all) – even though there won’t be any resolution to those issues for a number of months.

I intend to write two posts about the meeting, one discussing timeline issues and the other discussing everything else I learned there.  Since I think it’s more important to present what I learned about timelines, they will be the subject of this post.  The other will follow soon.

I think most of you already know the timeline for CIP Version 5.  The Medium and High impact assets need to comply by April 1, 2016; the Lows need to comply by April 1, 2017.  Nothing of this has changed.  However, what has changed is my thinking on the likelihood that CIP v5 will even come into effect.

Before I discuss that, I need to point out that the drafting team is preparing a new CIP version, which will most likely be called CIP Version 6.  Those of you who have been reading my posts for a while won’t be surprised by this statement, since I’ve been saying there will be a v6 since my post on FERC’s NOPR last April.[i]   However, everybody from NERC who was at the meeting bent over backwards to make it clear that v6 will not be in any way a “new” standard like v5 is.[ii]  Rather, it is simply v5 with the changes FERC ordered, nothing more.[iii]

I have said several times (including in my post on Order 791) that I don’t think CIP v5 will ever actually come into effect – that it will be superseded by v6, just as v5 superseded v4.  It seemed to me that forcing entities to comply with v5, which has the “Identify, Assess and Correct” language in 17 requirements, couldn’t be followed by requiring compliance with v6, which won’t have IAC (since one of the tasks FERC ordered NERC to do is to remove that language).  This would amount to cruel and unusual punishment and might lead many NERC entities to sue for whiplash. 

I brought this issue up to the SDT during the meeting.  Scott Mix of NERC pointed out to me that it really wasn’t going to be a big problem to do this – i.e. to have v5 come into effect, followed by v6.  NERC will simply need to make sure people understand that they should ignore the IAC language in v5 – and instruct the auditors to ignore it as well.[iv]  And he pointed out there is a precedent for this: When FERC approved CIP Version 1 in Order 706 in 2008, one of the many changes they said they wanted was removal of the language regarding “reasonable business judgment” (i.e. the idea that in some cases an entity could waive strict compliance with the wording of a requirement based on their own judgment of what was reasonable).   Since CIP v2, which removed that language, didn’t come into effect until after the compliance dates for v1, NERC let entities know to simply ignore that language in v1.  This isn’t necessarily a really elegant way to do things (it might not even be legal, although I ain’t no lawyer), but as long as it’s likely to work, that’s fine with me.

The upshot of this is that I was wrong in thinking v5 wouldn’t come into effect.  I now believe it will, and on the dates that have already been announced: April 1, 2016 for Medium and High assets, and April 1, 2017 for Lows.  However, keep in mind that these dates are for compliance only with the requirements in CIP v5 as filed with FERC in January, 2012.  They have nothing to do with the four changes[v] that FERC ordered NERC to make in CIP v5.  Those changes will be in v6.

So when will v6 come into effect?  When I believed that v6 would supersede v5, I also believed there would be an accelerated timeline for v6 – since FERC would look askance at the idea of v5 not coming into effect at all and v6 only coming into effect long after what was supposed to be the v5 compliance date. 

But there is no longer a need to accelerate the v6 timeline a lot – the new requirements in v6 are all completely unknown[vi] at this point, and won’t be known for sure until the end of this year, when NERC intends to have them approved and sent to FERC.  FERC won’t approve them for probably at least six months after that, say the third quarter of 2015. So if compliance with v6 became mandatory on the same dates as compliance with v5 will, High and Medium entities would have no more than 6-9 months from FERC approval of v6 to come into compliance with it on April 1, 2016.  And Lows would have only about a year and a half.  I contend that isn’t enough time at all, given the current complete uncertainty on what the new v6 requirements will be.

So if the SDT agrees with me and decides to keep the v6 implementation plan the same as the v5 one (i.e. “first day of the ninth calendar quarter…”), this would mean the v6 implementation date for Highs and Mediums would be late 2017, and for Lows would be late 2018.  But remember, these dates would effectively just be for the three new sets of requirements that FERC mandated – for transient devices, “communications networks”, and more specific Low requirements.  All the rest of v6 (i.e. what’s identical with v5) will have already come into effect in 2016 (Medium/Highs) and 2017 (Lows).

I do want to discuss the Low impact implementation date in more detail, since there is a lot of interest in that.  I believe it is just about certain that CIP-003-5 R2, the single requirement in v5 that applies to Lows, will still come into effect on April 1, 2017 as currently scheduled.  However, the new Low requirements being developed in v6 will presumably come into effect on the separate v6 implementation schedule that will be determined by the current SDT (and I’m currently guessing the compliance date for these requirements will be late 2018, as I just said).

However, there is one reason why I hesitate in making this prediction.  That is because FERC gave the SDT three or four options for how they will implement FERC’s mandate that they develop specific requirements for Lows.  One of those options is that they simply “flesh out” what needs to be in the four policies that are currently mandated by CIP-003-5 R2[vii]  - i.e. state what must be addressed in each policy.  If the SDT follows this option, then it’s possible that the Low entities would have to implement the fleshed-out policies on the v5 compliance date of April 1, 2017.  I don’t think that would be completely fair (since as I’ve said, the content of v6 won’t be known until the end of this year, and probably won’t be approved by FERC until the second half of 2015), but I guess it could happen.  To quote the philosopher Jimmy Carter, “Life is unfair”.

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

---

[i] While I was right that there will be a v6, I was wrong in my reasons for thinking so.  I thought it was the Federal Power Act itself that forbids any modification of a standard, once it is approved by FERC.  I’ve now learned the real reason is that NERC’s rules don’t allow a standard to be modified once it has been approved by the Board of Trustees and sent to the regulators (FERC and the regulatory bodies in each Canadian province); so the changes FERC ordered – which are of course what the new SDT is working on – need to be in a new standard.  And NERC’s numbering conventions pretty well require that the new version be v6, not v5a, v5.1, or something like that.

[ii] The NERC people are clearly walking on eggshells on this issue.  The community is so upset about the whole “v4…no, v5…no, v4…no, wait a minute, it’s v5 after all” saga that I think they’re worried they’ll be strung up on the nearest tree if they let it be known now that v6 is coming.  But they’re absolutely right that v6 won’t be a major change like v5 was; in any case, it’s mandated by FERC.

It might help if the CIP versions after v1 had been numbered as they should have been: v2 should have been 1.1, v3 should have been 1.2, v4 should have been 1.3 (or something like that).  These were all very incremental changes.  V5, on the other hand, is a major rewriting of CIP, so it should be called CIP v2.  If it were, then v6 could be called v2.1, and nobody would get apoplectic about that.

[iii] There is a small exception to this statement. Steve Noess of NERC did say that, if someone points out a “no brainer” change that should be made in the existing wording – such as changing a word that everyone agrees was the wrong one to use in the first place – the SDT could make it.  Of course, what the SDT won’t do is open up more fundamental issues like the problems with CIP-002-5 R1 that I’ve been bringing up in my posts for nine months or so – they have enough on their plate already.  This just reaffirms what Steve had said in answer to my question about this at the December CIPC meeting.

I have come to agree with Steve on this point; the SDT simply doesn’t have time to open any fundamental discussions of the standards, even if changes are needed to address basic inconsistencies in some of the wording.  This is why I’ve been saying that the problems I’ve been pointing out with CIP-002-5 R1 will have to be dealt with by the regions, in their interpretations of v5.  Fortunately, at least one of the regions does seem to be stepping up to the plate on this, so all may not be lost (however, this isn’t the entire solution, since all of the regions need to agree on a common interpretation.  I will be hearing more about another region’s interpretation this week, and may have more to report on this front soon).

[iv] NERC won’t simply say to ignore the language without explanation as to why, since there is a very good reason.  The reason NERC doesn’t think removal of IAC from v5 is a big problem is that the Reliability Assurance Initiative (RAI) will essentially accomplish the same thing (and for all NERC standards, not just CIP), without requiring any changes to wording in standards.  See my Part II post on the SDT meeting for more on this.

[v] I can name these by heart after all the discussion about them at the SDT meeting: 1) Removal of IAC; 2) Requirements for transient devices used in the ESP for less than 30 days; 3) More-specific requirements for Low impact assets; and 4) Protection of “communication networks”.  I will discuss what was said on each of these in my Part II post.

[vi] What is currently known is that IAC won’t be in v6.  However, even though it will remain in the 17 requirements where it’s found in v5, I’ve already said that NERC will effectively tell all concerned to pretend it isn’t there.  Having it removed in v6 will simply confirm that fact.

[vii] At the SDT meeting, it was pointed out several times that CIP-003-5 R2 says absolutely nothing about what the four policies should be – only that the Low entity needs to have policies for cyber security awareness, physical security controls, etc.  I have been joking that an entity could state that their – say - awareness policy was “Everybody at Headquarters will get ice cream on Thursdays.”  As long as they made sure that those lucky employees got ice cream every Thursday, they would be in complete compliance with that part of the requirement. 

Follow-Up on Remote EMS Workstations

  

In my previous post on the importance of the words “at” and “associated with” in CIP-002-5 R1, I discussed a question that was asked at the recent WECC workshop on CIP Version 5.  The question was whether an EMS workstation that was located remotely from a High or Medium impact control center would take the classification of the control center itself. 

My answer to that question was essentially that, if the control center was High impact, the workstation would have to be treated as a remote user (and would have to come in through a VPN to an Intermediate System with two-factor authentication, per CIP-005 R2); if the control center was Medium impact, the remote workstation would be a Medium BCS.  This is because of the different ways that High and Medium impact BES Cyber Systems are treated in CIP-002-5 R1 and Attachment 1.

However, the CIP compliance manager for the generation arm of a large IOU – who has contributed to previous posts – emailed me to point out that I wasn’t taking into account the NERC definition of a Control Center, namely “One or more facilities hosting operating personnel that monitor and control the Bulk Electric System (BES) in real-time to perform the reliability tasks, including their associated data centers, of: 1) a Reliability Coordinator, 2) a Balancing Authority, 3) a Transmission Operator for transmission Facilities at two or more locations, or 4) a Generator Operator for generation Facilities at two or more locations.”

This definition makes it clear that any location where operating personnel perform the above functions is a Control Center.  So a remote EMS workstation performing the above functions per the definition would be a Control Center cyber asset.  Moreover, the entity owning it would have to declare some sort of Control Center facility around it.[i]  If the Control Center with which this workstation is associated is either High or Medium impact, then the workstation itself will be a High or Medium BCS, and the Control Center facility that “houses” it will also be High or Medium impact.  

This means that, if the primary Control Center is a High impact, all of the v5 requirements that apply to High BCS will apply to the remote workstation and the separate Control Center facility that is created to contain it.  As a High BCS, the workstation will be subject to all the CIP v5 requirements that apply to Highs, including having two types of physical access control, log review at least every 15 days, testing of BCS configuration changes and monitoring for changes, active vulnerability assessments, etc. And similarly for the case of a remote EMS workstation that is a Medium impact BCS – it will have to comply with all the v5 requirements that apply to Mediums.

This means that, while I was technically correct in pointing out – at the WECC meeting and in the previous blog post – that the words “associated with” in Section 1 of Attachment 1 would preclude the hypothetical remote workstation for a High control center from being a High BCS in itself, I missed the larger point that there can never be a remote workstation for a Control Center in the first place.  If the workstation performs one of the functions shown in the NERC Control Center definition, the entity needs to declare a Control Center facility around it.[ii]

Let’s consider some of the implications of this:

1. For Control Centers, what I wrote in my previous post is now “inoperative”.[iii]  The “at” / “associated with” distinction doesn’t apply here, since every BCS that’s associated with a Control Center is ipso facto “at” a Control Center.  The entity will need to declare that the “remote” EMS user is part of a separate Control Center facility.  If it’s located within – say – an office building which isn’t a BES asset (e.g. the company headquarters), there will have to be physical and electronic controls protecting it, per the requirements of CIP version 5. 
2. For generating stations, transmission substations and the other assets in the list of six types in CIP-002-5 R1, the “at” / “associated with” distinction still does apply, since the definitions of those assets don’t implicitly require that all workstations associated with them be contained in a separate facility of the same type.  However, these will all be Medium impact assets, since the only High impact assets are Control Centers.  Since “associated with” (not “at”) is used in Section 2 of Attachment 1 (which introduces the Medium impact criteria), this means that any BCS “associated with” a Medium impact asset has to itself be protected as a Medium BCS[iv].  However, per R1.2, if the cyber asset in question isn’t located at one of the six asset types listed in R1, then it isn’t a Medium BCS.  Instead, it should be treated as a remote interactive user.[v]
3. What if the “remote” Medium BCS is located at a Low asset like a generating station of less than 1500MW?  These assets will possibly have to have some sort of physical and logical access controls, once the new SDT has complied with FERC’s directive (in Order 791) to develop more specific controls for Low impact assets.   Might these be deemed adequate to protect this Medium BCS?   The answer to this is clearly no, except in the very remote possibility that the controls for Lows end up being identical to those for Mediums.  All of the Medium impact requirements – physical and logical access control, PRA’s for users having physical or logical access, etc. – will apply to this workstation.
4. If there are any non-BES Cyber Assets networked with this “remote” Medium BCS, they will have to be treated as Medium impact Protected Cyber Assets, meaning that almost all of the requirements for Medium impact BCS will apply to them.  This  is true, whether the “remote” Medium BCS is physically located at a High, Medium or Low impact asset, or whether it’s not located at any BES asset at all (although it will probably be a moot point if it’s located at a High or Medium asset, since the appropriate protections will presumably already be applied due to that status). 
5. This also means that, if the “remote” Medium BCS is located at a non-BES asset like a corporate HQ and is networked with other cyber assets, all of those cyber assets will have to be enclosed in an ESP and a PSP (this effectively means the entity has declared a Medium asset containing all the cyber assets on the network containing the “remote” Medium BCS).  

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

---

[i] This “requirement” to declare a mini-Control Center around the remote workstation isn’t explicit in CIP v5, of course.  However, by the time you do all the things you have to do to a High impact BES Cyber System – enclose it in an ESP, enclose the ESP in a PSP, and apply all the appropriate High impact controls to these – you effectively have a new Control Center facility, even if it only contains this one workstation.

[ii] Of course, not only was I wrong, but Dr. Joe Baugh, who answered the question at WECC, was as well.  He said the remote EMS workstation would have to be treated as an instance of interactive remote access; he should instead have said that there can be no such thing as a “remote EMS workstation”.  I don’t blame him for this, of course, since I didn’t realize it either, until my friend emailed me yesterday.

[iii] Those of you of a certain age will probably remember this was the immortal word used by Richard Nixon’s press secretary Ron Ziegler to describe all of the previous statements he had made about Watergate, once the “smoking gun” had been found and there was no longer the shadow of a doubt as to Nixon’s guilt.  Those of us with a more traditional view of language would have preferred he use the more accurate term “lies”, but I guess that’s just a matter of taste.  Of course, I wasn’t deliberately lying in my previous post – I simply wasn’t smart enough to know I wasn’t telling the truth.

[iv] The CIP compliance manager pointed out to me that there are exceptions to this statement, in the case of assets that fall under criteria 2.1 or 2.2 in Attachment 1.  That is, BES Cyber Systems that are excluded from being Medium impact by the wording in these two criteria are either Low impact or nothing at all.  I have written about this issue previously in this post, under the heading “Segregated Cyber Assets”.

[v] If you don’t understand why this is the case, please refer to the previous post.  My goodness, I can’t do everything for you!

Be Careful Who You Associate With

Feb. 18: It turns out I was missing an important point when I wrote this post last week.  It isn't wrong per se, but it isn't the whole story.  See this new post - which you'll be glad to know is mercifully short compared to most of my posts.

Perhaps I find pleasure in strange activities, but I admit I found it quite pleasurable to attend WECC’s CIP Version 5 Workshop in Salt Lake City recently.  The main reason for this was that the WECC CIP auditors and enforcement people who spoke had done an excellent job of really thinking about all the standards and providing useful information.  Of course, the fact that there are so many of them (there were at least nine speakers) allowed each one to treat his or her topic quite thoroughly.

If you missed the workshop, don’t despair.  You can download the entire “presentation package” here.  However, before you click on it, keep in mind that the package is 33 megabytes (fortunately, Geoff Warnock of Gainesville Regional Utilities has come to the rescue and divided the file up into the presentations on each of the standards.  If you would like me to send them to you - in a few emails, depending on how much you can receive at one time - contact me at tom.alrich@honeywell.com.I do wish to make the suggestion to WECC that it might be a good idea to start breaking those packages up into at least two or three parts.  Herein ends my criticism of WECC (for this post, anyway).

I found a lot of the points that were made to be very interesting, and I hope to do a post soon that will address a number of these.  However, this post will focus on a question that was asked during the CIP-002-5 presentation and the discussion that followed.  The presenter for CIP-002-5 was Dr. Joe Baugh, a kind of rock star[i] among CIP auditors, who I wrote about for the first time almost two years ago (he was just Joe at the time, not Dr. Joe).

Before I get to this discussion, I do want to say that Joe provided a very good description, and flow chart, of two alternative methodologies for achieving compliance with CIP-002-5 R1.  And guess what?  They correspond fairly closely to the two methodologies I outlined in a recent series of three posts (the first is here) – one mine and one that of a friend who happens to be an auditor (not in WECC).  Joe referred to these as the “top down” and “bottom up” approaches.  The former corresponds roughly to my methodology, the latter to the auditor’s.[ii]

Even better, he recommended the top-down approach (i.e. mine) as the better one to pursue.[iii]Should I be surprised that Dr. Joe came to the same conclusion as to the best methodology for CIP-002-5 R1 compliance as I did?  Not at all; I know him to be a very intelligent person – this only confirms that.

Now to the discussion I found so interesting.  An attendee asked whether an EMS workstation that was located remotely from a High or Medium impact control center would itself take the classification of the control center itself.  Dr. Joe said it would, and further stated that there might have to be a special asset defined to house that remote workstation (he didn’t go into detail, but I presume that asset would be a type of High or Medium control center).  Of course, this would have to be done because in his preferred methodology (and mine), assets (i.e. the “big iron”) are classified first, then BES Cyber Systems are identified at the High and Medium assets.  So you can’t have a High or Medium impact BCS without a corresponding High or Medium asset.

However, in this case Dr. Joe gave an answer that, while not wrong, was incomplete; it was incomplete on two counts.  Always being eager to help, I pointed out one of those counts; it was only later that I realized there were two.  You might say I missed my chance to point both out at the meeting, but this is the great advantage of having a blog: you can always have the last word.  So this post will be devoted to describing what Dr. Joe missed; indeed, he missed two entire steps (or at least sub-steps) in the process of BCS identification.[iv]  And I now realize that NERC entities (and auditors!) could make a lot of classification mistakes if they don’t understand these steps.

The issue revolves around the wording of CIP-002-5 R1.1 and 1.2.  These two parts – and R1.3 - constitute what could be called the “payload” of R1, since when you come down to it, everything that R1 explicitly tells you to do is contained in these three parts.  Here is the wording of R1.1 and R1.2[v], along with the first phrase of each of the sections in Attachment 1 that each part refers to:

High Impact

1.1. Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset;

Refers to Section 1: Each BES Cyber System used by and located at any of the following:

Medium Impact

1.2. Identify each of the medium impact BES Cyber Systems according to Attachment 1, Section 2, if any, at each asset;

Refers to Section 2: Each BES Cyber System, not included in Section 1 above, associated with any of the following:

Let’s just consider the High and Medium impacts now.  Note that for Highs, R1.1 says you must identify “high impact BES Cyber Systems…at each asset”, and Section 1 says these systems must be “used by and located at…” assets that meet the criteria in Section 1.  Offhand, this seems to be quite consistent – both use the word “at” (note the italicizations are mine).  A High impact BES Cyber System must be physically located at the High impact asset that uses it.  So if the questioner at the WECC meeting was asking about a remote workstation for a High impact control center, there isn’t any question that it wouldn’t be a High BCS, since it isn’t located at the control center itself.

Let’s now look at the Mediums.  R1.2 says you need to identify “medium impact BES Cyber Systems…at each asset”.  However, Section 2 says simply “associated with any of the following”.  Going back to the WECC workshop question, and assuming we’re now talking about a remote workstation for a Medium impact control center, it seems like R1.2 would say the remote workstation isn’t a Medium BCS, since it’s not “at” the control center.  But Section 2 seems to say it is a Medium BCS, since it is “associated with” the control center.  Is this a contradiction?

When I first noticed this difference between how High and Medium impact BCS are treated, I assumed it was simply a mistake – that the SDT hadn’t noticed the discrepancy for Mediums.  However, late last year I discussed this with an Interested Party who has studied CIP-002-5 R1 very closely.  He pointed out to me that a proper reading reveals there is no discrepancy.  I have come to agree with him, although the language could certainly have been made a lot more explicit.[vi]

The Interested Party explained to me that R1.1 - R1.2 and Sections 1-2 of Attachment 1 are actually doing two different things.  R1.1 – R1.2 are telling you the universe of systems that need to be considered as High or Medium BCS; that universe consists of systems located at “each asset”, meaning assets corresponding to the six types that are listed right above this – control centers, transmission substations, etc.  Note that neither R1.1 nor R1.2 is saying that High or Medium BCS must be located at either a High or Medium asset, only that they must be located at one of the six types of assets, regardless of its classification as High, Medium or Low impact.

Going back to the WECC question, if the remote workstation is located in somebody’s home or in the company headquarters (probably not good security practice, of course), it will definitely not be a BES Cyber System at all – it will presumably have to be treated as a remote access user, and have to go through an Intermediate System (with a VPN to that IS) like other remote users.  If it is located in one of the six asset types, then it could be a BCS; but we now need to go to Attachment 1 to decide for sure whether or not this is the case.

It is in Attachment 1 that the difference comes out between High and Medium impact BES Cyber Systems.  Since Section 1 uses the words “used by and located at”, it is clear that a High BCS can only be physically located at the High impact control center that uses it.  If it is located anywhere else, it probably won’t be a High BCS[vii].

However, since Section 2 says “associated with”, it is very possible that an EMS workstation located remotely from a Medium impact control center could be a Medium BCS.  But since R1.2 restricts Medium BCS to systems located “at” one of the six asset types, it would need to be located at another control center, a generating station, etc.  As was just said, it couldn’t be in somebody’s home or in the corporate headquarters.

You may find this surprising, and I think Joe Baugh would have as well.  In fact, there was a follow-on to the first question, in which a different person asked if the user of the remote workstation could be classified as an interactive remote user, so that the workstation they were using wouldn’t be a BCS.  Joe said this was fine as long as the workstation wasn’t “controlling” the EMS or SCADA system in the control center.  He said that if the “full suite of EMS applications” were installed on the workstation, then it would have to be a BES Cyber System.[viii]

  

However, I think Joe’s answer needs to be qualified to say that:

a)      For a High impact control center, the only way the remote workstation could itself be High impact would be if it were located at another High control center.  Joe briefly alluded to the idea that the entity might have to declare the location of the workstation to be an asset in itself.  For this to apply in the case of a High, the new “asset” would have to itself be a High control center; and this might be a pretty burdensome thing to do (you’d have to have a PSP with two types of physical access control, as well as comply with all of the other requirements for Highs); I see no alternative to simply declaring the workstation (or rather its user) as a remote user and applying the protections (VPN, Intermediate System) required for remote users.[ix]

b)      For a Medium impact control center, the remote workstation would have to be located at one of the six asset types (per R1.2), but it could still be a Medium BCS, since it’s associated with the Medium control center.  Again, if it were not located at one of the six asset types, it would be a remote user.

So here is the answer to the original question whether a remote EMS workstation takes the classification of the control center with which it is associated:

1. If the control center is High impact, the workstation will have to be treated as a remote user, unless it is declared to be part of a separate High impact control center.
2. If the control center is Medium impact and the remote workstation is located at one of the six asset types, it will be a Medium BCS (of course, cyber assets networked to it will have to be treated as Medium impact Protected Cyber Assets).
3. If the control center is Medium and the remote workstation isn’t located at one of the six asset types, it will have to be treated as a remote user.

  

Revised CIP-002-5 R1 Methodology

Let’s generalize this from just an answer to one question to a correction to the CIP-002-5 R1 compliance methodology itself.  We’ll start with Dr. Joe’s “top-down” methodology shown on slide 45 of the WECC presentation packet.  The first step (in blue) is to classify your assets as High, Medium and Low impact using the criteria in Attachment 1.  The next step after that (in green) reads:

Use the inventory of BES Cyber

Assets at the High (R1.1) or

Medium (R1.2) Facility to identify

and list BES Cyber Systems

(BCS) at each such facility

This step should be replaced with the following two sub-steps:

1. For High impact assets, identify BES Cyber Systems that are “used by and located at” the asset.
2. For Medium impact assets, identify BES Cyber Systems that are “associated with” the asset.  These must exist at one of the six types of assets shown in CIP-002-5 R1, including the Medium impact asset itself.

 I think this clarification may save entities from mistakenly identifying High or Medium impact BCS where they don’t exist.  And since I realize some entities will have already done a preliminary identification and classification of High and Medium impact BCS, they may want to go back through the list to see if any BCS they've already identified could be removed from the list.

Postscript
I've just documented a complex wrinkle in the process for identifying BES Cyber Systems in CIP v5; one that probably limits the number of BES Cyber Systems below what some auditors may think will be the case. The bigger question is whether this is really what the SDT intended.  I believe the answer to that is it was an unintended byproduct of well-intentioned provisions they included in v5.

In particular, the provision that High BCS are limited to those "used by and located at" a High impact asset was almost certainly not put there with this consequence in mind.  I think it was put in because the SDT wanted to remove the possibility that every RTU, etc. controlled by a High or Medium impact control center would by that very reason be High or Medium.  This wording prevents that from happening, but also of course prevents a remote workstation from becoming a High impact BCS and forces it to become a remote interactive user.

I'm not sure anyone made a mistake here; it's more a function of the complexity of the requirement.  But NERC entities need to be aware that "there be dragons" lurking in CIP-005-2 R1.  Since I've already written maybe 15 posts on just that requirement, I should know.

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

---

[i] I do wish to point out now that the frequent rumors that Dr. Joe will be named Sexiest Man Alive for 2014 are without foundation.  However much he may deserve the title, he’s far too modest to accept it.

[ii] Note that I wrote in this post about two methodologies for identifying BES Cyber Systems, which I also labeled “top down” and “bottom up”.  These aren’t the same thing as what we’re talking about here.  In that post, “top down” meant basing your identification of BES Cyber Systems on an analysis based on the BES Reliability Operating Services (described in detail in the Guidance and Technical Basis section published with CIP-002-5), while “bottom up” meant basing the identification solely on cyber assets that complied with the definition of BES Cyber Asset.  I suggested in that post that the best approach would be to combine these two approaches, coming at your identification of BCS from both directions so as not to miss any.  Joe said the same thing in his presentation.

[iii] He actually said either one would be acceptable from an audit point of view.  But he pointed out that the bottom-up approach (corresponding to what I call the auditor’s approach) would require much more work on the part of the entity, since it involves - in some way - prior identification of all BES Cyber Systems at all assets owned by the entity, whether they are ultimately classified as High, Medium or Low impact.  And that added work – i.e. identifying BCS at Low impact assets - would essentially be a waste of time.  He pointed out dryly that it isn’t likely too many NERC compliance departments, rushing to become compliant with CIP Version 5 by April 1 2016, have lots of extra time on their hands.

[iv] I will admit that I glossed over these steps as well in the post where I outlined my methodology, although I had discussed the concept earlier in the previous post (in part D of “The Auditor’s Methodology”). 

[v] Note I’m not dealing with R1.3 here.  This is because, in my CIP-002-5 R1 compliance methodology and WECC’s, there is no need to identify Low impact BES Cyber Systems, so the considerations of “at” and “associated with” don’t apply at all.

[vi] Please note that for once I’m not saying the problem is caused by inconsistent wording in CIP-002-5 R1 – there are certainly other problems where that is the case!  However, since I missed this point in my first 100 or so readings of the requirement, I definitely think the wording could be much more explicit.   This does bring up another criticism I have made about CIP-002-5 R1: it tries to compress way too much into way too few words. Much of the requirement is not stated explicitly but is just implicit in the meanings of the words.  This is wonderful if you’re writing haiku, but not so great if you’re writing requirements with potentially huge fines for non-compliance.

[vii] Except in the scenario that it is located at another High control center and is “used by” that control center as well as the one in question.  I don’t know how likely this is, though.

[viii] I wish to thank Scott Kardos of Chelan Public Utility District in Washington.  He asked the follow-on question, and clarified my memory of Joe’s response to the question.

[ix] Of course, if the goal is really to prohibit people from setting up remote EMS workstations outside of regular BES assets, this might be accomplished by some sort of directive from NERC or the regions.  It would say there can be no remote EMS workstations for High or Medium impact control centers that are not themselves part of a High or Medium impact asset.  But like a lot of other things, this assumes the agency issuing the directive has adopted my (and WECC’s) methodology for complying with CIP-002-5 R1; only if that is the case do the terms “High impact asset” and “Medium impact asset” even make sense.