Monday, March 7, 2016

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.

No comments:

Post a Comment