On Results-Based Requirements

Warning: This post does not comply with this blog’s usual standards for unrelenting negativity. Anyone seeking a truly negative experience is referred to the current Presidential campaigns.

It seems that half my posts start out with thanks either to the EnergySec newsletter or to Lew Folkerth, Principal Reliability Consultant with RF. This post breaks new ground in that I owe thanks both to Lew for an inspiring new article, and to the EnergySec newsletter for pointing it out to me in the first place.

Lew’s article is in his regular “Lighthouse” column in RF’s March/April newsletter. The article discusses CIP-007-6 R3, Malicious Code Prevention. Lew starts by pointing out that this is a very minimalist requirement: “Deploy method(s) to deter, detect or prevent malicious code.” Lew admits that, when he first read this requirement, he thought it was poorly written. Indeed, when you look at the equivalent requirement in CIP version 3, CIP-007-3 R4, it seems to be missing something. The latter requirement mandates that the entity implement “anti-virus and malware prevention tools” on every device in scope, and that they have a process for updating signatures.

Of course, the big issue with the v3 requirement was that many devices – routers and switches, for one – don’t provide any way to install or run antivirus software. In this case, the entity was required to “document compensating measure(s) applied to mitigate risk exposure.”  They were also required to file a TFE, making this probably the number one cause of frustration with the TFE process (Why should you have to document that you can’t install antivirus on a Cisco switch?).[i]

After mentioning his initial reservations about CIP-007-6 R3, Lew points out that the v5 standards were intended to be “results-based and non-prescriptive”. I have heard this in many meetings as well. I have always looked on it as an attempt by the speaker to show he or she has a sense of humor, since I regard v5 (as well as the previous CIP versions) as prescriptive to a fault, and anything but results-based.

Look at CIP-007-6 R2 Patch Management, which requires (among other things) that all new patches be evaluated within exactly 35 days – meaning an entity is subject to fines for every extra day it takes for this, for every month that this happens and for every in-scope device affected. What is the result that this requirement is aiming at? It’s “evaluation of new patches within 35 days”. I don’t think I’ve ever read any cyber security book or article that says that 35 days is an absolute limit for this activity, due to the laws of physics or of information science.

However, Lew clearly believes that CIP-007 R3 is one CIP v5 requirement (at least) that actually is results based and non-prescriptive; and I certainly agree with him on that. He goes on to lay out a really good methodology for complying with the requirement, and for demonstrating this to the auditors. I’ll let you read the article to see that.

The biggest takeaway for me from Lew’s article was that it would certainly be possible to make all of CIP truly non-prescriptive and results-based (although it would take more than simply rewriting each of the current CIP standards so that it resembled CIP-007 R2. There would have to be broader changes as well). Unfortunately, I think it will be a while before this happens. I attended NERC’s Technical Conference on the CIP v7 SAR in Atlanta this week, and I can promise there is currently no movement to make such a change in v7. And if you’ll look at my two previous posts, I’m not recommending such a radical change now, either (although I’ve tried to make it clear that I think v7 should be the last prescriptive CIP standards. Future versions should move to a risk-based approach).

But interestingly enough, I think that CIP v5 and v6 - and v7 when it comes into effect in three or four years – will end up as fairly non-prescriptive and results-based anyway. This is a corollary to my frequent assertion that v5 (and v6) won’t be enforceable in the strict sense.  It’s becoming clear to me that CIP v5 audits will be very different from v3 ones, for this very reason.

Why do I think audits will be different? Because the time that an auditor can spend on a particular audit is limited, and they are now being explicitly directed not only to look for technical violations but to look for “opportunities for improvement” in cyber security practices. Of course, these “opportunities” will not result in potential violations (since they’re focused on practices not specifically required by CIP), but in “areas of concern” in the audit report. If you’re a CIP auditor (who is also a cyber security professional) and you’re auditing an entity that clearly has been trying to do the right thing for both CIP and cyber security, are you going to devote your limited time to finding cases where someone took more than 15 months to have their annual training (especially considering that, if this finding results in a violation and fine, it would very likely not be upheld if challenged in the courts)? Or are you going to – for example – look for ways the entity can improve their level of cyber security in general, going beyond what is strictly required by CIP?

I contend that auditors will do the latter. And frankly, I think that’s great. For one thing, the auditors will be happy as clams that they can be essentially cyber security consultants, not misguided folks out to ding well-meaning entities on purely technical violations. For another, audits will no longer be a dreaded exercise in “gotcha”, but an opportunity for entity staff to learn about how they can better secure their OT environment.[ii]

I know you don’t turn to this blog expecting to see a lot of optimism about CIP v5; and I admit I didn’t expect this post to end optimistically when I started it a couple of hours ago. But there you have it: I’m predicting that – for entities who are honestly trying to do the right thing for both cyber security and CIP compliance – CIP audits will turn into a positive learning experience. All courtesy of the fact that, in my personal opinion, wording problems make CIP v5 unenforceable.

  

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

---

[i] The words “where technically feasible” weren’t in the requirement, so the fact that a TFE was required – even though compensating measures were also required – seems to indicate that the drafting team for v3 didn’t believe at the time that it would work to simply have entities figure out compensating measures on their own, and auditors judge those measures after they had been implemented. In a TFE, the entity has to submit proposed compensating measures to their region before they implement them, and get them approved. Essentially, you can look at the v5 requirement as requiring the same things as the v3 one, but now trusting the entities to come up with good “compensating measures”, and the auditors to adequately judge those after the fact.

[ii] I do want to point out that I’m not advocating that entities stop trying to comply with the technical requirements of NERC CIP! They still need to do their best, but my guess is auditors won’t spend most of their time looking for technical violations and writing them up as PVs when they find them. And I think the tone of the audits will change. But an entity that isn’t really trying very hard on CIP will be treated quite differently.