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

Please note that Part 2 of this series is here and Part 3 (the exciting conclusion) is here.  I certainly recommend you read all three in order, though.  If you lived in Chicago like I do, what else could you do with your time in January? 

Faithful readers of this blog will note that I seem to have taken about a three-week hiatus from posting.  Part of the reason for this is of course the holidays, but the other part is that I was engaging in an active email dialog with four or five people involved with the NERC compliance process (four are at NERC entities; one is a regional auditor) about the topic of a workable methodology for asset identification in CIP v5 – in other words, for compliance with CIP-002-5 R1 as it’s currently written.  It is only now that I feel comfortable putting something out for the world to see.

This won’t be just one post but two or three posts on how a NERC entity can identify and classify facilities and cyber assets in scope for CIP Version 5, as mandated in Requirement 1 of CIP-002-5.   If you’ve been paying any attention at all to what I’ve been writing since late April, you’ll know I believe the wording of this requirement contains a number of inconsistencies and ambiguities – so much so that I don’t believe there is a consistent interpretation that doesn’t require ignoring some parts of the wording.  And I believe this is different from CIP versions 1-3, where the process of identifying Critical Cyber Assets was straightforward: You identify Critical Assets, and then the cyber assets that are essential to their operation.  There were of course some problems with that approach, but I believe a consistent interpretation of CIP-002 in each version was possible.

(I want to point out here that in this and the subsequent parts of this discussion, I'll be using footnotes to convey information that I think is important, but which isn't directly part of the current argument.  To get the fullest explanation of all of this stuff - which is pretty involved, I'll admit - it would be a good idea to read the footnotes, although maybe not the first time through)

Because of the problems with CIP-002-5 R1, I have been saying that the best way to deal with them is to rewrite the standard.  I at first hoped FERC would order NERC to fix the problem, but they didn’t do this in Order 791 (I’m told they couldn’t, since they hadn’t themselves raised the issue in the NOPR). I was then hoping that the new Standards Drafting Team, that will address the FERC directives in Order 791, would be tasked with doing this.  However, those who read my post on the Atlanta CIPC meeting will perhaps have noted the comment at the end regarding the answer to the question I asked at the meeting,  whether the new SDT would look at changing the wording of CIP-002-5.  The answer was simply “No”. I’m a big boy, and can take that.  I also don’t hold it against NERC for taking this position, since the new SDT will have a lot on its plate as it is, and having fundamental discussions about CIP-002-5 would without doubt take a lot of time and effort.

But excusing NERC and FERC doesn’t solve the problem, either.  To restate the problem, the language of CIP-002-5 R1 has enough inconsistencies and outright contradictions that a NERC entity trying to comply with it could never find a consistent methodology for doing so.  Similarly, an auditor trying to audit what the entity did could never find the entity’s CIP-002-5 R1 compliance activities to be free of violations of the wording, no matter what methodology they had used.  I have documented these problems (and there are at least a few other problems I haven’t gotten to yet) in about 8 or 9 posts, starting with this one in April. 

If nothing is done to address these problems, I predict there will be lots of expensive fines for violating CIP-002-5 R1.  In addition, there could be lawsuits as entities contest these fines (since NERC standards are regulatory law).  And if it comes to a lawsuit, I don’t think a federal judge is going to try to sit down and take testimony about what CIP-002-5 R1 really means; they are much more likely simply to throw the requirement out, which of course means the end of CIP v5.

NERC entities need to have a consistent, workable methodology for identifying and classifying BES Cyber Systems; moreover, they need to be able to implement that methodology, secure in the knowledge that the auditors aren’t going to tear it to shreds come audit time.  Since changing the standard isn’t an option[i] anymore, what’s Plan B?  In other words, how can we develop and – more importantly – get wide acceptance on a methodology for CIP-002-5 R1 compliance, given that the requirement itself isn’t going to change?

There are two goals that Plan B needs to address.  First, the methodology developed needs to be based on the realization that it won’t be consistent with all the wording of CIP-002-5 R1 (I say “R1” because that requirement is the problem, although I’d also like to see changes in Section 4.2, which precedes the requirements); something is going to have to “give” in how the current wording is interpreted, to allow a consistent methodology to be developed.  In other words, some parts of the wording have to be ignored or at least interpreted in a very unusual way, since I believe there is no single interpretation that would be compatible with all of the wording.

Second, there will need to be some consensus developed among NERC and the regions on what the acceptable methodology is, and this needs to be published.  If this isn’t done, there is simply no way a NERC entity could ever feel comfortable that they were complying with CIP-002-5 R1 in the correct manner.[ii] 

There is a good precedent for this.  The NERC CIPC put out two excellent documents after CIP v1 came into effect, on Critical Asset identification and Critical Cyber Asset identification.  I’m suggesting a similar effort[iii] now – with the big difference that these documents are needed as soon as possible, not after the v5 compliance date of April 1, 2016 and not even say in 2015, a year before the date.  Entities really need this as they’re gearing up their v5 compliance programs, which is now.[iv]

As I said, I have been discussing this problem with four or five interested parties over the past month and a half (actually, longer than that).  They have provided invaluable help and I thank them for that.  None of them want to be identified, so I have to thank them here anonymously.  One of those parties, a CIP auditor with one of the regions, had already developed (and revised) a consistent methodology, although it wasn’t written down.[v]  After many email discussions, I initially came to the conclusion that this was the methodology I was looking for.  However,  after even more discussions, I decided I can’t recommend it.  But those discussions helped me refine my own methodology, and there are several parts of the auditor’s[vi] methodology that I have incorporated into mine (which I will identify). 

I will discuss the auditor's interpretation in Part 2 of this post, and mine in Part 3.  Before I do that, though, I want to discuss three issues that need to be addressed in any methodology for compliance with CIP-002-5 R1.  In other words, I can’t see any methodology being successful if it doesn’t address these three issues.

I. Facilities/assets

I have spilled a lot of electrons in blog posts discussing the problems with respect to the use of these two terms in CIP-002-5 R1 (see this post, this one, and this one, although there are others).  As with the other problems I’ll mention, I don’t think there’s any way to fix this problem in a way that doesn’t involve violating some of the current wording.  I originally thought the problem was just inconsistency in the use of these two terms.  However, I now realize that CIP-002-5 R1 actually needs two such terms to be consistent – but their meaning needs to be different from the current meanings.  Actually, I think the term “asset”, which isn’t defined in CIP-002-5 R1 except through a list of six types of facilities – control centers, transmission substations, etc. – is fine as it is.  But “Facility” needs to be reinterpreted.

Before I go further, the astute reader will point out that the fact that Facility is capitalized means it is in the NERC Glossary, and thus can’t be arbitrarily re-interpreted.  All I can say is, do you want a standard that works or one that doesn’t?  If we just take the Glossary definition and try to apply it literally, we will run into two serious problems, as I will show.

The NERC Glossary definition of Facility is “A set of electrical equipment that operates as a single Bulk Electric System Element (e.g., a line, a generator, a shunt compensator, transformer, etc.).” Instead of using this definition, I would like for NERC and the regions to agree that, for purposes of CIP v5 compliance, “Facility” means “a Facility containing one or more of the six types of assets listed in CIP-002-5 R1”.  So we’re not really changing the definition of Facility here, but rather putting a qualification on it.

Why do I say this should be done?  Because otherwise, there is no official way to have a particular site, like a substation, that contains multiple assets.  For example, if a substation doesn’t meet the Medium impact criteria and thus is a Low, yet it “hosts” an SPS system that meets Criterion 2.9 and thus is Medium impact, there needs to be some term that makes clear that the substation itself is still Low, even with a Medium SPS asset within its fence line.[vii]  I believe the SDT understood this problem, which is why they reverted to using “Facility” in Criteria 2.3 to 2.8.  But, since they never explicitly said this was the case (which would have allowed the concept to apply to all the Criteria), they left this as a problem that needs to be addressed.

I believe the SDT used "Facility" in Criteria 2.4-2.8 because it wanted to make sure that entities could "carve out" the purely Distribution elements of a mixed Transmission/Distribution substation, so that only the Transmission elements would have to comply with CIP.  So their use of the term (assuming my belief is correct) is exactly what I'm suggesting it should be in a consistent methodology for complying with CIP-002-5 R1.  The problem is they never stated this outright in the requirement or the Definitions document (they did state it in the Guidelines and Technical Basis).

Someone who has carefully read the Guidance and Technical Basis section of CIP-002-5 may point to the first bullet point in the discussion of Attachment 1 on page 23.  That paragraph implies that the SDT considered “asset” to mean “group of Facilities”, so in fact assets contain Facilities, not the reverse (as I am suggesting should be the usage).  This might well be true, but it doesn’t change the fact that there needs to be some term for a “container” of assets – something that can be larger than an asset or at worst be coterminous with one, but never be contained within an asset. 

Again, if it were possible to change the wording of the standard at this point, I would be fine if we chose the term ‘rabbit’ or anything else, to refer to such a “container”.  But that isn’t possible.  I’m suggesting that, while nobody is looking, we take the effectively unused term Facility and redefine it as discussed above (and immediately below).

There is another problem with the term Facility that a CIP compliance person at a Canadian entity first pointed out to me last summer: Notice that the Facility definition includes the Glossary term Element.  What is the definition of Element?  It’s “Any electrical device with terminals that may be connected to other electrical devices such as a generator, transformer, circuit breaker, bus section, or transmission line. An element may be comprised of one or more components.”  Since we want each of the six asset types in R1 to be a subset of Facilities, we need to make sure they all meet the definition.  Do you think a control center would meet this definition?  I believe a good case can be made that it couldn’t.  A control center doesn’t have terminals connected directly to “other electrical devices”.  And even if it did, for it to be a BES element, it would have to operate at 100kV and above.  I don’t think there are any control centers that do that.

Does this mean that control centers are no longer in scope for CIP v5?  Taken literally, it does.  But it certainly doesn’t mean the SDT actually intended to remove control centers.  In our re-definition of Facility, we need to add that control centers are Facilities, to make sure nobody is tempted to use this mistake to exempt their control center.

Expert Testimony
In case you don't feel comfortable with the idea of wholesale reinterpreting words to meet an urgent need for clarity, I refer you to the noted regulatory expert Lewis Carroll, who wrote the following in Through the Looking Glass:

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean- neither more nor less."

"The question is," said Alice, "whether you can make words mean so many different things."

"The question is," said Humpty Dumpty, "which is to be master, you or the words.  That's all."

II. “Top-Down” vs. “Bottom-Up” Approaches

CIP-002-5 R1 requires identification of BES Cyber Assets, and the BES Cyber Systems of which they’re composed.  BCA has an elaborate definition, while BCS is only defined as “One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.”  So BCA is the fundamental concept in CIP-002-5 R1, while BCS is just a derivative one, only arrived at after you’ve inventoried your cyber assets and identified those that meet the BCA definition.  This leads to the idea that the entity should pursue a “bottom up” approach, first identifying BCA’s, then aggregating them into BCS.

However, there is another approach that, while not being referenced anywhere in CIP-002-5 R1 itself, is discussed extensively in the Guidance and Technical Basis included with CIP-002-5: It is an approach based on BES Reliability Operating Services (BROS).  I highly recommend you read that section (starting on page 17 of CIP-002-5), and I won’t discuss the concept here.  You can also read two blog posts I wrote on this problem, here and here.

Essentially, the top-down methodology consists of:

1. Identify the BROS that apply to the asset in question – i.e. the asset where you need to identify BES Cyber Systems.[viii]
2. Identify systems that fulfill these BROS.  These systems are BCS.
3. Identify the cyber assets that make up the BCS.  These are BES Cyber Assets (note that one BCA could be a component of more than one BCS).

As you can see from the blog posts I just referenced, I initially fought this interpretation as being “wrong”, and I said it could lead to entities mis-identifying BCA and BCS because it couldn’t be guaranteed that an entity would “catch” all BCA’s that meet the definition using this approach (and remember, BCA is the fundamental definition in v5, not BCS). 

But I believe the auditing community wants to use this language, at least as a check on the bottom-up process.  I’ll agree it’s quite elegant and directly addresses what CIP is supposed to be addressing: protecting the functions that keep the BES running.[ix]  Therefore, I recommend that entities (for High and Medium assets) conduct both approaches, using the top-down approach as a check on the bottom-up one.[x]

Another reason to combine the approaches is that it's likely there will be some BCS identified using the top-down approach that won't be BCS when you use the bottom-up approach.  Specifically, you may identify some BCS that fulfill BROS, that don't actually produce their effects within 15 minutes and therefore wouldn't be BCS using bottom-up (since the BES Cyber Asset definition includes the 15-minute clause).  So you should actually use both approaches as a check on the other.

III. Segregated Cyber Assets

One big topic of discussion with my friends has been how to classify two types of cyber assets:

1. Cyber assets at a Medium or High asset that aren’t BES Cyber Assets and aren’t networked with any BCA/BCS.  Should these be treated as Low impact cyber assets or as nothing at all – completely out of scope for CIP v5[xi]?
2. Cyber assets that were excluded from being considered Medium impact BCA/BCS because of the wording of Criterion 2.1 in Attachment 1 – “For each group of generating units, the only BES Cyber Systems that meet this criterion are those shared BES Cyber Systems that could, within 15 minutes, adversely impact the reliable operation of any combination of units that in aggregate equal or exceed 1500 MW in a single Interconnection.”  (Criterion 2.2 has similar wording regarding reactive resources)  Again, should these be treated as Low impact BCS or as completely out of scope for v5?

Neither of these questions is clearly answered – directly or indirectly - in CIP-002-5 R1.  I personally think these BCS should be treated as Low impact, not as completely out of scope.  The main reason I believe this is because CIP-005-5 R1 states that all cyber assets (not just BES Cyber Systems) should be enclosed in an ESP.  I think this points to all cyber assets being at least Lows.

However, regardless of how NERC wants to rule on this, it is another area that NERC should address up front, rather than force entities to guess, then end up in arguments with their auditors if they guess differently than the auditors do.

Having discussed these three preliminary questions, I’ll move on to the two CIP-002-5 R1 methodologies (mine and the auditor’s) in the next post.

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

---

[i] It was suggested to me that I write a Standards Authorization Request to rewrite CIP-002-5.  If I thought there was any way at all such a SAR would be seriously entertained, I would take up this suggestion.  But I don’t.

[ii] You may be wondering why I’m not bringing up the idea of the “original intent” of the Standards Drafting Team.  I’ve certainly seen that come up in discussions of interpretation of CIP v1-3.  Since this SDT was in session for four years and had a lot of turnover, all the while developing four complete versions of CIP (v2 through v5) and many drafts along the way (there were four formal drafts of v5 and I’m sure myriad informal ones), I think it would be a huge job to comb through the meeting minutes – which are mostly quite sketchy anyway – to try to determine what really was their intention in including particular language in v5.  Nobody can answer this question, and it really is meaningless given the problem here.  The problem is that the language of CIP-002-5 is inconsistent and contradictory, not that it’s vague and you need more interpretation.  The SDT approved it, so you have to assume this is what they intended to say.

[iii] Beside the document I’m advocating for now, there is a different document that is also needed – a guide to the many nuances of applying the Bright Line Criteria.  See this post, which was originally written about CIP v4 but is equally applicable to v5.  I learned from Joe Garmon of Seminole Electric Cooperative that the FRCC member services CIP subcommittee has a draft document for interpreting the BLC impact ratings.  I've seen the draft and it appears to be an excellent piece of work.  When finalized, it will be available for other parties.  For more information contact jgarmon@seminole-electric.com.

[iv] NERC is promising their v5 transition guidance document – based on the experience of the six entities in the “pilot group” – in June.  If the discussion I’m advocating were included in this document, that would be fine with me.  However, I’m sure that isn’t currently the intent of the document, which is to report on “lessons learned” by the pilot group.  Someone at NERC needs to decide this must happen, or it won’t.

[v] I have reason to believe that other regions may also hold to this auditor’s interpretation.

[vi] In case you’re thinking, “Why doesn’t he just accept the auditor’s interpretation?  If it would be consistent – which it is – isn’t that enough?  In general, it’s better to take an auditor’s interpretation than some scruffy blogger’s.”  The first reason I’m not doing this is that there are implications of the auditor’s interpretation which, in my opinion, will lead to serious and completely unnecessary paperwork burdens for owners of Low impact assets.  The second reason, which I don’t believe is as likely, is that the auditor’s interpretation might end up requiring an inventory of Low impact cyber assets/systems, despite the three places in CIP-002-5 and CIP-003-5 where this is supposedly ruled out.  As I said, there’s no consistent interpretation that can be developed that doesn’t ignore – or creatively re-interpret – some parts of the wording of CIP-002-5 R1.

[vii] Of course, there would need to be network separation between the SPS systems and the others in the substation.  Otherwise, the substation’s systems would end up being Medium impact Protected Cyber Assets.

[viii] I don’t think the auditor’s approach I’ll be discussing says you should identify BROS for a particular asset.  Rather, I think the auditor would say that the entity needs to start from a list of all BROS that it fulfills (across all assets), then identify the BCS (and the assets they’re associated with) that fulfill these BROS.  The reasons for this will become clear when I discuss the two approaches.

[ix] The BROS were actually in the definition of BCA in the first draft of CIP-002-5.  I thought that was a huge mistake and ranted about this, with three other parties, in this post in December 2011.  Whether or not it was due to the post, the SDT changed the definition of BCA at their next meeting, which I described in this January 2012 post.  By the way, I recently realized that, before posting, my language in the December post was altered and two people that contributed greatly to that post were left unacknowledged.  They were both NERC compliance professionals at a large Western utility (neither is at that same company now).  They know who they are, and thanks a lot!

[x] One of the Interested Parties says he believes the BROS approach could be used to identify BES Cyber Assets directly, rather than first identifying BCS then breaking these down.

[xi] Of course, any cyber asset networked with a BES Cyber System will be a Protected Cyber Asset, and be treated at the same impact level as full BCS.