NERC Interprets CIP v5 (and 6)!

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/10^th 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.