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.