Implicit Requirements: the Remix

In October of 2015, I wrote a post about an RF CIP workshop I had just attended. Of course, Lew Folkerth of RF spoke at the workshop, and I summarized his presentation this way (I’ve edited it a little, not because Lew used language unfit for a family blog like this one, but because I said a few things that don’t make complete sense. Since I’m allegedly three years wiser at this point, I can now see the problems in what I wrote):

“Lew pointed out that there are a number of “implicit requirements” in CIP v5. These are things that the entity needs to do to be in compliance, which are not specifically identified in the actual Requirements. Lew gave the example of the implicit requirement to “(identify) any associated Protected Cyber Assets” (this requirement never appears at all in CIP v5, but the entity obviously needs to identify PCAs, since many of the requirements apply to PCAs). RF isn’t just looking for a list of the PCAs, but wants to know how the entity verified that every Cyber Asset in the ESP had been identified as either a component of a BVS or a PCA.

“Another example is identification of Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). The entity is never explicitly required to identify these, but they obviously have to do so to be in compliance - and they need to be able to show that they haven't missed any EACMS or PACS systems when they did their identifications.

“Of course, you can’t find out about these implicit requirements by reading the RSAWs, since they only deal with the explicitly-stated requirements (2018 note: Tom was being fairly careless here, as he too often is. He should have said something like ‘The RSAWs are constrained not to require anything other than what is in the strict language of the requirement’). A questioner asked Lew if RF would publish a list of the implicit requirements. Lew said he’d look into doing that. I certainly hope he does – it is greatly needed (another 2018 note: Lew would have liked to publish that list, but ended up not being allowed to because – of course! – the ERO, meaning NERC and the Regions, isn’t allowed to provide anything that could be considered an “interpretation” of a NERC requirement. This is a very sorry situation, and has led to repeated false starts by NERC in trying to provide guidance on CIP. The CIP people at NERC would just love to be able to provide CIP guidance, since the need for it has been great all along and continues unabated. But it simply isn’t allowed by the NERC Rules of Procedure, and literally every attempt by NERC staff members to provide guidance on CIP has ended up being withdrawn).”

Lew’s presentation was the first time I had really thought about the idea of “implicit requirements”, which is an excellent way to describe a lot of the ambiguities in the CIP v5 requirements (another might be “unstated assumptions”, but I like Lew’s term better because it emphasizes the need for the entity to document how they complied with these implicit requirements – since there is no way that an entity can properly comply with a CIP requirement itself without first complying with any implicit requirements it contains). In requirements developed since v5, this problem hasn’t repeated itself (at least not much). But since most of the v5 requirements are still in effect, we still have to deal with the problem.

I had kind of internalized the idea of implicit requirements and considered it part of the overall CIP landscape, as much as the non-implicit requirements – so I’ll admit I haven’t really thought about it much, and I never wrote a full post on the topic. But, as I mentioned in a post two weeks ago, I’ve recently been working with several entities that are fairly new to CIP compliance, and I realized I needed to initiate them into the dark secrets of implicit requirements – so that they would have a prayer of surviving in the cold world of NERC CIP audits. Here is how I put it to them (OK, I never actually said these exact words, but I consider myself as having said them. And that’s just as good as saying them, right?):

I have the greatest respect for the CIP v5 drafting team – after all, they started working in the fall of 2008 and didn’t finish their work until January of 2013, when they submitted CIP v5 to FERC (along the way, they’d also developed– and gotten approved - CIP versions 2, 3 and 4, along with a “version”  in early 2010 that was too visionary for its time, but ended up mostly being incorporated into v5. That version was known as CIP-010 and CIP-011, but these standards had nothing to do with the current CIP-010 and -011).

However, in retrospect, the team did take some big shortcuts in drafting CIP v5, mainly because they were under huge pressure to get something approved by the NERC ballot body and out the door to FERC in 2012. This pressure was due to FERC’s having put the squeeze on them by rather impulsively approving CIP version 4 in April of 2012 – as discussed in this post (I regard approving CIP v4 as the worst mistake FERC has made regarding the NERC CIP standards. I discussed this in three posts in 2013, starting with this one). The drafting team most likely felt – and perhaps rightly so – that if they didn’t get v5 approved and on FERC’s desk in 2012, FERC was going to let CIP v4 come into effect on its 4/1/14 implementation date. And this would be followed two or three years later by the implementation of CIP v5, meaning NERC entities would have to go through two huge CIP transitions in 2-3 years. So they probably had no good option other than to take some shortcuts.

One of the biggest shortcuts the team took – again, looking back from 2018 - is that they didn’t bother to write explicit requirements for all of the steps that were needed to comply with some of the requirements that they drafted (I certainly didn’t think of this at the time the SDT was developing v5, even though I attended some of the drafting team meetings and participated in a number of the conversations). The effect of this is that a single requirement can contain five or more implicit requirements. You need to comply with all of the implicit requirements in order to comply with the requirement itself – but you need to figure them out entirely on your own, since none of the implicit requirements are actually written down anywhere.

Probably the most egregious example of implicit requirements can be found by examining CIP-002-5.1a R1. The “operational” parts of the requirement are R1.1-R1.3, which all mandate that the entity identify something called BES Cyber Systems. What’s a BES Cyber System? You go to the NERC definition, which just says it’s a bunch of BES Cyber Assets grouped together for “reliability purposes”. And what’s a BES Cyber Asset? That’s a very long definition, but it starts off with the term Cyber Asset. And what’s a Cyber Asset? Well, it’s a “Programmable electronic device...”, according to the NERC definition.

And what’s that? The words “electronic device” certainly have an accepted meaning, but the word “programmable” doesn’t. This leads to a problem that I discussed in a number of posts in 2014 and 2015, starting with this one: that there are a few words that are vital to understanding the CIP requirements, which have no NERC definition and no generally accepted meaning. For each of these words, the only solution – which it took me a long time to understand, although once again Lew Folkerth was ahead of me – is to do your best and come up with a reasonable definition of your own, then follow that consistently as you comply with the CIP standards.

So our attempt to comply with R1 and “identify” BES Cyber Systems has actually led us to three implicit requirements:

R0.1. Develop a definition of “programmable”.

R0.2. Identify Cyber Assets.

R0.4. Identify BES Cyber Assets, among the Cyber Assets identified in R0.1 (you’ll see why I numbered this as I did in a moment).

So are we finished with the implicit requirements in R1? No. Let’s look at the first part of the definition of BES Cyber Asset: “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non-operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System.” Do you understand exactly what that means, so you’ll have no problem identifying a BES Cyber Asset if it walks in your door?

You might, but my guess is you’ll end up doing what a lot of people in the industry did: getting hung up on the phrase “…impact one or more Facilities, systems, or equipment…”. Doesn’t that strike you as a little broad? After all, if I go out to a substation and hit a transformer with a hammer, I will have impacted a BES Facility (the transformer meets the NERC definition of Facility). Does that make my hammer a BES Cyber Asset? No it doesn’t, because a BCA has to be a Cyber Asset, meaning it’s programmable. OK, let’s say I take out my cell phone and lightly tap the transformer, leaving a very small dent in it. The phone is definitely a programmable electronic device, and the definition doesn’t say “big impact”, just “impact”. This makes my cell phone a BCA, right? After all, it impacted (dented) a BES Facility within 15 minutes. Of course, the drafting team was thinking of “impact” in the sense of “electrical impact” – but they didn’t include that in the definition. Hence the ambiguity.

So one big question as people were trying to figure out CIP v5 was the question of the meaning of “impact the BES”. They needed this before they could identify BCAs, and they needed to identify BCAs before they could group them into BCS. How did they answer this question? Well, I offered my own helpful opinion on that, but it didn’t exactly gain universal acceptance and shouts of acclamation (I still like it, and in fact I think it is the “definition” that most NERC entities have implicitly used in deciding what’s a BCA).

The fact is that, just as in the question on the meaning of programmable, there is still no answer from NERC on what “impact the BES” means. Both of these questions are officially on the plate of the current CIP Modifications drafting team, but that group isn’t going to directly answer either one of them – I’m 100% sure of that. And I support them 100% in this particular non-action, since there is simply no way to develop a real Webster’s-style definition of either term.

On the other hand, the drafting team will neatly deal with both issues, as part of their proposed changes to deal with virtualization. First, they’re going to neatly bypass altogether the need to keep using “programmable” by relegating the term Cyber Asset to a very unimportant role (essentially, the term will only be used as part of the definition of Transient Cyber Asset. My, how the great have fallen!). Second, they are retiring the term BES Cyber Asset altogether, and the new definition of BES Cyber System incorporates language that avoids the problem the phrase “impact the BES” – in fact, it in some way follows the “definition” I came up with in 2015, although I’m not in any way claiming credit for this. Pretty cool, huh?[i]

All of this means there’s another implicit requirement buried in CIP-002 R1:

R0.3. Develop a definition of “impact the BES”.

So we have, without breaking a sweat, come up with four implicit requirement buried in CIP-002 R1 – and we’re still not done! When we get to CIP-002 Attachment 1 (which of course is part of R1), there are a whole host of implicit requirements (I honestly guess there could be as many as 50 or 100, especially when you start looking at some of the bright-line criteria, which aren’t bright at all but are loaded with unstated assumptions – i.e. implicit requirements. Maybe I’ll take a month off sometime and try to enumerate them all, just out of sheer perversity).

CIP-002 R1 is probably the CIP requirement with the most implicit requirements buried in it. But CIP-005 R1 can certainly give it a run for its money, with maybe CIP-010 R1 easily winning “show”. I will leave those two as an exercise for the reader.

Let’s get back to reality (I enjoy doing that every now and then – breaks my routine). What does the fact that there are so many implicit requirements buried in the “actual” CIP requirements mean for a NERC entity? The main impact (so to speak) is that your RSAW compliance narrative for a particular requirement should go through all of the logical steps that are actually needed to comply with the requirement – if you do that, you’ll “discover” all of the implicit requirements, even though you probably won’t recognize them as such. For example, your CIP-002 R1 narrative could start with a list of the steps we went through above, although probably in reverse order.

And what will happen to you if you don’t do this? Will you get a violation? You definitely can’t get a violation, since implicit requirements aren’t stated in the real requirement. But your auditor isn’t just looking to nail you for violations, but to see if you really understood what you were doing when you complied with a requirement. So if you just say that you “identified” your BES Cyber Systems in your CIP-002 R1 narrative, your auditor might ask “And how did you do that?” If you answer, “I dunno, I thought this computer had a 15-minute BES impact – and besides, I like its metallic gray color”, you won’t get a Potential non-Compliance finding, but your auditor may well give you an Area of Concern, then tell you to think about how you should identify your BCS and re-do the RSAW narrative to include all the steps you need to take (implied or not). Then you’ll need to go back to make sure you actually identified all of your BCS properly.

And if you discover you actually missed one or two BCS? You would now have to comply for them, of course. But I don’t see any way you can get a violation for that, since – of course – implicit requirements aren’t stated in a requirement!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013; we also work with security product or service vendors that need help articulating their message to the power industry. To discuss this, you can email me at the same address.

---

[i] The SDT has released for comment a new set of revised standards and definitions that addresses virtualization, and I will discuss these questions more when I discuss that new release.  You can get a preview of what I’ll say from this post.