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:
- 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".
- 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.
- 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.
- 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.
- 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.
