The News from Atlanta, Phoenix and Washington

The week of January 20-24 was a significant one in the world of CIP Version 5, with NERC meetings in Atlanta and Phoenix and FERC agreeing to a rehearing on Order 791.  This post isn’t meant to be a synopsis of what went on, but rather what I personally see as some of the most significant aspects of those events.

NERC “Technical Meetings” on CIP Version 5

NERC held two long-anticipated meetings on CIP Version 5, in Atlanta on Tuesday and Phoenix on Thursday.  I think some people may have been disappointed when they realized the purpose of these meetings wasn’t to explain v5, but to gather input for the new Standards Drafting Team (members yet to be announced) that will address FERC’s mandates in Order 791.  But they were nevertheless both quite interesting meetings, which I listened to while enjoying the wonderful January weather here in Chicago.

In order 791, FERC ordered NERC to do the following five things.  For three of these, they gave a due date of one year from the effective date of v5 (which is Feb. 3, so the due date is Feb. 3, 2015).  However, NERC speakers made it clear that they want to get all of these done in a year; the industry has been living with uncertainty for so long that it needs to come to an end as soon as possible.  Here are the five things:

1. Remove “Identify, Assess and Correct” from the 17 requirements in CIP v5 that include that language[i].  There was a good discussion of this at both meetings.  The upshot is that this isn’t a disaster for the industry, because of probably the most important development in NERC compliance, the Reliability Assurance Initiative.  The RAI will essentially do what IAC was meant to do, but will do it completely outside the standards – in the auditing process.  Audits themselves will focus more on the robustness of the compliance program at the entity, and not so much on whether or not they took 25 hours rather than 24 to remove access for John Jones when he was terminated for cause last May.  And RAI will[ii] apply to all the NERC standards, not just the CIPs.  You can read a lot more on RAI at the NERC web site (on the site, RAI isn’t hidden as well as most of the CIP information is, so you can actually find useful information with a simple search.  I think this is the first example in human history of someone getting useful information through a search on the NERC site).

2. Develop specific requirements for Low impact BES Cyber Assets.  There was, as you might expect, a lot of discussion about this.  A couple points I found interesting were a) that Low impact assets like substations are often shared by multiple entities, making the personnel requirements of CIP-004-5 much more tricky (and requiring more guidance from NERC); and b) that, since physical security costs will probably be the biggest component of spending for compliance, it would be best if only certain areas of the facility (i.e. those with cyber assets) had to be protected, not the whole asset.

The Low requirements will probably be the most contentiously debated at the SDT meetings.  This is mainly because of their impact: there are so many Lows that even what may seem a minor requirement will become major just because of the sheer number of facilities it will affect.  I recommend that these requirements be put into a separate v5 standard, perhaps CIP-012-5.  This will allow the SDT to set a compliance date for this one standard that is later than that for the others, which would be completely justified (for more on compliance dates, see below). 

3. FERC directed NERC to “..conduct a survey of Cyber Assets that are included or excluded under the new BES Cyber Asset definition during the CIP version 5 Standards implementation periods.”[iii]  What this is specifically referring to is the “within 15 minutes” phrase in the definition of BES Cyber Asset.  FERC expressed doubts about this in the NOPR, and there was a lot of robust defense of the phrase in the comments received by FERC.  The problem is that FERC’s directive quoted above might be seen as requiring entities to survey all of their cyber assets at High, Medium and Low impact facilities.  This would be a huge deal (and is why CIP-002-5 specifically forbids requiring an inventory at Lows); this was forcefully pointed out by a woman from a large IOU (I believe) at the Atlanta meeting.[iv]  However, NERC speakers assured the audience that they have no intention of requiring such a drastic step; they will use sampling or some other method to reduce the effort required.

One thing that did become clear at the Phoenix meeting was that people have a lot of questions about the definition of BES Cyber Asset, and how 15 minutes fits into it.  This is clearly an area where NERC needs to provide guidance.[v]

4. Protect “transient devices”.  This section of Order 791 (pp. 74ff) is actually headed “30-day Exemption”, since NERC excluded from the definition of BES Cyber Asset those devices used within an ESP for less than 30 days.  In the NOPR, FERC questioned why this exemption was there, but they were persuaded by the comments they received that it should remain.  However, they did order NERC to develop or modify a CIP standard to provide some sort of requirements to protect these devices.  It seems clear to me that these requirements should also be put in a separate standard (e.g. CIP-013) rather than be modifications to one of the other v5 standards.  Again, the reason I say this is it will allow the SDT to set a different, presumably later, compliance date for this new and currently unknown standard than for the other v5 standards (which are all spelled out now, and won’t change except for removal of IAC).[vi]

The discussion in Phoenix on this topic was quite good, and convinced me that this will not be an easy standard to write, either.  One big obstacle is the wide variety of transient devices – thumb drives, laptops, flash memory cards, etc.  So it would seem sensible to categorize these and have separate requirements for each category.  But as someone in Phoenix pointed out, this runs into the problem that the devices themselves are always changing and taking on characteristics of other categories.  As I said, not an easy standard to write.

5. Develop new or modified standards that implement “appropriate and reasonable controls to protect the nonprogrammable aspects of communication networks” – i.e. the physical infrastructure of a network.  This includes cabling, jacks, etc.  There was of course a lot of discussion about this, but keep in mind that FERC’s use of the term “communication networks” does not include:

1. Encryption or other means to protect data in motion.  These topics fall under what FERC calls “communications security” – one of the three issues that FERC raised in the NOPR but declined to issue specific directives on in Order 791 (page 115ff).    The three issues will be addressed in a technical conference to be convened by FERC within 180 days of Order 791 (I’ve heard March is a likely month for this).

2. Communications networks outside of the ESP.  There was much discussion in both meetings about the infeasibility of protecting networks of communications providers like Verizon; NERC entities clearly have no control over the security of these networks.  However, I believe that, by the very fact that FERC is stating that communications networks should be protected within the CIP standards (and not with a new family of standards), they are saying that inter-ESP networks are out of scope.  CIP Version 5 is for protection of BES Cyber Systems, and these reside within ESP’s.  I don’t think it will be hard for the SDT to make clear in the new standard – and once again, I suggest this be a new standard like CIP-014, so that a separate implementation date can apply – that “communications networks” refers to intra-ESP networks only.

I further note that FERC directs that this topic should also be addressed in the technical conference.

FERC Grants a Rehearing for Order 791

You are forgiven if you didn’t know that two petitions had been filed with FERC, requesting a rehearing to clarify certain aspects of Order 791; I certainly didn’t know it either.  But they were, and on Jan. 22 FERC issued an “Order Granting Hearing for Further Consideration”.[vii]

The two requests were each from a pair of trade associations; one from EEI and EPSA, the other from NRECA and APPA.    To download these, you have to go to FERC Online (and you need a login for that) and search for documents on docket RM13-5.  Or else you can email me at tom.alrich@honeywell.com for the documents (I imagine they’re also available on the four associations’ web sites). 

To address the EEI/EPSA petition first, it requested a rehearing to address five issues.  I’ll discuss each, along with my opinion on them.

1. The survey regarding 15 minutes shouldn’t require an inventory of cyber assets.  I have discussed this above, and believe this won’t really be a problem, since I don’t think FERC was really requiring that inventory in the first place.  But I can certainly understand why EEI/EPSA would want to have FERC clarify this now.

2. FERC should confirm that April 1, 2016 is the compliance date for Medium/High impact assets (this had to do with the difference between the Order 791 date, Nov. 22, and the effective date of Version 5, which is Feb. 3.  NERC’s v5 implementation plan refers to the former, while Order 791 refers to the latter).  Since I don’t think there is any real dispute about this, it is another case where EEI and EPSA are trying to remove all possible uncertainty – certainly a good thing.

3. EEI and EPSA claim that FERC should have pushed back the implementation date for the Low assets beyond the roughly three years and a quarter shown in the v5 implementation plan (i.e. they want the date pushed back beyond April 1, 2017).  Their reasoning for this is that, by directing NERC to develop new requirements applicable to Lows - which will be delivered to FERC about a year from now – they are making it very hard, if not impossible, for entities to be compliant by the date in the implementation plan.  They point out that that date was agreed on by the NERC ballot body on the assumption that there would be only one requirement, CIP-003-5 R2, which applied to Lows.  Now that there will be other requirements, and that they won’t even be known for close to a year, the situation is very different.

I believe this question is easily answered: As I said above, NERC should develop a new standard for Low impacts; they can then set a different implementation date for this standard than for the rest of v5.[viii]  The implementation date for Lows in the v5 plan applies just to CIP-003-5 R2.  So, assuming the new Low requirements are put into a new standard with a later implementation date, entities with Lows will have to comply with CIP-003-5 R2 on April 1, 2017, and with the new Low standard at some date after that.

Again, even though I don’t think this is really a problem, I do commend EEI and EPSA for asking FERC to clarify it – just to be sure.

4. The FERC-led technical conference should take place within 90 days of the issuance of the Final Rule (i.e. Order 791).  The reasoning for this request is solid: The new SDT has to have the revised standards, including the new requirements for communication networks, to FERC by February, 2015.  Since the conference will address communication networks, if it is held this May (i.e. about 180 days after Nov. 22) and if new insights on this question are developed in the conference, it will be difficult for the SDT to incorporate them into the new communications requirements in time to meet FERC’s deadline.

This is certainly a good point, but I don’t think FERC will give EEI and EPSA what they want in this case.  90 days from Nov. 22 is Feb. 22, i.e. less than a month from now.  I don’t think they could get a conference together that quickly.  However, this makes it all the more likely that the conference will be in March, as I had heard it would be.

5. FERC should clarify that the new requirements for communications networks won’t apply to network components outside of an entity’s control.  As I said above, I think this can be pretty easily dealt with by the SDT, but again it’s a good idea to get FERC to confirm it.

NRECA and APPA’s petition just presents two issues:

1. Their first issue is an important one, although I don’t see it as the big problem that NRECA and APPA do.  They say that, by rejecting the “Identify, Assess and Correct” language in 17 requirements of v5, but giving NERC the option of either removing it altogether or just modifying it, they are leaving the industry in a very uncertain position as they start preparing for compliance on April 1, 2016. 

As with most of EEI/EPSA’s issues, I commend NRECA and APPA for asking FERC to clarify this.  However, I don’t think it’s FERC’s job to do that, in this case[ix]; it’s NERC’s job.  As I said in end note 1 below, NERC staff members made it clear this week that they aren’t even considering trying to modify the IAC language; and it’s hard to see how any modification would do that, since FERC doesn’t think the IAC idea should even be addressed in standards at all.   But someone from NERC needs to state that for the record.

2. The second issue has to do with FERC’s estimates of the regulatory burden of complying with the CIP v5 standards.  I totally agree that FERC’s estimates were ridiculously low (although NRECA and APPA don’t phrase it this way, of course.  This is why I could never be a lawyer).  I don’t think FERC will change their estimates, though.  And even if they did, it wouldn’t have any effect; they’re not going to go back now and gut the standards to make the regulatory burden less.  It’s certainly worth at least pointing out, though, so I commend the two organizations for doing so.

It will of course be interesting to see what FERC says at the rehearing (which I don’t believe is scheduled yet).

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

---

[i] FERC actually gave NERC the option of modifying the language to meet their objections.  However, it was clear in the meetings that NERC doesn’t intend at all to do that – and indeed, I see no good way the language could be modified.  FERC objected to trying to do IAC in the language of the standards at all, so it’s hard to see how you could change that language and satisfy them.

[ii] I probably don’t even need to use the future tense here.  I was quite surprised when I attended MRO’s compliance meeting in December where they explained their new compliance enforcement program – and I realized halfway through the presentations that it was RAI, although they didn’t call it that.  They have not only piloted RAI (at least one other region hasn’t even done that yet), but they’ve pronounced the pilot a success and they’re moving into production (this is something like a clinical trial where it becomes clear halfway through the trial that the medicine being tested is tremendously effective.  Ethics require that the trial be stopped and all subjects be given the medicine).  I’m not quite sure they were allowed to do this, but it seems to me the leaders of MRO would much rather beg forgiveness than permission.  I’ve always liked that attitude.

[iii] FERC Order 791, page 73.

[iv] She said her organization would have to suspend work on v5 compliance for several months and put everybody to work on the survey response, if they had to assess every cyber asset.

[v] Of course, I’ve just done three long posts on the need to have guidance on asset identification in CIP-002-5 R1.  And I’ve pointed out previously (actually, in the context of CIP Version 4, although the exact same argument can be used in v5) the need for guidance on the bright-line criteria in Attachment 1.  There’s a log of guidance needed on CIP-002-5!

[vi] My suggestion differs from another suggestion at the Atlanta meeting: that transient devices be just defined as another type of cyber asset, and inserted in the requirements that would make sense to apply to these devices.  Again, it seems to me it would be better to have a separate standard that could be given a different implementation date from the rest of v5.

[vii] Here is the entire text of the Order:

Rehearing has been timely requested of the Commission's order issued on November 22, 2013, in this proceeding.  Version 5 Critical Infrastructure Protection Reliability Standards, 145 FERC ¶ 61,160 (2013).  In the absence of Commission action within 30 days from the date the rehearing request was filed, the request for rehearing (and any timely requests for rehearing filed subsequently) would be deemed denied.  18 C.F.R. § 385.713 (2013).

In order to afford additional time for consideration of the matters raised or to be raised, rehearing of the Commission's order is hereby granted for the limited purpose of further consideration, and timely-filed rehearing requests will not be deemed denied by operation of law.  Rehearing requests of the above-cited order filed in this proceeding will be addressed in a future order.  As provided in 18 C.F.R. § 385.713(d), no answers to the rehearing requests will be entertained. 

I defy anybody to show me where in these two paragraphs it says that the request has actually been granted; if it weren’t for the title, I’d swear this text says it has been denied, or at least not approved.  I guess this is why lawyers seem to exist on a different plane than the rest of us – I’m sure any lawyer would take one look at this and it would be obvious to him/her that the request was granted.

[viii] Technically, of course, we’re talking about CIP Version 6, not v5.  As I said in my post on Order 791, as well as in this much earlier post, FERC doesn’t have the option of approving a standard and then ordering changes in it.  They can only completely remand the standard or completely approve it.  When they order NERC to develop modifications, those modifications really have to be in a new version of the standards, which I believe will be called CIP Version 6 (this happened previously with CIP Versions 2 and 3).  So in one year, the new SDT will present CIP v6 to FERC, which will consist of v5 plus the changes FERC ordered.  I also believe a) that v6 will supersede v5, like v5 superseded v4; and b) that, for standards CIP-002-6 through CIP-011-6 (i.e. the standards that currently exist in v5), the implementation plan will be modified so that entities will have to comply with v6 by approximately the same dates as they would have for v5.  You can read the chilling details of this in the Order 791 post.

[ix] After giving NERC two options in Order 791, FERC isn’t going to turn around and say they now only have one option.

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

Before I start, I’ll say that you should definitely read the first two posts in this series (Part 1 and Part 2) before you read this one.  I won’t say this will be unintelligible if you don’t, but you will understand a lot more if you do.

Some Preliminaries

In this, the exciting conclusion to my series of posts on identifying assets in CIP-002-5 R1, I will present my own interpretation of the best methodology for accomplishing this task.  Before I do that, I’ll summarize the premises of this exercise, as described in the previous posts (but I’ll admit I’ve refined some of this, so it doesn’t match exactly with what I said before.  As Emerson said, “Consistency is the hobgoblin of little minds”):

1. I contend that, because of the inconsistencies in the wording of CIP-002-5 R1 and the related Attachment 1, there can be no interpretation (i.e. no methodology for asset identification) that conforms to all of the words in that requirement. 
2. I have talked with a number of people (entities and auditors) about this, and I can confirm there is a variety of interpretations out there.
3. This is not a good situation, of course.  Entities need to conduct their CIP v5 asset identification, confident that the methodology they follow is the one that the auditor will refer to when they get their first CIP v5 audit.  And if the entity doesn’t follow the “correct” method to identify assets in CIP-002-5, they will be way off base in complying with the other v5 standards as well.
4. I had hoped that either a) FERC would order NERC to fix the wording problems as they make the other revisions mandated in Order 791, or b) NERC would decide on their own that the wording needs to be fixed, and add this to the set of tasks to be accomplished by the new Standards Drafting Team.  However, neither of these events has come to pass.
5. This leaves me with Plan B: NERC (working with the regions) needs to determine and publish a consistent interpretation of CIP-002-5 R1.  This won’t agree with every word in the requirement (and Attachment 1), since that is impossible.  But if NERC gives their blessing to one methodology, and the auditors audit based on it, we just may come out of this OK.  If an entity were to challenge this in court, of course, NERC’s interpretation won’t mean anything – only the words of the requirement will.  But short of that, it would mean a lot.
6. Over the past couple of months, I have had extensive email discussions with six or seven people involved with CIP v5 compliance, including a regional CIP auditor, on this question.  In the course of these discussions, I have been able to identify two different methodologies – one mine, one the auditor’s – for CIP-002-5 R1 compliance.  They are both consistent, although neither conforms to all the wording in the requirement and Attachment 1.  I won’t say there aren’t other consistent methodologies that could be developed, and I would very much like to hear if someone has one.
7. I not surprisingly feel my methodology is superior to the auditor’s, and I will outline my reasons for feeling that way in this post.  However, even if NERC were to choose the auditor’s interpretation, or another one, it would still be much better than the current every-man/woman-for-him/herself situation, in which ultimately each entity needs to decide how they’re going to comply with CIP-002-5 R1 (and each auditor, or at least region, needs to decide how they’re going to audit it).  There will be a lot of bad consequences, if nothing is done about this problem.

One benefit of my email discussions with the auditor was that I was able to clarify what really were the important differences between his position and mine, and which differences weren’t really differences at all.  Therefore, I’ve identified four stipulations that I believe should be made (by NERC), regardless of the methodology that is ultimately adopted.  I discussed three of these in Part 1, and now have decided there should be a fourth.  Refer to Part 1 for the full discussion of the first three.

1. The term “Facility” should be re-interpreted to mean “a Facility containing one or more of the six types of assets listed in CIP-002-5 R1”.  That is, a Facility should be a “container” for one or more assets.  If you want to know why I’m suggesting this, see the fourth stipulation below.
2. It should be made clear that the preferred approach to identifying Medium and High impact BES Cyber Systems is to combine the “top down” and “bottom up” approaches.  I discussed these approaches in mind-numbing detail in Part 1, as well as two previous posts referred to in the Part 1 discussion.
3. It should be made clear whether what I’m calling “segregated cyber assets” in Part 1 are either Low impact or out of scope entirely for CIP version 5.  I think the wording of CIP-002-5 R1 slightly favors the idea that they should be Lows, but I’m willing to go with whatever NERC says.  However, they need to say something, rather than requiring all entities to make this decision for themselves.
4. This is the stipulation I have added to the three I listed in Part 1:  I think NERC needs to make it clear that, with one exception, all of the BES Cyber Systems associated with a High or Medium impact asset should take that impact level.  The exception is in the case of Medium impact assets meeting Criteria 2.1 or 2.2.  Those two criteria state that BCS that don’t meet a certain threshold are explicitly not Medium impact, but they don’t say what they are.  If NERC decides they are Low impact, then this would be an exception to this stipulation; but it should be the only one.

Why do I say there should be just one level of BCS associated with a High or Medium asset?  Because there are a number of people who feel differently, saying it is somehow up to the entity to decide the impact level of the BCS at an asset.  In 90% of the cases, I think they’re saying this because of the lack of a clear term for a “container” of assets, as I have discussed in point 1 above.  If there isn’t such a term, then you can get confused by pointing to cases where one “asset” houses another – e.g. a transmission substation that contains an SPS system.  The SPS is itself one of the six asset types listed in R1, and of course the substation is as well.

So if the substation is Low impact but the SPS itself is Medium due to meeting Criterion 2.9, there will be two types of BES Cyber Systems at the one substation Facility: the Low BCS belonging to the substation asset and the Medium BCS that are part of the SPS.  If we make it clear that the substation Facility contains two assets – the Low impact substation and the Medium impact SPS – then we can have a rule that states that all of the BCS associated with an asset are one impact level (of course with the exception of Criteria 2.1 and 2.2.  And now, I state Alrich’s Law: There can be no statement made about anything having to do with NERC compliance that doesn’t have an exception.  I believe there are no exceptions to this law).

Why am I so concerned about this?  Because I know some entities seem tempted to believe they can classify BES Cyber Systems independent of the Attachment 1 criteria.  That is, they think they can say, “Even though this BCS is part of a Medium impact substation, it really doesn’t have that much impact, so I’ll call it a Low.”  I believe that is something that isn’t allowed in CIP v5, but I’ll admit the wording of Attachment 1 could well lead someone to believe this was possible.  I think there could be lots of problems if it isn’t made clear that, while there can be multiple levels of asset located at one Facility, there can be only one level of BCS associated with a particular asset (except for Criteria 2.1 and 2.2, of course).

And Now, Tom’s Methodology

With these stipulations out of the way, let’s look at my methodology for CIP-002-5 R1 compliance.  There is one big difference between my methodology and the auditor’s: In mine, you classify assets first, then identify the BES Cyber Systems associated with them.  In the auditor’s, you identify and classify BES Cyber Systems without ever actually classifying the assets.  

The main reason I prefer my methodology that it is essentially the one that entities are used to from complying with CIP versions 1-4 (yes, I know v4 never came into effect, but a lot of entities went fairly far down the road to v4 compliance).  In v1-4, you did two things.  First, you identified your Critical Assets (i.e. you classified your assets into two levels: critical and not critical).  Then, you identified the Critical Cyber Assets that were “essential to the operation of” those Critical Assets. 

I’m saying, let’s do the same thing for CIP v5.  Here are the entire details of my methodology:

1. First, an entity needs to classify its assets (defined as the six types listed in R1) into High, Medium and Low impact, based on the Attachment 1 bright line criteria. 
2. Second, the entity needs to identify BES Cyber Systems either at or associated with the High and Medium impact assets (and see the discussion in Part 2 about “at” and “associated with”).  As I've already mentioned, I recommend this be carried out by combining the top-down and bottom-up approaches.
3. Finally, the entity needs to identify Low impact assets, without having to identify BES Cyber Assets or BES Cyber Systems at those assets.  And why isn’t doesn't the entity need to identify Low impact BCA or BCS?  Because CIP-003-5 R2, the single requirement in v5 that applies to Lows, says absolutely nothing about BES Cyber Systems.  The four policies in that requirement need to be applied at the asset level, not the cyber asset level.  So there is no reason to even discuss the term Low impact BES Cyber System.[i]

And there you go: I’ve just given you my entire methodology.  But that was the easy part; now I have to convince you that this is a good one.  This brings me to the second reason why I prefer my methodology: I have yet to talk to any NERC entity (and I have been talking with a lot lately, and will be talking with a lot more in the near future) that isn’t using a methodology like mine.  I won’t say there aren’t a few out there who are using something like the auditor’s methodology; and I certainly won’t deny that his methodology may be the runaway favorite in the auditor community.  But I will say that I’ve had in-depth discussions of CIP v5 methodology with over ten entities, and every one of them has started by saying something like, “Well, we are first looking at which of our assets are going to be High, Medium or Low.”  Nobody has said, “We’re starting to identify our BES Cyber Systems, so we can then classify each one using Attachment 1.” 

And when you think about it, how could it be otherwise?  After five years of focusing relentlessly on what assets would be in or out of scope for CIP, and only then looking at what cyber assets are essential to them, does NERC really think the whole industry is going to do a huge shift and think almost entirely in terms of BES Cyber Systems, regardless of where they might happen to be deployed?

Now, I’ll concede right now that the language of Attachment 1 almost requires an interpretation like the auditor’s.  It is quite straightforward in saying that it is all about classifying BES Cyber Systems.  It clearly is written assuming the entity has already gone through all of its cyber assets and identified its BCS – which itself is very interesting, given that nowhere in R1 does it tell you to first identify BCS.  It seems the entity has to figure out for themselves - by the fact that R1 and Attachment 1 just talk about how BCS are classified - that they have to have already identified them all before they even start into Attachment 1.  Even Section 3 of Attachment 1, which deals with Low impacts, is written entirely in terms of BCS, saying simply that Low BCS are those that aren't Medium or High impact.  The entity clearly has to start out Attachment 1 with a complete list of its BCS, at least if they’re going to follow the language literally.

I do want to point something else out: Most people are used to dealing with the Attachment 1 that was included in CIP-002-4 (again, even though v4 never came into effect, many entities spent a lot of time trying to comply with it).  The wording of the criteria in that Attachment 1 is in some cases exactly the same as in Attachment 1 in v5.  Yet the v4 version makes clear that it is for identification of Critical Assets (the "big iron"), not Critical Cyber Assets ("little iron").  When those people turn to Attachment 1 in v5, they will have to make a complete shift to using those criteria to identify BES Cyber Systems (little iron), not the "assets" (big iron).  I haven't talked to any entity that has actually made this shift. And frankly, I see no reason why they should have to, other than confusion in the wording of CIP-002-5.

When you move from Attachment 1 to CIP-002-5 R1 itself, the wording is much more nuanced, and seems to favor my methodology.  It starts out by requiring the Responsible Entity to “implement a process that considers each of the following assets for purposes of parts 1.1 through 1.3”, followed by the list of six asset types in scope.  This is followed by R1.1 and R1.2, which instruct the user to identify High or Medium impact BCS "at" (in R1.1) or "associated with" (in R1.2) each asset, by going to Attachment 1.   This sounds like much more of an asset focus to me.

Now, I will concede that R1.1 and R1.2 aren’t strictly asking you to classify the assets themselves, but only the BCS located at them; so they don't clearly support my interpretation.  But when you get to R1.3, the instructions are much different.  There, you are instructed to identify each asset that “contains a low impact BES Cyber System” by again going to Attachment 1.  So R1.3 is explicitly asking you to identify assets, not BCS.

Of course, R1.3 doesn't call the asset in question a Low impact asset – that would be too much of a step away from maintaining the fiction that the whole purpose of CIP-002-5 R1 is to classify BCS.  But at the same time, it obviously can’t tell you to identify Low BCS (the way R1.1 and R1.2 did for High and Medium BCS), since it says in the next sentence that an inventory of Low BCS isn't required. 

Instead, R1.3 tells you to identify assets that “contain” low BCS, according to Section 3 of Attachment 1.  So let’s go there and see if we can figure out what’s going on.  There, we see that Low impact BCS are “BES Cyber Systems not included in Sections 1 or 2 above that are associated with any of the following assets”, followed by the same list of six asset types shown in R1.  What are we to conclude from this?  It seems clear that we have to start Attachment 1 with a complete list of BCS, then subtract out the High and Medium BCS to come up with our list of Lows.  We then use this list to identify the assets that contain Low BCS.  But how can we do this if a list of Low impact BCS isn’t required?

And this is where the auditor’s interpretation breaks down.  He says he will be comfortable if the entity simply asserts that an asset contains one or more Low BCS, without specifically identifying it.  However, I know he won’t necessarily just roll over if the entity asserts that an asset – that contains control systems – doesn’t contain any Low BCS.  He will ask the entity about systems like DCS (at a generating station), protective relays (at a substation), etc.  Has the entity really determined that none of these should be identified as BCS at/associated with the asset in question?  I certainly don’t begrudge the fact that the auditor has to dance around like this – essentially saying that, despite the literal meaning of the wording in Attachment 1, his auditing approach won’t require a pre-existing list of BCS.  It just goes back to what I was saying: there is no consistent methodology for CIP-002-5 R1 compliance (and the auditor's methodology is consistent) that won’t violate at least some of the wording of the requirement (including Attachment 1).

But let’s get back to what we were doing: trying to figure out how we comply with R1.3 and identify assets that contain Low impact BCS.  And let’s assume that we don’t have a pre-existing list of all BCS.  This means we have to do some sort of dance like the auditor is suggesting, where we look at each asset and try to take a good guess as to whether or not it contains a Low BCS.  Which assets do we do that dance for?  It has to be all of our assets.  Since, following the literal wording of CIP-002-5 R1 so far, we haven’t identified any assets that are High or Medium, we have to consider any asset - High, Medium or Low - as one that might potentially contain a Low BCS.  Indeed, it is quite possible that assets that we would identify – using my methodology – as High or Medium impact will also be “assets that contain a Low impact BCS”; this would happen if they contain what I'm calling "segregated cyber assets" above and in the previous post.  This means that those assets will have to comply with CIP-003-5 R2, along with all of the other v5 requirements that apply to Mediums.[ii]

As you can see, we have to do a lot of work – and probably go through a lot of hand-wringing and hair-pulling – to comply with the literal wording of R1.3 and identify assets containing Low BCS.  And why do we have to do that?  As I’ve already said, the one v5 requirement that applies to Lows says nothing about BCS; so there is absolutely no compliance need to identify Low BCS.  Wouldn’t it be a lot easier if we just dropped the fiction that, in order to identify Low impact assets, we need to identify Low BCS?  This is why my methodology simply requires that we identify Low impact assets, not the BCS that may or may not be in them.[iii]

Of course, to identify Low impact assets, we have to first identify High and Medium impact assets (since there are no criteria that tell you what a Low asset is).  So my methodology starts with identifying High and Medium impact assets using the criteria in Sections 1 and 2 of Attachment 1.[iv]  The Lows are all BES assets that aren’t High or Medium impact.[v]  The entity just has to identify BCS at or associated with the High and Medium impact assets, not with the Low impact assets.

I rest my case.  To summarize:

1. I believe the auditor’s CIP-002-5 R1 methodology (which I’ll admit is closer to the actual wording of the requirement and especially Attachment 1) will impose a big, totally unneeded paperwork burden on owners of Low assets.  They will struggle to show they have identified every asset that contains a Low BCS, when what’s really required for compliance is simply identifying Low assets.[vi]
2. As I said in Part 2, there is a possibility that an auditor, who interprets CIP-002-5 R1 according to my auditor friend’s methodology, will end up requiring an entity to have an inventory of cyber assets associated with at least some Low impact assets - if they want to be very hard-nosed about having the entity prove they don’t have BCS at those assets.  The literal wording of Attachment 1 would back the auditor up in making this demand.
3. Probably most importantly, my unscientific polling shows that the overwhelming majority of entities subject to CIP v5 are following “my” methodology, simply because it follows very naturally from what they are used to doing for compliance with CIP versions 1-4.  Is it really worth it to force them to use my auditor friend’s approach, given that there is absolutely no compliance or security reason to focus on classifying High, Medium and Low impact BCS, rather than High, Medium and Low impact assets (and the BCS that support the High and Medium ones)?[vii]
4. However, there is something worse than having NERC not adopt my methodology; it’s having them not adopt any methodology at all, even the auditor’s.  I see this as a great recipe for confusion, ill-will and disputed fines in the years ahead.

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

---

[i] Of course, FERC did order more specific requirements for Lows, and we won’t know what those will be until the new SDT meets and draws them up.  However, I and most others think it’s highly unlikely the new SDT will develop requirements that apply to particular Low impact cyber assets – whether BES Cyber Systems or not.  And FERC said in Order 791 that they don’t expect NERC to develop this type of requirement.

[ii] You might point out that it really isn’t the end of the world if Medium and High impact assets also have to comply with CIP-003-5 R2, the one Low requirement, since anything that an entity has to do in that requirement is surely already included in the many requirements with which High and Medium impact assets have to comply.  But there will certainly be a paperwork burden involved in doing this, which is of course completely meaningless from the point of view of cyber security (remember that?  CIP was supposed to have something to do with cyber security, if I recall correctly); and there will be a compliance risk if the entity misses some step in the paperwork.  I’m sure it wasn’t the intent of the SDT to have Mediums and Highs also have to be Lows, but this is the direct effect of the current wording.

[iii] Now that I think of it, this question is similar to the famous Schrodinger’s Cat paradox in quantum physics.  There, the poor cat, enclosed in an opaque box with a poison that may or may not have been released, is literally dead and alive at the same time until the box is opened and an observation is made - then it is actually either dead or alive.  In our case, the Low impact BCS might or might not exist at a Low impact asset.  But, unlike in the case of the cat, it’s not a question we even need to be asking, since as I said Low impact BCS have no role whatsoever in CIP v5 – so no observation ever needs to be made to determine whether they're there or not.

[iv] We of course have to ignore the language in those two sections that says we’re really looking for BES Cyber Systems “used by and located at” the High criteria or “associated with” the Medium criteria.  We’re really looking at the criteria themselves, which specify assets, not BCS.  As I’ve said, in order to come up with any consistent methodology for CIP-002-5 R1 compliance, you have to decide which wording you’ll ignore.  This is some of the wording I choose to ignore.

[v] There is a complication in my methodology: It doesn’t allow for any BES assets to be other than High, Medium or Low impact.  The auditor’s methodology, since it follows the wording of R1.3 about identifying assets that contain Low impact BCS, leaves open the possibility – whether or not it was intended by the SDT – that some BES assets won’t be High, Medium or Low impact, but will be nothing at all.  I regard this as a small price to pay for the fact that my methodology will greatly simplify the paperwork burden by doing away with the concept of Low BCS altogether.  But if you feel strongly that there should be BES assets that aren’t High, Medium or Low impact, this won’t bother you, and you’ll be happy to deal with the additional paperwork generated by the auditor’s methodology.

However, one could make a case that BES assets that don’t have any process control systems shouldn’t even be Lows – after all, CIP is to protect control systems, right?   If NERC wanted to adopt my methodology, they could easily say that assets without control systems aren’t High, Medium or Low impact.  Or they could just say that Low assets without control systems only have to comply with CIP-003-5 R2.1 (cyber security awareness, which is important for all employees of any organization nowadays) and R2.2 (physical security controls), but not with R2.3 and R2.4, which specifically apply to facilities with control systems.

[vi] When I was first thinking about this post, I thought there might be another big difference between the two approaches: one might result in many more BCS being identified than the other.  However, I don’t believe this is the case now (although if someone thinks it would be, I’d like to know why - I could be wrong about this).  In theory, there shouldn’t be any difference in results between the two approaches.  In the auditor’s approach, the entity identifies BCS across the various assets, then classifies these using Attachment 1.  In my approach, the entity first classifies assets as High, Medium or Low impact, then identifies BCS at the Highs and Mediums.  Keep in mind that I’ve already stipulated that the “top-down” and “bottom up” approaches should both be applied in identifying BCS at High and Medium assets, so this is removed as a source of difference between the two approaches (a couple months ago, I thought this was the most important difference between my methodology and the auditor’s, but I came to realize the two approaches could – and should – coexist.  And the auditor agrees with me on this).

[vii] A person from FRCC told me recently that Scott Mix of NERC, when he addressed their CIP group in May, said definitely that the first step in compliance with CIP-002-5 R1 was to use Attachment 1 to classify the assets, then to identify High and Medium impact BCS.  And when questioned about this, he said that NERC should probably clarify this for the entities.  I certainly hope he hasn’t changed his tune since then.  If not, I may owe Scott some sort of royalties for just repeating in my posts what he had already said very eloquently in May.  

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

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

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

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

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

The Auditor’s Methodology

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Advantages and Disadvantages of the Auditor’s Methodology

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

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

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

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

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

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

Here are the disadvantages that I see:

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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