Saturday, April 27, 2013

Asset Identification in CIP Version 5



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


Note: This post turned out to be the first in a series of four posts in which I complained bitterly about the very imprecise wording in CIP-002-5 - and ended up writing my own "fantasy" version. The next step in this tetralogy is here.

Oct. 7: I started another series of posts today, on how NERC entities could get through the CIP-002-5 ambiguities discussed in this and subsequent posts, in order to actually identify cyber assets in scope for CIP Version 5 (since I'm assuming FERC won't order that standard be rewritten, when it approves Version 5 in the near future).  You can see the first of that series here.


A funny thing happened on the way to this blog post.  After FERC’s NOPR on April 18, I decided I should do a series of blog posts that really tear into the details of CIP Version 5 – since very few people other than the SDT members can probably give you a good accounting of what is in there, and since a large number of NERC entities (many more than with the previous versions) will be facing CIP compliance under V5.  I started with CIP-002-5, which – as in the previous CIP versions – is where the entity identifies which of its cyber assets (if any) are subject to the remaining standards.

Now, I knew already that the wording of the requirements in CIP-002-5 was not the best.  However, I believed it was at least unambiguous, so that some clarification would help my readers understand what was at stake as they start to gear up their CIP V5 programs (if they haven’t already, since I know some have).  I had followed and written about the development of V5 for almost three years.  I certainly thought I knew what wording was in that standard now, and that it was adequate for the purpose, although somewhat rough.

So I pored over CIP-002-5 and started writing my post on it.  As I did so, I finally came to the conclusion that there are some serious problems in the wording of this standard!  I believe they will prove to be a big obstacle to doing workable and fair audits when the time for auditing rolls around.  I don’t think the current wording is completely unworkable[i] (as I did with the first draft of CIP-002-5 in 2011), but I do think that it needs to be substantially rewritten.  Fortunately, there will be a chance to do this since a new CIP version will have to be drafted and approved to make the modifications that FERC will require.  There are two areas in which I think the wording needs to be substantially changed.[ii]


I. Facilities/Assets
I have been telling people for some time that the fundamental concept in V5 is that of a BES “Facility”, and this corresponds to an “asset” in Versions 1-4.  In V5, you identify high, medium and low impact BES facilities, while in V1-4 you identify Critical Assets.  In both cases, you then go on to identify the cyber assets that are in scope, that are associated with those BES Facilities/Critical Assets.

So I started working down through the wording of CIP-002-5 (and this was the first time in more than a year that I’d gone through it in detail).  I nodded my head when I read Section 4.2, which identifies “Facilities, systems and equipment” that are subject to the V5 standards.  And I further nodded my head when I read the Guidelines paragraph on page 17 that provides a very good justification for the use of the term “BES Facilities”. 

I then came to the actual requirements; there are only two of these, and R1 is the one where you would expect to see Facilities come into play.  But guess what?  “Facilities” aren’t mentioned at all in CIP-002-5 R1.  Here is the first part of the requirement:

Each Responsible Entity shall implement a process that considers each of the following assets for purposes of parts 1.1 through 1.3:

i.Control Centers and backup Control Centers;
ii.Transmission stations and substations;
iii.Generation resources;
iv.Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements;
v.Special Protection Systems that support the reliable operation of the Bulk Electric System; and
vi.For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above.

Facilities have disappeared off the face of the earth, and it’s an undefined term called “assets” that is now the whole basis for CIP V5.[iii]  There is some explanation in the Guidelines section (page 17):

For the purpose of identifying groups of Facilities, systems, and equipment, whether by location or otherwise, the Responsible Entity identifies assets as described in Requirement R1 of CIP-002-5. This is a process familiar to Responsible Entities that have to comply with versions 1, 2, 3, and 4 of the CIP standards for Critical Assets. As in versions 1, 2, 3, and 4, Responsible Entities may use substations, generation plants, and Control Centers at single site locations as identifiers of these groups of Facilities, systems, and equipment.

So it seems that, in order to identify “Facilities”[iv] subject to V5, the entity instead identifies “assets”.  Then why didn’t Section 4.2 just refer to assets, not facilities?

I think I know the answer to this question.  Go to the “Guidelines and Technical Basis” section, page 23.  At the end of the first bullet point on that page you’ll find this:

..an identified BES asset may be a named substation, generating plant, or Control Center. Responsible Entities have flexibility in how they group Facilities, systems, and equipment at a location.

As we suspected (see end note iii), an “asset” is defined as one of the six things identified with lower-case Roman numerals in R1.  However, we still don’t know why Section 4.2 goes through all the trouble of discussing Facilities if you actually have to consider “assets” not Facilities in Attachment 1 (and a new term has been introduced - "location".  How does that relate to assets and Facilities?).  If we go to the top of the same paragraph, we read:

When the drafting team uses the term “Facilities”, there is some latitude to Responsible Entities to determine included Facilities. The term Facility is defined in the NERC Glossary of Terms as “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.).” In most cases, the criteria refer to a group of Facilities in a given location that supports the reliable operation of the BES. For example, for Transmission assets, the substation may be designated as the group of Facilities. However, in a substation that includes equipment that supports BES operations along with equipment that only supports Distribution operations, the Responsible Entity may be better served to consider only the group of Facilities that supports BES operation.

The SDT is making the point that, at least in the case of substations, an “Asset” isn’t the same as a “Facility”.  This has real consequences, since many substations have both transmission (i.e. BES) elements and distribution elements.  The latter aren’t usually subject to CIP at all; the former are.  So by saying that there can be multiple “Facilities” at the substation (and this is consonant with the NERC Glossary definition of Facility that is cited in this quotation), the SDT is saying that the entity should be able to just take the transmission facility or facilities separately from the rest of the substation, then run them through the Attachment 1 criteria to see if they end up being Medium impact.[v]

Great, now we understand what they meant.  There’s only one problem: R1 is what directs the entity to use Attachment 1, and R1 doesn’t mention “Facilities”, just assets!  In fact, if you look at the six different types of assets listed in R1, only “substations” are mentioned, not “transmission Facilities at substations” or something like that. 

So an entity with a combined transmission/distribution substation would have to take the whole substation asset through Attachment 1, not just the transmission Facility.  When they come to the criteria that deal with substations (2.4, 2.5, 2.7, and 2.8), they would…well, what would they do?  They might just skip those criteria altogether, since they all apply to “Transmission facilities” not an “asset” called a “substation”; therefore, no match.  Or they might feel that they have to consider the entire substation as a transmission facility, so they wouldn’t be able to separate out the distribution elements; this will obviously result in much higher compliance costs.  Or they might simply ignore the actual wording and just do what the SDT clearly intended for them to do: classify the transmission elements as a medium impact facility (if they meet one of the criteria), not the whole substation; hopefully, the auditors will also ignore the actual wording.

The paragraph I just cited above continues:

In that case, the Responsible Entity may designate the group of Facilities by location, with qualifications on the group of Facilities that supports reliable operation of the BES, as the Facilities that are subject to the criteria for categorization of BES Cyber Systems. Generation Facilities are separately discussed in the Generation section below. In CIP-002-5, these groups of Facilities, systems, and equipment are sometimes designated as BES assets.

Now we have a new category: a “group of Facilities by location”.  In the case of our substation, the transmission sub-group of BES facilities is what would be medium impact.  I believe that “group of Facilities by location” means the same as “Asset” in R1 (in fact, the last sentence above seems to imply that, although it doesn’t say that the two are interchangeable).  Why not just say this explicitly in R1?

So there are some real ambiguities here, regarding the Facilities/Groups of Facilities/Assets/Whatever with which cyber assets are associated.  If none of this language is changed, will it be the end of the world as we know it?  No.  I imagine the Regional Entities or someone else would issue some clarifying language (although I guess it won’t be a CAN, since they’re on their way out.  Maybe there would be an RFI).  But I think cleaning up this wording is very important (in fact, as you read through the second part of this post and especially some of the footnotes, you’ll see that the more serious problems discussed there are closely tied to the Facilities/Assets problem).

I would suggest changing the language in R1 to say in effect that

1.                   An Asset is defined as a group of Facilities at a single location (or maybe even drop the term ‘asset’ altogether and just say that the entity has to consider each ‘group of Facilities’ for sub-requirements 1.1 through 1.3).
2.                   Here are six examples of assets (i through vi in the current R1).

Phew.  Now on to the bigger problem.


II. Cyber Asset Classification
When you look at CIP-002-5 and compare it to CIP-002-3, you will notice that it has just two requirements, not four as in CIP-002-3.  Since the last requirement in each standard is for the “annual” review, this means that R1 of CIP-002-5 does what R1, R2 and R3 of CIP-002-3 do.  Is this a marvel of concise language?  I’ll admit the language is concise, but I won’t say it’s marvelous.  Here is the requirement as it now reads:

Each Responsible Entity shall implement a process that considers each of the following assets for purposes of parts 1.1 through 1.3:

i.Control Centers and backup Control Centers;
ii.Transmission stations and substations;
iii.Generation resources;
iv.Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements;
v.Special Protection Systems that support the reliable operation of the Bulk Electric System; and
vi.For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above.

1.1. Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset;
1.2. Identify each of the medium impact BES Cyber Systems according to Attachment 1, Section 2, if any, at each asset; and
1.3. 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).

Let’s follow down through this as if we were reading it for the first time, trying to figure out what we need to do to comply.  Here are the steps I believe this requirement is asking us to take:

1.                   We “implement a process” to “consider” each of the six asset types in addressing each of the three sub-requirements 1.1, 1.2 and 1.3.  This might be considered the equivalent of CIP-002-3 R1, in which we develop an RBAM, but don’t actually apply it.

2.                   Let’s start with sub-requirement 1.1, “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset.”  So far, we’ve just talked about assets.  How are we going to “identify BES Cyber Systems”?  And what are these beasts, anyway?

3.                   We go to the V5 Definitions document (since we already know to look there or in the NERC Glossary for any capitalized word in CIP V5).  There, we find the definition of BES Cyber System:
One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.

4.                   Aha, now we have to find out what a BES Cyber Asset is.  Fortunately, the definition is right above:
 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.

5.                   Now what do we do?  We know a BES Cyber System is made of BES Cyber Assets, but we’re being asked to “Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each asset.”  How do we do that?

6.                   I guess it would be a good idea to go to Attachment 1, Section 1.  The first line of that section reads “Each BES Cyber System used by and located at any of the following”.    And “the following” is four criteria for Control Centers.  Since we know Control Centers are one of the six asset types listed in the first part of R1, we can assume this means that we need to take each of our assets and compare it to each of these four criteria.

7.                   What do we do if there is a match with one or more of our assets?  Since the heading of this section is “High Impact Rating”, we probably have to apply that rating to every[vi] BES Cyber System associated with any asset (control center, in this case) that meets one or more of those criteria (although it would be nice if we didn’t have to guess these things!).

8.                   Now we physically visit that asset (control center).  We first consider every cyber asset associated with the control center, to see whether it meets the definition of BES Cyber Asset (of course, this is a laborious process, just as CCA identification is laborious in CIP V1-4). 

9.                   Those cyber assets that meet the definition of BES Cyber Asset now need to be grouped into BES Cyber Systems.  OK, we do that.[vii]  Now each of those BES Cyber Systems is high impact.

10.               We repeat this process for sub-requirement 1.2, and come out with our list of medium impact BES Cyber Systems (by first identifying the medium assets, then their systems, as in steps 6-9 above).

11.               However, we can’t repeat this process for sub-requirement 1.3 (low impact BES Cyber Systems).  There, we are told to identify

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 is followed by the same list of asset types that appears in the first part of R1.  So it seems we take a pre-existing list of BES Cyber Systems, subtract out the ones that already were classified as high or medium impact, and designate the rest (those that meet the part 4.2 applicability criteria and are associated with one of the six asset types) as low impact.

12.               But here we run into a problem: We don’t have a complete list of BES Cyber Systems![viii]  With sub-requirements 1.1 and 1.2, we have first identified the assets that qualify as high or medium impact; only then have we visited each of those assets (control center, generating station, etc) and identified all the BES Cyber Assets and BES Cyber Systems.  The only way we could have a complete list would be if we had gone to every asset that we own, inventoried all of the cyber assets associated with it, identified which of those were BES Cyber Assets, and then grouped them into BES Cyber Systems.  Does this mean we have to first take this step?  Of course not.  In fact, 1.3 says “a discrete list of low impact BES Cyber Systems is not required.”   So how could we possibly have such a list to start with?

13.               Let’s be honest about this: We’re not really classifying BES Cyber Systems in Attachment 1, no matter how the language reads.  We’re really classifying BES assets (substations, control centers, etc).  And we certainly do have a total list of BES assets for our entity.  That list is what we’re applying the criteria in Attachment 1 to.  We’re actually just subtracting the high and medium impact assets off that list, to come up with our list of Lows.

14.               But that’s where we stop in sub-requirement 1.3.  Even though Section 3 of Attachment 1 says we’re identifying

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:

we’re not actually doing that.  We’re just finding the low impact assets (substations, generating stations, etc) on our asset list, and then we’re stopping, since we’ve been told in sub-requirement 1.3 that an inventory isn’t required.[ix]

We’ve reached the end of our long journey through Requirement 1 of CIP-002-5.  Let’s ask a simple question: If it takes 14 steps to comply with this requirement, and those steps can only be discerned by parsing carefully through the words (except for sub-requirement 1.3, where you need to ignore the words in Attachment 1 part 3 in order to be able to understand what you’re really being asked to do), how in h___ is this ever going to be understood by Joe or Jane NERC Entity, let alone audited by Bill or Betty CIP auditor?

And before you say it’s a good thing that this can’t be audited, let me remind you that in the history of CIP, ambiguity has more often redounded to the detriment of NERC entities than it has to their benefit.  I don’t think there will be any winners, given this fundamental ambiguity in CIP-002-5.

So what needs to be done about the cyber asset classification problem in CIP-002-5?[x]  Two things at a minimum:

1.                   R1 should be broken into multiple requirements.  Maybe not 14 as I have done, but definitely at least three, as in CIP-002-3 – and maybe more.  I think it is terrible that entities will have to become lexicographers and diagram sentences (which most of us stopped doing in the fourth grade)[xi], just to discern what R1 is asking them to do.
2.                   The dishonesty of saying that Attachment 1 is for classifying BES Cyber Systems rather than assets needs to stop.[xii]  As I’ve shown, it leads to one sub-requirement (1.3) that simply cannot be obeyed as written.  But it also leads to a number of extra steps - and a lot of confusion - in complying with sub-requirements 1.1 and 1.2 - that could all be avoided with a simple change of wording.[xiii]



















[i] As I finalize this for posting, I must say that the problems got worse and worse the more I looked at the standard.  If you read the footnotes below, you’ll see at least two or three places where I haven’t even bothered to suggest how something should be rewritten – I was getting too tired of doing that, and this is already my longest post (the NOPR post is the second-longest).  What surprises me is that the FERC staff members didn’t seem to see any of this.  They only had to do what I did – start off as someone who knows nothing about V5 and try to figure out how to comply with this standard.  It was frankly quite a depressing experience to realize how muddled the language in this standard is after so many meetings and rewrites, and how it will be a big problem if none of this is changed, whatever NERC does with FERC’s NOPR complaints.
[ii] BTW, I still intend to do the series of posts on Version 5.  I’ll just have to fence off the many ambiguities, including those in CIP-002-5 discussed in this post.
[iii] It isn’t completely undefined, since the six items listed with lower case Roman numerals constitute a definition by example.
[iv] I’ve heard that some CIP auditors aren’t happy with the fact that the SDT used the NERC Glossary definition of Facilities, which is fairly narrow, instead of defining a broader term in the CIP V5 Definitions document.
[v] I think having the ability to “slice and dice” an asset into Facilities also has a bearing in Criterion 2.3;
Each generation Facility that its Planning Coordinator or Transmission Planner designates, and informs the Generator Owner or Generator Operator, as necessary to avoid an Adverse Reliability Impact in the planning horizon of more than one year.
The fact that this says “generation Facility” rather than “Generating asset” or something like “Generating station” means that, if a PC or TP says that a single unit or maybe a couple units at a plant is “necessary”, the GO/GOP only has to designate those unit(s) as medium impact.  The other units can be low impact, since they could be considered a separate Facility.  However, this is entirely my own interpretation.  This points to the need for a guidance document to be developed on CIP-002-5 (just as there were guidance documents on Critical Asset and Critical Cyber Asset identification in CIP Versions 1-3).  I would put out a post about that and get all worked up in righteous indignation that it wasn't being done, except for one thing: nobody can even write a good guidance document on CIP-002-5 as it currently stands.  It would be like trying to nail Jell-O (tm) to the wall.

[vi] I have had disagreements with a couple knowledgeable people – one an SDT member, another an auditor – about whether every BES Cyber System associated with a high or medium impact asset will have the same classification as the asset itself, or whether you could have multiple classifications of BES Cyber Systems at a single asset.  I have yet to be convinced that there could be multiple classifications of BES Cyber Systems associated with one asset.  If a control center is a high or medium impact, all of the BES Cyber Systems associated with it will be high or medium; if the control center meets at least one high criterion and at least one medium criterion (and only a control center could do this, since the only high impact assets are control centers), then it will be a high impact and all its BES Cyber Systems will be high impact (somewhere in the Guidance for CIP-002-5 it discusses the idea of a "high-water mark" which affirms this statement, but I can't find it now).  Any other cyber asset/system at the control center - that isn't an access point or something like that - isn’t a BES Cyber Asset/System at all (although it would probably be a Protected Cyber Asset if it’s on the same network as the BES Cyber Systems).
To explain this – and I’d do a footnote here if I weren’t already in a footnote! – remember that a system is a BES Cyber System by virtue of fulfilling one or more BES Reliability Operating Services (BROS); the BROS are discussed on pages 17-21 of CIP-002-5.  Let’s say a control center meets one criterion as a high impact, say criterion 1.2 (“perform the functional obligations of the Balancing Authority….”).  A system that performs one of the BROS for a BA control center (say “balancing load and generation”) will be a high impact BES Cyber System.  But say another system at the control center performs a BROS for one of the medium impact control center criteria, say 2.11 (“functional obligations of the Generation Owner…”).  Does this mean that this system is medium impact?  It certainly seems that it should be.

[June 13: I really have to do a footnote within a footnote here.  I no longer believe that a cyber asset is a BES Cyber Asset by fulfilling one of the BROS.  It is a BES Cyber Asset because it is associated with a BES Facility and meets the definition of BES Cyber Asset.  The BROS do have an informal role in the asset identification process, though.  See the paragraph after "Fantasy R4" in my post on Fantasy CIP-002-5.]

However, I believe this is really a case of there being two Facilities at one asset.  One Facility satisfies criterion 1.2; the other satisfies criterion 2.11.  They should be treated by the entity as if they were completely separate assets (or facilities) – their own compliance documentation, SME’s, etc.  I think it would be prudent (and perhaps absolutely essential) for the asset owner to separate the two types of BES Cyber Systems on different networks – this would avoid having to protect every cyber asset on the network as a High impact, which would presumably be the case without that separation.  But frankly, this is speculation that goes way beyond the language of CIP-002-4 (or any of the commentary provided by the SDT).  And that's the point: This is yet another area that should be fleshed out in CIP Version 6.
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 I believe this is the only Attachment 1 criterion that creates two classes of BES Cyber Systems at one asset.
[vii] Of course, grouping BES Cyber Assets into BES Cyber Systems will probably develop into a black art of its own.  Fortunately, you won’t be audited on whether you did this step right or not; it is there mainly to make your compliance life easier, and that’s where the art comes in.  When I do my blog post(s) on how to identify BES Cyber Systems, I may make suggestions about how to practice this black art.
[viii] I do realize that, in taking this step, the entity is actually following sub-requirement 1.3, which says “Identify each asset that contains a low impact BES Cyber System according to Attachment 1, Section 3, if any”.  So very technically, they are being told to identify assets, not systems.  However, they’re not being asked to identify a low impact asset but an "asset that contains a low impact BES cyber system."  This means that the only way to comply with this is to identify the low impact systems as described in section 3 of Attachment 1.
[ix] As I pointed out in my post on the NOPR, FERC seems to strongly disagree with the idea that an inventory of low impact BES Cyber Systems isn’t required.  If this gets changed, then we won’t stop when we've identified an asset as a low impact one.  We’ll have to do what we did at the high and medium assets: inventory the cyber assets, identify BES Cyber Assets among them, and group those into BES Cyber Systems.
[x] You may ask, “Why does Attachment 1 say that it’s for classifying BES Cyber Systems rather than BES assets?  Isn't that the root of the problem?”  I’m afraid the answer is probably just stubbornness.  The first draft of Version 5 – balloted in November and December of 2011 – really did try to start with identifying BES Cyber Systems by themselves; then it classified them according to the Facility (not asset) they were associated with.  I and Donovan Tindill of Honeywell (as well as two CIP compliance managers from a large IOU, who had to remain anonymous but were very helpful) pointed out in a post in December 2011 that this approach simply couldn’t work and would be unauditable as well.  This contributed – in a small way - to the overwhelming defeat of CIP-002-5 on the first ballot (although every other V5 standard also was resoundingly defeated on that ballot).
When the SDT met in January 2012, it immediately scrapped the previous approach and went with roughly the current language.  However, they unfortunately left a number of remnants of the old language in CIP-002-5; what I have just discussed is probably the most egregious example of that.  I will admit that, when I wrote my post on the V5 NOPR last week, I mentioned this problem (footnote vii).  I said it would be the source of a lot of confusion, but I didn’t say the wording should be changed.  I have since realized that it would be a huge shame if FERC and NERC didn’t take advantage of having to revise CIP V5 to fix the many serious wording problems with CIP-002-5.  Trying to fix the problems once the standard is implemented will be much more expensive for entities and NERC, both in terms of time wasted and money spent, than fixing them now.

[xi] An auditor pointed out to me that they have to diagram sentences all the time in the course of determining whether an entity is compliant with a particular CIP requirement.  Fourth-grade teachers across the continent should be proud of their contribution to securing our critical infrastructure.
[xii] This points to another fundamental disagreement I have with a few other interested parties (I realize I'm beginning to sound like I'm a very argumentative person - maybe it's true).  Not only do I believe there can be only one level of BES Cyber System at a particular Facility (or asset, if the asset only has one Facility), but I believe there is no such thing as a BES Cyber System that is independent of any Facility.  It was pointed out to me last year by the SDT chairman that an example of an independent system is a “leak detector”, which sits on a transmission line out in a field somewhere but performs a BES Reliability Operating Service in spite of not being part of a generating station, transmission substation, etc.  I hadn’t heard of these before, but I will certainly stipulate that it would meet the definition of a BES Cyber System (and there are probably other cyber assets, not part of any other Facility, that do as well).  However, my feeling is that this should be defined as its own Facility.
Of course, someone will point out that defining a cyber asset as its own Facility is simply an artificial construct, since the Facility is, in this example, being defined as just the leak detector, nothing more.  I agree this is artificial, but consider the consequences if we don’t do this.  In other words, what if the current language, which implies that there can be BES Cyber Systems independently of assets/Facilities, is allowed to stand?  Every NERC entity subject to CIP Version 5 will have to start their asset identification process by inventorying every cyber asset they have that touches the BES.  This includes cyber assets at all BES Facilities, but also cyber assets not associated with any Facility at all (such as the leak detectors).  They will then have to consider whether each cyber asset (or the system it’s part of) is a BES Cyber System, and this will all be before they classify their Facilities/Assets as High, Medium or Low impact (in other words, we end up in pretty much the position we were in in the first draft of Version 5 in November of 2011).  This will be a massive job, and I hereby assert that it will add very little to BES reliability – certainly not on a scale commensurate with the cost.   Is this really what we want the industry to have to do?
[xiii] You may ask (and if not, I have certainly asked myself), “You’ve pointed out you attended a number of SDT meetings while V5 was being drafted.  Why didn’t you bring up these problem then?”  Here's my answer: After the even bigger problem – that I’d pointed out in my December 2011 post – was fixed, a) I didn’t have a lot of stomach for more controversy (or it shifted to other areas, to be more accurate) and b) I stopped paying so much attention to the details of the wording of CIP-002-5.  I do remember pointing out in one SDT meeting that I really thought they hadn’t gone all the way to take out the idea that identifying BES Cyber Systems came before classifying Facilities, but I certainly didn’t make a complete nuisance of myself by bringing it up again.
There’s another reason: after Version 5 failed on the second ballot (not quite as overwhelminingly as on the first), I, as well as all SDT members, was quite aware that CIP Version 5 needed to pass on the third ballot.  If it didn’t, that would most likely be the end of the Version 5 effort.  The SDT would go home without a lot to show for their last two or three years of very hard work.  And either NERC would start over on Version 6 with a new SDT, or – more ominously – FERC might just figure out a way to write V6 itself, leaving NERC out.  I frankly didn’t want to jeopardize that by making a big deal of wording problems that could presumably be fixed in the future (like now, for instance).

Why Your Next CIP Version may be 6, not 5

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

July 25: The purpose of this post is to explain what I see to be the sequence of events for approval of whatever the next compliance version of CIP will be, either 5 or 6.  A separate post (also updated today) discusses the possible timing of those events, as well as of compliance with the new version.
I. FERC's comment period on the CIP Version 5 NOPR concluded in June; they are now mulling over the comments received.  It is possible they will ask for more information from NERC, but their next official step will be to approve V5, as they said they would do in the NOPR.

The question is whether they simply approve V5, or whether they also order NERC to provide a compliance filing.  This would be a new version of CIP that would start from what is in V5 now, but would include the various changes FERC will ask for (of course, nobody knows what those changes will be, but the NOPR gives a good indication of what FERC intended to ask for, at least in April when they wrote it).

You may wonder why FERC can't simply send V5 back to NERC and say, "Please change this." Why do they have to order a new version?  Although this isn't entirely clear, it seems that FERC doesn't have the power, under the Federal Power Act of 2005 Section 215, to do that; the only steps they can take are to either completely approve or completely reject a proposed standard.  This is what happened in September 2009: FERC approved CIP Version 2, but at the same time ordered NERC to come back in 90 days with a new version that included a requirement for physical escort of visitors in the PSP - this became CIP V3.[i]

But FERC also can't simply remand V5 and tell NERC to come back with something better.   If they do that, NERC will have to draw up a SAR, constitute a new SDT, spend a year or so drawing up an entirely new CIP Version 6, go through a few ballots before it’s approved, etc. – a 3-4 year process.   It is very unlikely that FERC (or NERC for that matter) has the stomach to go through all of this, especially since FERC couldn’t be at all sure that the sausage that came out at the end would be any more to their liking than V5 is now.

II. If FERC approves V5 and doesn't order any changes (this is what NERC, EEI, and most of the other commenters asked for), then the implementation dates will kick in per the V5 implementation plan. See my companion post on the question of dates.

If FERC approves V5 but orders a compliance filing, they will  give NERC a certain amount of time to come back with a new version - which I believe will be called CIP Version 6.  Given the amount of work that will be required to draw up and ballot a new version, I'm thinking nine months would be a good time frame; however, I'm guessing that FERC is impatient, so I'll say six months here.

III. Version 6 will have a provision in the implementation plan a lot like what was in Version 5: It will say that, should Version 5 be approved but not implemented when V6 is approved, V5 will never come into effect.  This is why I am saying that the next version of CIP, that NERC entities have to comply with, will be V6 - so we'll go from V3 to V6.  How's that for progress?

IV. When NERC returns to FERC with V6, it is likely that FERC will approve V6 fairly quickly (since the V6 that NERC brings back should include everything that FERC asked for in the compliance filing, and nothing more).  At that point, the compliance timeline for V6 will kick in.

V. But here's another wrinkle: The V6 compliance timeline may not be the same as the one currently in V5.  That timeline says that High and Medium impact facilities have to comply two years after FERC's approval, while Lows have three years.  In their NOPR, FERC expressed deep skepticism about this approach, saying the time periods were too long.  

Of course, most comments FERC received said to leave the implementation timeline unchanged. But it is possible that at least the High/Medium compliance date will be moved forward; I'm guessing it might even come down to one year from two.  I believe / hope that the date for Lows will remain at three years, though.  Many conversations with NERC entities on this topic have convinced me that bringing the Lows into compliance will be a huge job, and even three years will be pushing it (one reason why FERC might treat Lows differently from High/Mediums is that, in theory, the latter have mostly had to comply with CIP Versions 1-3.  So there shouldn't be such a huge effort for them as for Lows, which will be total CIP virgins, so to speak).

Now you can go to the timeline post to see what I think the likely compliance dates are.


If you haven't signed up for the joint Honeywell / EnergySec webinar on CIP Version 5 on August 21 - "Covering your Assets in CIP Version 5" - I recommend you do it today!  Seats are going fast, and you might end up sitting behind a pole if you wait too long.  Remember, even if you can't make that date, you should still sign up, so you'll receive the link to the recording when it's available a couple days after the webinar.  You can sign up here.


[i] I must admit that after rereading the Federal Power Act Section 215 (which established the whole NERC/FERC relationship), I am no longer completely sure that FERC can't simply require changes in Version 5 itself.  However, were they to do this - and given that it will take at a minimum 6 months or more for changes to be made by NERC - to do this would jeopardize their stated (in the NOPR) purpose of having the industry avoid CIP Version 4.  They would have to do this by Sept. 1, 2013 and give NERC the bare minimum of six months to make the changes - both unlikely events, in my opinion.

Also, by approving V5 as is and requiring a compliance filing, FERC makes sure there is a new CIP version coming, even if NERC totally messes up and never completes the compliance filing.  FERC doesn't have that leverage otherwise.




Friday, April 26, 2013

Where Did I Go Wrong?


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

Many people involved with NERC CIP were very surprised when FERC issued their NOPR on April 18, saying they intend to approve CIP Version 5, and that Version 4 wouldn’t come into effect.  I was especially surprised since I had been quite vocal for a year (in fact, for 364 days), saying that NERC entities should prepare for Version 4 compliance on April 1, 2014, and put Version 5 preparation on the back burner until after V4 came into effect.
I am now quite focused on Version 5, as some of you have already seen; since I have been closely following V5 since its conception in 2010, I feel I have a lot of knowledge to contribute to that discussion.  However, I’m also not the kind of person to just turn my back on a mistake I may have made.  I do want to examine what I did wrong, so I can learn a lesson for the future.  And the best way I can learn about something is by writing about it – so here we are!
I don’t want to sound like John Kerry, but I was a strong proponent of the idea that Version 5 would be the next CIP version, up until I abruptly changed my opinion on April 19, 2012.  When FERC issued their NOPR for Version 4 in September 2011, I put out an open letter (I wasn’t blogging then) saying that I didn’t think FERC would ever approve V4, and that they were using V4 as a kind of weapon in reserve in case NERC balked at approving Version 5 (saying in effect, “You’d better get behind Version 5, since otherwise you’ll have V4 to comply with, then V5 a couple years later”).  And when FERC actually approved V4, my initial post simply affirmed that V4 wouldn’t come into effect and that V5 was still the next CIP version that NERC entities would have to plan for.
However, the next day I got an email from an astute CIP observer who said I should really rethink this position.  Order 761 (which was released at the end of the day of FERC’s meeting approving V4, just like the NOPR for V5 was released at the end of the day on April 18) made it pretty clear that FERC wasn’t happy with Version 5 as it stood at the time.  This meant that, even when NERC finally approved V5, FERC would come back and require changes – which would very likely push the approval date for V5 beyond the compliance date for V4 (4/1/2014), so V4 would come into effect.
From April 20, 2012 through April 18, 2013, I firmly believed that Version 4 would be the next CIP version, and I made that point loudly on a number of occasions.  If I made it too loudly and offended anybody that way, I certainly apologize.  Ironically, the industry was clearly coming around to that idea (and I don’t pretend I was anywhere near the prime mover in that) in the last few months (witness the V4 transition document that came out from NERC a week before the NOPR, as well as the 570 signups we had for the Honeywell/EnergySec webinar on Version 4 in March) – so there was general surprise when FERC issued their NOPR.
I was obviously wrong, then.  Why did this happen?  I have thought about it a lot, and I see two main reasons:
  1. I didn’t read FERC correctly.  I had the perception that they were getting quite exasperated with NERC, especially for the length of time it was taking to approve V5 and for the fact that V5 clearly didn’t include everything they wanted included (as stated in Order 761 especially, but also Order 706).  I also believed that they would actually prefer that Version 4 go into effect before V5, since it had greater asset coverage (mainly in blackstart plants and substations).  However, the tone of their comments released at their meeting where they issued the V5 NOPR made it clear they were very concerned about the effect on the industry of having to comply with Version 4 and later with Version 5.  They also made it clear they weren’t going to let this happen.
  2. I made a technical mistake.  The big reason why I had switched positions on V4 after reading Order 761 was that it had laid out several mandates (not formally directives) for V5, which it was clear would never be approved by the NERC membership on their own.  Those mandates were never included in Version 5 as it was submitted to FERC this January, and in the NOPR FERC made it pretty clear they weren’t going to approve V5 without them.  So at some point after the V5 comment period (which will start once the NOPR is published in the Federal Register and go on for 60 days), FERC will require NERC to make these changes.  NERC will then have to reconvene the SDT (I believe), they will make the changes, the membership will have to vote at least once, the Board will have to approve the changes, FERC will have to mull them over to decide whether they’re what they wanted, then finally they’ll approve the new version.  It is still very unlikely this will all occur before April 1, 2014.            
However, there are two mechanisms by which FERC can make this happen.  One is to remand (i.e. reject) CIP Version 5.  This is a total rejection – it can’t be partial.  NERC would then presumably have to draw up a SAR, constitute a new SDT, spend a year or so drawing up an entirely new CIP Version 6, go through a few ballots before it’s approved, etc. – a 2-4 year process.   It is very unlikely that FERC (or NERC for that matter) has the stomach to go through all of this, especially since FERC couldn’t be at all sure that the sausage that came out at the end would be any more to their liking than V5 is now.
The other mechanism is for FERC to approve Version 5, but at the same time order NERC to submit a “compliance filing” – a new version based on V5 that would correct what they want corrected.  This is exactly the approach they took when they approved CIP Version 2.  They mandated a compliance filing to include escorted access procedures in CIP-006, and gave NERC 90 days to file it.  NERC did that, and it became Version 3.[i][i] 
Hopefully, FERC will give NERC more than 90 days this time, since the changes they’re likely to require are very fundamental and far-reaching.  But it really doesn’t matter as far as Version 4 is concerned.  The Version 5 implementation plan says that V4 won’t come into effect if V5 is approved before 4/1/2014.  In this mechanism, FERC will approve V5 before that date (and the commissioners said that explicitly in their meeting on April 18), but Version 5 will never come into effect – the changed version, called Version 6, will be what becomes enforceable.  That will very likely not be delivered to FERC (let alone approved by them) before 4/1/2014.
To sum up this second mistake, I didn't understand that FERC could approve V5, yet at the same time require changes in a new version - so that V5 would be approved (and "stop the clock" on V4) but the changed version (which would come into effect) would be V6.
These were my two main mistakes.  I promise not to make either of these  again.  Instead, I’ll find some brand new mistakes to make!  This gives me something to look forward to.



[i] This is also what FERC did with CIP Version 1.  They approved it in Order 706 in January 2008, but then required a whole raft of changes in a new version.  The SDT that was put together in the fall of 2008 to address Order 706 was the same SDT whose work concluded at the end of 2012, when V5 was approved by the NERC membership.  They ran into a few detours on the way, which is how they ended up drafting Versions 2, 3 and 4 before V5.  In Order 706, FERC didn’t set a date by which the new version should be delivered; you can bet they won’t omit a due date when they order the changes in V5!