Two days ago
I published a post
pointing out what I believe is a significant unintended contradiction between
CIP-013, the new supply chain security management standard, and CIP-010 R1.6,
one of three new requirement parts that are part of the CIP-013 “package”,
which are being balloted with that standard. Moreover, I believe this
contradiction could, if not corrected, lead to NERC entities having to expend
significant amounts of time and money complying with r1.6 in a way that was
never intended by the SDT.
One of the
great advantages of writing a blog on NERC CIP, but not actually being part of
NERC or one of the regulated entities, is that I get to complain about various
problems I find without having to propose any solution. In the last post, this
is exactly what I did. However, I did think afterwards about how this problem
might be fixed and – as always seems to happen with any question about NERC CIP
that I think about for more than a few minutes – I realized there is a Bigger
Story behind this problem. And, since I’m a Bigger Story kind of guy, I’ve been
pursing that. Here is what I’ve found so far:
The
contradiction at the root of this problem wasn’t in the first draft of CIP-013
(which you can retrieve from the SDT’s web
page). In that draft, all new requirements were included in CIP-013 itself,
not in other CIP standards. What is now CIP-010 R1.6 was CIP-013 R3 in the
first draft, and it read:
“Each
Responsible Entity shall implement one or more documented process(es) for
verifying the integrity and authenticity of the following software and firmware
before being placed in operation on high and medium impact BES Cyber Systems:
[Violation Risk Factor: Medium] [Time Horizon: Operations Planning] 3.1.
Operating System(s); 3.2. Firmware; 3.3. Commercially available or open-source
application software; and 3.4. Patches, updates, and upgrades to 3.1 through
3.3.”
The question
I asked about CIP-010-3 R1.6 in the previous post was what it applied to, and
the answer was “Every piece of software or patch installed on every Medium or
High impact BCS”; there is no provision in CIP-010-3 R1.6 (or in any of the
other requirements or requirement parts in CIP-002 through CIP-011) for ranking
risk of systems and/or vendors, and only performing the required actions for
the riskiest of them. Yet, as I discussed in the previous post, for the second
official draft of CIP-013 R1 and R2 the Implementation Guidance makes clear
that the entity is expected (although not required, of course) in its supply
chain cyber security risk management plan to prioritize vendors and/or systems
by risk, and then determine appropriate controls based on the risk posed by
each vendor or system type.
However,
when you ask this same question about CIP-013 R3 from the first draft (just
quoted), the answer is very different. Since the “documented processes”
referred to in R3 are part of the plan developed in CIP-013 R1, and since that
plan is risk-based, this means (in my opinion, of course) that R3 is a
risk-based requirement as well, and R3 doesn’t necessarily require the entity
to verify integrity and authenticity of every piece of software and patch
installed on any High or Medium impact BCS (as CIP-010 R1.6 does). R3 only
requires this be done for the more risky vendors and/or systems.
The upshot
of all this is that the contradiction I identified in the previous post is a
direct (and I’m sure unintentional) result of the fact that CIP-013 R3 in the
first draft was moved to CIP-010 R1.6 in the second draft. And now that I think
of it, this result was just about inevitable. CIP-010 R1 is a prescriptive
requirement (along with CIP-007 R2, it is one of my two poster children for
prescriptive requirements); any requirement part added to a prescriptive
requirement will itself have to be prescriptive. It will simply have to apply
to every piece of software or patch
installed on every Medium or high
impact BCS, period.
But what if
CIP-013 R3 from the first draft had been moved under a non-prescriptive requirement
such as CIP-007 R3 (anti-malware)? I actually don’t think it would have made a
difference. There is simply no provision in CIP-002 through CIP-011 for the
entity to be able to consider risk in how it complies with any of the
requirements; they all apply to everything that is listed in the Applicable Systems
column, no exceptions. The fact that CIP-013 R3 was moved to one of the other
CIP standards means that it could no longer be tied to the entity’s supply
chain risk management plan, and thus lost the benefit of that plan’s risk-based
approach.
So what are
the lessons of this? There are two that I can think of:
- Be careful what you wish for. A lot of entities commented
on the first draft that they would much prefer that CIP-013 R3 and R4 (the
requirement for controls on remote access by vendors) be moved into the
other CIP standards, rather than continue to be part of CIP-013. I
supported that move, since it seemed to me that CIP-013 itself would be
much more coherent if these two requirements were relocated. However, it
now seems there were severe unintended consequences of this move.
- Any attempt to make the CIP standards entirely non-prescriptive
and risk-based (as I would like to see happen) will very likely run up
against the fact that the whole NERC standards environment – especially CMEP,
which governs how all NERC standards are audited and enforced – has a very
difficult time accommodating anything but purely prescriptive requirements[i].
In fact, I would say they the current NERC standards environment will no
more accommodate true risk-based requirements than a women’s restroom will
accommodate men. I have raised this issue before,
and I’m sure I’ll raise it more in the future: In order to really fix the
problems with CIP, we will need not only new standards but a completely
different auditing process (which requires a new CMEP and perhaps a new
Rules of Procedure).
In fact, as
I will explain in an upcoming post, I’m now wondering if NERC can ever be
flexible enough to make the required changes. Their actions regarding CIP in
the near future will probably be key to whether NERC will still retain
authority for cyber regulation of the power grid, say 2-3 years from now. I
think the time for NERC to make changes is quickly running out.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte.
[i]
You may want to point out that the problem I described in the last post isn’t
caused by the “NERC standards environment” but the particular standard
(CIP-010) that the requirement in question (R3 in the first draft of CIP-013)
was inserted into. After all, you might point out, if R3 had remained part of
CIP-013 this problem wouldn’t have happened. This is a good point, but I also
know that at least some people in the NERC ERO Enterprise are quite unhappy
with the whole standard, so I wouldn’t say CIP-013 itself is established yet,
even though it is likely to be approved by the NERC ballot body and Board of
Trustees.
No comments:
Post a Comment