CIP-002-5: The Wars of Religion (Part II)

Nov. 8: It is very likely FERC will approve CIP Version 5 before Thanksgiving, most likely at their meeting on Nov. 21.  Of course, what will be important is the Order they issue with V5.  When that is issued, your reporter will sequester himself until he has figured out what it means, and will post that as soon as possible thereafter.

This is the second post in the series of three or four I am writing about ambiguities in CIP-002-5, and the different interpretations I've encountered that try to address these ambiguities.[i]  The last one had to do with how an entity identifies its BES Cyber Assets / Systems.  This one addresses a question I've debated with several other people who don’t have anything better to do than discuss CIP Version 5: Will all the cyber assets associated with a particular Facility take the ranking of that Facility, or can there be multiple levels of cyber assets (H/M/L) at the same Facility? 

But in the course of these debates – and especially a discussion with a veteran NERC compliance manager in the Generation arm of a large IOU – I have come to realize there are really two questions here:

1. Can there be more than one level of BES Cyber Systems at a particular Facility?
2. Can there be multiple levels of cyber assets at a particular Facility?

And let’s clarify something now: These questions can only apply to Medium or High impact Facilities.  At a Low impact Facility, there can’t be any question of having multiple levels of cyber assets.[ii]

Question 1: BES Cyber Systems

To address the first question, I’ll say at the outset that I believe there can only be one kind of BES Cyber System at a particular Facility.  I’ll admit that nowhere in CIP-002-5 is there any mention of whether or not this is a correct statement.  This is why I’m dealing with this issue as a religious one: absent the standard being rewritten or binding guidance being provided at some point by NERC, this is a question everyone will have to address to their own satisfaction.[iii]

Why would someone get the idea that there could be multiple levels of BES Cyber Systems at[iv] a single Facility?  That’s simple: because CIP-002-5 has many cases of sloppy wording.  It’s very easy to miss what the standard means by getting too hung up on what it says.[v] 

Exhibit A is the example my generation compliance friend brought up to me: Criterion 2.1 of Attachment 1 of CIP-002-5 reads (with its preamble sentence):

       (the entity needs to identify) Each BES Cyber System, not included in Section 1 above, associated with any of the following:

2.1. Commissioned generation, by each group of generating units at a single plant location, with an aggregate highest rated net Real Power capability of the preceding 12 calendar months equal to or exceeding 1500 MW in a single Interconnection. For each group of generating units, the only BES Cyber Systems that meet this criterion are those shared BES Cyber Systems that could, within 15 minutes, adversely impact the reliable operation of any combination of units that in aggregate equal or exceed 1500 MW in a single Interconnection.

The preamble sentence clearly states that the purpose of this criterion is to classify BES Cyber Systems, and the second sentence of the criterion says “the only BES Cyber Systems that meet this criterion are…”  Thus, there must be the possibility of more than one level of BES Cyber System at the plant, right?  Otherwise, how could this sentence be distinguishing between different types of BES Cyber Systems?

Again, the problem is you’re looking at the words that are written, not what was intended.  As I've explained in previous posts such as this one (especially the last section), it is simply dishonest for Attachment 1 to say it’s for classification of BES Cyber Systems.  Attachment 1 is really for classifying the Facilities (or “assets”, since the two terms are used almost interchangeably in CIP-002-5) at which BES Cyber Systems are located.[vi]  And if you look at criterion 2.1 that way (i.e. as really just classifying a Facility, not BES Cyber Systems at a Facility), I think you’ll agree it doesn't lead to the idea that there could be multiple BCS levels at one Facility (note, all of this discussion could apply as well to Criterion 2.2, which is essentially the same language applied to reactive resources - and I want to thank my Generation friend for pointing that out).

Are there other examples of language in CIP-002-5 that would lead one to conclude there could be multiple levels of BES Cyber Systems at a particular Facility?  I don’t think so.  Some people might point to the fact that entities are allowed to “slice and dice” a substation that has both Transmission and Distribution elements, so that only the Transmission elements are subject to CIP Version 5.  If the Transmission elements were a Medium impact Facility, would the Distribution elements be a Low?  Certainly not, since the Distribution elements wouldn't be part of the Facility at all, and thus wouldn't even be in scope for CIP V5 (this assumes they aren't networked with the Medium elements, but if they were, the substation couldn't be “sliced and diced” in the first place.  This operation assumes that the two types of elements are on separate networks).

My Generation friend also pointed out that Criterion 2.3 might lead to multiple levels of BCS at a Facility.  This could happen in the case where the Planning Coordinator or Transmission Planner notified the owner of a large generating station that one or more units in the station - but not the whole station - were what's known as "Reliability Must Run".  In this case, the systems that control or impact those unit(s) are Mediums, while those that control the other units are Lows (although my friend believes the latter could be out of scope altogether for CIP V5 unless they are actually Low BES Cyber Systems.  I actually think such an animal - a Low BCS - doesn't exist, but even if it did it wouldn't make a difference in practice at all.  I hope to do a follow-on post based on the emails we've been exchanging on this and other questions related to this post).

Not hearing any dissent,[vii] I will now go to the second question:  “Can there be multiple levels of cyber assets at a particular Facility?”

Question 2: Cyber Assets

To answer the second question up front, I do believe there can be multiple levels of cyber assets at a High or Medium impact Facility.  Let’s be clear about the difference between this and the first question: The first question dealt with BES Cyber Systems and implicitly with their components, BES Cyber Assets; you identify BES Cyber Assets by looking at the total population of cyber assets at a Facility and deciding which of those meet the definition of BCA.[viii]  What we’re talking about in this question is the cyber assets that weren't identified as BCA’s.  

These “leftover” cyber assets can be further classified by whether or not they’re networked with a BES Cyber System.  If they are so networked, then they are Protected Cyber Assets under CIP Version 5; any requirements in CIP-003-5 through CIP-011-1 that apply to PCA’s will apply to these cyber assets.  But what about the cyber assets that aren't networked with BES Cyber Systems but are still at the Medium or High impact Facility in question?

Let’s consider what we would have done with these cyber assets in CIP Versions 1-3.  Those of you who had to comply with one or all of those versions hopefully followed an important practice: you needed to segregate your Critical Cyber Assets (the V1-3 equivalent of BES Cyber Systems) onto separate networks.  This would keep them from being so-called “non-critical cyber assets within the ESP” (the V1-3 equivalent of Protected Cyber Assets in V5).  In fact, they would be completely out of scope for V1-3; they might as well not exist at all.

Do you think you can do the same thing in Version 5?  That is, once you've identified your BES Cyber Assets / Systems, can you segregate as many cyber assets as possible on separate networks and then not have to worry about them anymore?  Once again, the language of CIP-002-5 isn't clear on this subject, but it seems to me (and to many others.  This is one area in which I do agree with most of the people I've discussed this with) that these cyber assets don’t just fade from view, as they do in V1-3.  I and the others believe they need to be treated as Lows.[ix]

As before, I can’t point to any particular language in CIP-002-5 to support this position (although it should be there, in a perfect world).  But I will go back to the example of the large generating station in Criterion 2.1 of Attachment 1.  Essentially, the wording in that criterion separates the one plant into two: one plant with BES Cyber Systems that affect more than 1500MW of generation, and the other with systems that don’t affect more than 1500MW.  The former systems are clearly Medium impact, but what of the latter?  If they were completely out of scope for Version 5 (not Lows), then this second “plant” would be treated completely differently from any other plant on the BES.  All BES Facilities will be at least Low impact in Version 5, and by saying this second “plant” wasn't even a Low, you would be saying it wasn't even a BES Facility.  That would really be stretching the standard.  So I think the cyber assets that don’t affect 1500MW at a Criterion 2.1 plant are Low impact.

And if these cyber assets (i.e. the non-1500MW assets at a plant subject to criterion 2.1) are Lows, I think you can make a pretty good analogy to cyber assets at other Medium or High impact BES Facilities that aren't networked with BES Cyber Systems.  They aren't Medium or High impact, but they also aren't completely out of scope; so they must be Lows as well.[x]

My Generation friend also pointed out that Criterion 2.3 might lead to multiple levels of BCS at a Facility.  This could happen in the case where the Planning Coordinator or Transmission Planner notified the owner of a large generating station that one or more units in the station - but not the whole station - were what's known as "Reliability Must Run".  In this case, the systems that control or impact those unit(s) are Mediums, while those that control the other units are Lows (although I believe my friend says the latter are out of scope altogether for CIP V5;  I don't believe that myself, as is hopefully clear by now.  Of course, we are talking about religious discussions here!).

It seems, Dear Reader, that we've reached the end of this post.  To summarize, I think there can’t be multiple levels of BES Cyber Systems at a single Facility.  But I do think there can be multiple levels of cyber assets at a Facility.  Of course, the only way I can say this is by ignoring some of the wording of CIP-002-5 that I contend  doesn't reflect the intentions of the drafting team.  But before you condemn me for that, consider this: I don't think it is possible to make any consistent interpretation of CIP-002-5 without ignoring at least some of the language. Not a great situation, but it's what we've got.

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

---

[i] I’m calling this Part II, but there was really a follow-on to the first post that could have been called “Part IA”.

[ii] I’m sure someone will pipe up, “Hey, what about cyber assets that control one facility but are physically located at another one?  Like AGC, where a component is often located at a control center?”  I would agree this would be a valid question if we were dealing with CIP Version 3.  In that version, a cyber asset can be a CCA as long as it’s “essential to the operation of” a Critical Asset; it doesn’t have to be physically located at the Critical Asset.

However, the Version 5 SDT has – I believe accidentally – taken care of that problem for us.  For example, requirement part 1.1 reads “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset” (italics are mine).  It seems there is no longer a possibility of a BES Cyber System (the functional equivalent of a CCA) being located anywhere but at the BES Facility it’s associated with.  I really think the SDT meant for Version 5 to be like Versions 1-4 in this regard – namely, that all cyber assets associated with a Facility should be considered as BES Cyber Assets for that Facility.  And they actually say this in Attachment 1, where entities are required to identify BES Cyber Systems “associated with” each of the different criteria.  However, I think language found in Requirement Parts 1.1 and 1.2, which call out Attachment 1, would take precedence over language in Attachment 1 itself.  And those two requirement parts clearly say “at” not “associated with”.  Of course, this is yet another ambiguity in CIP-002-5 that would best be cleaned up by rewriting the standard.  I’d like to think FERC will order that to happen, but I don’t know whether they will.

[iii] When I rewrote CIP-002-5 for my comments to FERC in June, I explicitly included the statement “All BES Cyber Assets associated with an Asset/Facility shall take the impact level of that Asset/Facility.”  You can find a discussion of this point (if you look hard enough) in this post.

[iv] As I mentioned in end note ii, I don’t believe the SDT really wanted to limit BES Cyber Systems to those that are physically located at a Facility; I believe they wanted to include remotely-located systems that can control (or otherwise have an impact on) that Facility.  If this is the case, then there could be multiple levels of BCS located “at” a Facility, since an AGC system that controlled a Medium impact generating station could theoretically be located at a Low impact station.  However, if CIP-002-5 is corrected (or perhaps interpreted) to consistently say “associated with”, then the question I asked at the beginning of this post becomes, “Can there be multiple levels of cyber assets associated with a single BES Facility?”  The answer to that question will be the same as the answer to the equivalent question (with “at”) at the beginning of this post.  Given that CIP-002-5 currently reads “at” not “associated with”, we have to work with that wording at the moment.

[v] Of course, I’m engaging in gallows humor here (the fact that I’m writing this on Halloween may have something to do with that).  Asking people to follow the intent of the standard rather than the wording isn’t exactly the textbook approach to compliance enforcement.  Of course, this is just one of the very serious problems I see in CIP-002-5.  I frankly don’t think the standard, as currently written, would ever hold up in a court of law were an entity to challenge a large fine.  And if CIP-002-5 gets invalidated, the other V5 standards become invalid as well.  Comforting thought, isn’t it?

[vi] For proof of this, see requirement parts 1.1 and 1.2 of CIP-002-5 2 (1.1 reads “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset”).  I interpret these to mean (and I’ll admit that some might disagree with this interpretation) that Attachment 1 is being called out so the entity can use it to classify assets, not BES Cyber Systems.

[vii] This reminds me of a great cartoon I once saw.  It shows a dictator standing at a lectern, surrounded by menacing storm troopers glaring out at the crowd and Nazi-like flags.  He is saying, “...and I think I can state without fear of contradiction….”

[viii] Of course, there are some knowledgeable people who believe there is a different way to identify BES Cyber Assets.  I have discussed that difference of opinion in the first post in this series.

[ix] However, I’m not saying they should be treated as “Low impact BES Cyber Systems”.  I think that phrase is a contradiction in terms, like “English cuisine” or “business ethics”.  Now, I know that CIP-002-5 and CIP-003-5 both refer to “Low impact BES Cyber Systems”.  However, both say that no inventory of Low impact cyber assets is required; this means the entity is never required to identify these phantom Low impact BCS.  So this is a purely theoretical construct, and is explicitly removed from being applicable to compliance with CIP Version 5.  There are no requirements in CIP Version 5 that apply to Low impact BES Cyber Systems, only to the Low impact Facility as a whole.  Of course, FERC made noise about changing this in their NOPR in April, but I don’t think they will actually do that when they approve Version 5.

[x] I’ll be the first to admit that this “proof” isn’t exactly up to the highest mathematical standards.  But, given the many ambiguities in CIP-002-5 as currently worded, it’s the best I can do.

When will CIP Version 5 Come into Effect?

Nov. 8: It is very likely FERC will approve CIP Version 5 before Thanksgiving, most likely at their meeting on Nov. 21.  Of course, what will be important is the Order they issue with V5.  When that is issued, your reporter will sequester himself until he has figured out what it means, and will post that as soon as possible thereafter.

(I set out to revise the original post by this name from May.  Then I decided I should just post it anew so people can be aware of it without having to discover it in the musty archives.  I used to work for an economic forecasting firm whose informal motto was, "If you can't forecast right, forecast often."  I have taken that to heart)

If you have read some of my other posts, you will know the question in this title is a trick one: I don't believe CIP Version 5 will ever come into effect.  I believe it will be superseded by CIP Version 6, which will be developed to comply with the order that FERC will enter when they approve Version 5.  For more on that convoluted story, see this post.

Given this, what is the likely date that CIP Version 6 will come into effect?  Consider the following:

• I think it is likely FERC will issue the order approving Version 5 in Nov. or Dec. of this year. 
• The Version 5 implementation plan has V5 coming into effect two years after FERC approval for High and Medium impact BES Facilities (of course, we're talking the US here.  For Canadian entities, it depends on the province).  Specifically, the date is the first day of the ninth quarter after FERC approval.  However, FERC "approval" could be interpreted as either the day of their Order approving V5 or its effective date, which is 60 days after its publication in the Federal Register (which usually happens within a few days of the Order). If we use the Order date for approval and FERC issues their order in November, then the V5 compliance date for Highs and Mediums will be Jan. 1, 2016.  If we use the effective date (i.e. January 2014), then the compliance date will be April 1, 2016.  Lows will have to comply a year later than either of these two dates.
• But here's one catch: As I have discussed in various posts, I believe it is likely that FERC will, when they approve V5, at the same time require that NERC come back with a compliance filing.  This will be CIP Version 6.  If I am right about this, then the above compliance dates are meaningless, since V6 will be the next version NERC entities have to comply with, not V5.  I also estimate that FERC will give NERC about 9 months to come back with the compliance filing.
• This means that, if FERC approves V5 in November 2013 and orders a compliance filing, V6 will be presented to them by Q3 of 2014.  Since V6 will presumably be what FERC wanted (it will include what FERC ordered, and nothing more), it shouldn't take them long to approve it. Let's say they'll do this by the end of Q4 2014.
• If they do this, then the V6 compliance dates get shifted back exactly a year from the V5 ones.  So the High/Medium date will either be January 1 or April 1 2017, with Lows a year after.
• But I'm leaving something important out of this analysis so far: FERC hinted broadly in their NOPR that they are going to require the implementation times be shortened in Version 6. I'm guessing FERC will reason that their approval order in 2013 will end uncertainty about the contents of the next CIP version, since V6 will be based on V5 plus exactly what FERC orders in changes.  I'm thinking FERC may order the compliance dates for V6 to be shortened by a year, so that effectively they're the same as if FERC had simply approved V5 in 2013 (since FERC will approve V6 about a year after they approve V5).
• So if Version 6 gives just one year for Highs and Mediums to come into compliance, but two years for Lows, then the dates are the same - given these other assumptions - as what I just listed for Version 5 by itself: either Jan. or April 1 2016 for High/Mediums, and a year later for Lows.  
• Of course, given the amount of uncertainty described above, you certainly can't plan on having to comply on these exact dates.  You should put a confidence band around them - maybe three months either way, maybe six months.  And there's also the possibility (small, to be sure) that I don't know what the h___ I'm talking about, so the dates could be completely different.  What can I say?  This is a tough business.

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

Note: Honeywell has developed three white papers on CIP Version 5 – what’s in it and what you need to do to comply with it.  They haven’t been posted yet, but if you would like me to send them to you, email me at tom.alrich@honeywell.com.

To BROS or not to BROS?

Nov. 8: It is very likely FERC will approve CIP Version 5 before Thanksgiving, most likely at their meeting on Nov. 21.  Of course, what will be important is the Order they issue with V5.  When that is issued, your reporter will sequester himself until he has figured out what it means, and will post that as soon as possible after the Order is issued.

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

First a shameless plug: Last week, I spent three extremely enjoyable and useful days at NERC’s GridSecCon cyber security conference in Jacksonville.  This was the first one I have been able to attend (someone finally figured out how not to have it conflict with WECC’s CUG/CIPUG, as it has in previous years).  I really didn’t expect anything so well-attended and with such a high quality of discussion – both at the conference and at the receptions (of which there were three!), lunches and breaks.  And BTW, St. Augustine was a great side trip.

I congratulate Brian Harrell for the great job he’s done putting this together and building it up in just three years (the direct organizer / emcee this year was Bill Lawrence).  Brian is very busy organizing GridEx in November, which should be even more of a big, important event.  Even a couple months away, it has garnered popular mindshare,[i] and I predict it will be big news when it actually happens.  Next year, GridSecCon will be in Texas in October; you should mark your calendar now.

This post follows up on my previous post, which was part 1 of my sure-to-be-blockbuster series of posts on seemingly unsolvable problems in CIP-002-5.  In that post, I discussed the arguments between several very Knowledgeable People and myself on the role of the BES Reliability Operating Services in identifying BES Cyber Assets / Systems.  I strongly suggest you read that post (of course it’s long, but which of my posts isn’t?  I don’t think I could tell you the time of day in less than three pages), but I’ll summarize it now anyway.

The BES Reliability Operating Services (hereinafter “BROS”) were a concept introduced in the definition of BES Cyber Asset in the first draft of CIP-002-5.  In that draft, the entity needed to identify its BES Cyber Assets/Systems by first identifying the reliability functions the entity performs, then identifying the systems that allow it to perform those functions.  BROS was removed from the definition in the second draft and put in the Guidance and Technical Basis section (i.e. it is now not at all part of the requirements anymore, merely a “nice thing to consider”).  Meanwhile, the current CIP-002-5 R1 says the entity needs to identify its BES Cyber Assets (really Systems, but they’re composed of Assets), and since it doesn’t offer any further guidance, this means the only thing the entity can do is simply rely on the current definition, which doesn’t refer to the BROS at all, in order to find out which assets are BES Cyber Assets and which aren’t.

The Knowledgeable People I referred to (and my guess is there are a lot of them at NERC and the Regional Entities, as well as at some Registered Entities) believe the Registered Entity needs to use the BROS to identify its BES Cyber Assets (BCA), and if it doesn’t do that, it won’t be properly identifying its BCA’s.  Of course, if BCA’s aren’t identified properly, the entity is pretty much out of luck for being compliant with anything else in CIP Version 5.  Just as Critical Cyber Assets were the foundation of CIP Version 1-3, BCA’s[ii] are the foundation of Version 5.

My alternative proposal for identifying BES Cyber Assets also says that the entity should do the BROS analysis and identify all the cyber assets / systems that are possible with that analysis.  But given the wording of CIP-002-5, the entity can’t stop there.  I see no reason why the BROS analysis will identify every cyber asset that meets the definition of BES Cyber Asset (since, as I said, the definition no longer says anything about BROS).  Therefore, I suggested in the last post that the entity continue by examining all of their remaining cyber assets (i.e. those that were not identified as BCA’s through the BROS process), and compare each of these to the BCA definition.  The lists generated by both parts of this process will then be combined to produce the final BCA / BCS lists.

I am the first to admit this is a very kludgey process; it would be much better to just have one process for identifying BCA’s, not two.  However, if you really want a compliant methodology for identifying BCA’s, you need to follow the requirements.  And nowhere in the two requirements of CIP-002-5, or in Attachment 1, or in the Definitions document, is there any mention of BES Reliability Operating Services.  So anyone wanting to have a compliant one-step process for identifying BCA’s must instead just follow the second of my steps: compare each cyber asset to the BCA definition.  This may not be as much fun as using BROS, but it has the not inconsiderable advantage of not being likely to land you a big fine for violating CIP-002-5 R1 (and since this requirement is the foundation of the rest of CIP Version 5, violating that requirement will entail violating a lot of other requirements as well).

However, I must say I am totally alone in this opinion (as far as I can see, anyway.  If there is someone who agrees with me, please raise your hand.  Even my mother says she’s not sure whether I’m right or not).  I have talked to four people who are extremely knowledgeable about CIP Version 5, and they all say the BROS analysis is both necessary and sufficient for identifying BES Cyber Assets.  So what’s the deal?  Did they all have tainted sushi at some NERC meeting?  I won’t rule that out, but I thought that having a long conversation with one of them last week might allow me to state my case slowly and reasonably, thus undoubtedly convincing him I was completely right and he was completely wrong.

Well, guess what?  I had that conversation, and he didn’t budge an inch.  He continues to believe that doing the BROS analysis is all an entity needs to do to identify all of its BCA’s.  He gave me various reasons for this. So we agreed to keep disagreeing.

But this got me thinking about two questions:

1. Under what circumstances could the BROS analysis be considered sufficient for identifying BES Cyber Systems / Assets, from a compliance and auditing point of view (not just from an elegance point of view – and I certainly don’t deny the BROS approach is a very elegant one)?
2. If those circumstances were realized, what would be the implications of allowing, even requiring, entities to base their entire CIP V5 asset identification process on the BROS?

To address the first question first, I think the best way to give the BROS official status (again) in CIP-002-5 would be for FERC to order NERC to go back to the original BCA definition, which was based on BROS.  Nothing would have to be changed in the actual requirements of CIP-002-5.  However, I’m not betting FERC will order any changes in the wording of CIP-002-5 at all.  So what’s Plan B?

My Plan B is for NERC to issue some sort of guidance to the auditors, saying they should audit the entity’s process for identifying BES Cyber Assets based on how well they applied the BROS analysis.  Now, this might seem to be in some way rewriting the standard without going through the standards development process.  I will agree there would be questions about this, but NERC could just say, “All we’re doing is telling auditors how to interpret the definition of BES Cyber Asset”.  That might or might not fly, but I’ll admit I’m stretching to find a way to allow the BROS analysis to be officially part of the compliance process - meaning entities not only could use it but would have to use it, or risk being found non-compliant.[iii]

So there’s at least one possible way (and there are likely more) that NERC could mandate incorporating the BROS in the compliance process.  Let’s get to the second question: What would be some of the ramifications of this?

And here’s where it gets disconcerting (you may want to get your favorite antidepressant handy): While the BROS approach is a wonderful way to identify BCA / BCS in theory, I see some serious problems if it is designated the only compliant approach.  Here’s why:

As I mentioned in a previous post, the Standards Drafting Team usually discussed the asset identification process in terms of “big iron” and “little iron”.  The former term refers to the facilities (or assets) that perform functions for the grid – generating stations, transmission substations, etc.  The latter refers to the cyber assets that allow these facilities to perform their functions.  I will discuss four methods of identifying cyber assets, each of which treats the big and little iron in a different way.

1. The Old-Fashioned Method

In CIP Versions 1-4, the process of identifying cyber assets in scope (which is, of course, the entire purpose of CIP-002 in all of the CIP versions so far) consists of just two steps:

1. Identify the big iron in scope, called Critical Assets; then
2. Identify the little iron in scope, aka cyber assets “essential to the operation of” a Critical Asset, or Critical Cyber Assets.

This process, whatever its other flaws, has the advantages of simplicity and understandability.  Of course, there have been many disputes over whether a particular Critical Asset or a CCA should or shouldn’t be identified as in scope.  But I don’t know of any challenges to the process itself as being unworkable (a number of cyber security professionals thought it was simply the wrong way to approach cyber security for the grid, but that’s a different problem).

   B.   Prehistoric CIP Version 5

In the first draft of CIP Version 5, the process was completely changed.[iv]  Effectively, the entity had to follow this process:

1. Examine every one of the entity’s cyber assets (at any Facility, whether it would ultimately be declared High, Medium or Low impact) and determine whether it met the BCA definition, which read at the time “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its operation, mis-operation, or non-operation, when required, adversely impact one or more BES Reliability Operating Services.”  In other words, the entity needed to look at each cyber asset and determine if it fulfilled one or more BROS.  If it did, it was a BCA.
2. Once the entity had identified its BCA’s, it needed to go through CIP-002-5 Attachment 1 to determine if the Facility at which the BCA/BCS was located met one of the criteria for High or Medium impact.  If the Facility was High or Medium, its BCA’s would take the same classification.  If the Facility wasn’t High or Medium, it was Low, and its cyber assets were also Low impact.

There were a lot of problems with this approach.  I discussed these in my most recent post, but in even more depth in the 2011 post referenced in endnote iv.  However, look at what is happening here: The process above is almost the reverse of the “big iron then little iron” process in V1-4.  In this process, you start with your cyber assets (the little iron), and decide what is in scope based purely on whether or not they perform a BROS – big iron has nothing to do with it.  The big iron only comes into play in the next step, where you classify the Facility as H/M/L, and its BES Cyber Assets / Systems take that classification.

While the BCA identification process from the first draft of Version 5 is a completely unworkable approach in practice (if you think it would be bad to have to inventory each of your cyber assets at every H/M/L facility, just think what would be involved in also having to sit down and ponder whether each of these performed one or more BROS, then having to document that process.  And then having to argue with your auditor about whether this particular embedded processor at a 120MW generation station aided in performing the Controlling Voltage BROS or not), it is actually a consistent process.  I can’t see any grounds for dispute about whether the process itself is valid.

3. Enter the Hero

I now want to examine the approach I am suggesting as the only way to identify BES Cyber Assets, while strictly complying with CIP-002-5 as currently written[v]:

1. Identify BES Facilities and classify them H/M/L using Attachment 1.  This is like the first step in CIP Versions 1-4, except in those versions there were only two classifications for Facilities/Assets: Critical and not (with Critical Assets being the only assets in scope for the remainder of the requirements in that CIP version).
2. Identify cyber assets at those Facilities that meet the current BES Cyber Asset definition: “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non-operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System.”  This is like the second step in V1-4, with the BCA definition substituted for the CCA definition.

Of course, I did say at the outset that I think it would be a better approach to address the second step above by first using the BROS process to identify as many BCA/BCS as possible, then applying the current BCA definition to catch cyber assets that may have been missed by the BROS process.  But if this seems too cumbersome, stick to the above steps.

4. My Misguided Friends

Let’s now examine the approach my friends are all advocating for the current Version 5 (as opposed to the first draft from two years ago) and see how it compares with both of the above approaches.  Since I had that long discussion with a BROS advocate last week, I will focus on what I believe that person has in mind:

1. Based on each of the entity’s NERC functional registrations, identify the BROS that the entity is required to perform by that registration.  These are shown in a table on page 18 of CIP-002-5, in the Guidance and Technical Basis section (which, to repeat, is not part of the enforceable requirements of CIP-002-5.  It’s just guidance).
2. For each BROS, identify the systems that are used to implement the BROS.  These are BES Cyber Systems, and their components are BES Cyber Assets.  But there is an important thing to remember here: this analysis is independent of the Facilities where these systems are located.  For example, BCS components that support the Controlling Frequency BROS (one of the BROS that a GO or GOP performs) could be located in generating stations, control centers and perhaps other facilities (like substations) as well. 
3. Go to Attachment 1 and classify each BCS as H/M/L.  Here is where things get murky.  You could just consider the Facility each BCS was located at, and use its H/M/L classification to classify the BCS itself; that would be straightforward.  However, I really think my BROS friends want to classify all of the BCS that perform a particular BROS with some sort of rating based on that particular BROS, not on the Facility the BCS is located at.  For example, suppose a generating station is a Medium impact and it performs the Controlling Voltage BROS.  Furthermore, suppose one of the BCS that supports that BROS – for example an AGC system – is located at a Low impact plant.  Will the AGC be Low for that reason?  I think my friends would argue it would be Medium.  In any case, there is definitely ambiguity in this step.

This is clearly not an approach like in A or C above; it isn’t based on first identifying big iron, then little iron.  Instead, you do the reverse, as in B.  However, it still could be a workable approach, were it not that there are multiple problems with it:

1. How would step 1 be audited?  Since the page 18 table isn’t part of the requirements, the auditor can’t ding you for not including a particular BROS in your analysis.  The table would have to be brought into the standard (perhaps as Attachment 2) and referred to in R1 before it could be audited against.  Of course, if FERC orders this be done when they approve Version 5, it could be accomplished along with the other changes they order.
2. This table, no matter how well drawn up, hasn’t been through the standards development process.   Something that would play such an important role in CIP-002-5 (and by extension in the rest of CIP Version 5, since everything in V5 depends on CIP-002-5) needs to do that.  Again, this would be possible if FERC orders NERC to do it when they approve V5 (and would be impossible to do, in my opinion, if they don’t order it.  When FERC approves V5 this fall, I don’t think NERC will have any leeway to introduce any changes to V5 other than those FERC specifically orders).
3. Requirement part 1.3 of CIP-002-5 (which is technically what sends you to Section 3 of Attachment 1) contains this sentence in parentheses: a discrete list of low impact BES Cyber Systems is not required.  But it seems you do have a list of Low impact BCS in the BROS approach – that’s what you get when you finish with Section 3.  And you can bet the auditors are going to want to see that list.  If they don’t, how can they be sure you’ve identified all of the BES Cyber Systems that support the applicable BROS?  If you tell them that just one – or maybe even none – of the BCS supporting the Monitoring and Control BROS is a High or Medium impact and the rest are Lows, they will rightly say, “Show me that’s the case.  Where is your list of all the BCS supporting Monitoring and Control?”  As you go through each BROS this way, you will potentially have to show the auditors all of your Low impact BES Cyber Systems – ergo, you will need a list after all.
4. This whole approach needs to follow requirement 1 of CIP-002-5; however, it doesn’t.  R1 addresses big iron first, then little iron – as in Versions 1-4.  The first part of R1 requires the entity to “consider” a list of six asset types (control centers, transmission substations, etc).  The second part requires it to identify High, Medium and Low impact BCS using the three sections of Attachment 1.  So the entity has to first identify the Facilities in scope and then do two things in the second part: classify those Facilities H/M/L and identify BCS at those Facilities – presumably by looking at which cyber assets meet the BCA definition, then aggregating these into systems.[vi]  Since the BROS approach just described starts with the little iron then goes to the big, it will obviously not fit in with the current CIP-002-5 R1, which does the opposite; R1 would have to be completely rewritten.
5. As I said above, the BROS approach doesn’t care where a BES Cyber Asset/System is located.  If a BCS that facilitates a Generation Owner BROS such as Controlling Frequency is housed in a substation, and that BCS is Medium impact because the generating station it operates through is a Medium, then it will still be Medium even if the substation it’s in is a Low impact.  Because of this, all of the cyber assets in the substation that are networked with this BCS will be Medium impact Protected Cyber Assets (by the “high-water mark” rule), and subject to almost all the requirements of Medium BCS.[vii]  This of course doesn’t make it impossible to utilize the BROS to identify BCS/BCA, but it is something to think about: it could lead to some (and I don’t know how many) Low impact Facilities being effectively upgraded to Medium or even High impact.

Since I’m getting tired and I’ve once again produced a post that seems to rival War and Peace in length, I’ll stop here.  The upshot is that I don’t think the BROS approach is workable – unless I’m completely missing the point about how it would be implemented – without a complete rewrite of CIP-002-5, which I think is highly unlikely.  I don’t think FERC will order that be done when they approve Version 5.

So what is the solution?  I don’t know.  You have a seemingly irresistible force (the strong inclination on the part of many key players to base identification of BCS on the BROS) meeting an immovable object (the likelihood that CIP-002-5 won’t be rewritten).  What will give?  Maybe it will be you, Mr/Ms NERC compliance person.  Maybe you’ll just have to muddle through and hope you are in line with whatever inclination your auditor has (on this and the other “religious” questions in CIP-002-5).  Doesn’t that sound like fun?

Didn’t think so.

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

Note: Honeywell has developed three white papers on CIP Version 5 – what’s in it and what you need to do to comply with it.  They haven’t been posted yet, but if you would like me to send them to you, email me at tom.alrich@honeywell.com.

---

[i] Brian said a woman called him to say her daughter was going to give birth during GridEx and to please not bring down the power grid during that time.  He promised her he wouldn’t do that, but just as a favor to her (OK, he didn't really say that second part).

[ii] Of course, the standards are now based on BES Cyber Systems, not BES Cyber Assets.  But BCS are only defined as aggregations of one or more BCA, so BCA is foundational from a definition standpoint.

[iii] A possible precedent would be the NERC Transition Guidance, both for CIP Version 4 and Version 5.  In both of these, NERC gives the entity the option of adopting the Version 4 bright-line criteria in place of their RBAM, but announces they will not include blackstart facilities in compliance audits.

[iv] You can read my interpretation of this process in this post from November 2011.

[v] Those words “currently written” cover a multitude of sins.  There are all sorts of problems with the current CIP-002-5 wording, and I’ve already written about 7 or 8 posts discussing those.  For now, I’m just focusing on the current wording, not what it really should be.

[vi] Of course, the problem here is that these two steps should never be combined as they are, leaving the poor reader (like me) to take an educated guess as to what is really going on.  I believe I have mentioned once or twice somewhere that CIP-002-5 needs to be completely rewritten – and I did that in this post. 

[vii] I will soon do another post on a second “war of religion” in CIP-002-5.  It will discuss the question whether there can be multiple levels of BCS at a single Facility.  For an advocate of the BROS approach to BCA/BCS identification, the answer is simple: “Sure, there can be lots of different levels at one Facility.  It all depends on the impact level of the BROS that they fulfill.”  I say there can’t be different levels at one Facility, except in the case of a couple well-defined exceptions.  So the side someone takes in the BROS/no BROS controversy will be closely correlated with the side they will take in this “multiple/single levels” controversy.

CIP-002-5: The Wars of Religion (Part I)

Nov. 8: It is very likely FERC will approve CIP Version 5 before Thanksgiving, most likely at their meeting on Nov. 21.  Of course, what will be important is the Order they issue with V5.  When that is issued, your reporter will sequester himself until he has figured out what it means, and will post that as soon as possible thereafter.

10/21: I posted yesterday a follow-on to this discussion, which brings it to the exciting conclusion.  You won't want to miss it!

I have been working and talking with a number of people (NERC entities, regional auditors, consultants) recently about how they will identify their cyber assets in scope for CIP Version 5; the imminent approval of V5 seems to be focusing people’s minds on that.  And I haven’t just been talking with them, I’ve been arguing (although one auditor and I agreed to call it “constructive engagement” or some other euphemism for “argument”).

What are we arguing about?  Not Obamacare.  We’re arguing because there are some serious ambiguities in CIP-002-5 (where the dirty work of identifying those cyber assets gets done).  I have written seemingly interminably about these ambiguities and even ended up rewriting the standard and submitting it to FERC during their V5 comment period.  When they approve V5, I really don’t think FERC is going to tell NERC to replace the original CIP-002-5 with mine, but I do hope they at least tell them to try to fix the problems, since it looks like they will order NERC to draft a new version (V6) anyway.

But at this point we really can’t assume there will be any changes made in CIP-002-5 when it’s redrafted as CIP-002-6, and this leads to a question: Given that the ambiguities will probably not go away, how should NERC entities identify their BES Cyber Assets and BES Cyber Systems?  And what are the ambiguities, anyway?

In my arguments on this topic, I have noted a lot of resemblance to religious discussions: Both sides have equal claim to being right (or wrong) based on objective facts, so you can’t just point to something (in this case, a particular phrase in the requirements) and say, “Aha, there’s the proof!  Your argument doesn’t hold water.”  If there were some sort of proof for one opinion or the other, there wouldn’t be the ambiguities I was just mentioning. 

Throughout history, I believe there have been two primary ways in which religious discussions have been resolved:

1. Killing everybody who doesn’t believe as you do; and
2. Figuring out some way to compromise.

Now, I have been accused (unjustly, of course) of injecting too many of my personal opinions into my posts.  So I won’t try to say which of these two courses of action would be better for resolving disputes over CIP-002-5.

However, I don’t really believe the first option is the right one to use in the case of CIP Version 5 disputes (plus it has never worked so well historically, either.  See the case of Christians vs. Lions ca. AD200.  Who ultimately won that one?  Hint: not the lions).  The conclusion is we need to figure out some way for different viewpoints to be reconciled, when it comes to disputes over interpretation of CIP-002-5 (it would of course be very nice if, once FERC does approve V5, NERC set to work immediately on an Interpretation document that tried to fix these problems.  They did do that regarding CIP Version 1, when they produced very good documents on identifying Critical Assets and Critical Cyber Assets.  Unfortunately, they didn’t do that until a year or two after CIP Version 1 came into effect – not exactly great timing for entities who needed to identify their CA’s and CCA’s for V1.  NERC will be releasing their final version of the V5 Transition Guide next June, which will incorporate lessons learned from the current Transition Implementation Study.  Hopefully, these issues will be addressed in that).

With all this in mind, I’d like to discuss a) what are the primary ambiguities in CIP-002-5 and b) how I would suggest they be resolved.  I believe there are either three or four of these primary ambiguities, plus some secondary ones.  I will try to address each primary ambiguity in a separate post.

This first post deals with a very meaty ambiguity.  It has to do with the question “How does an entity identify the BES Cyber Systems that are in scope for CIP Version 5?”  The ambiguity can be succinctly stated: There seem to be a number of people (including auditors) who say the whole cyber asset identification process is based on the BES Reliability Operating Services (hereinafter BROS).  There are others – well, there’s me anyway – who point out that the BROS are nowhere mentioned in the actual requirements (or Attachment 1) of CIP-002-5.  What is mentioned is the definition of BES Cyber Asset (which underlies the definition of BES Cyber System); therefore, IMHO the BCA definition should be the starting point for any complete identification of BES Cyber Systems (BCS).

You may rightly ask, “Why should there be any dispute in this matter?  Some people are saying entities should rely on a concept not even in the requirements, while you’re saying they should rely on something that is in the requirements.  Those other people don’t seem to have any real ground to stand on.”

I would be tempted to let it go at this, except that people whose opinion I respect (including a couple regional auditors, as well as one of Honeywell’s consultants who forms his opinions very carefully) are proposing to base their whole approach to BCA/BCS identification on the BROS.  I want to try to figure out a way that both approaches can be accommodated, since they both have merit.  And let’s be clear: With the imminent FERC approval of Version 5, every entity (with High and Medium impact Facilities) will have to figure out how it is going to go about identifying cyber assets in scope for V5.  It’s not like they can wait a year for the final guidance to be available.[i]

History Lesson

First, some history on the BROS:  The first official draft[ii] of CIP Version 5 was posted in November (or perhaps October) 2011; it was the subject of the first CIP V5 ballot, which concluded that December (and failed dismally).  In that draft, the process of identifying BES Cyber Assets/Systems[iii] consisted of these steps:

1. Identify BCA’s using the definition.  That definition stated that BCA’s needed to fulfill one or more BROS: “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its operation, mis-operation, or non-operation, when required, adversely impact one or more BES Reliability Operating Services.”
2. Classify those BCA’s as High, Medium or Low impact depending on the classification of the Facility with which they’re associated –and this comes from Attachment 1. 

Pretty straightforward, right?  Just two steps, not the 14 I identified as being required to list and classify BES Cyber Systems in the final version of CIP-002-5.  However, I and others[iv] became convinced this would be a nightmare to implement, and we made our point in this blog post from December 2011.  I recommend you read the post, but I’ll summarize what we said:

• The approach in Draft 1 would require a huge effort of every NERC entity subject to CIP.  They would have to inventory every cyber asset they owned (at a Low, Medium or High impact facility, although this classification wouldn’t be done at this point[v]), decide whether or not it performed one or more of the BROS, and if so which one(s). 
• It is only in a few special cases that a cyber asset performs a BROS all by itself; in almost all cases, it is the facility it’s associated with that performs the BROS.  Take the system that controls water purification in a control plant – does it perform the Controlling Frequency BROS all by itself?  No, but it contributes to it, given that the plant might shut down if that system failed – and the plant does perform the BROS.  The system’s contribution is only through the plant, not on its own.  But the first draft of CIP-002-5 required the entity to conduct the BROS analysis on every cyber asset it owns (i.e. regardless of the BES Facility it was part of, or even if it was part of any BES Facility at all), and only then classify each system as Low, Medium or High impact based on the Facility it was associated with.  And since this would require an inventory of all Low impact cyber assets (indeed, it would go far beyond an inventory), it would of course violate the statement that such an inventory isn’t required (this statement was in the first draft, as well as the final version).
• This would be an auditing nightmare.  The auditors would have to go over the documentation of this entire process to make sure it was conducted correctly (and probably sample some cyber assets to make sure they were included).  There would be endless arguments over whether loss of a particular cyber asset “adversely impacted” a particular BROS or not.  And who would settle these arguments?  Would the auditors have to bring with them a team of EE’s?  And would the entity be able to counter with its own EE’s?  Then who would be the uber-EE’s who made the final ruling on this?

In the December 2011 post, we suggested a much more straightforward approach to BES Cyber Asset identification, modeled after CIP versions 1-3:

1. Classify each BES Facility as Low, Medium or High impact using Attachment 1;
2. Determine the BROS that the Facility supports; and
3. Identify the cyber assets associated with the Facility whose loss or misoperation would cause the Facility not to be able to fulfill one or more of the BROS it supports (i.e. identify cyber assets that met the definition in the first draft).  These are the BES Cyber Assets.[vi]

Whether this post had anything to do with it or not, the first draft of CIP Version 5 was roundly voted down.  When the SDT met at ERCOT’s headquarters in January 2012, they quickly changed the BCA identification process to reflect something like our suggestion.   However, they went further than that: they removed all reference to the BROS in the BCA definition, in the requirements of CIP-002-5, or in Attachment 1.  From that point on, the BROS were only in the Guidance and Technical Basis which accompanied the standard (which cannot be audited or enforced as part of the requirements).  The new BCA definition was pretty close to the final one, which begins:

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

Back to the Present

I went through this history to let you know how the BROS came to be discussed in the Guidance and Technical Basis section of CIP-002-5.   The BROS were in the requirements themselves (through being in the definition of BCA) in the first official draft of Version 5 (and they had been in all the previous unofficial drafts going back to the original CIP-010 and -011, which were the first attempt to draw up a new CIP version to finally address the remaining issues in FERC’s Order 706).  I won’t deny that using the BROS is a very elegant way to identify cyber assets that should be in scope for CIP.  What would be a better way to protect the BES than by looking at the services that support the reliable operation of the BES, then finding the cyber assets that support those services?

However – once again – the BROS are not at all part of the requirements of CIP-002-5.  This means that

• An auditor can’t assess a Potential Violation because an entity didn’t use the BROS in identifying BES Cyber Assets; and
• An auditor can (and presumably will) assess PV’s against an entity that didn’t identify all of its cyber assets that meet the final CIP Version 5 definition of BES Cyber Asset. 

So let’s get back to the argument.  My position (at least my starting one) is pretty simple: CIP-002-5 R1 requires the entity to identify BES Cyber Assets, period (actually, it requires them to identify BES Cyber Systems.  But the BCS definition simply refers to the BCA one, so the concept of BCA is still fundamental to the cyber asset identification process).  The only way to strictly comply with this is to go through all cyber assets (following the cyber asset definition in Version 5) associated with[vii] a Medium or High impact[viii] Facility and identify those that meet the definition.

But what do the BROS people argue now?  They don’t say the same thing that was in the original draft of CIP-002-5, namely that the entity needs to go through every cyber asset they own and determine whether it fulfills one or more BROS.  What they say is that the entity needs to:

1. Identify the BROS that the entity has to fulfill, given their NERC functional registrations.  For example, a BA performs the “Balancing Load and Generation” BROS (the table on page 18 of CIP-002-5 provides a good list of which registrations perform which BROS). 
2. Identify the systems that implement that function, which become BES Cyber Systems.  In this example, it would be the BA’s EMS or SCADA system.  This (or perhaps a subset of it) is a BES Cyber System.
3. Identify the cyber assets that make up the BCS.  These are the BES Cyber Assets.[ix] 

This is a completely different approach from mine, which I believe to be the only compliant one given the wording of CIP-002-5.  Mine is a "bottom up" approach, where you start with each cyber asset and see whether or not it meets the definition of BCA[x]; you then aggregate these into BES Cyber Systems to suit your needs (and of course, you can have a single BCA constitute a BCS).  The BROS-based approach is a “top down” one, where you first identify BCS, then the BCA’s that constitute the BCS.

The Solution?

How could these two approaches be combined?  By doing both, of course.  I’m fine with having the entity first do the BROS analysis; as I mentioned, that is certainly more elegant and attuned to the whole function of NERC CIP than just using the BCA definition.   Furthermore, it is almost certain that any BCA’s identified through the BROS process will meet the definitions, so none of this effort will be wasted.

However, the converse of the above sentence isn’t true: It isn’t certain that every potential BCA (i.e. every cyber asset that meets the definition of BCA) will be identified with the BROS process.  I see nothing in the BCA definition that precludes the idea that there could be BES Cyber Assets that don’t actually assist in performing one or more BROS.  These wouldn't be identified in the BROS process.

And – once again – what is required in CIP-002-5 is that every cyber asset that meets the definition be identified, and that it be incorporated into a BES Cyber System for compliance with CIP-003-5 through CIP-011-1.  Therefore, I suggest that the entity look at all cyber assets that weren’t previously identified as BCA's in the BROS approach, and identify those that meet the BCA definition.  These will then be aggregated into BCS.

Here is how I would combine the two approaches:

1.     Identify the BROS that the entity has to fulfill, given their NERC functional registrations.  For example, a BA performs the “Balancing Load and Generation” BROS (the table on page 18 of CIP-002-5 provides a good list of which registrations perform which BROS). 

2.     Identify the systems that implement that function.  In this example, it would be the BA’s EMS or SCADA system.  This (or perhaps a subset of it) is a BES Cyber System.

3.     Identify the cyber assets that make up the BCS.  These are BES Cyber Assets.

4.     Examining the remaining cyber assets, identify those that meet the definition of BCA.

5.     Aggregate these into BCS, composed of one or more BCA’s.

6.     Combine the two BCA lists and the two BCS lists – voila, here are your lists!  Now take the BCS list and go forth and conquer CIP-003-5 through CIP-011-1 (but keep your BCA list in the closet for when the auditor shows up).

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

---

[i] There will be some interim releases of lessons learned from NERC’s Transition Implementation Study, before the final report in June 2014.  However, I’m frankly kind of skeptical about this whole exercise.  Whenever NERC tries to offer guidance to clear up ambiguities in the standards, they run into the problem that they’re then seen as rewriting the standards in some way – without benefit of member input and a Standards Drafting Team (of course, the unhappy fate of the CANs was a perfect example of this).  NERC isn’t a regulatory body – FERC is.  Any binding interpretation really has to come from them.

FERC can provide guidance by approving or remanding interpretations that NERC drafts (lately, they seem to be mostly remanding the ones having to do with CIP).  On the other hand, the whole Request for Interpretation process takes a year or more, and I don’t even know when RFI’s could be entered for Version 5 – certainly not now, and maybe not until V6 is drafted and approved by FERC in about a year.  FERC really isn’t going to provide any up-front guidance on V5, unless they provide it in their Order approving V5.

[ii] I would normally include here a link to that draft.  I know it exists somewhere on the NERC web site (along with the other three drafts of all the CIP standards), but after a lot of fighting with the site I gave up.  And this is the NEW, IMPROVED NERC web site!  I have said for a long time that I know a foolproof way to protect critical infrastructure data from Al Quaeda: Just post it on the NERC web site.  They’ll never find it there!

[iii] The terms BES Cyber Asset and BES Cyber System were used almost interchangeably in the first draft, which led to a number of negative comments.  In the next draft, the Standards Drafting Team settled on BCS as the fundamental unit of CIP V5 compliance, although BCS are only defined as made up of individual BCA’s (or even just one BCA).  This remains the approach today.

[iv] I had three collaborators, although only one – Donovan Tindill of Honeywell – could be identified in the post.  Two were NERC compliance people from a large IOU who had come to the same conclusion about the current draft of CIP-002-5 that I had (and had done a much better job of identifying both the problem and a possible solution).  I regret to this day that I couldn’t thank them publicly.

[v] I think this would also have included all of the payroll, accounting, etc. systems on the IT network.  There was nothing in this draft to exclude any systems from the initial consideration.  In fact, there’s nothing in the final CIP-002-5 that excludes those systems, either.  This wouldn’t be a problem if the wording of the final version accurately reflected what I believe to be the intent of the SDT: To have the entity first classify its BES Facilities, then identify the BES Cyber Assets among those cyber assets that are associated with each Facility.  However, the wording of CIP-002-5 still has remnants of the approach in the first draft (especially in Attachment 1), so that it isn’t clear that the entity doesn’t have to first inventory and analyze every cyber asset it owns as a potential BCA, before it even classifies its Facilities.  This is just another of the many ambiguities in the wording of CIP-002-5.  This is a wonderful situation for a blogger like me, as it has given me material for a number of posts.  It isn’t so wonderful for the NERC entities that have to try to comply with this, or for the poor auditors who have to figure out how to audit it.

[vi] In case you think I was for the BROS before I was against them, I remind you that the BROS were part of the BCA definition in the first V5 draft.  In the December 2011 post, we were arguing that definition should be used, but the entity shouldn’t have to apply it to every single cyber asset they owned – just the ones at Medium and High impact BES Facilities.

[vii] I just realized something – and I don’t know why I didn’t realize this a while ago.  Requirement 1 of CIP-002-5 refers to BES Cyber Systems at each Asset.  Shouldn’t this really have been “associated with” as it is in CIP-002-3 R3, where Critical Cyber Assets are identified as “associated” with the Critical Asset?  I always thought this distinction was important, since the systems that control a Critical Asset could be in a completely separate location – e.g. AGC for a gen plant that is located elsewhere.  I think I know what knowledgeable people (who are also of the BROS persuasion) will say: “This is the whole point you’re missing, that cyber assets can fulfill a BROS wherever they are, whether or not it’s for the Facility at which they’re located.  You’re the one who is saying the entity has to first identify the Facility (or Asset) and then identify the cyber assets associated with that Facility.  If you wouldn’t do that, there wouldn’t be any problem with whether or not a cyber asset was located at the Facility – it would still be caught up in the BROS analysis.”

I can’t say there’s anything wrong with that argument as far as it goes.  But the whole point of this post is that the BROS can’t be the entire basis for BCA/BCS identification – and that it was never the intention of the SDT (after the first draft of V5 went down in flames) that it should be (even though the new language they put in at the meeting at ERCOT still – maddeningly – partly reflected the previous approach, especially in Attachment 1.  And that language remains today).  So I would think the final NERC Standards Transition Plan will change the wording “at each asset” in R1 1.1 and 1.2 to “associated with each asset”.  That is, unless NERC actually wants to only include cyber assets physically located at the Facility in question. If that’s the case, then nothing needs to be done.

[viii] This analysis doesn’t have to be done for Low impact Facilities, of course.  The only way that might change is if FERC requires there be cyber asset-specific requirements for Lows in the new version.  For example, if they require patches be evaluated and applied, antivirus be implemented and updated, etc.  Requirements like these would need to be audited on a per-device basis, meaning the Low entity would have to inventory cyber assets and identify BES Cyber Systems.  I don’t think this will happen, though.  I think FERC will require some more programmatic requirements – there must be a patch management program, an A/V program, etc. for the cyber assets at the Facility.  These requirements will be written in such a way as not to require auditing of specific cyber assets.  And I think it’s very likely FERC will require that every cyber asset be within an ESP, but without requiring auditing of each particular cyber asset to make sure this is the case.

[ix] I am grateful to Sarosh Muncherji of Honeywell for designing this approach, and pointing out that it is a top-down one.

[x] Of course, the definition of BCA changed between the first draft and now.  Otherwise, both my approach and the one in the first draft would be the same.