All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.
7/26/2014: I see that this post is suddenly getting a lot of hits, more than a year later. I'm of course glad to see that, but I want to warn you that my thinking has evolved way beyond this, so you shouldn't take this as being indicative of how I would rewrite CIP-002-5 R1 now if given the chance. My more recent posts like this one are a much better guide. However, I do want to "rewrite" the requirement again, and hope to do that soon - even though it is of course way too late to hope that the requirement can be rewritten. As I've said at various times, someone like NERC is going to have to issue a comprehensive "interpretation" of CIP-002-5 R1, and I might be able to aid that process by detailing how I think the standard should have been written in the first place - which is fairly different from what I thought when I wrote this post.
6/15: I just posted the follow-on to this post, including my final version of Fantasy CIP-002-5.
This post started off as the second of two posts discussing comments I plan to make to FERC[i] in response to their NOPR on CIP Version 5, during the comment period that ends on June 20. The first post is here. As with that post, this one is confined to CIP-002-5, because a) I see a lot of problems with the wording of that standard, and b) CIP-002-5 is the foundation for all of the remaining CIP V5 standards – if the foundation is rotten, the house falls down. I contend the foundation is rotten.
However, as I started to write this new post, even I – perennial skeptic and generally gloomy fellow – was taken aback by how rotten that foundation really is. I found I couldn’t discuss one problem with CIP-002-5 without uncovering another problem to which it was linked; and that problem was usually linked to another. Just listing a bunch of problems, as I did in the first post and I had planned to do in this one, seems to miss the point. I want to discuss what needs to be done to address those problems. I believe CIP-002-5 needs to be substantially rewritten. That is what I propose to do in this post.
When I say ‘rewritten’, I do want to point out that I don’t want to change the intended meaning of CIP-002-5, only to clear away the sizable buildup of mud and debris that seems to have grown on top of it as the standard was revised and re-revised by many players and in response to two decisive rejections by the NERC ballot body. The problem is that it is awfully hard to tell what CIP-002-5 is trying to do with regards to asset identification. The Guidance section doesn’t provide any true step-by-step guide through the whole asset identification process.
So how can we find out the intended meaning of CIP-002-5? The best I can think of is to actually read through the standard and map out the entire asset identification process, without paying attention to anything else – the Guidance sections, the wording of previous drafts of CIP-002-5, comments made during the three comment periods, Supreme Court rulings, the four Gospels, etc. The standard has to be allowed to speak for itself, since entities will be audited on what it means, nothing more than that. This is important partly because many entities will not approach CIP-002-5 with a lot of prior knowledge, but more importantly because only the actual steps required by the standard can be audited against.
So how can we find out the intended meaning of CIP-002-5? The best I can think of is to actually read through the standard and map out the entire asset identification process, without paying attention to anything else – the Guidance sections, the wording of previous drafts of CIP-002-5, comments made during the three comment periods, Supreme Court rulings, the four Gospels, etc. The standard has to be allowed to speak for itself, since entities will be audited on what it means, nothing more than that. This is important partly because many entities will not approach CIP-002-5 with a lot of prior knowledge, but more importantly because only the actual steps required by the standard can be audited against.
For example, I just mentioned that the CIP-002-5 Guidance (which starts on page 17) spends a lot of time discussing “BES Reliability Operating Services”; these are services that can be performed by cyber assets to support the reliable operation of the BES. The implication of this discussion is that the entity will start to identify their BES Cyber Assets by first determining what BES Reliability Operating Services each one performs; if a cyber asset performs one or more of these, it is a BES Cyber Asset. There is only one problem with this: the actual wording of the standard itself never once refers to BES Reliability Operating Services.[ii] A Knowledgeable Person has explained to me where exactly the BROS does fit in with the asset identification process, and I agree with what they said; I will note that at the appropriate point below.
Fortunately, I have already analyzed CIP-002-5 to determine what the standard as written does require the entity to do in order to identify assets in scope for CIP Version 5. In my recent post “Asset Identification in CIP Version 5” I tried to go through CIP-002-5 from the point of view of a NERC compliance person that was reading it for the first time – with no prior knowledge of how it was developed, etc. – in order to map out the actual steps such a person would need to take in order to identify their BES Cyber Systems. When I wrote that post, I was appalled at the number of steps required – I documented fourteen – and how the need to take each step was often not stated directly but only implied through the syntax of the standard, definitions of key terms, etc. But I have to use what was written in the actual standard, since that is the only thing we can rely on to tell us what the standard wants us to do.
However, even though I identified fourteen steps that an entity would have to take in order to comply with CIP-002-5, this doesn’t mean the asset identification process really has to take that many. I believe that a properly written standard would require the following steps (and these are all included – directly or by implication - in the list of fourteen from the previous post):
However, even though I identified fourteen steps that an entity would have to take in order to comply with CIP-002-5, this doesn’t mean the asset identification process really has to take that many. I believe that a properly written standard would require the following steps (and these are all included – directly or by implication - in the list of fourteen from the previous post):
- Develop a list of all of the entity’s Facilities that are in scope for CIP Version 5;
- Using Attachment 1, identify High impact Facilities from that list;
- Using Attachment 1, identify Medium impact Facilities;
- Identify Low impact Facilities as those on the list that do not meet either High or Medium impact criteria;
- Identify BES Cyber Assets associated with each Facility, using the definition found in the Version 5 Definitions document. The BES Cyber Asset will take the Facility’s impact rating;
- Aggregate BES Cyber Assets into BES Cyber Systems for Version 5 compliance purposes.
The revised version of CIP-002-5 that I describe in this post will include these six steps, nothing more or less. However, even though I do intend to provide a rewritten CIP-002-5 in this post, it won’t address all of the problems I see in that standard (and that is why I have the asterisk in the title). As I discussed in the first post, there are two primary things that need to be identified as in scope in CIP-002-5 (and for that matter, the previous CIP versions), the “big iron” (generating stations, control centers, substations, etc), and the cyber assets associated with them (called BES Cyber Assets and BES Cyber Systems in V5), aka “little iron”. I see serious problems with how CIP-002-5 describes the identification process for both big and little iron.
The first post addressed the big iron problems, primarily the confusion over the terms “asset” and “Facility”. This new post is intended to address the little iron identification process – i.e. how BES Cyber Systems are identified once the assets/Facilities in scope for V5 are identified. I did honestly start out to simply summarize the problems I saw in the little iron area, just as I had done for big iron in the previous post. However, I realized that just listing a bunch of problems would only leave the reader very confused about what had to be done - the problems are so intertwined.
The first post addressed the big iron problems, primarily the confusion over the terms “asset” and “Facility”. This new post is intended to address the little iron identification process – i.e. how BES Cyber Systems are identified once the assets/Facilities in scope for V5 are identified. I did honestly start out to simply summarize the problems I saw in the little iron area, just as I had done for big iron in the previous post. However, I realized that just listing a bunch of problems would only leave the reader very confused about what had to be done - the problems are so intertwined.
This is why I decided to rewrite CIP-002-5, creating my Tom Alrich Fantasy version, which I will refer to as CIP-002-5-taf. I make this version available royalty-free to anyone who wishes to reproduce (or modify) it in any way. If FERC decides that the next compliance version of CIP (which I believe will be Version 6, not 5, but that’s the last I’ll mention that in this post) should include CIP-002-5-taf rather than the CIP-002-5 submitted by NERC in January, that is fine with me (of course, this is a joke. They’d never consider that. But I hope the standard I lay out in this post does help FERC and NERC as they work to come up with a CIP-002 that is more to FERC’s liking than CIP-002-5 is).
In this, post, I will lay out a version of CIP-002-5 that addresses the “little iron” problems I see in the current version. What it won’t address is the “big iron” problems, which I listed in the first post (but I didn’t suggest specific changes to address those problems). Those problems are also quite severe, and it’s not just a question of whether “Facility” or “asset” is the right term to use. It will take some work to get to the bottom of those issues. I will kind of leave a “placeholder” for that discussion by using “Asset/Facility” instead of one term or the other in my CIP-002-5-taf. I hope to do a new post soon that will lay out my complete CIP-002-5-taf (i.e. without an asterisk). It will address both the big and little iron problems.
Let’s turn to the “little iron” problems in CIP-002-5. The purpose of CIP-002-5 is to enable you to identify your BES Cyber Systems that will be in scope for CIP Version 5, just as the purpose of CIP-002 in Versions 1-4 was to enable you to identify Critical Cyber Assets in scope for those versions. How do you do that? I contend it is literally impossible to do this, given the way CIP-002-5 is currently written, without crossing your fingers and taking a few huge leaps of faith (and hoping your auditors will join you in those leaps). Here is why.
Conciseness is not Godliness
As I have already mentioned, in my post “Asset Identification in CIP Version 5” I pretended I was from a NERC entity and was reading CIP-002-5 for the first time, in order to figure out what was going to be in scope for Version 5. I went through what I saw as the logical steps required to identify BES Cyber Systems using the current wording in CIP-002-5; I came up with 14 steps.
Having this many logical steps isn’t in itself the problem. The problem is that the standard doesn’t explicitly state that these steps are required. All of these steps are taken in the process of complying with just one requirement, CIP-002-5 R1. And most of these steps are not explicitly spelled out within that requirement – they are “required” through either the syntax of a sentence or the meaning of a term used in the sentence. So the fact that CIP-002-5 is very concisely written isn’t an asset but a liability. Poor Mr/Ms NERC Compliance Person needs to pull out their fourth-grade sentence diagramming textbook (you still have that around, don’t you?) and start parsing through the sentences in CIP-002-5 as well as in the Version 5 Definitions document (and the NERC Glossary).
Of course, this isn’t to say that Mr/Ms NERC Compliance Person (hereafter, “NCP”) can’t do those things. But how on earth can CIP-002-5 be a precise, auditable standard if you have to go through such machinations in order to comply with it? And how will NCP’s work ever be audited by the poor CIP auditor? Will they require the entity to document their sentence diagrams along with their lists of BES Cyber Systems? Compliance will be hugely more difficult if not impossible. Audits will be hugely more difficult if not impossible. If fines are levied and contested, the entity will need to hire a set of English teachers to explain the sentence diagrams. And if the entity ends up contesting their fine in court (which they can ultimately do), I think the judge will take one look at the wording of CIP-002-5 and simply dismiss the fine as being levied on a standard that is impossible to follow.[iii]
My Replacements for R1
What can be done to fix this problem? Here’s an idea: Since the steps for identifying Critical Cyber Assets were fairly clearly spelled out in CIP-002 in Versions 1-3, why not use that structure as a rough model for identifying BES Cyber Systems in CIP-002-5? Let’s go through the six logically-required compliance steps I listed above and figure out how to map them into requirements and sub-requirements that roughly line up with the requirements in CIP-002 Versions 1-3.
In CIP-002 Versions 1-3, the entity starts out with a list of its assets (although this list is implied, not actually required by the standard). R1 requires the entity to develop a Risk-Based Assessment Methodology (the beloved RBAM) that “considers” the asset types in R1.2; the RBAM will later be applied to the pre-existing asset list in R2. Since this is a fairly straightforward step, how can we “replicate” it as the first step in my CIP-002-5-taf?
When we’re complying with CIP-002-5, we come into the first requirement with a list of assets (really Facilities) developed in Section 4.2 (which precedes the actual requirements). This is different from the previous CIP versions, where the entire compliance process begins with the first requirement. In Section 4.2 we find that, for all NERC functional entities in scope for CIP-002-5 (the functional entities are determined in Section 4.1) except for Distribution Providers, the "big iron" that is in scope for V5 are all of their “BES Facilities” (“Facility” is defined in the NERC Glossary); DP’s only have to comply for four very specific types of facilities.
Given this previous step, what will be the Version 5 equivalent of CIP-002 R1 in Versions 1-3? Actually, this is the first task that the current wording of CIP-002-5 R1 requires: The entity needs to “implement a process” to “consider” each of six asset types[iv] as High, Medium or Low impact. In other words, the entity needs to document a process (at this point, they’re not actually applying that process, just as they’re not actually applying the RBAM in CIP-002 R1 in Versions 1-3). The details of the process will be clear as you read the further requirements in my CIP-002-5-taf. So here is Requirement R1 of CIP-002-5-taf.
Fantasy R1. Each responsible Entity shall:
R1.1 Implement a process that considers each of the following Assets/Facilities for purposes of Requirement R2:
(here, the same list of six asset types will appear as is found in the ‘real’ CIP-002-5 R1)
R1.2 Develop a list of its assets/Facilities including each asset/Facility type listed in R1.1.
Why is R1.2 in there? I just got through saying that Versions 1-3 don’t require that the entity have a list of all its Assets before it identifies Critical Assets – so why am I requiring it in Fantasy CIP-002-5? Even though such a list isn’t required by CIP-002 in Versions 1-3, I know auditors ask for it to make sure the entity has properly complied with R2. Moreover, as you’ll see in my Fantasy R2 below, it needs to be in place, since otherwise Low impact assets/Facilities can’t be identified at all.
We’ve settled R1. What about R2? Going back to CIP-002 in Versions 1-3, R2 has the entity apply the RBAM to the asset list it started with (but which wasn’t required by R1 in those versions). The result of that process is a list of Critical Assets. In Version 5, there are three types of assets/Facilities to be identified, not just one. There are High, Medium and Low impact assets. How do we identify these? Obviously, not using an RBAM. We use the bright-line criteria in Attachment 1[v]. Here is my Fantasy R2:
Fantasy R2. Each Responsible Entity shall identify its High, Medium and Low impact BES Facilities/assets in parts 1.1 through 1.3:
2.1 Using the criteria in Attachment 1, Section 1, identify its High impact Facilities;
2.2 Using the criteria in Attachment 1, Section 2, identify its Medium impact Facilities;
2.3 After removing High and Medium impact Facilities from the list of assets developed in R1.2, identify the remaining Facilities as Low impact.
Now we have our lists of High, Medium and Low impact Facilities, which correspond to the list of Critical Assets in Versions 1-3. The next step, as it is in Versions 1-3, is to identify the cyber assets associated with those Facilities that are in scope for Version 5. In V1-3, CIP-002 R3 identifies Critical Cyber Assets at Critical Assets, using the definition that they are cyber assets “essential to the operation of the Critical Asset”. My CIP-002-5-taf R3 will identify BES Cyber Assets at the High, Medium and Low impact Facilities[vi]; the identified cyber assets will then become Low, Medium or High impact depending on the rating of the Facility. But what is the definition of BES Cyber Asset? Here is what the V5 Definitions document says:
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. Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact. Each BES Cyber Asset is included in one or more BES Cyber Systems.[vii]
Essentially, we need to do a similar analysis to what we currently do in Version 3. There, we determine which cyber assets are “essential to the operation of” the Critical Asset. In Version 5, we have to take a more inclusive view. BES Cyber Assets are those that “if rendered unavailable, degraded, or misused would, within 15 minutes[viii] of (their) required operation, misoperation, or non-operation, adversely impact” the Facility/Asset. So my Fantasy CIP-002-5 R3 reads:
Fantasy R3. The Responsible Entity shall identify BES Cyber Assets associated with each High, Medium and Low impact Asset/Facility. All BES Cyber Assets associated with an Asset/Facility shall take the impact level of that Asset/Facility.
That’s quite simple, right? Hardly. Both sentences will be quite controversial, although probably with different audiences.
The first sentence will be controversial mainly because it requires identification of BES Cyber Assets at Low impact facilities. CIP-002-5 says in a couple places there is no requirement to inventory or identify cyber assets at Lows. However, FERC in the NOPR makes it pretty clear they don’t like this provision and want it changed, for two reasons (you can find my full discussion of the NOPR in this post):
- They will most likely require there be specific technical requirements developed for Low impact BES Cyber Systems (instead of the current situation, in which Low impact Facilities are only required to draw up and implement four policies). Those requirements couldn’t be audited without a list of those systems.
- They question the purpose of this provision since it goes against what seems to be the purpose of CIP-002-5. That is, CIP-002-5 is supposedly for the identification of Low, Medium, and High impact BES Cyber Systems. How is this compatible with the idea that the entity doesn’t have to identify the Low impact systems?[ix]
The second sentence, “All BES Cyber Assets associated with an Asset/Facility shall take the impact level of that Asset/Facility”, will also be controversial, but with a different group. I have had discussions with SDT members and others on this very topic: whether it is possible for there to be multiple impact levels of BES Cyber Systems associated with one Asset/Facility or not. I contend it is not possible, but I admit that CIP-002-5 as currently written doesn’t rule out that possibility. So I’m making this explicit in Fantasy CIP-002-5. If you follow through the steps of CIP-002-5-taf, I think you’ll agree there is no possibility of this happening according to my standard, even without having this second sentence in R3.[x]
I have now drawn up three requirements for CIP-002-5-taf that correspond to the three requirements of CIP-002 Versions 1-3. However, there still needs to be one more requirement in CIP-002-5-taf. Do you know what that is? Of course you do – you’re so bright. We’ve identified and classified BES Cyber Assets, but CIP Version 5 deals with BES Cyber Systems. How do we move our assets into systems? Fortunately, this is pretty straightforward. We simply read the definition of BES Cyber System. It says:
I have now drawn up three requirements for CIP-002-5-taf that correspond to the three requirements of CIP-002 Versions 1-3. However, there still needs to be one more requirement in CIP-002-5-taf. Do you know what that is? Of course you do – you’re so bright. We’ve identified and classified BES Cyber Assets, but CIP Version 5 deals with BES Cyber Systems. How do we move our assets into systems? Fortunately, this is pretty straightforward. We simply read the definition of BES Cyber System. It says:
One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.
So the fourth requirement of CIP-002-5-taf is:
Fantasy R4. The Responsible Entity shall identify BES Cyber Systems from groupings of one or more BES Cyber Assets.
I said at the outset that I would point out where the BES Reliability Operating Services (which are discussed at length in the Guidance and Techical Basis section of CIP-002-5 but never once appear in the requirements themselves) are applicable. It is at this point, where the entity is identifying BES Cyber Systems as groupings of BES Cyber Assets. As was explained to me by a Knowledgeable Person, the BES Reliability Operating Services provide guidance on the types of systems that should be considered as BES Cyber Systems, depending on where the entity falls in the NERC Functional Model.
In particular, the table on page 18 of CIP-002-5 identifies which BROS would logically apply to which Functional Registration types. It is certainly advisable - although not mandatory - that the entity determine which BROS apply to it, given its registrations. The entity should then examine the descriptions of the BROS that apply to it (e.g. a TO should examine each of the BROS with an X in its column), to determine which systems it should definitely consider as BES Cyber Systems (of course, there may be other systems that should be considered as well).
Now to Attachment 1
In particular, the table on page 18 of CIP-002-5 identifies which BROS would logically apply to which Functional Registration types. It is certainly advisable - although not mandatory - that the entity determine which BROS apply to it, given its registrations. The entity should then examine the descriptions of the BROS that apply to it (e.g. a TO should examine each of the BROS with an X in its column), to determine which systems it should definitely consider as BES Cyber Systems (of course, there may be other systems that should be considered as well).
Now to Attachment 1
With the three requirements I have just described, my CIP-002-5-taf has straightened out the problems with CIP-002-5 R1 (except for the big iron problem, of course). I don’t see that the current CIP-002-5 R2 needs to be changed at all, other than numbering it R5. The big problem now is Attachment 1. What changes need to be made there?
As I did in my changes to CIP-002-5 R1, I need to put aside Big Iron issues as I change Attachment 1. Specifically, the whole asset/Facility[xi] wording in Appendix 1 needs to be redone, although I have to spend some time thinking about how to do that. As with what I did above, I’ll leave that issue aside by saying asset/Facility whenever needed.
I also don’t want to even suggest any changes in the bright-line criteria themselves. These have been determined by the SDT and voted on by the NERC ballot body and the board, so there is no point in opening up any questions about them (nor would I be competent to do so). What I will suggest be changed are the three short (1-3 line) introductory phrases that precede the criteria in each section. I’ll go through these by section. Keep in mind that each of the sections of Attachment 1 of the current CIP-002-5 is logically and syntactically preceded by sub-requirement 1.1, 1.2, or 1.3 of CIP-002-5 R1. In the same way, each of my Fantasy sections of Attachment 1 is preceded by sub-requirement 2.1, 2.2 or 2.3 of CIP-002-5-taf R2.
As I have previously alluded, and as I said explicitly in my post on asset identification in V5, I consider it dishonest to state that the entity is using the Attachment 1 criteria to classify BES Cyber Systems, rather than the assets/Facilities themselves (it also leads to a situation where the entity literally cannot identify anything at all – Facilities, assets, BES Cyber Systems, whatever – that is Low impact. This will make NERC entities happy since they won’t have any Low impact stuff at all, but it hardly reflects the intent of either the Standards Drafting Team or FERC). The only sensible statement that can be made about the bright-line criteria in Attachment 1 is that they are for classifying big iron, not little iron.
The heading of Section 1 of Attachment 1 currently reads:
1. High Impact Rating (H)
Each BES Cyber System used by and located at any of the following:
(followed by the High impact criteria)
What needs to be done with this? Pretty simple. We just need to say:
Fantasy 1. High Impact Rating (H)
Facilities that meet one or more of the following criteria are High impact:
Section 2 reads:
2. Medium Impact Rating (M)
Each BES Cyber System, not included in Section 1 above, associated with any of the following:
(followed by the Medium impact criteria)
I propose this replacement:
Fantasy 2. Medium Impact Rating (M)
Facilities that meet one or more of the following criteria, and are not included in Section 1 above, are Medium impact:
Section 3 is more interesting. It currently reads:
3. Low Impact Rating (L)
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:
3.1. Control Centers and backup Control Centers.
3.2. Transmission stations and substations.
3.3. Generation resources.
3.4. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements.
3.5. Special Protection Systems that support the reliable operation of the Bulk Electric System.
3.6. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above.
Here is my suggestion for this part:
Fantasy 3. Low Impact Rating (L)
BES Assets/Facilities meeting the applicability qualification in Standard Section 4, that are not included in Sections 1 or 2 above: [xii]
(followed by the same list of types of facilities)
(I wish to thank Bob Case of Black Hills Corp. for suggesting improved wording for this part)
(I wish to thank Bob Case of Black Hills Corp. for suggesting improved wording for this part)
Well, that’s it. I have outlined my Fantasy version of CIP-002-5, with the big proviso that I haven’t addressed the Big Iron problems in the current version. I will hopefully soon be able to do that, and will then provide my complete Fantasy version, all ready for FERC to adopt unchanged (hey, a guy can fantasize, right?).
P.S. In writing this post, I saw a problem with the definition of BES Cyber Asset in the V5 Definitions document (this definition is reproduced above in the discussion of my Fantasy R2). The phrase “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” is quite disturbing. It’s another of those phrases that includes an entire requirement embedded in its syntax. What it’s saying is that before an entity can say that a cyber asset is a BES Cyber Asset, it has to make sure it’s associated with a Facility that’s essential to the BES.
Why is this disturbing? Consider CIP Versions 1-4. In those, the definition of Critical Cyber Asset (embedded in one of the requirements) is that it is “essential to the operation of the Critical Asset”. The definition doesn’t say what attributes an asset (big iron, of course) must have in order to be a Critical Asset; that is the job of CIP-002 R1 in those versions. However, the V5 Definition of BES Cyber Asset not only defines the required attributes of the cyber asset (the little iron), but it also – in the above phrase – describes the attributes of an Asset/Facility that is in scope for Version 5 (the big iron).
This is in complete conflict with the wording of CIP-002-5 Section 4.2 described above, which states that Facilities in scope for V5 are all BES Facilities owned or operated by a functional entity type listed in Section 4.1. The determination of how critical a facility is to the BES has already been made by the SDT, in the course of developing the bright-line criteria in Attachment 1. It is not up to the entity to make its own determination just in order to follow the definition for BES Cyber Asset. The solution is clear: This phrase needs to be completely taken out of the BES Cyber Asset definition. The definition should just be about the cyber asset, not the Facility it’s associated with.
One more question: Did anyone bother to read any of this stuff? Just curious.
The second part of this post can be found here.
The second part of this post can be found here.
[i] I just hope I have time to make the comments by June 20. I keep finding new problems I need to write posts about!
[ii] The first draft of CIP-002-5 did refer to BES Reliability Operating Services, and in fact asserted that the first step in compliance was to identify cyber assets that fulfilled one or more of these services. As I and three colleagues (two anonymous because they work for a large IOU) pointed out in this blog post at the time (December 2011), this approach led to a completely unworkable standard. The first draft of CIP-002-5 was resoundingly defeated in the first ballot, and the second draft removed all reference to BES Reliability Operating Services in the requirements of CIP-002-5.
[ii] The first draft of CIP-002-5 did refer to BES Reliability Operating Services, and in fact asserted that the first step in compliance was to identify cyber assets that fulfilled one or more of these services. As I and three colleagues (two anonymous because they work for a large IOU) pointed out in this blog post at the time (December 2011), this approach led to a completely unworkable standard. The first draft of CIP-002-5 was resoundingly defeated in the first ballot, and the second draft removed all reference to BES Reliability Operating Services in the requirements of CIP-002-5.
[iv] I don’t understand why the list of six asset types is in CIP-002-5 R1. The entity has already been told in Section 4.2 that Version 5 will apply to all of their BES Facilities. Is this list of six types meant to constrain that list further? If so, it would be better just to include it in Section 4.2, rather than say all BES Facilities are in scope in that section and then constrain it in R1 (I don’t know how many BES Facilities wouldn’t be included in this list of six types, but I assume there must be some). However, I’m assuming there is a good reason for the list being in R1, so I am including it in my Fantasy R1.
[v] However, we need to disregard the language that precedes each of the sections of the current Attachment 1. That language should be indicted for perpetrating a fraud, since it pretends that we’re identifying BES Cyber Assets in Attachment 1, when we’re really just identifying Facilities/assets as High, Medium or Low impact. In other words, Attachment 1 is really about identifying big iron, not little iron. This shows that CIP-002-5-taf needs to make modifications to the Attachment 1 language as well, which I will do.
[vi] CIP-002-5-taf will make explicit that the entity needs to identify BES Cyber Assets first, then will clearly state that these need to be included in BES Cyber Systems. I won’t start by telling the entity they need to identify the systems, then leave it to them to figure out that they really need to first identify assets not systems (since the V5 Definitions document just defines BES Cyber Systems as groupings of BES Cyber Assets) – as is done in CIP-002-5. This will make things much clearer for the entities that have to comply. Hey, I’m just that kind of guy – always trying to be helpful.
[viii] Given the skepticism FERC expressed in their NOPR regarding the 15-minute provision in the definition of BES Cyber Asset, I’d say it’s likely they will order that removed. At that point, the question is whether they will put in a longer limit – say 2 hours, one day, etc. – or simply leave the limit out. If there’s no limit, this means a cyber asset would be a BES Cyber Asset even if its loss or misoperation wouldn’t have an effect on the Facility for days.
[ix] If you read my post on asset identification in Version 5, you will notice I point out toward the end (paragraphs numbered 11-13) that this provision, that Low impact systems don’t need to be inventoried, literally makes it impossible fully to comply with requirement R1 (since the third section of Attachment 1 requires the entity to determine its Low impact BES Cyber Systems by subtracting the Highs and Mediums from a pre-existing total list of systems. How could you have a total list of Low, Medium and High systems without identifying them all – Lows, Mediums and Highs? Of course, in CIP-002-5-taf I'm requiring an initial list of assets/Facilities, not BES Cyber Systems). So even if FERC did agree with the provision that no inventory was required for Low impact BES Cyber Systems, the standard would still need to be changed to make it even possible for entities to comply with CIP-002-5. I could suggest language for that possibility, but since it appears clear to me that FERC is serious about removing the provision that there not be an inventory of Lows, I won’t bother to do that.
[x] There is one specific exception to the rule of all BES Cyber Systems at an asset (or Facility) having the same rating; it was pointed out to me in a comment on my NOPR post. Criterion 2.1 in Attachment 1 of CIP-002-5 deliberately creates two classes of BES Cyber Systems associated with one asset (a generating station greater than 1500MW):
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.
So BES Cyber Systems that can impact more than 1500MW are Medium impact; all other BES Cyber Systems would be Lows. But this is the only Attachment 1 criterion that creates two classes of BES Cyber Systems at one asset.
[xi] You may have noticed that I capitalize Facility but not usually asset. That is because Facility is a defined term in the NERC Glossary, while asset is never defined, in either the NERC Glossary or in the Version 5 Definitions document. This of course is part of the big iron problem in CIP-002-5, which I will address in a new post.
[xii] This is the same list that appears in R1. I don’t see the need for it here, any more than I did in R1. As I said in note iv above, if the intent is to constrain the types of BES Facilities to which Version 5 applies, it would be better to include this list in Section 4.2. My Fantasy version of the Low impact introduction would then read “BES assets/Facilities that are not included in Sections 1 or 2 above:”
[xiii] I wish to thank Bob Case of Black Hills Corp. for suggesting improved wording for the Fantasy 3 section.
[xiii] I wish to thank Bob Case of Black Hills Corp. for suggesting improved wording for the Fantasy 3 section.
My initial version of this post referred three times (in the end notes) to an argument I'd had with Joe Baugh, a senior WECC auditor, about asset identification and the BES Reliability Operating Services, during the WECC CIP User Group meeting in Portland, OR last week. I'm pleased to say that I was misinterpreting his statements and we are in fundamental agreement on the asset identification process in CIP Version 5.
ReplyDeleteI also wish to point out that the reason WECC (and Joe Baugh in particular) gets so much flak on their interpretations of new CIP versions is that they are willing to take the lead in this area. I don't believe any other region has yet addressed what entities need to start doing to comply with CIP Version 5. The same thing happened at the June WECC meeting a year ago, when Joe stuck his neck out and presented on how they would audit the V4 bright line criteria. I described the resultant firestorm in this blog post: http://insecurity.honeywellprocess.com/index.php/2012/09/not-so-bright-lines/
ReplyDeleteAnother point from the WECC meeting: Joe Baugh said unequivocally that CIP Version 4 won't come into effect. Other regions have hedged their bets more. But I agree with Joe. FERC stated in their NOPR that V4 won't happen, and they have several different ways to ensure that outcome. Most importantly, they understand the industry impact of having to comply with two new standards, and seem very committed to avoiding that.
ReplyDeleteOf course, just a few months ago I was assuring people that V4 would come into effect, so my track record isn't exactly pristine. But I think Joe can be trusted more than me.