Sunday, July 9, 2017

Expanding on my Last Post

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 they 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:

  1. 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.
  2. 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