Monday, March 13, 2017

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

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.”

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).

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).

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.