More on implicit requirements: Lew’s article

In my last post, I went back to a topic I’d only touched on briefly in a post a few years ago, but which is certainly an important concept to understand if you are working on NERC CIP compliance nowadays: implicit requirements. I mentioned that I first heard the term from Lew Folkerth of RF in a presentation in October 2015.

But I neglected to also mention that Lew wrote an article for the RF newsletter on this subject in December 2015[i]. I just went back and reread it. To my great surprise – and I just now took a quick look out the window to make sure there weren’t any dark clouds that might strike me down with a bolt of lightning – I actually find myself disagreeing with Lew.

This article is done in a Q and A style, although I suspect the Q’s and the A’s were both written by Mr. F (nothing wrong with that, of course). In his first A, Lew says that implicit requirements are due to the fact that CIP v5 was written as “results-based Standards”. He goes on to explain “In a results-based Standard, the desired end result is specified, with the method of achieving the result left unspecified. This provides great flexibility in how the result is achieved, but one effect is that some actions that are actually required are not explicitly stated in the Standard.” In other words, he’s saying that implicit requirements are actually a virtuous byproduct of the drafting team’s high-minded purpose of making all of CIP objectives-based.

First off, the CIP v5 standards aren’t results-based or anything-else-based. Some of the requirements are results-based (CIP-007 R3 and CIP-011 R1, to name two). But these aren’t the ones with a whole set of implicit requirements built into them. Implicit requirements are only a problem when the underlying requirement is prescriptive. In my last post, I provided several examples of prescriptive CIP requirements that contained lots of implicit requirements. The basic pattern that leads to a lot of implicit requirements is that the base requirement uses a number of words that each then lead to one or more implicit requirements.

To show what I mean, let’s turn to CIP-007 R2, my poster child for a prescriptive requirement. R2.2 says “At least once every 35 calendar days, evaluate security patches for applicability that have been released since the last evaluation from the source or sources identified in Part 2.1.” Let’s say you’ve never seen this requirement before, and you’re trying to understand what you will need to do to comply with it. You’ll ask a set of questions, and the answers in most cases will lead to an implicit requirement:

Q1: How do I know which security patches have been released since the last evaluation?

A1: You approach the patch sources you identified in Part 2.1. This leads to the first implicit requirement:

IR1: Identify patch sources to approach regarding new security patches.

Of course, each implicit requirement usually leads to a new question.

Q2: I have a lot of patch sources. Do I need to approach them all?

A2: No, you just have to approach the patch sources for the software and firmware packages that you currently have installed on systems within your ESP.

Q3: How do I know what those software and firmware packages are?

A3: You take an inventory of all software and firmware currently installed on systems in your ESP.

This answer leads to another prescriptive requirement:

IR2: Every 35 days, take an inventory of all software and firmware currently installed on systems in your ESP.

Q4: Do I need to inventory anything else?

A4: Yes, you need to list the version numbers. Of course, this leads to:

IR3: Include version numbers in your inventory.

Q5: Anything else?

A5: Yes, now that you mention it. If the software includes various third-party applets, you need to inventory those as well. This leads to:

IR4: Include all applets for any software package in your inventory.

Q6: OK, now that I know what I need, what’s my next step?

A6: You’re ready to go. Now you need to find out from each patch source if they have a new security patch this month. This leads to:

IR5: Ascertain from each patch source identified in Part 2.1 whether a new security patch has been released.

Q7: What do I do now?

A7: You evaluate each patch for applicability.

Q8: And what’s applicability?

A8: A patch is applicable if it can be applied.

Q9: Well, that’s really helpful! So what patches can be applied?

A9: There are a lot of factors that determine applicability. For one, a patch is applicable if it is for a software or firmware package that is installed on at least one system in your ESP, taking into account the version number and any possible applets. This leads to:

IR6: Discard as inapplicable any patch that doesn’t apply to a software or firmware package that is installed on at least one system in your ESP, taking into account the version number and possible applets.

Q10: Does anything else determine applicability?

A10: Well, yes. What if you’ve already installed the patch? And what if you’ve installed a different patch that also closed the vulnerability that the current patch addresses? In both cases you shouldn’t install the new patch……

Q11: I’m getting a headache…

A11: That isn’t a question. If you’re looking for headache remedies, I recommend name of product removed.

OK, that’s enough. We’ve listed six implicit requirements so far, and A10 will lead to at least two more. Most important, we’re just getting started on “applicability”, since there are all sorts of other considerations that would lead one to declare a patch to be applicable or not. So it turns out that just this one part of CIP-007 R2 (and the requirement has four parts) has well over eight implicit requirements. It’s not out of the question that each of the 40-odd CIP requirements, leaving out CIP-002 R1 for the moment, has between 5 and 50 implicit requirements, leading to somewhere between 200 and 2000 implicit requirements in CIP.

And I deliberately left out CIP-002 R1, since – as I mentioned in my last post – just the “bright-line” criteria in Attachment 1 could easily lead to almost an infinite number of implicit requirements. But I won’t try to justify this statement, since it’s like delivering an ocean instead of a lake, when all you had asked for in the first place was a cup of water.

So what does it mean – this discovery (and it’s almost as much a discovery for me as for you) that there are a huge number of implicit requirements in the CIP standards? For one thing, it means that the goal of coming up with a definitive list of implicit requirements (as I mentioned that Lew had initially talked about doing, in the last post) is certainly well-intentioned, but nothing that can be accomplished in a human lifetime. Face it: There is always going to be a lot of uncertainty around how you comply with the prescriptive CIP requirements.

Uncertainty isn’t good when you’re talking about mandatory requirements with big potential fines. What’s the solution? In the near term, the solution is the same one as for all of the other problems with CIP: It will be handled one-on-one between the auditors and the Responsible Entities, as all the other problems have been handled. I wrote over 50 posts on the problems with CIP-002 R1 after CIP v5 was approved. None of these problems was ever resolved, yet the CIP compliance process today works fairly smoothly. This is because all parties – NERC, the Regions (especially the auditors) and the entities – have a big stake in having things run smoothly. They have always figured out how to do it in the past, and they’ll continue to do that. I call this the “Don’t Ask, Don’t Tell” NERC CIP compliance approach. But the original DADT worked fairly well also, until the climate had shifted enough that it wasn’t needed anymore. Maybe that will happen with CIP as well.

What about the longer term? Fortunately, there the outlook is brighter. This is because it seems there’s widespread recognition that the prescriptive requirements in CIP are a dead end. Specifically, while the current CIP Modifications drafting team doesn’t have fixing the prescriptive requirements as an item in their SAR, they do have virtualization. And they’ve realized that a comprehensive solution to the problem of integrating virtualization into CIP requires fixing the most prescriptive requirements.

I wrote about the SDT’s initial work on this problem in this post (and two more in the series) in June. They’ve recently come up with what looks like a great set of follow-on documents, including suggested revisions to the standards and new definitions. I have to spend some quality time with these, which I hope to do soon, but my initial impression is that they seem to have some really good ideas. But I do think the SDT is greatly underestimating how difficult it will be to get all of this passed by the NERC ballot body (and they may find it hard to get approved by FERC as well). However, once these changes are in place, they will go a long way to fixing the problem of overly prescriptive CIP requirements.

But it still isn’t all puppies and roses on this front. While prescriptive requirements are a big problem, there’s an even bigger problem: prescriptive auditing. This is a much harder problem to solve, and will be hanging over the effort to get the new virtualization requirements approved. While the problems with prescriptive requirements are also hard to solve, the means to solve them are clear: revising the CIP requirements and definitions. The same can’t be said for prescriptive auditing. In fact, at the moment I don’t know how that will be solved, although ultimately I think it will be. More on this topic soon.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013; we also work with security product or service vendors that need help articulating their message to the power industry. To discuss this, you can email me at the same address.

---

[i] To find the article, go here and look for the Newsletters line near the bottom. Click on the + and then click on 2015. Click on the Nov-Dec newsletter. Go to the index on the left of the first page and click on The Lighthouse.