I have been saying
for close to two years that NERC (or perhaps the regions) needs to come up with
an informal “interpretation” of the many ambiguous (or contradictory)
areas in the wording of CIP v5. It can’t be an official Interpretation, since
that can only be triggered by a Request for Interpretation and that process
takes a couple years at least.[i]
So NERC can’t produce anything that’s binding, but I have always wanted them –
or somebody – to provide some non-binding
interpretations of the ambiguous areas in the v5 wording.
NERC has
produced some Lessons Learned, but they are deliberately not interpretations of
the wording – rather, they provide helpful guidance on how other NERC entities
are addressing different CIP v5 challenges. Whenever NERC has tried to take a
stand on what particular wording means, this hasn't worked (as was the case with the five Memoranda
that they released in April and withdrew in July).
I decided a
while ago that NERC would never provide little-“i” interpretations, and
therefore it was completely up to the entities to come up with (and document)
their interpretation of each of the ambiguous areas in v5 – “programmable”,
ERC, “adverse impact on the BES”, etc.
I still
believe this is the case. However, I was pleasantly surprised to see that NERC
has identified one vehicle by which they can provide some little-“i”
interpretations. I’m referring to their “CIP
Version 5 Evidence Request User Guide” that was published on December 15,
2015.[ii]
Of course, NERC doesn’t tout this document as one that interprets ambiguities
in v5; instead, it is meant as a supplement to the RSAWs, which – according to
the document – have been described as lacking in detail by “industry
representatives”.
The actual
Evidence Request is an online tool; the Guide is simply that – a guide to using
the tool. However, I find it provides some useful interpretation information,
since there is no way anyone could write evidence requests for requirements in
v5 that are ambiguously worded, without in the process taking some position on
what that wording actually means.
This post
tries to “reverse engineer” the questions in the Guide to identify the
interpretations that were used to generate them. This is a pretty roundabout
way to glean NERC’s interpretations, but – hey, you can’t be choosy when it
comes to finding interpretations of CIP version 5! The Guide is divided into
sections with short acronyms; my post is divided the same way (although I don’t
address all of the sections in the Guide; just the ones where I found something
interesting that should be reported).
I do want to
say that my main criticism of this document is that it doesn’t address more
than maybe 1/10th of the major interpretation issues in v5. However,
at least it does something, and that’s a help. Its biggest achievement is
acknowledging for the first time that virtualization needs to be accommodated by
the v5 standards, even though it is nowhere mentioned in the standards
themselves.
BES Assets
As with
almost all presentations on CIP-002-5.1 R1 (that I have seen or read), the
first section of the Guide deals with the “big iron” – the assets that house
the Cyber Assets in scope for CIP v5. What I say in this section will be more
understandable if you reread this
post.
1.
The first item in this section is “Asset Type”
(page 4). This means the entity should start by identifying its assets in scope
for CIP v5, confining their list to assets that meet one of the six types
listed in R1. As I said in the above-referenced post, this is how virtually all
auditors and entities understand R1 to read; so it should be followed. However,
this isn’t how the requirement (or Attachment 1) actually reads.
2.
Two items at the bottom of page 4 read “Contains
BES Cyber System – High Impact” and “Contains BES Cyber System – Medium Impact”.
As I discussed in footnote ii of the previous post, using this wording rather
than “High Impact Asset” and “Medium Impact Asset” fits a little more closely
with the wording of R1 and Attachment 1, but less closely with how NERC
entities and auditors actually understand the R1 process. Virtually every
entity (and every auditor) that I have ever heard present or talked with starts with classifying their assets, not their BCS;
it would be better not to pretend this isn’t really what they’re doing, and
just refer to High and Medium impact assets – which then lead to High and
Medium BCS.[iii]
CA
This is the
first official NERC document I’ve seen that recognizes that virtualization is
now a big part of many computing environments subject to NERC CIP. The paragraph
titled “Cyber Asset Function” on page 7 allows for identifying a Cyber Asset as
a “Virtual Host”.
VM
Even more
striking than the mention of Virtual Hosts is the fact that there is an entire
section on Virtual Machines (VMs). In this section, you identify and provide information on your
VMs in a similar (although not identical) manner to how you had to
enter your Cyber Assets in the previous section (that section makes clear that
only physical devices can be Cyber Assets, which is why VMs have to be handled
separately).
The first
paragraph of this section (page 9) immediately recognizes an important fact:
that there can be multiple hosts capable of running a particular VM. This means
that each host should be protected appropriately for all VMs that are capable of running on it (for example,
if all the VMs capable of running on a host are Low impact, the host itself
only needs to be protected by the Low requirements. But if one High VM could
potentially be run on this host, then it has to be treated as a High from the
start – not just when that high VM is actually moved to it. This is not stated
in the Guide itself, but I believe this is a reasonable inference from it).
BCS
I’ve stated in
a couple of posts (here
and here)
that CIP v5 allows entities to group BES Cyber Assets differently into BES
Cyber Systems for different requirements. However, this conclusion just came
from the fact that this isn’t actually prohibited in CIP-002-5.1 R1.
Now NERC has
provided a positive acknowledgement of this idea in the second paragraph of the
BCS section (page 10), which states “If all BES Cyber Systems are used to meet
the obligations of all CIP Standards, Requirements, Parts, and Attachment
Sections, then the ‘BCS’ tab should be used.” Furthermore, there is another tab
- “BCSdetail” - that can be used to enter information on BES Cyber Assets that are
included in more than one BCS, depending on the requirement.
CABCS
The first
paragraph of this section (page 12) reads “The ‘CABCS’ tab is used to logically
group Cyber Assets into one or more BES Cyber Systems, and to associate
supporting Cyber Assets with BES Cyber Systems. For each Cyber Asset, specify
the BES Cyber System into which it has been logically grouped or with which it
is associated. Provide one row for each Cyber Asset/BES Cyber System grouping
or association. Indicate the type of the association (‘Member of BCS’ or ‘Associated
with BCS’).”
I must admit that I haven’t previously seen the distinction
that is being made here, between a Cyber Asset being a “member of a BCS” and
being “associated with a BCS”. Of course, the meaning of membership in a BCS is
quite straightforward. The definition of BES Cyber Asset includes this
sentence: “Each BES Cyber Asset is included in
one or more BES Cyber Systems.” That is what “membership” means.
But what does “associated with
a BCS” mean? The only meaning I can think of is that EACMS and PACS are “associated
with” BCS in the “Applicability” column of some requirements. If that’s the
case, this only applies to those two categories of Cyber Asset, not to all
BCAs. Yet this question implies that all BES Cyber Assets are either a member
of a BCS or associated with one – but that doesn’t make sense either, since
EACMS and PACS aren’t necessarily BCAs, meaning they wouldn’t normally even
encounter this question in the first place.
This also doesn’t refer to
Protected Cyber Assets, since the user has already identified these in the CA
section. Did someone get confused by the fact that Section 2 of Attachment 1
describes Medium impact BCS as those “associated with” one of the Medium impact
criteria? This of course refers to an association with an asset, not with
another BCS.
Since I don’t see this idea
recurring anywhere else in the document, I guess it doesn’t do any harm, other
than confuse people. If anybody has an idea what it means for a BES Cyber Asset
to be “associated with” a BCS, please let me know, and I’ll share it with my devoted
readers.
ESP
One of the paragraphs in this
section (page 13) reads “Is External Routable
Connectivity Permitted into the ESP? This
column contains a pull-down list. TRUE should be selected if this ESP contains
a Cyber Asset with External Routable Connectivity. Otherwise leave blank.” This
alludes to a point that Lew Folkerth of RFC made in an RFC newsletter, which I
reported in this
post: If ERC is allowed for at least one Cyber Asset within an ESP, all of the
other Cyber Assets (whether they be PCAs, BCAs, or just Cyber Assets) will ipso facto also have ERC.
EAP
One finer
point that people often forget about (at least I do!) is that an Electronic
Access Point isn’t a device like a firewall, but an interface on that device. This section (page 14) makes that point clear,
as well as the fact that the device that contains the EAP will always be an
EACMS (but the converse isn’t true. Other devices like AD servers can be EACMS
even if they don’t contain an EAP).
TCA and TCA Non-RE
There are
good sections describing information required for Transient Cyber Assets (page
15) and TCAs that are managed by a third party and thus treated differently in
CIP-010-2 R4 (page 16).
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i] It
has previously taken at least two years for NERC (really, an Interpretations
Drafting Team) to develop an Interpretation, submit it to a few votes by the
NERC ballot body, get NERC Board approval, submit it to FERC for them to ponder
for a while, then wait to see whether or not FERC approves it (they rejected
the last two Interpretations for CIP v3 in 2012).
EnergySec reported in their Dec. 23 NERC CIP Newsletter
that the NERC Standards Committee Process Subcommittee (SCPS, for those keeping
score at home) had decided this process needs to be streamlined. That’s the
good news. The bad news is that they will take 12 months just to recommend
changes; these will of course have to be debated and voted on by the NERC
membership, etc. EnergySec also reported that the full Standards Committee has
decided that all work on the two RFIs that were accepted in September should be
put off until at least next April 1, and that it should be coordinated with the
re-drafting of certain standards that the current Standards Drafting Team is
starting to undertake now. Bottom line: Don’t look for finalized CIP v5
Interpretations with a capital “I” for years.
[ii] I
learned of this document through EnergySec’s NERC CIP Newsletter of Dec. 23. Would
you like to get the newsletter? Join EnergySec!
[iii] You
may have noticed that I always capitalize High, Medium and Low in the context
of classification of assets and BCS, even though the CIP v5 requirements all
use lower case; I have had more than one person point out to me that I shouldn’t
capitalize common words that aren’t defined in the NERC Glossary. I do this for
a reason: I have seen a number of people (including one who presented on the
asset identification process at a regional meeting) misunderstand these terms
to mean that the entity should simply make their own judgment on whether the
asset or BCS has a high, medium or low impact on the BES. While there is some
support for this idea in the wording of CIP-002 (the problem is that there is
support for a number of contradictory ideas in that standard!), it is
definitely not the case that this is a matter of the entity’s judgment. For
better or for worse, it is a matter solely of the meaning of the Attachment 1
criteria. Judgment has nothing to do with it, except that the criteria
themselves require a fair amount of judgment to interpret. But that’s another
post.
Link to “CIP Version 5 Evidence Request User Guide” doesn't seem to be working.
ReplyDelete"An unexpected error has occurred.
Troubleshoot issues with Microsoft SharePoint Foundation. "
Stan
A working link:
Deletehttp://www.nerc.com/pa/comp/Pages/ERO-Enterprise-Compliance-Auditor-Manual.aspx