How will CIP-010 R4 and other Non-Prescriptive Requirements be Audited?

I have written a lot about the problems caused by prescriptive requirements in NERC CIP, and the need to replace them with non-prescriptive requirements. What I haven’t written anything about – frankly, because it had never occurred to me to do so – is how the non-prescriptive requirements will be audited. This might seem like a question that can safely be addressed later, but that’s wrong. There are already a number of non-prescriptive requirements in the NERC CIP standards[i], and audits have already started on at least one of them, CIP-007-6 R3.

With his usual great sense of timing, Lew Folkerth of RF has published a very good article on this topic in the January-February issue of RF’s newsletter (click on Archives under Newsletters and choose 2017. The article is on pages 9-10). While the title of the article is “Transient Cyber Assets and Removable Media”, what it actually addresses is what kind of evidence NERC entities will need to produce to demonstrate compliance with CIP-010-2 R4, which Lew calls “the epitome of a non-prescriptive, results-based standard” (and I agree with this statement).

However, I will take what Lew says a step further (and he has given me permission to say this): Similar evidence is likely to be required for all “non-prescriptive, results-based” requirements, both existing ones like CIP-007-6 R2 and future ones. So it’s worth paying attention to what he says, even if your organization doesn’t have High or Medium impact BES Cyber Systems and thus doesn’t have to comply with this requirement[ii].

What does Lew say about this question? I’ll let you read the article, but Lew lists four components of a good evidence package for CIP-010-2 R4 compliance:

1.        First, you need “A documented plan to protect the Transient Cyber Asset” (or Removable Media) according to “the R4 base requirement”. The base requirement mandates implementation of “one or more documented plan(s) for Transient Cyber Assets and Removable Media that include the sections in Attachment 1.” So you first have to document the plan itself.

2.       Second “The plan must include the methods you employ to protect the Transient Cyber Asset” from the risk introduced by one of the five objectives identified for TCAs in the requirement. These are found in Attachment 1 of CIP-010-2. For example Section 1.2 is titled “Transient Cyber Asset Authorization”, and lists three “sub-objectives”: User, Locations and Uses. This means your plan needs to include methods to authorize users, locations and uses of TCAs. Similarly, the plan must include methods to protect Removable Media against the two threats listed for those devices: Software Vulnerabilities Mitigation and Malicious Code Mitigation.

3.       Third, the plan must show “how methods documented in the plan achieve the objectives.” For some of the objectives listed in Attachment 1, it is left completely up to the entity to determine a method to achieve the objective (although there is very good guidance provided in the Guidance and Technical Basis included with the standard). For other objectives, there are several suggestions for methods that can be used, but there is also the option of using “Other methods”.

4.       Last, there must be “Evidence that these methods are applied consistently and reliably for each applicable Transient Cyber Asset.”

Of course, even though Lew was writing specifically about CIP-010 R4 in the article, you should be able to easily apply his guidelines to other non-prescriptive requirements like CIP-007 R3 – or any other requirement or requirement part that simply states an objective without telling the entity how to achieve it.

So as an exercise, I turned to CIP-007 R3 to see how easy this was. And I sent my work to Lew to review, to make sure I was on the right track. Here is what I came up with, with revisions suggested by Lew (the numbered bullets below correspond to their counterparts above):

1. CIP-007 R3 doesn’t specifically require that you “develop a plan” for malicious code prevention, as CIP-010 R4 does for TCAs and RM security. However, R3 does require “one or more documented process(es)”, which amounts to almost the same thing. So you need to document the processes you will follow for malicious code prevention. Lew points out “The documented processes will be audited to ensure they contain the minimally required provisions. Audit teams will also look at the effectiveness of the processes.”
2. The plan will need to include the methods you use to prevent malicious code. And the methods will most likely vary according to the BCS, PCA, EACMS or PACS being protected. Of course, that was the whole idea of making the anti-malware requirement non-prescriptive in CIP v5 – that you wouldn’t need to use the same method for every device. The CIP v3 anti-malware requirement, CIP-007-3 R4, required the entity to use antivirus or another anti-malware tool to “detect, prevent, deter and mitigate” the threat of malware attacks (or take a Technical Feasibility Exception if the device wouldn’t support antivirus. This of course led to a lot of late nights as CIP compliance professionals painstakingly documented that their nice new switch or router wouldn’t support loading antivirus software. They also had to let their region know at regular intervals after this that the switch still didn’t support A/V. My guess is most people who lived through this have repressed all these painful memories. They may not even remember that there was a CIP v3 at all, or even where they worked from 2010 to 2016).
3. Next, the entity needs to show how the methods documented in the plan achieve the objective. This objective is ideally malicious code prevention. If that isn’t possible in the case of a particular cyber asset or assets, Lew points out that the methods should include detection (Part 3.1), threat mitigation if detected (Part 3.2) and signature updates if applicable (Part 3.3).
4. Finally, the entity needs to document that the methods have been applied “consistently and reliably” for every cyber asset in scope. Note that this doesn’t mean you need to show that one method was applied to each of those cyber assets. As I just said, the main reason this requirement was written non-prescriptively was that there is likely no single anti-malware method that will apply to all of your cyber assets in scope. The methods will differ according to the cyber asset[iii], but you will need to document that you have applied one of the methods identified in the second part to each of those cyber assets (and, as Lew points out, it is preferable if you’ve applied multiple layers of defense to some or all of the cyber assets in scope).

I predict that, once you compare your workload for complying with these non-prescriptive requirements with the workload for complying with the highly prescriptive ones (and CIP-007 R2 is my poster child for those!), you might begin to see why I’m advocating that all the requirements be made non-prescriptive.

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

---

[i] I used to just list three non-prescriptive requirements: CIP-003-7 R2 (still not in effect, of course), CIP-007-6 R3, and CIP-010-2 R4. However, I know there are more than that. In writing a recent post about CIP and cloud security, I discussed four requirement parts that are relevant to that topic, and realized that three of the four are non-prescriptive. I am sure that if I looked I’d find other non-prescriptive requirements and requirement parts, and I hope to soon have time to categorize all the requirements in CIP v5 and v6 as either prescriptive or not. This may seem like an easy task and perhaps it is, but almost nothing I’ve ever undertaken regarding CIP has ever proved easy, and my guess is this won’t either. First I have to get my taxes done.

[ii] If you just have Low impact assets, you should note that the main requirement that applies to Lows, CIP-003 R2, is non-prescriptive.

[iii] Lew points out that he discussed this in his column (called “The Lighthouse”, as always) in the RF March 2016 newsletter. You can find it at the same link I provided near the beginning of this post.