I have mentioned in at least a few posts the idea of “implicit requirements” in CIP v5 – that is, things an entity needs to do to comply with the written requirements, that aren’t actually stated as requirements. I believe I have also acknowledged (at least I hope I have) that this idea wasn’t mine but that of Lew Folkerth, Principal Reliability Consultant with RF.
Even though I may not always have identified them as such, my posts on CIP v5 have been loaded with implicit requirements – to identify Cyber Assets, BES Cyber Assets and BES Cyber Systems in CIP-005-5.1 R1; to develop and document a methodology for determining whether there is External Routable Connectivity for substation relays that are connected to a device like an RTU which is then connected through IP to a control center; etc. I have even put together a document listing all of the implicit requirements I have so far identified in v5 (it is growing all the time, of course).[i]
At RF’s CIP v5 workshop in Cleveland on October 1, 2015, Lew – in response to a question – said he would “look into” preparing a list of implicit requirements in v5. He published an article in the most recent RF newsletter (pages 8 and 9) in which he discusses what he found when he did look into this. As with everything else Lew writes on CIP, I strongly recommend you read this article, whether or not you’re in RF (there is nothing in it that just pertains to RF. In fact, I don’t recall anything he’s written on v5 that doesn’t apply to all NERC entities, no matter which Regional Entity they’re part of. I believe you can find the archived newsletters on the RF site; Lew’s articles are always under the heading “The Lighthouse”).
Lew admits up front that he doesn’t have a list of implicit requirements to provide. Moreover, he admits he will not be providing one in the future, either. This is because “My opinion is that we may never be able to achieve a complete list of implied requirements; the more we mature in our understanding of CIP Version 5, the more implied requirements we will find.”
You may wonder why Lew can’t provide at least an incomplete list – after all, wouldn’t it be better to have a partial list of implied requirements than no list at all? I believe the answer to this question (although I haven’t discussed it with Lew) is that, if someone in NERC (and of course, the Regional Entities are all part of NERC, or the “ERO Enterprise”) provides a partial list of implied requirements, entities will complain if they are later cited for missing an implied requirement that isn’t on that list. There is really no way he can provide this list, given his current job responsibilities.
I find the above statement of Lew’s to be very significant for another reason: I think it raises serious doubts about whether NERC CIP version 5 can ever be “enforceable” in the strict sense of being upheld in the US court system. I will have more to say on this point (a lot more, in fact) in one of my next posts. However, I also do have a few comments on Lew’s article, which I’ll discuss now.
Lew states close to the beginning of his article that “Implied requirements are a consequence of writing CIP Version 5 as results-based Standards.” This is an interesting idea, but I believe it’s contradicted in the section titled “Sources of Implied Requirements”. In that section, he lists four cases in which implied requirements can arise. I agree with everything he says in this section, but note that the second of these four cases is “Results-Based Specification”. If this is only one of four ways in which implied requirements arise, how can Lew’s initial statement that implied requirements arise from “results-based standards” be true, since it clearly is meant to apply to all implicit requirements? My personal opinion is that the only general statement that can be made about all implicit requirements in CIP v5 is what I said in the first sentence of this post - they are things an entity must do to comply with one or more v5 requirements, which are not themselves stated in a requirement.[ii]
As I said, I do completely agree with the section entitled “Sources of Implied Requirements”. Lew wrote this section to give entities a way to identify implied requirements on their own. Since he can’t provide them with his own list, this is obviously the next best thing that he can do. I think all of the four “sources of implied requirements” he lists can definitely lead to implicit requirements, although I would think there are some implicit requirements that don’t spring from one of these sources.[iii]
However, I don’t agree with the next section of the article, “Failure to Comply with an Implied Requirement”. It states in part “If an implied requirement is violated, an audit team will return a finding for the Requirement that is supported by the implied requirement. Since an implied requirement may support multiple Requirements, a violation of the implied requirement may result in multiple audit findings. An example of this would be the failure to identify and protect an EACMS associated with a high impact BES Cyber System. Failure to identify and protect each EACMS could potentially result in an audit finding in 64 Parts of 18 different Requirements.”
I agree that there are some implied requirements – like the implied requirement to identify all EACMS associated with high BCS – which are quite evident. If you’re not required to identify your EACMS, how could you possibly comply with all the requirements that apply to EACMS? If you don’t identify your EACMS out of pure stubbornness, I can see a PV is justified. But there are other implicit requirements that are not clearly implied at all.
For example, I think every Regional Entity will require that an entity being audited present a list of “Medium impact” substations, or more correctly “substations that contain at least one Medium impact BES Cyber System”. This is an implied requirement, but it is also not one that can be easily identified from the wording of CIP-002-5.1 R1 or Attachment 1 (in fact, I believe it can’t be identified from that wording[iv]).
In a case like this, I think it would be very hard for an auditor to actually issue a PV for violating that implicit requirement. My guess is, if the entity doesn’t have the list of Medium substations, the auditor will simply ask them to draw one up.
And going back to Lew’s example of an entity that failed to identify one or more EACMS and thus didn’t comply with 64 parts of 18 requirements, I find it very hard to believe they would receive any PVs at all because of this – unless they had simply pretended that they didn’t have to identify any EACMS and therefore none of the requirements that apply to EACMS applied to them. Except in that extreme case, I think most failures to identify EACMS will be caused by confusion over what exactly the definition applies to (or perhaps whether or not ERC is present); and as I’ve said in several posts including this recent one, I don’t think any PVs will be issued for these cases until there is general agreement in the NERC community on the many areas of ambiguity in v5 – which will probably be at least a year after April 1, 2016.[v]
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.
[i] Deloitte Advisory provides this document to entities that decide to take advantage of the free CIP v5 Quick Check, described in this post.
[ii] I also disagree with the example Lew uses to illustrate a “results-based specification”. It is CIP-002-5.1 R1. I disagree that this requirement is “results-based”. As I discussed in this post from 2014 (in the section labelled “Issue 4”), because of the ambiguities and missing definitions in R1, there can never be a definitive statement of what results are required by R1, other than to get into a curious argument: a) R1 requires the entity to properly identify and classify its BES Cyber Systems. How does the auditor determine whether or not the entity has done this properly?; b) The auditor needs to determine whether they have properly followed the procedure described in the requirement; c) But Lew has just said that much of what is required by R1 is implicit – how can the auditor possibly say they have followed the correct procedure or not, other than to use his or her own personal judgment?
I followed up the 2014 post with this post, which made the point that calling CIP-002-5.1 R1 a “results-based” requirement leads to a completely circular argument, where a correct “result” of the requirement can only be determined by whether or not the requirement has been “properly” followed – and the only way to determine whether it has been properly followed is to know what the result should be!
[iii] My guess is some implicit requirements are implicit simply because the Standards Drafting Team didn’t think to include them; there is simply no further reason. Someday I would like to go through my list to see which implicit requirements are due to one of Lew’s “sources of implied requirements”, and which ones are simply there because of SDT error.
[iv] The reason this is the case is that the criteria that apply to substations – 2.4 through 2.8 – all use the word Facilities as their subject. A Facility is a line, transformer, etc. – but not the substation itself. Literally every entity or auditor that I have talked to either a) thinks “Facility” means the substation or b) knows that it doesn’t, but is choosing to treat it that way because of the complications of trying to classify BCS in a substation according to the Facility they’re associated with, not the substation itself. Effectively, these criteria do apply to substations, and a list of Medium substations is implicitly required. On the other hand, this isn’t what the wording says.
[v] There is another consideration here: I believe there has been some sort of unofficial doctrine in place among the CIP auditors since CIP v3, to the effect that a failure to identify a particular cyber asset in scope (e.g. a Critical Cyber Asset under v3 or a BCS under v5) will at most lead to a PV for violating the original identification requirement (CIP-002-3 R3 or CIP-002-5.1 R1), but not to PV’s for missing other requirements due to not having identified that cyber asset as in scope. If that is the case, then at worst the entity would receive a single PV for not having identified an EACMS – and frankly, even that is hard to support since there is no requirement that even implies EACMS need to be identified. If a PV is issued for not identifying an EACMS, what requirement would it apply to?