CIP-002-5: The Wars of Religion (Part I)

Nov. 8: It is very likely FERC will approve CIP Version 5 before Thanksgiving, most likely at their meeting on Nov. 21.  Of course, what will be important is the Order they issue with V5.  When that is issued, your reporter will sequester himself until he has figured out what it means, and will post that as soon as possible thereafter.

10/21: I posted yesterday a follow-on to this discussion, which brings it to the exciting conclusion.  You won't want to miss it!

I have been working and talking with a number of people (NERC entities, regional auditors, consultants) recently about how they will identify their cyber assets in scope for CIP Version 5; the imminent approval of V5 seems to be focusing people’s minds on that.  And I haven’t just been talking with them, I’ve been arguing (although one auditor and I agreed to call it “constructive engagement” or some other euphemism for “argument”).

What are we arguing about?  Not Obamacare.  We’re arguing because there are some serious ambiguities in CIP-002-5 (where the dirty work of identifying those cyber assets gets done).  I have written seemingly interminably about these ambiguities and even ended up rewriting the standard and submitting it to FERC during their V5 comment period.  When they approve V5, I really don’t think FERC is going to tell NERC to replace the original CIP-002-5 with mine, but I do hope they at least tell them to try to fix the problems, since it looks like they will order NERC to draft a new version (V6) anyway.

But at this point we really can’t assume there will be any changes made in CIP-002-5 when it’s redrafted as CIP-002-6, and this leads to a question: Given that the ambiguities will probably not go away, how should NERC entities identify their BES Cyber Assets and BES Cyber Systems?  And what are the ambiguities, anyway?

In my arguments on this topic, I have noted a lot of resemblance to religious discussions: Both sides have equal claim to being right (or wrong) based on objective facts, so you can’t just point to something (in this case, a particular phrase in the requirements) and say, “Aha, there’s the proof!  Your argument doesn’t hold water.”  If there were some sort of proof for one opinion or the other, there wouldn’t be the ambiguities I was just mentioning. 

Throughout history, I believe there have been two primary ways in which religious discussions have been resolved:

1. Killing everybody who doesn’t believe as you do; and
2. Figuring out some way to compromise.

Now, I have been accused (unjustly, of course) of injecting too many of my personal opinions into my posts.  So I won’t try to say which of these two courses of action would be better for resolving disputes over CIP-002-5.

However, I don’t really believe the first option is the right one to use in the case of CIP Version 5 disputes (plus it has never worked so well historically, either.  See the case of Christians vs. Lions ca. AD200.  Who ultimately won that one?  Hint: not the lions).  The conclusion is we need to figure out some way for different viewpoints to be reconciled, when it comes to disputes over interpretation of CIP-002-5 (it would of course be very nice if, once FERC does approve V5, NERC set to work immediately on an Interpretation document that tried to fix these problems.  They did do that regarding CIP Version 1, when they produced very good documents on identifying Critical Assets and Critical Cyber Assets.  Unfortunately, they didn’t do that until a year or two after CIP Version 1 came into effect – not exactly great timing for entities who needed to identify their CA’s and CCA’s for V1.  NERC will be releasing their final version of the V5 Transition Guide next June, which will incorporate lessons learned from the current Transition Implementation Study.  Hopefully, these issues will be addressed in that).

With all this in mind, I’d like to discuss a) what are the primary ambiguities in CIP-002-5 and b) how I would suggest they be resolved.  I believe there are either three or four of these primary ambiguities, plus some secondary ones.  I will try to address each primary ambiguity in a separate post.

This first post deals with a very meaty ambiguity.  It has to do with the question “How does an entity identify the BES Cyber Systems that are in scope for CIP Version 5?”  The ambiguity can be succinctly stated: There seem to be a number of people (including auditors) who say the whole cyber asset identification process is based on the BES Reliability Operating Services (hereinafter BROS).  There are others – well, there’s me anyway – who point out that the BROS are nowhere mentioned in the actual requirements (or Attachment 1) of CIP-002-5.  What is mentioned is the definition of BES Cyber Asset (which underlies the definition of BES Cyber System); therefore, IMHO the BCA definition should be the starting point for any complete identification of BES Cyber Systems (BCS).

You may rightly ask, “Why should there be any dispute in this matter?  Some people are saying entities should rely on a concept not even in the requirements, while you’re saying they should rely on something that is in the requirements.  Those other people don’t seem to have any real ground to stand on.”

I would be tempted to let it go at this, except that people whose opinion I respect (including a couple regional auditors, as well as one of Honeywell’s consultants who forms his opinions very carefully) are proposing to base their whole approach to BCA/BCS identification on the BROS.  I want to try to figure out a way that both approaches can be accommodated, since they both have merit.  And let’s be clear: With the imminent FERC approval of Version 5, every entity (with High and Medium impact Facilities) will have to figure out how it is going to go about identifying cyber assets in scope for V5.  It’s not like they can wait a year for the final guidance to be available.[i]

History Lesson

First, some history on the BROS:  The first official draft[ii] of CIP Version 5 was posted in November (or perhaps October) 2011; it was the subject of the first CIP V5 ballot, which concluded that December (and failed dismally).  In that draft, the process of identifying BES Cyber Assets/Systems[iii] consisted of these steps:

1. Identify BCA’s using the definition.  That definition stated that BCA’s needed to fulfill one or more BROS: “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its operation, mis-operation, or non-operation, when required, adversely impact one or more BES Reliability Operating Services.”
2. Classify those BCA’s as High, Medium or Low impact depending on the classification of the Facility with which they’re associated –and this comes from Attachment 1. 

Pretty straightforward, right?  Just two steps, not the 14 I identified as being required to list and classify BES Cyber Systems in the final version of CIP-002-5.  However, I and others[iv] became convinced this would be a nightmare to implement, and we made our point in this blog post from December 2011.  I recommend you read the post, but I’ll summarize what we said:

• The approach in Draft 1 would require a huge effort of every NERC entity subject to CIP.  They would have to inventory every cyber asset they owned (at a Low, Medium or High impact facility, although this classification wouldn’t be done at this point[v]), decide whether or not it performed one or more of the BROS, and if so which one(s). 
• It is only in a few special cases that a cyber asset performs a BROS all by itself; in almost all cases, it is the facility it’s associated with that performs the BROS.  Take the system that controls water purification in a control plant – does it perform the Controlling Frequency BROS all by itself?  No, but it contributes to it, given that the plant might shut down if that system failed – and the plant does perform the BROS.  The system’s contribution is only through the plant, not on its own.  But the first draft of CIP-002-5 required the entity to conduct the BROS analysis on every cyber asset it owns (i.e. regardless of the BES Facility it was part of, or even if it was part of any BES Facility at all), and only then classify each system as Low, Medium or High impact based on the Facility it was associated with.  And since this would require an inventory of all Low impact cyber assets (indeed, it would go far beyond an inventory), it would of course violate the statement that such an inventory isn’t required (this statement was in the first draft, as well as the final version).
• This would be an auditing nightmare.  The auditors would have to go over the documentation of this entire process to make sure it was conducted correctly (and probably sample some cyber assets to make sure they were included).  There would be endless arguments over whether loss of a particular cyber asset “adversely impacted” a particular BROS or not.  And who would settle these arguments?  Would the auditors have to bring with them a team of EE’s?  And would the entity be able to counter with its own EE’s?  Then who would be the uber-EE’s who made the final ruling on this?

In the December 2011 post, we suggested a much more straightforward approach to BES Cyber Asset identification, modeled after CIP versions 1-3:

1. Classify each BES Facility as Low, Medium or High impact using Attachment 1;
2. Determine the BROS that the Facility supports; and
3. Identify the cyber assets associated with the Facility whose loss or misoperation would cause the Facility not to be able to fulfill one or more of the BROS it supports (i.e. identify cyber assets that met the definition in the first draft).  These are the BES Cyber Assets.[vi]

Whether this post had anything to do with it or not, the first draft of CIP Version 5 was roundly voted down.  When the SDT met at ERCOT’s headquarters in January 2012, they quickly changed the BCA identification process to reflect something like our suggestion.   However, they went further than that: they removed all reference to the BROS in the BCA definition, in the requirements of CIP-002-5, or in Attachment 1.  From that point on, the BROS were only in the Guidance and Technical Basis which accompanied the standard (which cannot be audited or enforced as part of the requirements).  The new BCA definition was pretty close to the final one, which begins:

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.

Back to the Present

I went through this history to let you know how the BROS came to be discussed in the Guidance and Technical Basis section of CIP-002-5.   The BROS were in the requirements themselves (through being in the definition of BCA) in the first official draft of Version 5 (and they had been in all the previous unofficial drafts going back to the original CIP-010 and -011, which were the first attempt to draw up a new CIP version to finally address the remaining issues in FERC’s Order 706).  I won’t deny that using the BROS is a very elegant way to identify cyber assets that should be in scope for CIP.  What would be a better way to protect the BES than by looking at the services that support the reliable operation of the BES, then finding the cyber assets that support those services?

However – once again – the BROS are not at all part of the requirements of CIP-002-5.  This means that

• An auditor can’t assess a Potential Violation because an entity didn’t use the BROS in identifying BES Cyber Assets; and
• An auditor can (and presumably will) assess PV’s against an entity that didn’t identify all of its cyber assets that meet the final CIP Version 5 definition of BES Cyber Asset. 

So let’s get back to the argument.  My position (at least my starting one) is pretty simple: CIP-002-5 R1 requires the entity to identify BES Cyber Assets, period (actually, it requires them to identify BES Cyber Systems.  But the BCS definition simply refers to the BCA one, so the concept of BCA is still fundamental to the cyber asset identification process).  The only way to strictly comply with this is to go through all cyber assets (following the cyber asset definition in Version 5) associated with[vii] a Medium or High impact[viii] Facility and identify those that meet the definition.

But what do the BROS people argue now?  They don’t say the same thing that was in the original draft of CIP-002-5, namely that the entity needs to go through every cyber asset they own and determine whether it fulfills one or more BROS.  What they say is that the entity needs to:

1. Identify the BROS that the entity has to fulfill, given their NERC functional registrations.  For example, a BA performs the “Balancing Load and Generation” BROS (the table on page 18 of CIP-002-5 provides a good list of which registrations perform which BROS). 
2. Identify the systems that implement that function, which become BES Cyber Systems.  In this example, it would be the BA’s EMS or SCADA system.  This (or perhaps a subset of it) is a BES Cyber System.
3. Identify the cyber assets that make up the BCS.  These are the BES Cyber Assets.[ix] 

This is a completely different approach from mine, which I believe to be the only compliant one given the wording of CIP-002-5.  Mine is a "bottom up" approach, where you start with each cyber asset and see whether or not it meets the definition of BCA[x]; you then aggregate these into BES Cyber Systems to suit your needs (and of course, you can have a single BCA constitute a BCS).  The BROS-based approach is a “top down” one, where you first identify BCS, then the BCA’s that constitute the BCS.

The Solution?

How could these two approaches be combined?  By doing both, of course.  I’m fine with having the entity first do the BROS analysis; as I mentioned, that is certainly more elegant and attuned to the whole function of NERC CIP than just using the BCA definition.   Furthermore, it is almost certain that any BCA’s identified through the BROS process will meet the definitions, so none of this effort will be wasted.

However, the converse of the above sentence isn’t true: It isn’t certain that every potential BCA (i.e. every cyber asset that meets the definition of BCA) will be identified with the BROS process.  I see nothing in the BCA definition that precludes the idea that there could be BES Cyber Assets that don’t actually assist in performing one or more BROS.  These wouldn't be identified in the BROS process.

And – once again – what is required in CIP-002-5 is that every cyber asset that meets the definition be identified, and that it be incorporated into a BES Cyber System for compliance with CIP-003-5 through CIP-011-1.  Therefore, I suggest that the entity look at all cyber assets that weren’t previously identified as BCA's in the BROS approach, and identify those that meet the BCA definition.  These will then be aggregated into BCS.

Here is how I would combine the two approaches:

1.     Identify the BROS that the entity has to fulfill, given their NERC functional registrations.  For example, a BA performs the “Balancing Load and Generation” BROS (the table on page 18 of CIP-002-5 provides a good list of which registrations perform which BROS). 

2.     Identify the systems that implement that function.  In this example, it would be the BA’s EMS or SCADA system.  This (or perhaps a subset of it) is a BES Cyber System.

3.     Identify the cyber assets that make up the BCS.  These are BES Cyber Assets.

4.     Examining the remaining cyber assets, identify those that meet the definition of BCA.

5.     Aggregate these into BCS, composed of one or more BCA’s.

6.     Combine the two BCA lists and the two BCS lists – voila, here are your lists!  Now take the BCS list and go forth and conquer CIP-003-5 through CIP-011-1 (but keep your BCA list in the closet for when the auditor shows up).

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

---

[i] There will be some interim releases of lessons learned from NERC’s Transition Implementation Study, before the final report in June 2014.  However, I’m frankly kind of skeptical about this whole exercise.  Whenever NERC tries to offer guidance to clear up ambiguities in the standards, they run into the problem that they’re then seen as rewriting the standards in some way – without benefit of member input and a Standards Drafting Team (of course, the unhappy fate of the CANs was a perfect example of this).  NERC isn’t a regulatory body – FERC is.  Any binding interpretation really has to come from them.

FERC can provide guidance by approving or remanding interpretations that NERC drafts (lately, they seem to be mostly remanding the ones having to do with CIP).  On the other hand, the whole Request for Interpretation process takes a year or more, and I don’t even know when RFI’s could be entered for Version 5 – certainly not now, and maybe not until V6 is drafted and approved by FERC in about a year.  FERC really isn’t going to provide any up-front guidance on V5, unless they provide it in their Order approving V5.

[ii] I would normally include here a link to that draft.  I know it exists somewhere on the NERC web site (along with the other three drafts of all the CIP standards), but after a lot of fighting with the site I gave up.  And this is the NEW, IMPROVED NERC web site!  I have said for a long time that I know a foolproof way to protect critical infrastructure data from Al Quaeda: Just post it on the NERC web site.  They’ll never find it there!

[iii] The terms BES Cyber Asset and BES Cyber System were used almost interchangeably in the first draft, which led to a number of negative comments.  In the next draft, the Standards Drafting Team settled on BCS as the fundamental unit of CIP V5 compliance, although BCS are only defined as made up of individual BCA’s (or even just one BCA).  This remains the approach today.

[iv] I had three collaborators, although only one – Donovan Tindill of Honeywell – could be identified in the post.  Two were NERC compliance people from a large IOU who had come to the same conclusion about the current draft of CIP-002-5 that I had (and had done a much better job of identifying both the problem and a possible solution).  I regret to this day that I couldn’t thank them publicly.

[v] I think this would also have included all of the payroll, accounting, etc. systems on the IT network.  There was nothing in this draft to exclude any systems from the initial consideration.  In fact, there’s nothing in the final CIP-002-5 that excludes those systems, either.  This wouldn’t be a problem if the wording of the final version accurately reflected what I believe to be the intent of the SDT: To have the entity first classify its BES Facilities, then identify the BES Cyber Assets among those cyber assets that are associated with each Facility.  However, the wording of CIP-002-5 still has remnants of the approach in the first draft (especially in Attachment 1), so that it isn’t clear that the entity doesn’t have to first inventory and analyze every cyber asset it owns as a potential BCA, before it even classifies its Facilities.  This is just another of the many ambiguities in the wording of CIP-002-5.  This is a wonderful situation for a blogger like me, as it has given me material for a number of posts.  It isn’t so wonderful for the NERC entities that have to try to comply with this, or for the poor auditors who have to figure out how to audit it.

[vi] In case you think I was for the BROS before I was against them, I remind you that the BROS were part of the BCA definition in the first V5 draft.  In the December 2011 post, we were arguing that definition should be used, but the entity shouldn’t have to apply it to every single cyber asset they owned – just the ones at Medium and High impact BES Facilities.

[vii] I just realized something – and I don’t know why I didn’t realize this a while ago.  Requirement 1 of CIP-002-5 refers to BES Cyber Systems at each Asset.  Shouldn’t this really have been “associated with” as it is in CIP-002-3 R3, where Critical Cyber Assets are identified as “associated” with the Critical Asset?  I always thought this distinction was important, since the systems that control a Critical Asset could be in a completely separate location – e.g. AGC for a gen plant that is located elsewhere.  I think I know what knowledgeable people (who are also of the BROS persuasion) will say: “This is the whole point you’re missing, that cyber assets can fulfill a BROS wherever they are, whether or not it’s for the Facility at which they’re located.  You’re the one who is saying the entity has to first identify the Facility (or Asset) and then identify the cyber assets associated with that Facility.  If you wouldn’t do that, there wouldn’t be any problem with whether or not a cyber asset was located at the Facility – it would still be caught up in the BROS analysis.”

I can’t say there’s anything wrong with that argument as far as it goes.  But the whole point of this post is that the BROS can’t be the entire basis for BCA/BCS identification – and that it was never the intention of the SDT (after the first draft of V5 went down in flames) that it should be (even though the new language they put in at the meeting at ERCOT still – maddeningly – partly reflected the previous approach, especially in Attachment 1.  And that language remains today).  So I would think the final NERC Standards Transition Plan will change the wording “at each asset” in R1 1.1 and 1.2 to “associated with each asset”.  That is, unless NERC actually wants to only include cyber assets physically located at the Facility in question. If that’s the case, then nothing needs to be done.

[viii] This analysis doesn’t have to be done for Low impact Facilities, of course.  The only way that might change is if FERC requires there be cyber asset-specific requirements for Lows in the new version.  For example, if they require patches be evaluated and applied, antivirus be implemented and updated, etc.  Requirements like these would need to be audited on a per-device basis, meaning the Low entity would have to inventory cyber assets and identify BES Cyber Systems.  I don’t think this will happen, though.  I think FERC will require some more programmatic requirements – there must be a patch management program, an A/V program, etc. for the cyber assets at the Facility.  These requirements will be written in such a way as not to require auditing of specific cyber assets.  And I think it’s very likely FERC will require that every cyber asset be within an ESP, but without requiring auditing of each particular cyber asset to make sure this is the case.

[ix] I am grateful to Sarosh Muncherji of Honeywell for designing this approach, and pointing out that it is a top-down one.

[x] Of course, the definition of BCA changed between the first draft and now.  Otherwise, both my approach and the one in the first draft would be the same.