Location, Location, Location

Location, Location, Location

…

Things fall apart; the centre cannot hold;

Mere anarchy is loosed upon the world,

…

The best lack all conviction, while the worst

Are full of passionate intensity.

…

And what rough beast, its hour come round at last,

Slouches towards Bethlehem to be born?

W. B. Yeats, The Second Coming (1919)

Let me start by admitting the above quotation has nothing to do with this post. I was just struck by the remarkable fact that Yeats eerily foreshadowed the 2016 US election campaign almost a hundred years ago!

Now to my topic: I’ve realized for a while that one of the biggest sources of confusion in CIP v5 and v6 is the concept of Location. As with other sources of confusion in v5, the cause of this isn’t that people are stupid, but that there are contradictions and missing definitions in CIP-002-5.1 R1 and Attachment 1. I can’t do anything about those contradictions and missing definitions, but perhaps the Standards Drafting Team can. In this post, I’ll try to describe the following:

1. How almost all NERC entities, regions, and NERC itself are interpreting the concept of location in CIP-002 R1;
2. What I  (aided by one or two Interested Parties) interpret the words regarding location to really mean; and
3. How I think the words of R1 and Attachment 1 might be rewritten to make CIP-002 R1 both more understandable and (perhaps) more enforceable than it now is.

I.                    The Prevailing Understanding

As I discussed in this post, the general understanding of how Location works in CIP-002-5.1 R1 is that the entity needs to start with the list of six asset types in R1, then “run” this list through the Attachment 1 criteria to identify High, Medium and Low impact assets. Once this has been done, the entity needs to identify BES Cyber Systems located at High or Medium assets. These BCS become subject to the High or Medium impact requirements of CIP-003-6 through CIP-011-2. Meanwhile, Low impact assets (aka “assets containing Low impact BCS”) are subject to CIP-003-6 R1.2 and R2. I can count to ten and include all of the individuals – whether employees of NERC entities, NERC regions, or NERC itself – who have stated within my hearing that this isn’t actually how R1 and Attachment 1 are written.

Of course, this isn’t how R1 and Attachment 1 are written, as I discussed in the above-linked post. But I also pointed out that this isn’t necessarily a bad thing. In fact, I don’t see any other way that entities can reasonably be expected to comply with R1 except by taking this approach. And I certainly don’t think they should receive PVs because they didn’t follow the exact meaning of the words of R1, since that meaning is very difficult to ascertain, as I’ll describe next. The problem this causes is that it makes R1 (and perhaps all of the other CIP requirements) unenforceable in the strict sense that a fine for violating it is unlikely to be upheld if appealed to the court system.

II.                  How I Interpret the Words

There are two main problems with the Prevailing Understanding of Location. The first is that Attachment 1 explicitly states that the High and Medium impact criteria are for classifying BES Cyber Systems, not assets, so the six asset types listed in R1 must serve another purpose than the one assumed in the PU. The second is that the “preamble” to Section 2 of Attachment 1 states that the entity needs to identify BES Cyber Systems “associated with” the Medium impact criteria in that section. In practice, this means that a BCS doesn’t have to be physically located at the asset in order to be Medium impact due to that asset.[i]

Let’s deal with the first problem first (although you’ll see that in dealing with that problem we’ll also end up dealing with the second one). Why is the list of six assets in R1, since it isn’t there to do what the Prevailing Understanding thinks it does – furnish the set of assets that is run though the Attachment 1 criteria? An Interested Party explained this mystery to me a couple of years ago, pointing out that this list is actually the six types of locations where BES Cyber Systems that are subject to the requirements of CIP v5 can be found; if they are located anywhere else, they aren’t in scope for v5.[ii]

Here’s an example. Suppose someone uses a remote computer system to make changes to settings of physical systems in a generating plant that has been designated as “necessary to avoid an Adverse Reliability Impact…” as described in Criterion 2.3. Since the loss, misuse, etc. of this computer could “adversely impact” the BES within 15 minutes, this means this system is a BCS. But is it a Medium impact BCS?

Let’s say this system is located at a generating plant, which is otherwise Low impact. Since that plant falls under one of the six asset types in R1, this means the system would be a Medium BCS, because it is located at one of the six asset types and because it is associated with an asset meeting criterion 2.3.

As an aside, you might or might not consider the entire plant a “Medium” one. If you could physically and logically protect the single Medium BCS in the plant so that it complied with all of the appropriate v5 requirements, without involving any other systems that might be in the plant, then you might still consider the plant simply a Low one with one Medium BCS. Otherwise, you’d have to say the plant is both Medium and Low impact – and if your Regional Entity is requiring a list of Medium assets, you would need to include the plant on that list, as well as the list of Low assets. In either case, you would need to include the one Medium BCS on the list of Medium BCS.

Now suppose that the system is located in somebody’s living room. Since a living room (or the house that contains it) isn’t one of the six asset types, that system won’t be a Medium BCS. In fact, it won’t be a Low BCS either, since Low BCS also have to be located at one of the six asset types. It might theoretically still be a BCS, but that is a purely academic question; you don’t have to deal with this computer in CIP v5.  Of course, since it is being used for Interactive Remote Access, its use will be subject to CIP-005 R2 and the systems in the ESP located at the Medium plant will presumably be protected that way.

In practice, I believe that the only serious cases of BCS at Low impact assets, that might have become Medium impact, were “far-end relays”. This became a big issue in 2014. I wrote this post describing the problem, and this post describing an Interested Party’s solution to the problem. In fact, the IP’s solution was so good that NERC later adopted it wholesale for their Lesson Learned on this issue.

The IP’s argument was very specific: This problem only comes up in the case of substations subject to criterion 2.5. Since there is very specific language in 2.5 that protects against exactly this situation, it isn’t a problem. In this case, the words “associated with” don’t reach out to BCS located at Low impact assets and make them Medium impact. But can it happen elsewhere? That is, are there cases where the “associated with” wording will lead to BCS at Low assets becoming Medium impact? To be honest, I haven’t found any cases where that will happen, although I admit I haven’t conducted a survey to identify if there are such cases.[iii]

III.                How I Would Rewrite the Words

How would I rewrite the wording of CIP-002-5.1 R1 and Attachment 1 to address these two issues? To address the first issue – regarding the six asset types – I would rewrite that section of R1 so that it made clear that the six asset types are only locations at which BCS can be found, not the “raw material” that gets fed into the Attachment 1 process in an effort to classify Medium or High impact assets (or BCS).[iv]

Regarding the second problem of “associated with”, it seems to me that, even though there may be a few BCS at Low assets that could become Medium impact due to that wording, it isn’t worthwhile requiring entities to do the extra work needed to identify these BCS (they will still be protected at a Low level where they are). I think Medium BCS should be identified just like High ones are: they are BCS located at a High or Medium asset (or Facility). Of course, to do this would require v5 purists to admit that there are actually such things as High and Medium impact assets – even though the strict wording of CIP-002-5.1 doesn’t countenance such things.

However, as I’ve said many times, virtually all NERC entities and regions are acting as if High and Medium assets (or Facilities) are real – so I suggest the purists get over this. Similarly, if I thought that unicorns were very important to help lots of people get through their day, I’d be the first to suggest we simply say they’re real and move on. Life is too short to worry about finer points of wording when everyone agrees on what it means – even if everyone is wrong.

  

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

---

[i] You may notice that there is a direct contradiction here. I just got through pointing out that Attachment 1 says the High and Medium criteria are for classifying BCS. Yet by saying that a BCS is Medium because it is “associated with” one of the Medium criteria, the original SDT was admitting that the criteria really apply to assets in some way! This is because R1 and Attachment 1 were written at different times from two different viewpoints, and they were never reconciled with a set of consistent wording. This clash of contradictory viewpoints is what I have called the fundamental problem of CIP-002; it manifests itself in a number of places in the wording.

As a further note, this issue doesn’t appear for High impact BCS. The preamble to Section 1 of Attachment 1 says that High BCS are those “used by and located at” a Control Center that meets one of the four High criteria. So High BCS can only be located at a Control Center that meets one of criteria 2.1 to 2.4.

[ii] I won’t take the time to try to prove this to you, but I’m sure it’s right – even though the wording of R1 seems to go out of its way to obscure this point. I will point out that you can get a good clue that this is the case by considering the fact that the wording of 1.2 would contradict the words “associated with” in Section 2 of Attachment 1, if the word “asset” in 1.2 referred to the asset that meets one of the Medium criteria. So “asset” in 1.2 must refer to one of the six asset types, thus making 1.2 (and 1.1 and 1.3) refer to the locations where Medium BCS can be found. This resembles the word puzzles I used to enjoy doing as a boy; unfortunately, it’s not a wonderful practice to build a regulatory framework with potential million-dollar-a-day penalties on a foundation of word puzzles, as seems to have been done in the case of CIP version 5.

[iii] I initially thought that Automated Generating Control (AGC) systems that controlled Medium generating plants might be located at Low impact plants or at substations, and thus be themselves Medium impact. But nobody has told me they know of an example where this actually is the case.

[iv] In stating this, I’m conveniently (for me) leaving out the much bigger problem – the fact that Attachment 1 (and parts of R1) is written assuming that BCS themselves are first identified, then run through the criteria to classify them High or Medium, while almost every NERC entity and auditor – from what I have seen – approaches R1 in the same way they did CIP-002 in version 3. That is, they first classify the “big iron” (High, Medium or Low assets in v5; Critical vs. non-critical Assets under v3), then they classify the Cyber Assets that are critical to the asset with the same classification as the asset itself (H/M/L BCS in v5, and Critical vs. non-critical Cyber Assets under v3). Fixing this problem will require a complete rewrite of CIP-002-5.1, and from what I’ve seen there is no appetite on NERC’s part to do this. And as I’ve recently said, I no longer think it’s worthwhile trying to come up with a comprehensive fix for the problems of CIP versions 5 and 6. I think CIP needs to move in a different direction, a sustainable one.

What Did FERC Mandate?

At the NERC CIPC meeting last week in Louisville, KY, Tobias Whitney of NERC summarized the main issues that the Standards Drafting Team will address in CIP version 7 (although the dreaded term “version 7” was not mentioned, of course). Included in his slides was one that listed what FERC had mandated for the next version when they approved CIP v6 in Order 822 in January. The items listed were[i]:

• Protection of transient electronic devices used at low-impact bulk electric system cyber systems,
• Protections for communication network components between control centers, and
• Refinement of the definition for Low Impact External Routable Connectivity (LERC). 

Being very astute on these matters, I immediately noticed that one item had been left off this list: protection of data in motion between control centers (you can find my interpretation of what FERC ordered in the second post linked above). I pointed this out to Tobias, and he admitted this was a mistake and said it would be fixed.

Indeed, the website for NERC’s new “Project 2016-02 Modifications to CIP Standards” also lists three points as above, but one of them is now “Develop modifications to the CIP Reliability Standards to require responsible entities to implement controls to protect, at a minimum, communication links and sensitive bulk electric system data communicated between bulk electric system Control Centers in a manner that is appropriately tailored to address the risks posed to the bulk electric system by the assets being protected (i.e., high, medium, or low impact).”

You’ll notice that this point now includes both “communication links” (which I assume means basically the same thing as “network components” in Tobias’ slides) and “sensitive bulk electric system data communicated…” I believe this latter phrase addresses what FERC was asking for in Order 822 when they stated “..we find that additional measures to protect both the integrity and availability of sensitive bulk electric system data are warranted.” I think it would be clearer if these two items were in separate bullet points, but this does address what I brought up at the CIPC meeting.

However, I now realize that, in my post on Order 822, I identified five changes that were mandated, not just four. The fifth one (also not mentioned by Tobias) is protection of “data at rest” inside Control Centers. Unlike data in motion between Control Centers, the mandate to protect data at rest was not hinted at in FERC’s NOPR last summer. Yet FERC makes it clear they want these protections in the Order when they say “NERC’s response to the directives in this Final Rule should identify the scope of sensitive bulk electric system data that must be protected and specify how the confidentiality, integrity, and availability of each type of bulk electric system data should be protected while it is being transmitted or at rest (my emphasis).”

As I stated in my post on Order 822, this new mandate might well be the most important, especially in terms of the amount of effort it will take to turn it into requirements, and for NERC entities to comply with those requirements. This is a whole new expansion of the scope of NERC CIP, but it has to be addressed. After all, FERC wants it.

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

---

[i] These are NERC’s words, not mine. These three items are listed in the email that NERC sent out last week which announced the CIP Technical Conference in Atlanta on April 19. Since Tobias’ slides haven’t been released yet, I can’t confirm they had this exact wording; however, I’m sure that substantively it was the same.

A Big Implicit Requirement

I’ve written about implicit requirements in CIP versions 5 and 6 previously; these are tasks the entity needs to do to comply with the v5/v6 requirements, that aren’t actually themselves specified as requirements. An example of implicit requirements is identification of EACMS, PACS, ESPs, and Protected Cyber Assets. Even though many requirements are written on the assumption that the entity has identified these, the entity is never required actually to identify them.[i] The requirement is implicit, but obviously must be followed nevertheless.

Over the last six months or so, I have been putting together a list of implicit requirements in CIP v5. A few of them currently say something like this: “Compliance with this requirement must be done on the level of each component of a BCS, not just on the BCS level.” What this means is that, even though the requirement in question (like most CIP v5/v6 requirements) is applicable to BES Cyber Systems, it is really the components of each BCS (all Cyber Assets, of course) that are in scope. I had assumed this was only the case for a few requirements, including patching and anti-malware. Obviously, both of these requirements are only effective if they apply on the BCS component level.

However, I had the good fortune to be asked to address MISO’s CIP User Group recently, and in a different part of the meeting there was a discussion of the issue of BCS vs. components. It was pointed out that there are actually many more requirements where the components, not the BCS themselves, are in scope than I had thought.  I went back to the standards and found the following requirements to be component-level ones:

• All the requirements of CIP-007;
• All the requirements of CIP-009;
• All the requirements of CIP-010; and
• CIP-011 R2

And if you think about this, the above are almost all of the requirements that apply to cyber assets or systems. Most of the other requirements apply at the organizational level (security policies, physical protection, CSIRP, etc), even though they may state they apply to BCS. Just about the only requirements that actually do apply to BCS – as far as I can see – are CIP-004 R4 and R5, both of which have to do with access control. This actually makes sense, since most systems require just one authentication that applies to all components; you don’t have to authenticate for each component.  These requirements definitely should apply on the BCS level.

This is all quite interesting to me, because I remember the history: The first draft of CIP v5, which was released (and soundly voted down) in late 2011, used the BCA and BCS terms rather promiscuously. This led to complaints, and the idea that there should just be one term, not two. The next version standardized on the BCS term. I remember the example brought up to justify this step was that authentication was almost always done on the system level, so BCS was obviously the appropriate concept to standardize on. I thought that was reasonable until the MISO meeting, when I realized that BCS-level compliance is really the exception, not the rule.

However, if the SDT had standardized on BCA, that would have been inadequate, too. The reason why is described in my previous post, where I point out that in some cases (depending on how they’ve identified their BCS), the entity won’t have identified BCAs – just BCS. This is because entities are neither explicitly nor implicitly required to identify BCAs in CIP v5. If the SDT had chosen to standardize on BCA instead of BCS as the standard for applicability, this would have in some cases forced the entity to do a lot of extra work to identify BCAs, for no gain in either compliance or security.

I’m sure this wasn’t the SDT’s reasoning, though. It must have been something like “If we standardize on BCAs, then we will force entities to always comply on the cyber asset level, not the system level. But if we standardize on BCS, they can exercise either option.” In retrospect, there are two problems with this reasoning. First, it assumes that all BCS components are BCAs, which isn’t true, as discussed in the previous post. So if the BCS components were to be the standard for applicability, the applicability wording in all of the requirements listed above would have to be something like “Cyber Assets that are components of BES Cyber Systems”, not “BES Cyber Assets”.

Second, by having all requirements apply to BCS, the SDT ensured that the literal meaning of the words of CIP v5 was that only BCS were in scope. This means that the only way literally to comply with v5 is to have a one-to-one correspondence between BCA and BCS; that is, every BCA is its own BCS, period. Of course, this effectively eliminates the advantage of having BCS in the first place[ii]. But – given that it’s clear that requirements like patch management need to be applicable on the BCS component level – how can you assure these requirements will be properly complied with other than by doing this?

However, in practice this isn’t a huge problem. Even though the standards now say that only BCS are in scope, I’m sure the regions have all made it clear at some point that they will audit on the component level where appropriate, which means for the requirements listed above. And an Interested Party pointed out to me that the evidence workbook published by NERC last fall specifically states that, in the component-level requirements, evidence is required for all “Cyber Assets that are members of (a Medium or High BCS)”. 

So does this discrepancy between the v5 wording and how entities will be complying with it pose a problem? The situation is the same as the one I discussed in this post, where I distinguished between enforceability in the strict and not-so-strict senses. In the not-so-strict sense, CIP v5 will be perfectly enforceable even with this problem, since there is agreement between both auditors and entities that this is the correct way to comply.

This results in the same situation as what I described in this post regarding how entities and auditors are interpreting CIP-002-5.1 R1: They are both interpreting these requirements in the same way, which means the requirements are enforceable in the not-so-strict sense. But in the strict sense, in my opinion these requirements will never be enforceable until their applicability sections are rewritten to reflect that they apply on the component level. It would be nice if that were on the v7 SDT’s agenda, but it isn’t now.

  

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

---

[i] In fact, there isn’t actually a requirement to identify BES Cyber Systems, either. Where the word “identify” is used in CIP-002-5.1 R1.1 and R1.2, the word really means “classify”. This is because Attachment 1 (where you are sent to “identify” your High and Medium BCS), is written on the assumption that the BCS have already been identified, and just need to be classified. Of course, the lack of a requirement to identify BCS means there is no required methodology to identify BCS. Naturally, this has led to a lot of confusion.

[ii] I know some entities are taking this approach. As discussed in the previous post, it does greatly simplify the BCS identification process, since it eliminates a lot of the confusion caused by inconsistency and ambiguity in CIP-002-5.1 R1. On the other hand, it probably does significantly increase the compliance paperwork burden.

Is Every Component of a BCS a BCA?

This post started as a footnote to the post I will put up next. When it became clear that the footnote was going to be much longer than the post itself[i], I decided the footnote needed to be its own post and to publish it first – since it’s a “prerequisite” for the other post.

Like most people involved with NERC CIP, I originally thought that every component of a BES Cyber System must be a BES Cyber Asset. This would seem to be implied by the definition of BCS: “One or more BES Cyber Assets logically grouped…to perform one or more reliability tasks…” However, more than a year ago an Interested Party pointed out to me that it is perfectly possible to have Cyber Assets included in a BCS that are not BCAs. This takes a little explaining.

I have discussed a number of times – the most succinct probably being in this post – the two basic methodologies for identifying BCS; I call these “top down” and “bottom up”. The bottom up methodology, in its pure form, would always result in every component of a BCS being a BCA, since it is essentially the methodology that is implied by the definitions of BCA and BCS: You first identify your BCAs, then you aggregate these into BCS (of course, you can also make each BCA its own BCS. In my opinion, this imposes a much greater compliance burden on the entity, but it does have the advantage of eliminating a lot of the potential confusion in BCS identification).[ii]

But even though the top-down approach isn’t implied by either the wording of R1 or by the definitions of BCA and BCS, it is supported by the discussion in the Guidance and Technical Basis section of CIP-002, so it shouldn’t be dismissed. More importantly, it is an easier methodology to implement, in the sense that it requires less data-gathering on individual devices and more pure thinking. My guess is that a lot of entities have used this methodology, probably without explicitly identifying it.

In the top down approach, you start by identifying the BES Reliability Operating Services (BROS) that your asset or Facility fulfills. Then you identify those that affect the BROS within 15 minutes.[iii] These systems are all BCS.

But are you done at this point? From everything that you can tell from the wording of R1, you are done. However, I highly recommend you not stop at this point. This is because there can well be Cyber Assets that meet the definition of BES Cyber Asset, but which aren’t included in any of the BCS you’ve identified. The reason for this is that a Cyber Asset can impact the BES without fulfilling a BROS.

In the above-referenced post, I discussed the hypothetical case of a CEMS system in a power plant that is programmed to shut the plant down within ten minutes if there’s an environmental excursion. If it were misused, the plant would shut down; this would obviously impact the BES within 15 minutes. However, since environmental monitoring isn’t a BROS, the CEMS wouldn’t be identified in the “pure” top down methodology (although such monitoring is very important, it isn’t needed for reliability. The lights will stay on no matter how much the environment is being degraded).

For this reason, the “top down” methodology I discuss in the above referenced post (and others), has an added step after the initial BCS identification: You should go through all of your Cyber Assets (i.e. programmable electronic devices) that are not components of one of the BCS you’ve identified, and identify any of these that meet the BCA definition. These should then either be included in a new BCS or grouped into an existing one. You now have your complete BCS list. You can now be sure that there are no BCAs that have not been included in one or more BCS.

But here’s a question: Why should you care whether or not you’ve identified all of your BCAs? You are never explicitly required to identify BCAs in R1. More importantly, you’re never implicitly required to identify BCAs either, since none of the v5 or v6 requirements ever refers to BCAs. If you want to follow the wording of R1 as closely as possible, all you have to do is identify your BCS by the “pure” top-down methodology (i.e. without the extra BCA identification step), and you’re done.

Let me repeat this: Even though a lot of entities have invested a lot of time trying to figure out how to identify their BCAs – especially given the ambiguity around the phrase “adversely impact” in the BCA definition – identifying BCAs is not required at all, given the wording of CIP-002-5.1 R1. And it isn’t implicitly required either, since there is no requirement in any of the standards that applies to BES Cyber Assets.

Then why do I say you should make sure that all your BCAs are accounted for in BCS? Because it was clearly the intent of the Standards Drafting Team to make sure that all BCAs at Medium and High assets or Facilities are protected - but they unfortunately never stated this explicitly in the requirements. The fact that the heart of the BCS definition is the words “BES Cyber Assets” is evidence of this. I expect that no auditor will be happy if he or she finds a Cyber Asset, like the CEMS system above, that he thinks should be a BCA, but which you haven’t identified as part of any BCS. You might tell him or her that you only used the pure top-down approach (which is definitely easier!) to identify your BCS, and you stopped after that because you aren’t actually required to identify BCAs. And the next thing you know, he’ll hand you a PV.[iv]

Since it may seem that I’ve gone astray, let me summarize what I’ve said so far. We started out with the question whether every component of a BCS is a BCA. I’ve gone through the discussion of the top-down and bottom-up BCS identification methodologies because the answer to the original question will depend on the methodology you used to identify BCS. If you used the bottom-up methodology, the answer is yes, every component of a BCS is a BCA. Since your objective is to include every BCA in a BCS, why would you then include other non-BCAs as well?[v]

But if you used the top-down methodology, the answer is no. Not only is it very possible that not every component of a BCS will be a BCA, it also may be that you don’t have to identify BCAs in the majority of your BCS; you can just identify their components as “BCS components” and leave it at that. Let me explain.

Remember that the top-down process includes two parts. The first is the “pure” top-down part, where you simply identify systems that fulfill a BROS within 15 minutes. For the components of these systems, why should you even bother to worry whether they’re BCS or not? Since the v5 requirements all apply to BCS, not BCAs, the components will all be protected as if they were BCAs. There is simply no need to take the additional step of looking at the components one-by-one to determine whether they meet the BCA definition.

However, in the second part of the top-down methodology, you do need to look at Cyber Assets to determine if they’re BCAs or not; then you need to include these in BCS. But you only have to do this for the Cyber Assets that aren’t part of a BCS already. In general, I would think there will be few (if any) BCA/BCS that are identified this way, so your job will be a lot smaller than it would be with the bottom-up approach, where you have to look at every single Cyber Asset to determine if it is a BCA.

So the answer to my original question, whether every component of a BCS is a BCA, is no, unless you used just the bottom-up methodology to identify your BCS. As I said, I needed to answer this question before I could write the post I intend to put up next. However, I hope this discussion of the top-down and bottom-up BCS identification methodologies will be of help to you as you work on your CIP v5/v6 documentation (and see footnote ii for a discussion of what you need to be doing regarding your BCS identification methodology, even though you’ve presumably already identified your BCS if you have High or Medium impact assets or Facilities).

PS: I want to emphasize that this discussion provides another reason why CIP versions 5 and 6 (and most likely 7) will never be enforceable in the strict sense, as discussed in this post. The fact that I had to go so far beyond the wording of the requirements to answer a fairly simple question shows that a fine for violation of CIP-002-5.1 R1 could never be upheld in a court of law, in my opinion. And it is also my opinion that, without this requirement – the fundamental requirement in CIP v5/v6 – the rest of the edifice cannot stand.

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

---

[i] I should have realized that any discussion of issues with CIP-002-5.1 R1 is bound to be long and convoluted. Even after I made the footnote its own post, its length doubled or tripled from what I originally thought it would be.

[ii] You may wonder why I’m bothering to discuss CIP v5 asset identification methodologies so close to the v5 compliance date. I’m certainly not doing it because I think there are NERC entities with High or Medium assets or Facilities that haven’t identified their BES Cyber Systems yet! However, you not only need to identify your BCS, but you need to document the methodology you used to do so. And you need to document that you applied this methodology consistently across your assets. Since neither of these steps is explicitly required by v5, they come under the category of implicit requirements. As discussed in this recent post, you don’t need to have all of your documentation for implicit requirements in place on the compliance date, since there is no obligation to self-report non-compliance with an implicit requirement – unless that non-compliance makes you violate an explicit requirement. But you definitely need to have it in place before you are audited, since – if the auditor asks you to show why you didn’t identify some particular Cyber Assets as BCA/BCS – you will need to be able to show him or her your methodology and that it was consistently applied. And even though you have already identified your BCA/BCS, you should now develop your methodology and “retrofit” it so that all of your BCA/BCS identifications are shown to logically follow from it (and if they don’t, then you need to rethink either your BCA/BCS identifications or your methodology!).

[iii] You may ask why I bring in the 15 minute criterion at this point. Because that’s in the BCA definition, of course. But why do I bring in the BCA definition, since BCAs are nowhere referred to in any of the CIP requirements? That’s true, but the BCS definition is based on the BCA one, and since we’re identifying BCS -and since R1 doesn’t give us any help on how to do this - we’re forced back on the definition to provide us a roadmap. I’ll admit this is a pretty convoluted argument. When you enter the world of CIP-002 R1, you enter into a hall of mirrors. All arguments are convoluted.

[iv] Of course, were you to be fined for this violation and were you to appeal the fine to the courts, I’d say your chances of winning the case would be very good. Most entities don’t want to take this chance, though. I would say there are definitely some cases of real ambiguity where you should take a substantial fine to court, but as I said I think it’s pretty clear that the intent of the SDT was that every BCA should be included in a BCS – so in this case it wouldn’t be a good idea to challenge that.

[v] There actually is a good answer for why you might include some non-BCAs in BCS if you have used the bottom-up methodology. This is because, if a Cyber Asset is a component of a system, it will most likely be on the same network as that system. So if the system is a BCS, then the Cyber Asset will be a Protected Cyber Asset, even if it isn’t explicitly included in a BCS. Since the requirements that apply to PCAs are almost exactly those that apply to BCS, you don’t gain anything by leaving it outside of the BCS. It may be slightly easier, from a record-keeping point of view, to include non-BCAs, that would otherwise be PCAs, in a BCS. But I think it’s probably close to a wash either way.