The Ship has Sailed, NERC

This is the fourth and last of a series of posts on the many problems with CIP-002-5.1 R1, and what both NERC entities and NERC itself need to do to deal with them.  The series started with a post in which I said the compliance date for CIP v5[i] should be pushed back from its current date, April 1, 2016.  It was followed by a post that listed serious interpretation issues with this requirement (which is of course the fundamental requirement of CIP v5), and most recently by a post describing a high-level “methodology” for complying with this requirement (or more accurately, showing graphically why it is impossible to develop any sort of definitive methodology).

To go back to the first post in the series, the reason I gave for pushing the compliance date back was that a large number of entities will clearly either a) not be compliant by 4/1/16; or b) only achieve compliance through a large, very inefficient expenditure of money – as the huge demand for assistance with v5 runs up against the small number of competent resources available to meet the demand.

I listed three reasons why entities won’t be ready by the compliance date, although it’s possible there are other reasons as well:

1. They won’t have budget for CIP v5 until 2015;
2. They have been holding back from taking action on v5 due to the many uncertainties in interpretation; or
3. They are already spending money on v5, but they aren’t addressing what needs to be done.

You could say that 1 and 3 are the result of the entity’s actions or inactions, and aren’t anyone else’s fault (like NERC’s)[ii].  I don’t dispute this, although that doesn’t in any way mean the date shouldn’t be pushed back.  When you have a large number of people not in compliance with a law or regulation, you have to look at whether a) the law or regulation imposes too much of a burden for compliance; or b) the implementation period is too short.  I assert that both of these are true in the case of CIP v5, although addressing a) will be much harder than addressing b).

But let’s focus on the second reason that a large number of entities aren’t going to be ready for v5 compliance on 4/1/16: uncertainties in interpretation.  Folks, this one is entirely NERC’s fault.  Since April of 2013, I’ve written maybe 40-50 posts on problems with CIP-002-5.1 R1 and Attachment 1, culminating (for the moment) with the second post referred to above.  This post describes about 20 problems with CIP-002-5.1 R1 (most quite serious), and I’m sure that there are a lot of others lying in wait in the “bright-line” criteria (I love that term, which is FERC’s.  It shows they have a great sense of humor).

Of course, CIP-002-5.1 R1 (hereinafter referred to as “R1”) is just one of 33 requirements in CIP v5 (there are more requirements in CIP 6.3940, the “version” that entities will actually have to comply with)[iii].  However, R1 is definitely the foundation of v5.  The goal of CIP v5 is to protect BES Cyber Systems.  To comply with R1, you need to identify those BES Cyber Systems.  If you don’t do that properly because you don’t understand what that requirement means, none of your efforts to comply with the other v5 requirements will really be valid (even though it’s not likely you’ll actually be assessed PV’s for violating those other requirements, due to a mistake in complying with R1).  It’s like a real estate salesperson is trying to sell you a house called CIP v5.  They say, “It has wonderful bathrooms, a great kitchen, huge living room…The foundation is rotten and could go at any time…But LOOK at these bathrooms!”

You may point out to me that CIP v5, like all NERC standards, was written by a Standards Drafting Team composed of employees of NERC entities, and it was approved by a ballot of those entities; therefore, any blame for problems resides with the NERC entities themselves.  While this isn’t completely true (since NERC staff members played a big role in guiding the SDT), I’ll stipulate you’re right.  But IMHO, once the NERC Board of Trustees approved v5, ownership passed to NERC.  As problems began appearing (and they appear with every standard), it was NERC’s responsibility to address them in a timely fashion, so that entities could comfortably meet the compliance deadline.  Despite some half-hearted efforts like coming out with some Lessons Learned, NERC hasn’t definitively addressed any of these issues.

I contend that yesterday, Jan. 1 2015, was a watershed day for CIP v5.  As of that day, there remain exactly 15 months for NERC entities with High and Medium impact BES Cyber Systems to achieve full v5 compliance for those systems.  Yet there remain a huge number of uncertainties about definitions of terms used in v5 and interpretation of wording (especially in R1, but the uncertainties are certainly not limited to that requirement).  NERC has put out about ten “Lessons Learned”[iv] and FAQ documents on v5 issues, most still in draft form.  That is just about the only “guidance” they have provided (and all these documents will ever be is guidance.  The only official Interpretations – which carry the full force of Requirements - of the v5 wording won’t be approved for years). 

NERC has also put out a list of 23 issues (ten of which are in R1) that they plan to address in future Lessons Learned or FAQs.  One or two have already been addressed in draft form, so there are about 21 issues they say they really really want to get to one of these days.  My guess is at most one, maybe two, of these will be addressed each month in 2015; so just addressing the issues NERC has said they’ll address will take all year.  And these are just a portion of the issues that are actually out there (I believe only two of the problems with R1 that I pointed out in my second post were even on NERC’s list to address at all).  If you assume there are at least 40-60 other serious issues to be addressed (including the 18 from my post), this means the Lessons Learned process will have them all nailed down by around the end of 2017, running at its current pace.  Does anyone else see a teeny teeny problem with leaving the compliance date at 4/1/16?

NERC, I’m sorry to say this, but the ship has sailed.  Entities needed to start their compliance process six months ago, but at the latest they should start it tomorrow (OK, I’ll give them ‘til Monday Jan. 5).  I was hoping you (NERC) would get a good number of these issues addressed by the end of 2014, so that entities could start off 2015 by a) identifying all their cyber assets/systems in scope for v5; b) conducting a gap assessment to see what they need to do; and finally c) rolling up their sleeves and implementing what they need to fill those gaps.   Because you only addressed one or two of the CIP-002-5.1 R1 issues, the entities simply don’t have enough guidance for them to start this process as they need to: with a comprehensive effort to identify all cyber assets in scope for v5 (BCAs, BCS, ESPs, PCAs, EAPs, etc). 

You’ve taken a remarkably leisurely approach to the Lessons Learned effort, NERC (for instance, the last LLs were posted in November).  I appreciate that you all have family commitments, etc, but this approach has eliminated any remaining possibility that entities will be able to competently and efficiently comply with CIP v5 by 4/1/16.  

So this is what you need to do, NERC:

1. As I believe I’ve just mentioned, the compliance dates for v5 need to be pushed back - a minimum of six months, but preferably a year.
2. You need to declare CIP-002-5.1 R1 an “open” requirement.  I doubt there’s any provision for doing this in the Rules of Procedure, but I also doubt there’s ever been a requirement that’s been both a) so extremely critical, and b) so vague and contradictory.  You need to simply declare that any entity that makes a good faith effort to understand R1, and that properly studies and applies all the appropriate Lessons Learned, etc, will never be assessed a PV for violating R1.

I know you’re not going to like this idea, NERC (in fact, you’re not going to like any of the ideas in this post).  But you know what?  It really doesn’t matter whether or not you declare R1 an open requirement; it will be that of its own accord.  There is simply no way any self-respecting auditor will assess a PV for R1, on an entity that has made a good-faith effort to comply.  And this is because there’s no way any assessed violation of R1 would ever be upheld in a court of law – the requirement is simply too contradictory and vague.  What auditor wants to waste their time (and credibility) writing PVs that have zero chance of ever being upheld?

3. You need to bust your a__ providing guidance on v5.  No more one or two Lessons Learned a month.  You need to a) come up with a full list of ambiguities, etc. in all the CIP v5 standards; and b) make a plan to address each of these – through Lessons Learned, FAQs, fatwas, Papal encyclicals, or whatever means you have – by at a very minimum a year before the new (initial) compliance date for v5.  For example, if you put off the initial compliance date for a year to April 1, 2017, you need to address all of the ambiguities in v5 by April 1, 2016.
4. You need to write a SAR[v] for a new version of CIP-002 (which of course would be the first and perhaps only CIP Version 8 standard).  Even though I’m assuming you’ll listen to what I said in the paragraph above this (after all, you always listen to me!), there is simply no way that R1 can be made whole without completely rewriting it.  And if you’re not sure what’s wrong with the current standard and don’t feel like plowing through the 40 or so posts I’ve written on that topic (who can blame you for that?  I get tired of looking at them myself), I’ll be glad to make a couple suggestions.  Once a new CIP-002 R1 is in place, then I think CIP v5 (of course, I mean v6.3940) will be a completely enforceable version.  There are certainly problems with the other standards beyond CIP-002, but in my opinion they are all fixable through Lessons Learned or other documents; the problems with the current 002 are not fixable without a complete rewrite.

I must admit these four “suggestions” are based on an assumption: that rewriting CIP-002 will be a 2-3 year process, including writing the SAR, constituting a new SDT, drawing up and balloting a few drafts before final approval by NERC, submitting the new version to FERC, awaiting their approval, and addressing any changes FERC may require when they approve it.  A further assumption is that it would be unacceptable to leave CIP v3 in place during this entire process.

If either of these assumptions isn’t correct, then what I recommend is much simpler: NERC needs to start the process of rewriting CIP-002, and leave CIP v3 in place until the new version (CIP-002-8, by my calculations) is ready.

Of course, you may well ask what is the likelihood that NERC will take up any of my suggestions?  I refer you back to the first post in this series, where I said the likelihood was about that of the Chicago Cubs winning the World Series in 2015.  Quite small, yet still greater than zero.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Honeywell.

---

[i] In this and other posts, when I say “CIP v5”, I’m almost always referring to what I call CIP 6.3940, the specific mix of v5, v6 and v7 CIP standards that NERC entities will actually have to comply with.  Everyone still refers to it as “CIP v5”, and that’s fine with me – as long as nobody is looking any more at any of the “real” v5 standards except for CIP-002, -005 and -008.  All the others have been replaced by their v6 or v7 versions.

[ii] I would say that blame for Number 1 can actually largely be attributed to FERC.  I believe they approved CIP version 4 in April 2012 not because they intended to see it come into effect, but as a way to put pressure on the NERC membership to quickly approve CIP v5 (the first draft of v5 had just gone down to resounding defeat, with no standard gaining more than I think about a 20% positive vote).  Unfortunately, by approving v4, the signal they sent (especially to the Legal and Compliance departments at large IOUs) was that v4 would come into effect, regardless of whether or when CIP v5 was approved.  So a lot of money and effort were wasted on v4 compliance efforts, which I documented in a series of posts (starting with this one) last summer.

A year and a day after FERC approved v4 (and undoubtedly due to a lot of frantic lobbying by NERC), FERC issued a NOPR saying they intended to approve v5, and that v4 would never come into effect.  Yet some of those IOU Legal departments a) continued to tell people to work on v4, since after all that was still the law of the land; and b) wouldn’t allow expenditures on v5 because it wasn’t actually approved, and because FERC had made it clear they wanted some changes in it.  FERC did approve v5 in November 2013, but that was past the date that most large utilities (and IPP’s) had prepared their 2014 budgets; hence a lot of NERC entities (some quite large) won’t have v5 budget until sometime in 2015.

[iii] There are problems in most of the other requirements as well – there always are.  However, the R1 problems are serious enough that I now contend there is no single methodology that can be written down for R1 compliance that conforms to all of the wording in R1 and Attachment 1; there are just too many missing definitions, holes in interpretation, and out-and-out contradictions.  The third post in this series drove home that point in nauseating detail.

[iv] Of course, to speak of “Lessons Learned”, when the v5 standards probably haven’t been fully implemented yet by any large NERC entity, is kind of strange.  These aren’t really lessons learned but non-binding interpretations (with a lower-case i).  True Interpretations, which are binding, will take probably three years to go through the whole process of drafting, balloting, and approval (or not) by FERC; they obviously won’t solve anyone’s problems with compliance by 4/1/16.

[v] Standards Authorization Request

Here’s Your CIP-002-5.1 R1 Compliance Methodology!*

This is the third in a series of posts on the serious problems with CIP-002-5.1 R1, and what entities and NERC need to do to deal with them.  The first post is here.  The exciting conclusion - in which I chide NERC for their mishandling of these problems and say what I think needs to be done to address them - is here.

June 11, 2015: I'm afraid I've come to the conclusion that there can be no definitive guidance developed for complying with CIP-002-5.1 R1; there are just too many contradictions and ambiguities in the standard.  I would like to see the standard rewritten, but since that is a multi-year process, it obviously won't help entities preparing for compliance next April. I will continue to discuss different aspects of the R1 (and Attachment 1) compliance process, such as in this post.  But my hope to keep updating this post as a kind of comprehensive guide for R1 compliance is officially ended.  There is probably nothing in this post that is simply wrong, but keep in mind that my ideas on how you should comply with R1 have moved beyond what's here.

*I’m worried the FTC lawyers will be contacting me any minute to hit me up for pulling a bait-and-switch.  The fact is, I have no intention of telling you what your CIP-002-5.1 R1 and Attachment 1 (“R1” for short) compliance methodology should be.  That’s because I’ve become convinced that it is impossible to write down a single procedure for R1 compliance that takes up something less than the length of War and Peace; or if you prefer, I don’t think you could document the process with a diagram that takes up less than the size of my living room.  And this leads to a couple important conclusions.  For the whole sorry story, read on.

A brief history:  I’ve made three main efforts to come up with a single methodology for R1 compliance.  The first was when I rewrote R1 as a comment to FERC in June 2013.  I cringe when I read it now, since a lot of it is simply wrong – although I still think it’s better than the requirement as currently written.  The second was at the very beginning of 2014, when I thought I finally knew exactly how to comply with R1 and I laid it all out in three posts (the first is here).  Yet within three weeks, I knew I’d missed a couple really important nuances, most notably why “Facilities” was the subject of criteria 2.3-2.8.

My most recent attempt was last April, when I wrote Part 1 of what was to be a couple posts that would lay out for once and all exactly how to comply with R1 for substations (and substations, of course, account for 95% of the v5 compliance effort).   I don’t think there was anything in that post that was strictly wrong; however, I gave up on it when it became clear that criterion 2.5 – and probably others as well - had to have a different compliance methodology associated with it from the other criteria; so there was a whole new layer of complexity I hadn’t realized.

I’ll be honest:  Since that time, I’ve just kept on discovering more layers of complexity as I realize new problems with R1 (for a list of the 21 primary problems I see now, see my last post).  One of the biggest new sources of complexity is the various areas where an entity needs to “roll your own” definitions and interpretations.  You could think of each of these areas – e.g. the definition of “programmable” – as being its own “subroutine”[i].  In other words, you need to roll your own definition of programmable and insert it at the appropriate place in the overall R1 methodology.  The same for your interpretation of “affect the reliable operation of the BES”, your definition of “associated with”, etc.

So it’s not like I’m saying there could never be a complete methodology for R1 compliance, although it might take something approaching the remaining lifetime of the universe to put it down on paper.  But the real problem is something that I first learned in my statistics classes in college: Uncertainty is multiplicative.  If you have only a 50% certainty that a particular sub-methodology (such as the definition of “programmable” you’ve just developed) is correct, and you have 9 other sub-methodologies each with only a 50% certainty, the percent of certainty you have about the whole string of processes together is 0.09765625% (i.e. less than a tenth of a percent).  This means you simply have no clue whether the whole thing makes sense or not.  Of course, I think there are a lot more than ten major areas of uncertainty in complying with R1; even this very low level of certainty is probably too high an estimate for any methodology you might develop. 

So I’m not exaggerating at all when I say there is simply no way to write a single methodology for R1 compliance that has some reasonable probability of being correct.  The likelihood of being able to do that is similar to the proverbial likelihood of a bunch of monkeys, pounding on keyboards, being able to recreate the works of Shakespeare.

Now that I’ve established the fact that I lied to you in the title, what is the point of this post, anyway?  It’s quite simple: The fact that no comprehensive R1 compliance methodology can be written down doesn’t mean you’re off the hook for complying.  Regardless of the difficulty, every entity does need to come up with a documented process for R1 compliance, and to follow that process in identifying their Medium and High impact BES Cyber Systems, as well as their Low impact BES assets. 

So in this post I’m going to try to lay out, on a high level, the main tasks that need to be taken to comply with R1, as well as what I think are the primary considerations that need to be addressed under each task.  There is no way I can put together even a reasonably detailed methodology that will work for your organization.  Hopefully, you can use this post to guide your effort to put that methodology together – perhaps using the help of a knowledgeable consulting organization such as the one I work for.  Where I’ve discussed a topic in a previous post, I’ll include a link.

Note that the discussion below is geared toward substations, since as I said above, I believe literally 90-95% of the CIP v5 compliance effort will be for Medium impact substations.  I believe the discussion also applies to Medium impact generating plants that meet criteria other than 2.1.  The methodology for those plants is quite different from what I outline below, mainly because of the huge numbers of devices that may meet the definition of Cyber Asset in large coal plants, as well as because of the “exemption” for BES Cyber Systems that don’t affect 1500MW.  I’ll hope to address those plants in a future post.

Task 1: Preliminary Identification and Classification of Substations and Facilities

The first step of the process is to decide which substations may be Medium impact – or more correctly, which substations are likely to contain Medium impact BES Cyber Systems.  Criteria 2.4 to 2.8 are the ones that can potentially apply to substations.[ii] 

The next step is to make a decision that every owner of Medium impact substations needs to make: whether to classify BCS based on the asset (substation) or on the Facility (line, transformer, etc) they’re associated with.  There are a couple key questions that your entity needs to answer, in order to decide which route they will take.  If you decide to classify based on substations, you will probably end up identifying more Medium impact BCS than you would if you classified based on Facilities.  On the other hand, there may be more work involved, and potentially more cost if networks need to be separated.  I will generally refer to “substations/Facilities” below; you need to choose this to mean one of the two terms, depending on your answer to this question.

If you do choose the Facilities route, you need to identify and list the Facilities at each substation.  To simplify things going forward, you can remove from the list Facilities that don’t have any cyber assets associated with them, since they obviously won’t have any BES Cyber Systems (the same applies to substations that don’t have any cyber assets associated with them, if you’re going the “substations” route).  Finally, you need to identify the Medium impact Facilities using Criteria 2.4 – 2.8 (and you should document a methodology for doing this, both to guide the people who do this work, as well as to show the auditors how you did it). 

A final step in this task is to develop a methodology for dealing with substations that are jointly owned or operated with one or more other NERC entities.  NERC has promised this will be one of the upcoming Lessons Learned, but you probably can’t wait for that to come out (of course, when it does, it will just be a draft for comment.  And even when it’s finalized, it won’t be binding on auditors or entities.  This applies to all the Lessons Learned[iii]).

Task 2: Inventory of Cyber Assets

This task (and the remaining tasks except for the last two) only needs to be taken for substations/Facilities that meet a Medium impact criterion.  You need to identify all of the electronic devices “associated with” the  substation/Facility, that meet the definition of Cyber Asset: “programmable electronic device”.  Of course, there are three important details embedded in this seemingly simple task:

1. You need to come up with a definition of “programmable".  This word is the heart of the NERC definition of Cyber Asset, but isn’t itself defined.  A Lessons Learned document was recently released in draft form by NERC.  You need to consult this, but keep in mind that it isn't mandatory you follow it - however, you do need to at least document why you didn't.
2.           Jointly Owned Substations – Your entity needs to decide how it will allocate responsibility for BES Cyber Systems with any joint ownership partners.
3.          “..affect the reliable operation of the BES” – This undefined phrase is an important part of the definition of BES Cyber Asset.  How your entity defines this phrase will have an impact on the number of BCAs (and BCS) you identify.  See this post.

Once you have developed addressed these three items, you need to inventory every device that could possibly be a Cyber Asset associated with a Medium impact substation.  The inventory needs to include identification of the Facility/substation with which it is associated, as well as the asset (whether that is a substation or another of the six asset types in R1, like a control center) where it is actually located (and if you’re going the “Facility” route described above, you’ll first need to inventory the Transmission Facilities located at each Medium substation).

Task 3: “Top-Down” Identification of BES Cyber Systems / BES Cyber Assets

I have written extensively about the two main approaches to identifying BCS/BCA: “top-down” and “bottom-up”.  Until recently, I thought that entities should combine the two approaches, for all types of assets.  It combines top-down and bottom-up, since not using both approaches can lead to under- or over-identification of BES Cyber Systems.  However, I've recently been persuaded that, for substations, only the bottom-up approach is needed; it remains a good idea for generating plants (except those that meet Criterion 2.1.  As I said above, these need a completely different appraoch) and perhaps for Control Centers.

Since, this post is partly about generating plants, I'll start by describing the top-down approach.  For generating plants (other than 2.1 plants, of course) I think it is better to start with the top-down approach, then use the bottom-up as a check on it (you’ll see this will reduce the work required, since starting with bottom-up will result in your doing some unnecessary classification work).  It would be nice if NERC, or for that matter the regions, provided some guidance on this issue.  But that is pretty unlikely at this point, so you’ll need to decide for yourself whether to use just one or both approaches. 

 

The first step for applying the top-down approach is to develop a methodology for it.  While the Guidelines and Technical Basis in CIP-002-5.1 does provide a good overall description of how the BES Reliability Operating Services (the heart of the top-down approach, of course) can be used to identify BES Cyber Systems, this is far from being a complete methodology for this task.  You need to develop that methodology first, both to guide whoever will be doing this and to show the auditors how you came up with your list of BCS. 

The methodology you develop should show how you will apply the BROS to develop a list of systems that are potentially BCS.  Very briefly, “potential BCS” are systems that support one or more BROS and are associated with a Medium impact substation/Facility.  For each of these potential BCS, you then need to ask, “Does this affect the reliable operation of the BES within 15 minutes?”  If the system doesn’t do that, it isn’t a BCS; if it does, it is one.  This is because a BCS is made up of BCAs, and the 15-minute criterion is part of the definition of BCA; what doesn’t meet this definition isn’t a BCA, and a system with no BCAs isn’t a BCS.

At this point, you should make a list of the component Cyber Assets within each BES Cyber System, but you don't need to actually classify these into BES Cyber Assets or Protected Cyber Assets (as I originally thought - see this correction to this post.

Task 4: “Bottom-Up” Identification of BCS

Whether you're dealing with a substation or a generating plant, you do need to do the bottom-up analysis to identify BCS.  In the bottom-up approach, you start with the definition of BES Cyber Asset, apply it to each Cyber Asset, and then determine which Cyber Assets are BCAs (and remember to use the "interpretation" you did of "affect the reliable operation of the BES" in the BCA definition, as described in Task 2 above).  Finally, you aggregate BCAs into BCS, so that every BCA is included in at least one BCS (and a BCS can consist of a single BCA).

There is a big difference in how you apply this process to generating plants vs. substations, though. For plants, you only need to apply the bottom-up analysis to the Cyber Assets that haven't already been included in a BES Cyber System as a result of the top-down analysis.  Since these are already in scope for v5, you don't need to spend your time deciding again whether they're in scope.  For substations, since you aren't doing the top-down analysis, you need to apply the bottom-up analysis to every Cyber Asset you've identified.

For both substations and plants, you now need to include all BES Cyber Assets in at least one BES Cyber System.  But there is a difference in how you do this for the two asset types.  For substations, you simply create as many BCS as are required to include every BCA.  But for generating plants, since you have already identified a number of BCS in the top-down analysis, you can always look first to those BCS when you're trying to find "homes" for the BCAs you've just identified in bottom-up.  You can then create new BCS to "house" the new BCAs (and of course, you always have the option of making every BCA its own BCS).

Of course, when I talk about combining BCAs into BCS, I'm not saying how that should be done. This is because there are no "directions" for this in CIP-002-5.1, the NERC Glossary definition of BCS, or the CIP-002 Guidance and Technical Basis.  NERC did publish a draft Lessons Learned document that at least gives you some ideas on what you can do - but in the end, this is something that's up to the entity to determine, with the idea that some choices will lead to a much easier CIP v5 compliance job than others will.

Speaking of this Lessons Learned document, I think it provides several good ideas and one spectacularly bad one: the idea that you could group BCAs into BCS differently in order to comply with different requirements - i.e. you would comply with one requirement using one set of BCS and another requirement with a potentially different set.  There is nothing illegal about doing this, but in my opinion it would create all sorts of problems in other parts of the v5 compliance effort.  I'll hopefully have a post out on this soon.

For a substation, the list of BES Cyber Systems you develop in this step is your final list.  However, for generating plants - since you have already developed a BCS list as part of the top-down analysis - you need to combine the bottom-up with the top-down list.  This, then, is the list of BCS that is the final outcome of R1.

Task 5: Draw Preliminary ESP

You may wonder what drawing the ESP has to do with complying with CIP-002-5.1 R1.  After all, that requirement is solely concerned with identifying and classifying BES Cyber Systems, not PCAs and certainly not ESPs.  The reason I have this task here is that, as we get into classifying BCS as Medium or High vs. Low impact, it is important to know which of these are networked with which others.  This is important not from a strictly compliance point of view but more from an operational point of view: if you don’t know where your ESP is drawn, you don’t know whether a Cyber Asset – that isn’t a BES Cyber Asset – is a PCA or not.  As a consequence, you may make decisions about classifying BCAs/BCSs that will result in your over-classifying Cyber Assets as BCAs.

There is a big difference between drawing the ESP in CIP v5 vs. in v3.  In v3, you needed to include all Critical Cyber Assets in an ESP.  In v5, you just need to include those BCS that are connected on an internal routable network (this is of course a different issue than whether an asset has external routable connectivity).  Other than that, you should draw your ESP(s) just as you did in V3, trying to include only those Cyber Assets that need to be in it, and making networking changes to reduce their number as much as possible.

Task 6: Classifying BES Cyber Systems

We now come to probably the most important task, and the only one that is explicitly called out in R1.  Each of your BES Cyber Systems needs to be classified according to the Facility/substation with which it is associated.  If the Facility/substation is a Medium impact, the BCS will be Medium; if it is Low, the BCS will be a Low.

There is an exception to this rule in the case of relays, located in an otherwise Low impact substation, that are associated with a line that meets criterion 2.5 as Medium impact (i.e. “far-end” relays in a transfer-trip scheme).  NERC’s recent Lessons Learned document on this topic, and their previous pronouncements, seem to make clear that such relays will not be Medium impact but Low; this is because of the specific wording of criterion 2.5 (thus, this provision only applies to that criterion). 

I need to point out that, IMHO, if you are taking the interpretation that criteria 2.4 – 2.8 apply to entire substations, not to particular Facilities in those substations (as discussed at the beginning of this post), then it isn’t clear that this “exemption” will apply to your far-end relays.  The Lessons Learned document and the wording of criterion 2.5 make it quite clear that this exemption applies to the Facility – i.e. a line between 200 and 499 kV – not to the substation itself.  So if you interpret 2.5 as classifying an entire substation[v] as Medium impact, then strictly speaking you should classify your far-end relays as Medium BCS.  However, my guess is that no auditor would issue you a PV for calling the far-end relays Low impact, at least if they didn’t want to come out to find their tires had been slashed. 

You finish this task by listing your Medium impact BES Cyber Systems, and the substation/Facility with which they are associated.

Task 7: List of Low Impact Assets

The final list you need is one of Low impact assets (although for not-very-good reasons they are called “assets containing Low impact BES Cyber Systems”) in R1.  This will of course be all of the Transmission substations that aren’t Medium impact.  However, if some of the Medium substations do contain Low BCS (meaning you identified BCS based on the Facility they’re associated with, not the substation – this can then result in a mixture of Medium and Low BCS at the same substation), you need to list these as Lows as well.

Task 8: Distribution Provider Assets

There are many NERC entities that are registered as both TO or TOP (who thus could have Medium impact substations) and Distribution Provider.   Section 4.2.1 of CIP-002-5.1 lists four types of assets, owned by some Distribution Providers, which are in scope for CIP Version 5.  In other words, if an entity is registered as a DP, it needs to treat any of these assets that it owns as in scope for CIP v5, even though they are Distribution assets and wouldn’t otherwise be subject to CIP.  Each of these assets needs to be added to the Low impact list, since none would meet one of the Medium criteria.

And Now, the Moral of Our Story
The purpose of this post has been twofold.  First, it has hopefully at least given you an idea of everything I currently see that needs to be included in a CIP v5 methodology, so you can use it as a completeness check for your own methodology.  But more importantly, I hope it has shown you (with "you" meaning NERC entities, FERC, the NERC regions and NERC itself) how serious the problems are with this requirement.  If you can't develop a defined methodology for complying with a requirement, you simply have a requirement that can't be complied with in any meaningful sense of the word; and that's what R1 is.  More on this in the next post, which brings this four-part series to its exciting conclusion.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Honeywell.

---

[i] The fact that the best way I can express this idea is to use a term from the days when programming involved spending a lot of time typing punch cards perhaps tells you the last time I did any serious programming (in FORTRAN).  I’m told you no longer have to use punch cards to write programs, which I’m glad to hear.

[ii] Criteria 2.2, 2.9 and 2.10 could also identify substations that contain Medium BES Cyber Systems, although you need to make some modifications to the remaining Tasks to properly deal with these criteria.  Of course, I'm completely glossing over the fact that technically none of the criteria apply to substations.  They apply to Facilities that may be found at substations.

[iii] In fact, the term Lesson Learned is quite inappropriate here, since the documents NERC is coming out with address topics that nobody has had to address so far, meaning no lessons can yet have been learned.  But “Lessons Learned” is an established category of documents with NERC, which provides a convenient fig leaf covering the fact that these are really quasi-Interpretations (capital I), and thus pushing the bounds of legality in the NERC world.

[v] In my opinion, to say that criteria 2.4 – 2.8 apply to substations, not Facilities, is to ignore the clear meaning of the words in those criteria.  The reason why you might nevertheless want to do this is that it will make your job of classifying BES Cyber Systems easier, although it will most likely increase the number of BCS that you end up classifying as Medium impact.

Interpretation and Definition Issues in CIP-002-5.1 R1 and Attachment 1

This is the second of a series of four posts on the serious problems with CIP-002-5.1 R1, and what NERC entities and NERC need to do to address them.  The first post is here.  The next post is here.

In the at least 30 posts I have done on problems with CIP-002-5.1 R1 and Attachment 1 (hereinafter “R1”), I have identified many problems with the wording in that document.  However, I’ve never gathered these together in one post.  I am now doing that, both for the sake of clarity and to support a couple new posts I’ll be doing very soon.

This list is important because NERC entities with Medium and High impact assets need to get started very quickly – if they haven’t already – on developing their final lists of cyber assets in scope for CIP v5, and they can’t do that without having some resolution to the issues listed below[i].  Unfortunately, none of these issues have been finally resolved – that can only done by rewriting R1, or by capital I Interpretations, which take 2-3 years.

Please note:

• This is far from being a complete list of problems with R1.  For one thing, there are a whole host of issues with the bright-line criteria, since those criteria don’t seem to fit any asset very well.  I’m sure you could easily more than double this list by including all of those issues.  And I’m sure there are more problems in the other parts of R1 as well.
• All of the issues in this list relate to Medium impact Transmission substations, since it is for these assets that the bulk of the CIP v5 effort will be expended.  There are other issues that relate to control centers, generating stations, etc. that I haven’t included in this list; I hope to add those at a later date.  On the other hand, all entities subject to CIP v5 compliance should find this list useful.  Most of the items on this list apply to all types of BES assets, not just substations.
• I have addressed some of these issues in previous posts; I include links in those cases.  I hope to do future posts on some of the other issues.
• FWIW, NERC has included a couple of these issues on their list of planned Lessons Learned and FAQs.  If we’re lucky we’ll see a draft for comment of these documents within a few months.  But my guess is there aren’t too many entities that will feel comfortable waiting a few more months to identify their cyber assets in scope for v5, while the compliance date remains 4/1/16.  If you’re still waiting to do this, you’ve already waited too long.  You need to get moving, even though that means taking these issues into your own hands to resolve.
• My suggestion is that, for each of the issues below, entities should decide how they will interpret each one (in conversation with their NERC Regional Entity, if possible) and document it – then go about identifying their cyber assets in scope.  Of course, any guidance NERC has provided will be helpful, as will any advice from the Regional Entity.  But remember, the only mandatory “guidance” is the wording of the standards themselves, along with any capital “I” Interpretations that NERC and FERC may approve.  The standards aren’t going to change in the next few years, and there will be no Interpretations available for at least 2-3 years.  I don’t advise anyone to wait for either of these things to happen, before they start to become compliant with CIP v5.

Here’s the list:

1.       The beginning of Section 4.2 of CIP-002-5.1 says “…the following Facilities, systems, and equipment owned by each Responsible Entity in 4.1 above are those to which these requirements are applicable…”  Yet R1 talks about “BES Cyber Systems” as being in scope and also discusses six types of “assets”.  Attachment 1 discusses things like “control center”, “generation”, “reactive resources”, “Transmission Facilities”, SPS, RAS, and “system or group of Elements”.  What is the relation, if any, between all of these things and “Facilities, systems and equipment” in 4.2?  And if there is no real relation, why is this wording in 4.2?

I can see that “Facilities” might be taken to roughly correspond to the “big iron” referenced in the bright-line criteria (i.e. roughly “assets” and true “Facilities”).  I can also see that “systems” might refer to the BES Cyber Systems that will be in scope for v5.  But “equipment”?  That sounds more like monkey wrenches and forklift trucks.  Is that really in scope for v5?  Does the entity need to come up with a list of all the “equipment” they own and decide what impact it has on the BES?  I’m sure they don’t, but that would be a valid interpretation of this section.

2.       Subsection 4.2.2 seems to narrow “Facilities, systems and equipment” down by saying that, for all entities listed in 4.1 except DP’s, what is in scope for them is “All BES Facilities”.  If the SDT hadn’t capitalized “Facilities”, this would be quite easy to understand, since lower case “facility” can generally be thought to be any of the “big iron” to which CIP v5 might apply, including control centers, substations, generating stations, etc.  However, the fact that Facility is capitalized means it’s a NERC defined term.  If you look it up in the NERC Glossary (and also look up Element, which is a key part of the Facility definition), you’ll see that a Facility has to have terminals and presumably be operated at high voltage.  Do you know any control centers that have terminals and are operated at high voltage?  I don’t either.  This means that all control centers are out of scope for CIP v5!  I’m sure all the big BA’s will be pleased to hear this.[ii]

3.       There’s another “get out of jail free” card embedded in the quote from Section 4.2 in item 1 above.  Note that the “Facilities, systems and equipment” need to be “owned by” the Responsible Entity, in order for them to be in scope for CIP v5.  So to eliminate your CIP compliance burden, how about selling your equipment – or even the asset itself – and leasing it back?  Businesses do this all the time as a financial strategy.  There you go: You don’t own anything, so you don’t have anything in scope for v5!

4.       Of course, the whole point of R1 is to identify and classify BES Cyber Systems.  What is the first step in that process?  If you restrict yourself to the wording of the requirement itself, the only thing you have to go by is R1.1 – R1.3, since they constitute the entire actionable part of the requirement.  1.1 and 1.2 tell you to respectively “Identify each of the high impact BES Cyber Systems….” and “Identify each of the medium impact BES Cyber Systems…”  But how do you do that?  There is nothing in the requirement to guide you, other than the definitions themselves.  And you have to work backwards.  Since you’re told BCS are your target, you need to read the BCS definition first; of course, that references BCAs, so you then need to read that definition; that references Cyber Assets, so now you need to read that definition. 

Why couldn’t these three crucial steps have been each explicitly stated in R1?  Better yet, why couldn’t they have been broken up into three or four separate requirements, as was the case in CIP v1 – v4?  The whole process would have been much easier to understand if this had been done; plus the whole process would have been a lot less susceptible to confusion, as shown below.

5.       The first step for identifying BES Cyber Assets/Systems is to identify Cyber Assets, which are defined as “programmable electronic devices.”  But what does “programmable” mean?  This is on NERC’s list to address, of course, but many entities have decided they can’t wait for NERC to do something to start their BCS identification process.  These entities have developed and documented their own definition (a number of entities – especially owners of large generating stations – did this last summer.  They had to get going on their v5 compliance process then, if they were going to have a good chance to meet the 4/1/16 compliance date).

6.       The definition of BES Cyber Asset includes the phrase “affect the reliable operation of the BES”.  What does this mean, and how do we measure it?  It’s safe to say that no cyber asset has been installed in a substation, control center or generating station purely because it looks nice.  They can all be said to affect the reliable operation of the BES in some way, albeit small.  So what distinguishes BCAs from other cyber assets?  Again, entities that can’t wait for this issue to be clarified by NERC (and NERC hasn’t even listed this as a topic they’ll address in the Lessons Learned) need to develop and document their own interpretation of this phrase.
6.5    In order to classify a BES Cyber System as Medium or Low impact, you need to know which substation or Facility (see below) it is "associated with", since Section 2 of Attachment 1 says that Medium BCS are those that are associated with any asset/Facility that meets one or more of the Medium criteria.  But "associated with" is not defined, nor does NERC currently plan to define it. Each entity needs to develop its own definition (although EnergySec has developed a white paper that discusses this).  It could be an operational definition, stating for example how to determine which Facility or substation a relay is associated with.

7.       Once you’ve identified your BES Cyber Assets, how do you get to BES Cyber Systems?  The definition of BCS is “One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.” While the entity has complete discretion on how to do that grouping, some groupings may be more efficient than others, depending on the environment.  Fortunately, NERC does have a good Lessons Learned document on this question; but again, it would have been nice if this step had been explicitly called out, rather than implicitly included – along with about four other steps – in the single word “Identify” in R1.1 and 1.2.  R1’s use of very compressed meanings works very well if you consider it haiku poetry, but not well at all if you consider it a requirement that in theory can carry million-dollar-a-day penalties for violation.

8.       In any case, through applying three NERC definitions (and adding a couple of our own), we have now come up with a list of BES Cyber Systems, staying strictly within R1 itself.  But in the Guidance and Technical Basis section of CIP-002-5.1, there is a lengthy discussion of the BES Reliability Operating Services (aka BROS), including a description of how they can be used to identify BES Cyber Systems; this is what I have called the “top-down approach” to identifying BCS (what we just did above is the “bottom-up” approach). 

However, the BROS are nowhere referenced in R1 (or the BCA/BCS definitions) itself[iii].  What place should they play in identifying BES Cyber Systems, vis-à-vis the “bottom-up” approach described above?  Should an entity use both approaches and then combine the results, in order to make sure they do not over- or under-identify BCS?  This question isn’t raised, let alone answered, in CIP-002-5.1.  Yet it is very important.  If the entity uses just one approach rather than the other, there is a big risk of either under- or over-identifying BES Cyber Systems.  And another consideration: the only approach that’s actually required by R1 is the bottom-up one (although as I’ve just said, that “requirement” is purely implicit in the definitions of three phrases, not overtly stated).

9.       What is the role of the six asset types (control centers, etc) listed in R1?  Are they meant to be the types of assets that are “run through” the bright-line criteria to determine which are High, Medium or Low, or are they the locations at which BCS can be found?  If the former interpretation is chosen, a number of wording conflicts result[iv].  If the latter interpretation is chosen, it needs to be made clear in your R1 compliance methodology that, even though BES Cyber Systems associated with a Medium impact substation can be located outside of the substation itself, they have to be located at one of the six asset types; otherwise, they need to be treated as remote users (I discussed this question in this very long post, under the section Questions of Scope, about 5 or 6 paragraphs down.  Also in this post, in the section entitled “The Auditor’s Methodology”).

10.   Criteria 2.4 – 2.8 apply to Facilities, not assets.  It is clear that substations are not Facilities.  Rather, Facilities are lines, transformers, busses, etc.  Yet the regions seem to differ in their interpretation of “Facilities” in these criteria.  SPP makes clear that Facilities are the lines, etc; NERC also indicates that.  However, some regional auditors (including Joe Baugh of WECC, in his presentation on CIP-002-5.1 in September) have indicated that “Facilities” means “substations” in these criteria.  Which should it be?  If “Facilities” means lines, etc, there will potentially be a lower compliance burden for Transmission entities, since BES Cyber Systems at a “Medium” substation, that are not themselves associated with a Medium Facility (line, etc) will be Low impact.  For instance, at a 500kV substation that falls under criterion 2.4, relays associated with a 230kV line will be Low impact, not Medium.  Only the relays associated with the 500kV line(s) will be Medium impact.

11.   Criteria 2.4 – 2.8 refer to “Transmission Facilities” as being in scope.  This is to distinguish the lines, transformers, etc. that are associated with Transmission from those that are associated with Distribution; this is important, since in many substations both Transmission and Distribution Facilities are present.  However, there are many questions that arise when it comes to actually separating the equipment out.  There needs to be a definition of Transmission Facilities that entities can use to distinguish the two types of Facilities. 

12.   Medium impact BES Cyber Systems are “defined” in Attachment 1 as those that are “associated with” Medium impact Facilities (in criteria 2.4-2.8), meaning they don’t have to be located at the same substation as the line, breaker or transformer they’re associated with.  However, according to NERC’s recent Lessons Learned document, relays that are associated with a Medium impact line - under Criterion 2.5 - through a “transfer-trip” scheme, but which are themselves located at a Low impact substation (i.e. so-called “far-end relays”), are Low impact. Will this exception apply in other cases where systems (like relays) associated with a Medium impact substation or Facility are located at a Low impact substation[v]?

13.   There are a host of issues that come up regarding equipment located in shared substations.  NERC has promised a Lessons Learned document on this question.  Entities that can’t wait for that will have to “roll their own”.

14.   If a relay (or other device) in a substation is connected serially to an intermediate device like a terminal server or RTU, and that intermediate device has External Routable Connectivity, in what circumstances can the relay itself be considered to have ERC?  In what circumstances should it not be considered to have ERC? 

15.   Criteria 2.6 and 2.9 both refer to IROLs, which are not used in WECC.  How should WECC entities interpret these two criteria without referring to IROLs?

16.   What does “routable” mean?  There are about three places in CIP v5 where a definition is required, but there is no NERC definition.  While this may seem like a fairly well-understood term, it isn’t so clear cut when you look at Modbus/TCP, DNP/IP, etc.  NERC’s very well-written 2010 guideline for identifying Critical Cyber Assets (pp. 26-29) contains a good discussion of this issue.  Should entities assume that, if their definition of “routable” coincides with what is discussed in this document, that they are defining it properly?

17.   What constitutes a “substation” (there is no NERC definition)?  This is important for criterion 2.5.  For example, suppose a substation meets the 3000-point threshold in criterion 2.5, but has two separate control rooms.  If each of these control rooms is considered part of a separate substation (say there is a fence between them, or the entity decides to put one there to lower their compliance costs), then each of the separate substations probably won’t have 3000 points.  Instead of one Medium substation, there would be two Low substations, and all the BES Cyber Systems at both “substations” would be Low impact.

18.   Low impact assets are “defined” in R1 as “assets containing a Low impact BCS”.  But no inventory of cyber assets is required for Lows, and thus BCS will never be identified at Low impact assets.  How is this contradiction to be reconciled?   

19.   Conversely, the implication of this “definition” of Low assets seems to be that assets that don’t contain a Low impact BCS aren’t even Lows.  This is good, but how do you prove it to your auditor, without inventorying all the Cyber Assets at the potential Low asset to show that none of them meet the definition of BCA/BCS?

20.   The beginning of Section 3 (“Low Impact Rating”) of Attachment 1 reads: “BES Cyber Systems not included in Sections 1 or 2 above that are associated with any of the following assets…”  This states pretty clearly that the entity is to a) take their pre-existing list of BCS, b) subtract out those BCS not identified as High or Medium impact in Sections 1 or 2, and c) identify the remainder as Low impact BCS.  There is only one problem with this: The entity is never required to make a list of all their BCS before they start to classify them[vi].  In fact, v5 says explicitly in two places that an inventory of Low impact BCS isn’t required.  How can this contradiction be reconciled?

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Honeywell.

---

[i] The list also contains a couple items – like 14 and 16 – that aren’t really part of R1 per se, but are definitely part of the asset identification process for substations.  Therefore, Transmission entities need to address these at the same time they’re applying R1 to identify BCS.

[ii] Of course, I don’t recommend that Southern California Edison tell WECC that their control centers don’t have to comply with v5; there is too much other evidence in R1 and Attachment 1 that control centers do have to comply.  It was obviously a mistake by the SDT that “Facilities” was capitalized.  I know one region has suggested to NERC that there be an errata filing for all of the v5 standards – since this wording appears in all of them, as well as the v6 and v7 standards – asking to un-capitalize that word in Section 4.2.2.  But I doubt that will happen.

[iii] The BROS were part of the definition of BES Cyber Asset in the first draft of v5, so they were then the “official” means for identifying BCA/BCS; this was changed in the second draft.  See footnote v below.

[iv] For instance, let’s go to the Medium impact criteria in Section 2 of Attachment 1, and see if they “map” to the six asset types.  Each criterion has a subject, generally at the beginning of the criterion.  Some of those subjects do vaguely resemble items on the asset list, but how about criteria 2.2 (where the subject is “reactive resources”), 2.9 (“Each…Remedial Action Scheme (RAS), or automated switching System that operates BES Elements..”), and 2.10 (“automatic load shedding systems”)?  These aren’t on the list of six at all.  Why did the SDT carefully provide us this list of six asset types and tell us to consider them in Attachment 1, then ignore some of them and add some new ones when we actually get to Attachment 1?  The answer is what I’ve just said: the six asset types are the locations where you should look for BES Cyber Systems, not what gets run through the criteria; you classify the BCS themselves using the criteria in Attachment 1.  High BCS will always be located at a High asset, because they have to be “used by and located at” a control center that meets one of the four High criteria.  But Medium BCS don’t have to be located at a Medium asset/Facility, since they just have to be “associated with” the asset/Facility, not “at” it.  It is important to know that a Medium BCS has to be located at one of the six asset types, rather than somewhere else like the home of a manager.

[v] My opinion is they won’t, since NERC’s reasoning for their “ruling” on Transfer-Trip relays was very specifically tied to Criterion 2.5 (and that reasoning had first appeared in this blog post about two months earlier, having been contributed by an Interested Party).

[vi] Actually, in the first draft of CIP v5, which was roundly defeated in the first ballot in December 2011, the wording of R1 clearly required the entity to first inventory all Cyber Assets in its system, whether High, Medium or Low (of course, at this point in the requirement, nothing had yet been classified High, Medium or Low impact).  Then they had to determine which were BCAs (and hence what the BCS were, although the first draft of v5 almost used the terms BCA and BCS interchangeably).  To identify BCAs/BCS, entities had to apply the BES Reliability Operating Services analysis to each cyber asset (since the BCA definition at the time was based on the cyber asset’s fulfilling a BROS).  Of course, this would have been an incredible burden on entities, since it would have literally required spending hours inventorying and classifying every cyber asset they owned.  I wrote a post on this while the first draft was being balloted, and flatter myself that I contributed in a small way to its defeat.  R1 (and the BCA definition) was substantially rewritten at the first SDT meeting after this ballot.