I have said more than once that I might as well call this “Tom Alrich and Lew Folkerth’s Blog”, given the number of times I have written posts about something Lew has written or said. So, despite the fact that a recent post was about two articles Lew wrote (and another post shortly before that quoted him on a different topic), I now find myself writing about what was at the time an offhand comment he made while addressing other topics. His comment struck me as quite profound, as well as very serious in its implications regarding the CIP standards – and also in its implications regarding how NERC entities should be complying with those standards now.
Lew’s comment was that he was expecting entities with High or Medium impact BCS to be self-reporting violations of requirements CIP-007 R2 (patch management) as well as CIP-010 R1 (configuration management). He specifically said “These two requirements are so prescriptive that it will be nearly impossible for an entity of any size to get them right for every system, every time.”
Think about it. Lew is saying he expects to see most entities self-report violations of these two requirements – and I would add to what he said the words “assuming the entity has a good compliance program for these two requirements, which can identify potential violations in the first place.” what little I know about the rules of logic tells me that the converse of this statement must also be true, which I will phrase like this: If an entity is not self-reporting a number of violations of these two requirements, this almost certainly isn’t because that entity is some sort of paragon of good CIP compliance. Rather, it is probably because the entity’s compliance program for these two requirements is so poor that it doesn’t even know when it is in violation!
Let me rephrase this another way (and Lew approves this statement in principle): If you work for a NERC entity with High and/or Medium impact BES Cyber Systems and you aren’t self-reporting any violations of CIP-007 R2 and CIP-010 R1, you need to look closely at your compliance programs[i] for these two requirements. It is very likely there is something wrong with one or both of them.[ii]
But let’s turn the screw again: What does it mean if we in effect say there is almost no way an entity could not be self-reporting violations of these two requirements if it has a good program for compliance with them? You’re right – it means there is something wrong with the requirements![iii] You might think it is that there are problems with the wording, and in one sense you are right. But I don’t think that’s the root of the problem. I don’t think there is any wording that would ever change the situation I’ve just described.
What is at the root of the problem? Let’s look at what Lew said: these two requirements are “so prescriptive” that it’s almost impossible to conceive of an entity (with more than a small number of BCS) being in complete compliance with them.[iv] You might recall that I’ve been waving the flag lately about the prescriptive nature of the CIP requirements (and I will continue to do so); I believe this has resulted in the NERC CIP program becoming unsustainable – for many reasons. And my poster child for an unsustainable, way-too-prescriptive requirement is CIP-007 R2, although I may now have to include CIP-010 R1 as the poster child’s identical twin.
Folks, if the two most prescriptive CIP requirements (and not all of the CIP requirements are prescriptive. There are now at least three or four non-prescriptive ones, including CIP-007 R3 and CIP-010 R4) are literally impossible to completely comply with, there are only two possible reasons for this. The first is that the vast majority of CIP compliance people employed by NERC entities are idiots, and simply can’t figure out how to comply with these requirements. The second is that there is something really wrong with prescriptive requirements, at least where cyber security is concerned. I’ll let you decide which of these is the case, although for my personal answer I’m going to rule out the first reason offhand, since I know for a fact it isn’t true. That leaves the second reason, IMHO.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.
[i] And for a good description of what the CIP-007 R2 compliance process should be, you should read the article by Lew that I referenced in this post.
[ii] I will make the exception for entities with very few Medium or High BCS. When you don’t have many of these (as well as Protected Cyber Assets), then you might very well be able to be 100% confident that you are properly complying with both requirements – or at least the lack of self-reports shouldn’t be considered prima facie evidence that you are out of compliance. But if you have hundreds or thousands of BCS and PCAs and you aren’t self-reporting any violations, you should look closely at these two programs and make absolutely sure you’re doing everything right. If you do this and you are still confident you’re in the good, congratulations. But you should not make this assumption without being absolutely sure these two programs are bullet-proof.
[iii] Lew wanted to make it clear that he wasn’t criticizing the CIP v5 SDT for their drafting of these two requirements. He pointed out that the SDT had originally included the “Identify, Assess and Correct” language in 17 requirements (including the two in question here), which would have mitigated most of the bad effects of overly prescriptive requirements. FERC always had lots of questions about this language, since they considered it likely to make the CIP v5 requirements un-auditable. So in their Order 791, they ordered NERC to remove that language (in v6). NERC did this, of course, but that then left NERC entities exposed to the full force of the cruel, cold winds blowing from the most prescriptive CIP v5 requirements.
[iv] I should point out that Lew made that statement during an email exchange regarding the problem of prescriptive requirements, so it may not be surprising that he pointed to that as the problem. On the other hand, Lew wouldn’t have said this if he didn’t mean it.