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.