BES Cyber System Identification Methodology – Now, Less Filling!

Sept. 1, 2015: I made some important changes to this post just now, since I want to reference it in a new post I'm writing. So don't be surprised that this post references posts that weren't written until afterwards. The only ESP I possess is the kind that surrounds BES Cyber Systems.

I am a great believer in recycling.  So today, when I ended up writing – for a different purpose – a kind of “Lite” version of my previous post on CIP-002-5.1 R1 compliance methodology (“R1”), I decided – gee, wouldn’t the blog readers just love to see this?  Plus, since I receive about $5 a word for what I put up, I’m always interested in having more words to post (you always suspected I was paid by the word, didn’t you?).

Note: The previous post just referenced lays out a "methodology" for the entire process of complying with R1.  In this post, I am just addressing the BES Cyber System Identification part - which you will conduct for assets and Facilities that meet High or Medium impact criteria.

Seriously, I do like this post, since it’s really the first time I’ve written down a high-level R1 methodology that is actually readable.  However, I need to make the same qualifications I did in the previous post:

1. This is a high-level methodology.  If you want a little lower-level view, go to the previous post.
2. But even that post makes clear there is no such thing as a complete methodology for R1 compliance.  To write out a methodology that covered every possible option, you would produce something longer than the Bible, and the effort would have to be continued by your children and grandchildren.
3. As you go through what I write below, keep in mind that at some point I’ve probably done a whole post on each sentence you read.  I don’t feel like putting all those links in (a lot of them will be found in the post linked above), but if you want clarification on something, email me at talrich@deloitte.com.

Just to make you feel bad, compare what I write below (or even better, in the post linked above) to the methodology for Critical Cyber Asset identification in CIP v1-3 (and this is the complete methodology, believe it or not):

1. Identify your Critical Assets using your RBAM;
2. Identify the Critical Cyber Assets that are essential[i] to the operation of those Critical Assets;
3. Done!

Makes you want to cry, doesn’t it?  Well, let’s get on with this dirty business. 

There are two main approaches to Cyber Asset identification.  I call these “top-down” and “bottom-up”.  In practice, I (and a few others I’ve worked this out with) think substations and generating stations that meet Criteria 2.3 and 2.6 should just do bottom-up.  Control centers and Criterion 2.1 generating stations should do top-down, which includes bottom-up as a reality check (as you’ll see below).  Bottom-up is what is “required” by CIP-002-5.1 R1 (although R1 never explicitly states the entity has to do this), but the top-down approach (which includes some of the bottom-up approach) will save a lot of time when it’s applicable (it is likely to involve unnecessary work when it's applied to substations, though, which is why I recommend the bottom-up for those).

Bottom-up

Once you have decided what are likely to be your High and Medium impact assets/Facilities (and I’m skipping a huge discussion on what “Facilities” are), you need to identify all Cyber Assets at the asset (for High control centers), or associated with the asset or Facility (for Medium assets/Facilities).  You next need to compare these to the definition of BES Cyber Asset to identify your BCAs (This requires your having some interpretation of "adverse impact" in the BCA definition. See this post for more on that).

Finally, you group the BCAs into BCS.  A BCS can consist of one or more BCAs, but you can also include Cyber Assets that aren't BCAs as well; however, you should make sure that every Cyber Asset you include in a BCS needs to be included, since all components of the BCS will be subject to the CIP v5 requirements that apply to BCS.  There is no obligation to group BCAs in a particular way, and you shouldn’t get distracted by the use of the words “reliability tasks” in the BCS definition.  Since every BCA you’ve identified performs a reliability task per the BCA definition, you don’t need to repeat that exercise when you group them into BCS. 

Top-down

In the top-down approach, you basically follow the discussion of the BROS in the CIP-002-5.1 Guidance and Technical Basis.  I won’t go through all the steps outlined in the Guidance, but in general you need to identify the BROS that are fulfilled by the asset / Facility in question and then identify the systems that fulfill one or more BROS.  This is your preliminary list of BES Cyber Systems. You don’t now need to go on and consider whether each Cyber Asset that is a component of a preliminary BCS meets the BCA definition or not; all components of the BCS will be subject to the v5 requirements, whether or not they are BCAs.  

The next step is to perform a "reality check" on the preliminary BCS list, to remove those systems that don't have a 15-minute impact on the BES - since the components of these systems wouldn't meet the definitions of BES Cyber Asset.

However, there could be other BCS that haven't been identified so far. These are composed of Cyber Assets that meet the BCA definition but don’t fulfill a BROS.  For example, the components of a CEMS system in a generating plant (which monitors for various gases in the emissions, and issues a warning or shuts the unit down in the event of an excursion) don't fulfill any BROS (environmental monitoring isn't a reliability service. The plant is just as reliable even if it's spewing dirty gases into the air). But if the CEMS system is programmed to shut the plant down within 15 minutes of an excursion, then its components probably do meet the BCA definition. So CEMS is a BCS in this case, even though it wouldn't be identified by the top-down procedures described so far.

This means that, once you have your preliminary BCS list, you need to run a modified bottom-up approach. However, you get a pretty big break when you do this: For each Cyber Asset that is a component of one of the BCS on your preliminary list, you don’t need to consider whether it is a BCA or not.  As I just said, as a BCS component, it’s already subject to all of the BCS requirements and there’s no reason to determine whether or not it as a BCA.  So, from the original list of all Cyber Assets, you subtract all those that are components of systems on the preliminary BCS list.  You then apply the BCA definition to the remaining Cyber Assets to identify BCAs (for example, the components of the CEMS discussed above should come up as BCAs at this point).  Finally, you make sure each BCA is included in at least one BCS (you might include them in BCS that are already on the preliminary list, or you can group them into new BCS).

You now add the BCS identified through this (limited) bottom-up approach to those identified through top-down.  This is your final BCS list.[ii]  Congratulations, you’re done!

Simple, isn’t it?

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

---

[i] I realize “essential to the operation of…” was never defined in the previous CIP versions.  However, people seem to have gotten over that, whereas gaps like the definition of “programmable” are causing major fits in v5.

[ii] There is an exception to this process: Criterion 2.1 generating stations may have to be creative about how they do the bottom-up check, since they sometimes have tens of thousands of potential BES Cyber Assets.  Entities owning such a plant need to figure out a way to identify Cyber Assets and then BES Cyber Assets en masse rather than one-by-one. I'm told this can definitely be done.