In my last post,
I concluded with this paragraph: “And this, folks, is the canary in the coal
mine, which has just keeled over dead: It’s clear (to me, anyway) that no
new compliance area (like supply chain or virtualization) can be incorporated
into CIP unless this is done with non-prescriptive requirements. Indeed, no new
prescriptive CIP requirements have been proposed since 2012, when CIP v5 was
approved by the NERC membership. Yet it is also now clear to me that no new
non-prescriptive standards (or requirements) will ever be freely accepted by
the NERC membership until the CIP compliance regime itself has changed. I will
be watching to see what happens.”
To summarize
the argument in this paragraph:
1. New
“compliance areas” won’t be incorporated into CIP unless the requirements
implementing them are non-prescriptive.[i] The two
examples of new compliance areas that I used are supply chain security and
virtualization.
2. But
(as discussed in the last post) no new non-prescriptive requirements will be
“freely accepted” by the NERC membership until the overall NERC CIP compliance
regime has been changed. Of course, I used the phrase “freely accepted”,
because I was arguing in that post that, even though CIP-013 was very likely to
be approved by NERC, it was going to be approved either without a passing vote
by the NERC ballot body (i.e. through use of the Section 321 process) or as a
result of a substantial effort by an important industry trade group to
“persuade” their members to vote yes on the next ballot, despite what are
likely to be substantial misgivings.
3. Therefore
(by implication, although I didn’t explicitly state it), only a compliance
regime change will allow CIP to be expanded to address these and other new
compliance areas.
While I
still agree with my conclusion in point 3, I do have two misgivings about point
2:
First, it is
still possible for new non-prescriptive requirements to be freely accepted by
the NERC ballot body. The changes in CIP-003 (the “LERC” requirement and the
new requirement for Transient Cyber Assets used at Low assets) that were
recently approved by both the NERC ballot body and the NERC Board were freely
approved, although I think the fact that a FERC deadline was looming for the
LERC requirement helped get that one passed. I was frankly surprised, given the
negative comments by many entities on the second ballot, that this requirement
nevertheless received the required super-majority.
However, I
now don’t want to go so far as to say that a new area like supply chain can
never be implemented through exclusively non-prescriptive requirements – i.e.
that the non-prescriptive requirements required to incorporate a new compliance
area (such as supply chain security) into CIP will never be freely accepted by
the NERC membership. I believe CIP-013 would eventually have been balloted,
modified and re-balloted enough times that it would have passed without any
external intervention; it is just that FERC’s very aggressive one-year deadline
for developing the standard precluded this from happening.
But
virtualization is an example of an area that can only be addressed through
modifications of a number of existing prescriptive requirements, as well as new
requirements and definitions. I see no end to the balloting that will be
required to effect all of the changes that might be required to implement
virtualization, to the extent that I am close to certain the current CIP
Modifications SDT will never complete the mandate in their SAR to incorporate
virtualization into CIP.
Second, it
may seem that I am implying in the second point above that only if a new
standard or requirement is “freely accepted” will it be “legitimate”. I agree
that, given the standards approval process described in the NERC Rules of
Procedure, the only “normal” process for approving a new standard is one in
which it receives the required super-majority of votes; this implies that
standards not approved by a super-majority in a ballot are somehow less
legitimate than others. However, while I am a great fan of democracy in
general, I’m not saying that this is the only
way to develop mandatory cyber security requirements. In my opinion, it would
be quite legitimate if for example a group composed of stakeholders (mainly
NERC entities) would both draft and approve new CIP standards; these would then
be submitted to FERC for final approval. Of course, this would require a change
to the NERC Rules of Procedure.
What I was
actually trying to say by using the phrase “freely accepted” was that, if there
isn’t broad consensus among NERC members that a particular standard is a
legitimate one worthy of their attention, the entire compliance process – which
requires a huge amount of cooperation by the entities themselves – will be
thrown into chaos. It will be very hard to convince the NERC membership that
they need to comply with a standard if a majority of members believe complying
with this standard will simply be a waste of time and money with no benefit to
the reliability or stability of the BES. As long as NERC is charged with
developing new or revised standards for cyber security, any standard that is
approved in such a case will almost inevitably end up being changed or
withdrawn before it ever reaches FERC for approval. There is going to have to
be substantial input by the entities into the final product, whether or not it
is expressed in an actual ballot.
However,
implementing a new area of compliance like virtualization (which is, of course,
on the docket for the current CIP Modifications drafting team) will require a lot
of changes to existing prescriptive requirements, as well as some new
requirements, which presumably could be non-prescriptive. To push beyond the
points I made in this
post, I believe just getting the needed non-prescriptive requirements approved
will take literally years (I’m guessing there might be at least five or six new
non-prescriptive requirements required to incorporate virtualization into CIP,
each of which will take at least six months of the SDT’s full attention[ii]).
But
modifying the many existing prescriptive requirements that will need to be
changed to accommodate virtualization will take far longer, both because there
will be more of them but also because there are likely to be epic battles over
the wording of the changes; in prescriptive requirements, the wording is
everything. This is the main reason why I believe the drafting team will never
complete their virtualization mandate.
The same
reasoning would apply to any future effort to allow entities to put BCS in the
cloud (as opposed to putting BCS Information in the cloud, which is already permitted
by the existing CIP requirements), although such an effort is not even being
contemplated at this point. Besides probably some new requirements, this effort
would require substantial changes to almost all of the existing CIP requirements,
prescriptive and non-prescriptive. I think trying to make these changes in the
existing set of CIP requirements would require something like a generation of
effort, so SDT members would need to be recruited fresh out of college with the
somewhat slim hope that they will finally accomplish their goal before they
retire. Not exactly a formula for success, IMHO.
To
summarize, in this post I tried to clarify the conclusion of my last post (not
sure I succeeded, though). Instead of implying (as I did in that post) that
there can never be any expansion of CIP to address new areas of compliance, I
want to say that there can be
expansion that doesn’t require changes to existing CIP requirements (as is the
case for CIP-013. Even though the new draft will include changes in several
existing CIP requirements as well as a revised CIP-013, the wording of the existing
requirements themselves wasn’t modified, just added to). But for areas like
virtualization and BCS in the cloud that do require changes to existing
requirements, I believe that expanding CIP to cover these areas will never be possible
until all of the CIP standards are rewritten from scratch, and incorporated
into a new compliance regime similar to the one I outlined in my last post.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte.
[i]
In fact, as I will point out in my next post, no new prescriptive CIP
requirements at all have been drafted since CIP v5. This is not by chance: Both
NERC and FERC now realize that non-prescriptive requirements are the only way
to go when it comes to cyber security.
[ii][ii] I’m basing
this estimate on the fact that the LERC requirement – which was
non-prescriptive – took more than six full months of the SDT’s time, using my
informal observations. And this requirement was a modification of an existing
prescriptive requirement. The SDT made it non-prescriptive and thus allowed
entities more options for complying with it, without removing any options they
previously had, yet it still was greeted with a lot of concerns and even
outright hostility. So my guess is that getting a brand new non-prescriptive
requirement approved would take significantly more of the SDT’s time than six
months – which is why I think my estimate of six months for each new
requirement is quite conservative.
Despite wide-spread suspicion of "new" technology (that has well over a decade in operation in a broad spectrum of highly-secure IT environments), the security measures for virtualized environments are NOT wildly different from those in physical environments.
ReplyDeleteWhere NERC CIP goes off the rails is where it tries to invent specific definitions unique to the utility industry rather than using standard IT Security terminology and concepts, and then tuning and tuning the definitions and wording until they can't find use cases that allow people to weasel out of the strict parsing of requirements language using grammatical tricks. It's a lawyer's approach to compliance, not a security professional's approach to safeguarding critical infrastructure. But it's the approach people are conditioned to expect.
It's also the wrong approach; you can't possibly cover every use case in any document that is humanly readable.