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