How do I Identify Assets for CIP Version 5? (Part 2)

January 13: I've just posted the third and final part of this series here.

This post is the second of a three-part series.  You should read the first one before you start this part (and if you read the first part last week or you read it from the FeedBurner email, you might want to reread the post, since I made a few improvements the day after I posted it).  I anticipate having the third post – the exciting conclusion wherein I lay out my own preferred CIP-002-5 R1 methodology – by early next week (the week of Jan. 17).

I will now – without using a net and at great personal risk – present two differing methodologies for compliance with CIP-002-5 R1.  One is that of a CIP auditor with one of the regions, the other is mine.  To repeat what I said in the first part, each of these methodologies is consistent.  On the other hand, both methodologies are contradicted by various wording in the requirement and in Attachment 1.  This isn’t a fatal problem, because I don’t think there’s any consistent methodology that could be developed that is compatible with every word of the requirement (and Attachment 1).  We have to look at other criteria in deciding what methodology to use, such as comprehensibility and whether it limits unnecessary paperwork burdens.

I don’t want to make it sound like these are the only methodologies that could be developed; others certainly could be (in fact, if anyone else has what they consider a consistent methodology, I’d love to hear about it.  Maybe I’ll even run a contest).  But at the end of the day, someone at NERC or the regions (or both) is going to have to say, “Here is the methodology we would like you to comply with, Ms/Mr NERC entity.  If you follow this methodology correctly, you can be assured we will audit based on it”.[i]  Until that happens, entities embarking on the CIP v5 compliance process will have no choice but to simply choose a methodology, take a deep breath and hope that their methodology ends up being the preferred one of whoever their auditor is years from now.  Doesn’t that sound like a lot of fun?

The Auditor’s Methodology

Note that, while I wrote this section based on my email conversations with the auditor, I ran this by the auditor to confirm I wasn’t misrepresenting him, and to incorporate changes he suggested, before posting.  I will list what I see as the advantages and disadvantages of this methodology at the end of this post.  He probably still doesn’t agree with every word I’m saying here about his position, but I think I have this basically correct.

The auditor starts, quite sensibly, with the statement of purpose in Section A Part 1 of CIP-002-5: “To identify and categorize BES Cyber Systems and their associated BES Cyber Assets for the application of cyber security requirements commensurate with the adverse impact that loss, compromise, or misuse of those BES Cyber Systems could have on the reliable operation of the BES…”  This makes it clear (as does some of the wording of CIP-002-5 R1, and especially Attachment 1) that the things we need to identify and categorize as High, Medium and Low impact are BES Cyber Systems, not assets (control centers, substations, etc).

A.    We first have to identify BES Cyber Systems.  How do we do this?  CIP-002-5 R1 isn’t helpful in this regard.  There are three requirement parts that form the core of this requirement.  Parts 1.1 and 1.2 just tell us to classify High and Medium BCS[ii]; 1.3 tells us to identify assets containing at least one Low BCS.  In other words, these requirement parts tell us to classify the BCS, but don’t tell us how to identify them in the first place.

B.    So we turn to the Guidance and Technical Basis section of CIP-002-5, which discusses (starting on page 17) the BES Reliability Operating Services and how to apply them based on the entity’s NERC registrations.  You can read the details of how this works, but the result will be a list of BROS that the entity is expected to fulfill based on its functional role(s), such as “Balancing Load and Generation” and “Controlling Voltage”.  BCS are simply the systems that facilitate fulfilling the BROS.  Now go out there and find them.  Simple, no?

Notice here that the auditor isn’t saying anything about the assets those systems are associated with, and whether they’re High, Medium or Low impact.  This may lead you to say, “But what about Low impact BCS?  CIP v5 says in three places ‘a discrete list of low impact BES Cyber Systems is not required.’  How can we possibly identify Low impact BCS without first doing an inventory?”

To this, the auditor may say, “An inventory isn’t required in order to identify any BCS – Low, Medium or High impact.  You just have to find each BROS that an entity fulfills and identify the assets (generating plants, substations, etc) that perform the BROS or support its performance.  Finally, you identify the BES Cyber Systems and then the BES Cyber Assets associated with those assets that perform the BROS. For example, take the Controlling Frequency BROS, which can be fulfilled by a Generation Owner or Generation Operator.  A generating station may help control frequency, and the DCS in the generating station might be one of the systems that carry out this task.   An entity could designate the DCS as a BES Cyber System, without having to first conduct an inventory.  Instead of having to perform an inventory up front, you develop it through this top-down identification process.”

C.    In Part 1 of this series (and in previous posts), I discussed the fact that there are “top down” and “bottom up” approaches to identifying BCS.  The auditor is clearly suggesting the former here; does that mean he doesn’t think an entity should use the bottom up approach? 

The answer to that question is “not at all”.  The auditor is OK with either approach, as long as he is satisfied – come audit time – that you have identified all the BCS.  And if you go back to my discussion of the two approaches in the Part 1 post, you’ll see I’m suggesting that the best idea – for High and Medium assets[iii] – is to use both approaches, one as a check on the other.   No matter what we do, we end up with a list of BES Cyber Systems which covers our entire network (i.e. all BCS at all BES assets owned by the entity).

(I need to qualify this last paragraph somewhat.  The Auditor insists that he won't make the entity produce a full BCS list for Low assets, just Medium and High.  For Lows, he is comfortable with the entity simply saying whether there are one or more BCS at a particular Low asset.  If the entity asserts there aren't any BCS at a Low asset, he's going to want to hear a good argument why there aren't any - obviously, if there aren't any cyber assets doing control functions, that would be a good reason.  I will have more to say about this below and in the next post, where I outline my methodology)

D.    We now need to classify our BCS as High, Medium and Low impact.  To do this, we go to the three parts of CIP-002-5 R1, and do what they tell us to do:

1)     Part 1.1 reads “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset”.   Before we go to Attachment 1, we notice one thing, the phrase “at each asset”.  We know what “asset” refers to, since we have just seen the list of six types of assets – control centers, etc. – in the first part of R1.  But we also note the seemingly insignificant word “at”.  This makes it clear that the High BCS we will be identifying must be physically located at one of the six asset types. In fact, this applies for Medium and Low BCS, as you’ll see below.  This leads to a general rule: In identifying BCS, we don’t have to consider any system that isn’t physically located at one of the six asset types listed in R1. 

2)    We now go to Attachment 1, Section 1, where the operational phrase reads, “Each BES Cyber System used by and located at any of the following:” followed by the four criteria that cause a control center to be considered High impact.  We first take note of “used by”.  This means that a BCS has to be actually used by the control center, not merely located at it, to be considered High impact.

We next take note of “and located at”.  This is even more significant than “at” was in 1.1.  If you want to peek down to Section 2 of Attachment 1, the equivalent wording is “associated with”, not “located at”.  Is this just a case of inconsistent wording?  No, it’s not.  The SDT deliberately restricted High BCS to be those located within the four walls of the control center, because they didn’t want to take the chance that cyber assets controlled by the control center – located in substations, generating plants, etc. – would have to be considered High BCS.  This might then make other BCS at those substations and plants High impact themselves, requiring a much higher level of compliance cost and effort for those assets.

3)     Having noticed all of this, we now work down through the four criteria in Section 1, and decide whether each of the BCS on our list corresponds to any of those criteria.  You may well ask, “Do we have to do this for every BCS on our list?”  The auditor smiles (auditors do smile occasionally, believe it or not) and assures that you don’t have to; this is where the word “at” comes in very handy.  For identifying High impact BCS, we don’t have to consider every BCS on the list, but only every BCS that is located at a control center, since no other BCS are even eligible for consideration.[iv]

You may notice something strange here: We’re not looking at the asset (control center, in this case) and saying it’s a High, then classifying the BCS at the asset as High impact.  We’re starting from our pre-existing list of all the BCS in our entire network (although in this case restricted to those BCS physically located at control centers), and determining whether each of those is “used by and located at” one of the four types of control centers described in Criteria 1.1 – 1.4.  Why are we doing this?

The auditor will answer, “Because that is how the wording of Attachment 1 reads.  We’re classifying BCS, not assets.”  I will point out here that it doesn’t make any operational difference whether we’re classifying BCS at a control center that meets one of the four criteria as High, or whether we first classify as High any control centers that meet one of the criteria, then classify the BCS located at them as well.  However, I will also point out that this will make a difference when we get to Section 2 of Attachment 1, since the words “associated with” change the situation a lot.

4)     Let’s tackle Mediums now.  We return to R1 and go to part 1.2, which reads “Identify each of the medium impact BES Cyber Systems according to Attachment 1, Section 2, if any, at each asset”.  Since this doesn’t differ significantly from R1.1, we can move right to Attachment 1.

5)    The operative wording of Attachment 1 Section 2 is “Each BES Cyber System, not included in Section 1 above, associated with any of the following:”.  I’ve already pointed out the big difference between this and Section 1: Unlike with High impact BCS, a BCS is Medium impact if it is “associated with” an asset that meets one or more of the criteria in Section 2 of Attachment 1.

Keeping this difference in mind, we once again take our BCS list and compare each BCS[v] to each of the criteria in Section 2 of Attachment 1.  Those that meet one of the criteria are Medium impact; those that don’t, stay in the list of unclassified BCS.

An example of a BES Cyber System that is associated with a Medium impact asset, but isn’t directly located at it, is a protective relay that may really operate equipment in a substation, but is instead located in an adjacent control center for space or other convenience reasons.  Even if the control center were a High one, the relay would still be a Medium, since Section 1 of Attachment 1 requires that High BCS be “used by and located at” the control center, not just “located at”. 

Sometimes, of course, a BCS associated with a Medium impact asset will be located at a Low asset.  An example is the far-end protective relay that protects the Facilities, systems, and/or equipment located at a Medium asset.  In this case, the other cyber assets at the Low asset won’t be raised to Medium status, unless they’re directly networked with the Medium BCS.

6)    We now turn to Low BCS.  We go to R1.3, which reads “Identify each asset that contains a low impact BES Cyber System according to Attachment 1, Section 3, if any (a discrete list of low impact BES Cyber Systems is not required).”  This is different from R1.1 and R1.2, in that we’re not classifying BCS, but producing a list of assets.  The BCS have evidently already been classified – otherwise, how could you identify assets that contain Low BCS? To see how this trick works, keep reading.

7)    We next go to Section 3 of Attachment 1, where the important wording reads “BES Cyber Systems not included in Sections 1 or 2 above that are associated with any of the following assets and that meet the applicability qualifications in Section 4 - Applicability, part 4.2 – Facilities, of this standard:”.  This tells us which of the BCS on our list are Lows – it’s all of them except the BCS already identified as High or Medium in the two preceding sections of Attachment 1.  And they also have to be “associated with” one of the six asset types listed below this phrase (which exactly duplicates the list in R1); otherwise, we don’t need to consider them as Low impact.

E.     Now we have our list of Low BCS.  We then get a list of the assets that contain Low impact BCS[vi], and this is the list that 1.3 told us to get.  Guess what?  We’re finished complying with CIP-002-5 R1!

Advantages and Disadvantages of the Auditor’s Methodology

Here are what I see as the advantages of the auditor’s methodology:

1.     It fits exactly with the wording of Attachment 1, which clearly presumes the entity has identified all of its BES Cyber Systems before embarking on the classification process in CIP-002-5 R1.

2.     My guess is it is more in line with the intention of the Standards Drafting Team than my methodology, although – as I said in a footnote in Part 1 – it would be impossible to establish that definitively (in any case “intention” has very little meaning when talking about a team that worked over four years, developing three complete CIP versions and many drafts, with a lot of turnover during that time).

3.     It is consistent and could be followed by entities once they had training in concepts like BES Reliability Operating Services.

4.     It could be unambiguously audited – meaning the entity and the auditor might disagree on facts, but they are unlikely to disagree on what needs to be done for compliance.

5.     It probably has a good following among other auditors, although I haven’t taken a poll.

Here are the disadvantages that I see:

1.     Nowhere in CIP-002-5 R1 or Attachment 1 is there one word about using BES Reliability Operating Services to identify BES Cyber Systems (i.e. the “top-down” approach).  On the other hand, the “bottom-up” approach is at least implicitly required, through the definitions of BES Cyber Asset and BES Cyber System.  This is why, for completeness, I recommend combining the two approaches. And, while I admit that the auditor's approach is in line with the wording of Attachment 1, I don't think it lines up with R1 itself, which is asset-focused, not BCS-focused.  R1 starts out with a list of six asset types that are in scope for v5 and states they need to be considered for parts 1.1 through 1.3.  And while 1.1 and 1.2 talk about classifying BCS, 1.3 is about assets that contain a Low BCS. I don't think this language would be in here, if the SDT had intended that only BCS had to be classified, not assets themselves.

2.     As you will see in the next post, while I do like the top-down approach, I think it should be applied on the asset level, only at assets that have already been identified as Medium or High impact. That is, I don’t have much use for the idea that the entity should look at all the BROS it fulfills across its entire asset footprint, and then search diligently for systems that fulfill those BROS.  In my opinion, this will lead to a lot of effort being spent identifying BES Cyber Systems at Low assets, where - as shown below – there is no need for such identification.[vii]  Rather, I think the entity should a) identify High and Medium impact assets; b) determine the BROS fulfilled by those High and Medium assets; and c) identify the systems that fulfill those BROS, which are the BCS associated with those assets.  No other BROS or BCS need to be identified.

3.     I have a very strong objection to the idea that BES Cyber Systems should be identified before the assets are classified High, Medium or Low (actually, in the Auditor’s methodology, the assets are never explicitly classified at all).  Obviously, BCS need to be identified for High and Medium impact assets.  But they don’t at all for Lows, because Low impact BCS play no role whatsoever in the v5 standards. 

As proof of this, please read CIP-003-5 R2, the only requirement that applies to Low assets, and tell me where it says anything about BCS.  It lists four policies that need to be implemented, but says nothing about the cyber assets (BCS or not) that need to be covered by them.  And the reason for this is clear: The SDT wanted to make sure there wouldn’t be anything in the requirement that applied to individual cyber assets (or BCS), which would then possibly be a back-door requirement for an inventory.[viii]

4.     And speaking of inventory, I believe that requiring identification of any BCS associated with Low impact assets can lead ultimately to a request by an auditor for the results of an inventory of all the cyber assets associated with the asset.  I realize this is forbidden in three places in v5, but ultimately how can an entity ever conclusively prove it’s identified all of the BCS associated with Low impact assets?  And if entities believe there’s a non-zero chance they’ll be required to have an inventory, they will probably make the effort to do that inventory up front, no matter how much effort and expense it may require.[ix] 

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

---

[i] When I brought this problem up at the NERC CIPC meeting in Atlanta in December, Scott Mix of NERC said something to the effect that one of the goals of the CIP process is not to have requirements that are so rigidly written that there is only one way to comply with them.  Offhand, I’d say that if this is really the goal, CIP-002-5 R1 deserves the gold medal.  However, this statement misses a couple important points (and since Scott is a very intelligent person, I have to believe he said this without thinking first):

a) If the goal were really to allow diverse methodologies for compliance, that would be made clear in the requirement (for an example of a well-written requirement that intends to allow multiple methodologies for compliance, see CIP-007-5v R3 Malicious Code Prevention).  In the case of CIP-002-5 R1, the problem is inconsistent use of the English language.    Instead of there being multiple possible methodologies for complying with the wording of the requirement, there is no single methodology that is compliant with all of the wording.  In the two methodologies I’m presenting, I will be sure to point out where each one violates the wording of the requirement.

b) Since almost all of the other CIP requirements deal with application of controls, it makes sense that they might allow for multiple methodologies for doing this.  CIP-002-5 R1 deals with identification of BES Cyber Systems, the fundamental unit of compliance in CIP Version 5.  If NERC and the regions are really OK with diversity of methodologies for this requirement, they also have to be OK with the fact that different entities, using different methodologies, will come up with different numbers of BES Cyber Systems for similar asset types.  Maybe they are OK with this, but I tend to doubt it.

[ii] Don’t be fooled by the word “identify” in 1.1 and 1.2.  This really means “classify”.  You find this out when you go from either R1.1, 1.2 or 1.3 to Attachment 1, and you see that Attachment 1 is written on the assumption the entity has already identified its BCS. The only thing left to do is to classify them, and that is in theory all that CIP-002-5 R1 is doing.  This echoes a criticism of CIP-002-5 R1 that I made in the first post where I started digging into these problems: R1 should really be broken up into about three different requirements, as was the case in the previous CIP versions (for instance, R1 could be classification of assets; R2 could be identification of BCS; R3 could be classification of BCS).  Having a bunch of requirements or requirement parts not explicitly stated, but only discoverable through parsing through R1 and diagramming sentences, makes for a very difficult time complying with R1, and an even more difficult time auditing it.

[iii] The auditor pointed out to me – for probably the tenth time in our email conversations – that he doesn’t believe there are High, Medium or Low impact assets, but only H/M/L BES Cyber Systems.  This is of course because of the approach he takes, where he first identifies BCS at all BES assets (H/M/L) owned by an entity.  As you’ll see in the next post, I focus on the assets from the start, so I have no problem with talking about H/M/L assets.  However, to humor the guy, I’ll say here that whenever in this post I refer to a H/M/L asset, I’m really referring to an asset whose associated BCS are H, M or L.

[iv] In fact, only BCS located at a control center meeting one of the four criteria in Section 1 should be considered, since they are the only ones that could be High impact.

[v] Following the strict wording of Attachment 1 Section 2, you don’t have to do this exercise for BCS that have already been identified as High impact in the previous step.  However, the auditor does point out that, since one BCS can be associated with more than one asset or fulfill more than one BROS, it is a good idea to consider all BCS here as well – keeping in mind that if the BCS ends up with more than one classification (say it ends up both Medium and Low impact), it will need to be protected at the higher level under CIP Version 5.

[vi] Note that the assets referred to in R1.3 – the ones that might contain Low impact BCS – aren’t the same as the assets in Attachment 1 Section 3, which make the BCS Low in the first place.  It is of course entirely possible that a Low asset won’t have any BCS located at it; as long as a BCS is associated with it, it’s a Low BCS.  But this leads to an interesting circularity: By R1.3, an asset is Low impact because it contains at least one Low BCS.  Yet, since the wording in Attachment 1 Section 3 says “associated with” not “at”, it is leaving open the possibility that there would be no BCS at a Low asset.  But how could that asset be Low, since it doesn’t contain a Low BCS?  This is just one of the many interesting peculiarities of CIP-002-5 R1.

The auditor also points out to me that there could be Low impact BCS located at a High or Medium impact asset.  According to R1.3, you need to include these assets in your list of Low assets, as well as those assets where the only BCS is a Low.  However, this leads to another question: for such a mixed Medium/High and Low asset, what do you do when you get to CIP-003-5 R2?  Since that requirement applies to “assets identified in CIP-002-5, Requirement R1, Part R1.3” – in other words any asset that contains a Low, regardless of whether it might also be a High or Medium impact – this would seem to mean that this asset (and its associated BCS) will have to comply with all of the requirements that apply to Mediums, plus the one requirement that applies to Lows, CIP-003-5 R2 (plus of course the Low requirements that will be developed by the new SDT in response to FERC’s directive in Order 791).

[vii] The auditor insists that his approach wouldn’t require detailed identification of BCS at Low assets, but rather that the entity could simply assert that a certain collection of cyber assets contained at least one BCS – so that the asset could be identified as a Low through R1.3 (which of course identifies Low impact assets as those with at least one Low BCS).  Even this strikes me as a very confusing approach, and of course completely unnecessary.  It’s like the entity were told to paint an X on every Low impact facility, then told that the definition of Low facility was one with an X on it.  If you already know what facilities are Low, why even bother with the X – in other words, why bother with designating Low BCS (based on the fact that assets that aren’t Medium or High are Low) simply so you can use them to identify Low assets (which you have already identified)?  Requiring the entity to identify all BCS, then defining a Low asset in R1.3 as one containing a Low BCS (with Low BCS defined as all BCS that are not High or Medium), is not only confusing but a big, completely meaningless paperwork exercise for a large number of entities and assets that are perhaps complying with CIP for the first time and need to focus on security, not paperwork that is unrelated to security or compliance.

Of course, I don’t feel very strongly about this.

[viii] I realize that FERC ordered NERC to draft more specific requirements for Lows.  However, as I discussed in this post, I think it’s highly unlikely the new requirements will apply to anything below the facility (asset) level.

[ix] I’m not of course saying that an inventory of cyber assets is a bad thing; it’s a good thing.  However, FERC seems to have been convinced – by the comments on this subject – that it is too much of a burden to impose on the industry at this time. So the matter is settled, in my opinion.