Roll Your Own Part VI: “Affect the BES”

This is yet another in a series of posts on questions of the meaning of particular wording in CIP version 6.3940 – questions for which there is not now and perhaps never will be any definitive guidance from NERC or the NERC regions.  In other words, this is just another case (number 6 of what I project to be about 5,246 cases) in which entities need to “roll their own” interpretation.  For a full description of the implications of what it means to roll your own, I refer you to the first three posts in this series, starting with this one[i].

I recently prepared an up-to-date summary of all the steps required to identify and classify BES Cyber Systems for a customer, and then called him to review it.  As I’m sure you know by now, one of the first required steps is to identify Cyber Assets[ii] that meet the definition of BES Cyber Asset (although the need to do this is never explicitly stated in CIP-002-5.1 R1 or in Attachment 1.  This is because the requirement was evidently written by a haiku master for whom compression of meaning into very few words was the primary criterion for a good requirement.  CIP-002-5.1 R1 may win a Pulitzer Prize for Poetry, but it won’t win a prize for regulatory clarity, if there is such a thing):

 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.[iii]

As we got to this step, my customer asked, what does “affect the reliable operation of the BES” mean?  And to be honest, I didn’t have an answer – except to say there’s no official guidance that I know of on this question, at least for BES Cyber Assets.

However, there is guidance on this point for BES Cyber Systems.  This guidance is found in the long discussion on pages 17 - 22 in the Guidance and Technical Basis section of CIP-002-5.1, of the BES Reliability Operating Services.  It is a good discussion, and while there are still many questions to be answered about how the BROS are applied in the real world, using the BROS can certainly be helpful in identifying BES Cyber Systems.

Because the BROS analysis really is meant to apply on the system level, it should be applied as part of the "top-down" approach to BCS identification.  You can read about that approach in this post on my overall "methodology" for CIP-002-5.1 R1 compliance, or in this post which specifically compares it to the "bottom-up" approach.

When I originally wrote this post (the one you're reading.  I'm updating it on Jan. 27), I thought that all entities should apply both the top-down and bottom-up approaches to identify BES Cyber Systems.  Because I thought that, and because the BROS are much more suited to the top-down approach, I said there was no point in entities re-doing the BROS analysis as part of the process where they identify Cyber Assets that meet the BCA definition - i.e. the bottom-up approach; they would presumably have already used the BROS in their top-down analysis (which should always come first).  So in my original version of this post, I didn't recommend the BROS be used to help determine what "affect the BES" means for particular Cyber Assets.

However, I have now changed my opinion that all entities should perform both the top-down and bottom-up analyses to identify BCS.  I do still recommend this for control centers and generating stations (except plants that meet Criterion 2.1, which need a different methodology altogether - one I hope to write about one of these days).  But for substations, I no longer think the top-down approach provides any value; the bottom-up by itself is sufficient.

Given this change, my previous argument that entities shouldn't use the BROS in identifying Cyber Assets that meet the BES Cyber Asset definition is no longer valid; I do think it is helpful to do so, although I don't think you should only consider the BROS when identifying Cyber Assets that affect the BES.  Specifically, I think the entity should a) read through the discussion on pages 17 - 22 in the Guidelines and Technical Basis section of CIP-002-5.1; b) identify the BROS that apply to the substation being examined, or specifically to the Facility within that substation that the Cyber Asset (potential BCA) is associated with; and c) determine whether the Cyber Asset actually contributes to fulfilling one or more BROS.  If it does, and if it its loss, etc. would result in a BES impact in less than 15 minutes, then the Cyber Asset is a BCA.

However, the BROS don't tell the whole story when it comes to identifying Cyber Assets that have a sub-15-minute impact on the BES.  Here are two examples of Cyber Assets whose loss, misuse, etc. can definitely affect the BES within 15 minutes, yet which would not be identified as BCAs at all if only the BROS are used in the bottom-up approach.  In SPP’s excellent BES Cyber System Identification workshop (which I attended in March in Dallas, and which they re-ran in June), they discussed an environmental monitoring computer (CEMS) in a large plant subject to criterion 2.1.  They hypothesized there was a rule at the plant saying that the plant had to be tripped offline if there were an environmental excursion that lasted more than ten minutes.  So someone wanting to bring the plant down would only have to hack into the CEMS computer and display false data indicating there had been an excursion; the plant would immediately be tripped.  This computer clearly has an impact on the BES within 15 minutes, but it doesn’t fulfill a BROS at all; environmental compliance isn’t a reliability function (essential though it may be for the owner of the plant).

Here’s another example in a substation.  Many substations have fire suppression systems protecting their control room; there is usually a computer controlling this system.  If say a disgruntled employee (or an outside hacker) uses the computer to disable the fire suppression system, it won’t be able to control a fire when it breaks out – meaning the lines, transformers, etc. controlled by the relays in the control room may be brought down in the event of a fire there (of course, here is where the words “when needed” in the BCA definition come into play.  The hack of the system doesn’t produce its effect until a fire breaks out and it’s not suppressed.  But the interval of time between when the fire breaks out and isn’t suppressed and the time when the BES is impacted will most likely be less than 15 minutes, so the computer is a BCA).  As with the CEMS system above, fire suppression isn’t a reliability service and this computer wouldn’t be identified as a BCA if only the BROS were used to define “affect the reliable operation of the BES”.

I’ve just said you shouldn’t base your BCA identification on the BROS.  Here’s another thing you shouldn’t base it on: network connectivity (and I want to thank Steve Parker of EnergySec for pointing this out to me).  I have heard it said that some people – perhaps even in NERC and the regions – are pointing to a Cyber Asset’s connectivity as a measure of its impact on the BES (for some Cyber Assets).  The reasoning  they use is probably something like, “This Cyber Asset doesn’t itself have a direct impact on the BES, but it is routably connected to a number of other Cyber Assets.  Collectively, loss of most or all of these Cyber Assets, through say a DOS attack launched from any one of them, would affect the BES within 15 minutes.  Therefore the Cyber Asset should be a BCA and part of a BCS, and the rest of the Cyber Assets on the network should be Protected Cyber Assets.”

This is of course a perfectly good argument for securing this network.  The network should be deemed a “critical network”, and the devices on the network should be protected to a higher degree than devices on a different network that isn’t “critical”.  Moreover, I’ll stipulate that the SDT should have included some provision in CIP v5 so that an entire network would have to be declared a BCS, if it could have this collective impact.  However, they didn’t do this; CIP-002-5.1 R1 says nothing about “critical networks”, only BES Cyber Assets and BES Cyber Systems.  So don’t let anyone tell you that network connectivity has anything to do with whether a Cyber Asset is a BCA or not – it doesn’t.[vi]

There is another way you can define "affect the BES".  To describe this, I'd like to go back to the days of yesteryear – 2008, when dinosaurs still roamed the earth and CIP v1 was being implemented.  My readers may have heard their tribal elders talk about how Critical Cyber Assets were identified in v1-v4.  It was much simpler then.  You first identified “big iron” – your Critical Assets (substations, generating plants, etc).  Then you identified Critical Cyber Assets that were “essential to the operation of” these Critical Assets. End of story.[vii]

I suggest that a similar methodology be used to identify BES Cyber Assets – i.e. to implement the bottom-up approach.  You need to look at the asset/Facility with which the Cyber Asset you’re evaluating is associated; this asset or Facility will be the “subject” of the bright-line criterion that has made you consider this Cyber Asset as a BCA in the first place (since you only have to identify BCAs/BCS for assets/Facilities that meet one or more of the High or Medium criteria in the first place).[viii]  Then you need to identify Cyber Assets that are “essential to the operation of” the asset/Facility in question (and you need also to consider the effects of misuse, availability “when needed”, etc. – since the BCA definition includes more than the CCA “definition” did).[ix]

Of course, there is still the question of what “essential” means. There isn’t one definition that applies to all types of assets/Facilities; rather it has to be defined specifically for each type.  Fortunately, many NERC entities already have a lot of experience with this question, since it was the foundation of their v1-v3 compliance efforts.  And if you haven’t had to comply with CIP before v5, there are organizations like mine that can help you do this.

To summarize this post:

1. Every entity needs to develop and document a methodology for identifying BES Cyber Systems, then apply it in their environment.  There are two main approaches in this methodology: "top-down" and "bottom-up".
2. The bottom-up approach to identifying BES Cyber Systems (which I think should be used by all entities, except for a generating station meeting Criterion 2.1.  For substations, bottom-up is the only approach needed; for control centers and non-2.1 generating plants, a combination of both approaches is needed) requires the entity to develop their own "definition" of what the words "affect the BES" mean in the NERC definition of BES Cyber Asset.
3. I haven't provided a definition for you, but I have discussed a methodology that I think is more than adequate.  It involves two steps: a) Using the BROS and b) considering whether a Cyber Asset is "essential to the operation of" the asset or Facility it's associated with.
4. Step 3a) only makes sense for assets that haven't already applied the top-down approach - that is, for substations.  Step 3b) makes sense for all assets.
5. None of what I say here is actually mandated by the requirements.  What is mandated is that you have some methodology for identifying and classifying BES Cyber Systems.  I'm suggesting the material in this post can form part of that overall methodology.  To see my suggestions for the full methodology, see this post.

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

---

[i] I’m saying you should read the first three posts because they all provide some general guidance on how to roll your own definitions and interpretations.  Of course, the others are worth reading as well, but mainly because of the specific issues they address, not as a discussion of rolling your own in general.  It would be nice to include all of these in a big, comprehensive book on CIP v5 (I’ve certainly written enough blog pages on v5 to fill a book or two), but I see no way to do that for probably a year or more.  I’m discovering all of the stuff I’m writing about in the blog in real time, and I don’t expect that situation to change very soon; there’s no way I could write a book now without having to update it every month or so. 

[ii] Of course, identifying Cyber Assets – i.e. “programmable electronic devices” – is really the first step in the BCS identification and classification process.  But a previous step to that is rolling your own definition of “programmable”, as discussed in the first post in this series.

[iii] Of course, there’s more to the definition than this.  But this is the operational part.

[iv] I’ll give you notice here that this session with the customer led me to a much broader realization: It is simply not possible to come up with any single methodology for complying with CIP-002-5.1 R1, even if you leave spaces for the various “roll your own” issues.  Therefore, I believe this requirement is simply not auditable, in the sense that PV’s can be given for failure to follow the “proper” methodology.  The best an auditor can do is determine whether the entity has made a good faith effort to gather all the available information and come up with a methodology that takes as much of that into account as possible.  If they have, there can’t be any PVs, since no penalty for violating this requirement would ever be upheld in a court of law if it were challenged; there are simply way too many holes and inconsistencies.   As you can imagine, I’ll have more to say on this in the near future.

[v] In fact, the bottom-up approach is the one that is “required” in R1 although, as in the case of BCA identification, the need to do this is never explicitly stated in the requirement.  It’s another example of a point I plan to make in the near future – that R1 should be read more as a poem than a regulatory requirement.  I’m not kidding about this, either.

[vi] I did also hear that someone had been told by an auditor that the fact that a Cyber Asset had certain known vulnerabilities meant that it was a bigger threat to the BES and should be considered a BES Cyber Asset.  Again, the threat posed by a device has nothing to do with whether it’s a BCA.  It should of course be protected (and if it’s networked with at least one other BCS, it will be a PCA and will therefore have to be protected in the same way as BCS).

[vii] I have to admit that there was a great oversimplification for substations in the v1-v3 approach, since it considered the entire substation to be the Critical Asset, not the individual Facilities in it – lines, transformers, etc.  This was based on an improper analogy to generating stations and control centers.  The latter two assets both have a defined function: generating power and controlling the grid, respectively.  But a substation is simply a collection of equipment with a fence around it.  It’s the Facilities (500kV lines, etc) at the substation that should be judged critical or not, not the entire substation.  In other words, when it comes to substations in v1-v3, CCA’s should have been defined as “essential to the operation of” the Facilities located at the substation, not the substation itself.  This seems to have been done when the bright line criteria were introduced in v4, although since v4 was never implemented these questions were never really brought out – at least I certainly never realized there was a difference between a Transmission Facility and a substation when v4 was being discussed.

[viii] Since some of the Medium criteria refer to Facilities, not assets, you can’t just say the criteria refer to assets – as I used to do (and as it seems 95% of people in the NERC community - including most of the NERC and Regional Entity people who should know better - say).  So when asked what the criteria refer to, I have been saying they refer to their subjects, which can all be described as either assets or Facilities - with the further complication that, in some cases, the word “Facilities” isn’t used in a criterion even though the subject is a Facility (e.g. in criteria 2.2, 2.9 and 2.10).  However, a customer pointed out to me that the criteria aren’t written as complete sentences, so technically they don’t have a subject. He was right, of course, but I’m simply going to pretend I didn’t hear that.  I’ll still refer to “the subjects of the criteria”.

[ix] You’ll note I’m substituting “impact on the asset/Facility” for “impact on the BES” here.  I have always believed that the idea that Cyber Assets have a direct impact on the BES itself is a real stretch (I argued that in this post in 2011, as well as in person and by email with SDT members that year) – and whether or not this is possible, it is certainly nothing the entity can determine, except in a few cases.  What you can determine is the impact of the Cyber Asset (potentially a BCA) on the asset/Facility it’s part of, just like you did in v1-v3.  Once you know whether the Cyber Asset impacts the asset or Facility, you’ll know whether or not it impacts the BES.  This is so because the bright-line criteria determine whether an asset/Facility has a High, Medium or Low impact for you; you don’t have to determine this on your own, as you did in v1-3 with the RBAM (I again thank Steve Parker for pointing this out).  That’s why I’m saying here that you should look at the impact of the Cyber Asset on the asset/Facility it’s associated with, not on the BES directly.