Stop Making Sense: the Remix

I have been working this year with two organizations that are getting ready for CIP compliance at the Medium impact level, as well as a Canadian organization with Highs, Mediums and Lows, that only had to comply with CIP starting in 2017. These discussions have brought to my mind a number of issues that I addressed in posts and discussed with various entities, as the whole industry was getting ready for CIP v5 compliance in 2014-2016.

A very small number of these issues were actually resolved by revising the standards (although I really can’t think of any issue that was completely resolved in this way. Since changing one of the CIP standards is easily a 3-5 year process from initial idea to having an enforceable standard, it’s not surprising that this happens very rarely). A number of these issues (especially the various problems with CIP-002 R1 and Attachment 1, about which I wrote at least 50 posts, starting with this one) are no longer burning issues, since the auditors and the NERC entities came to a rough consensus on how to resolve them (even though it’s not supported in the requirements as written).

However, there are some issues (like the cloud) on which there hasn’t been any resolution of any sort. The only reason why you don’t hear complaints every day about these issues (from me as well as from others involved with CIP compliance) is that it’s quite clear that nothing can be done about them in the near term, except to do your best to work around them. In fact, I’m sure a lot of CIP compliance people have probably forgotten that these even were issues in the first place. They’re simply part of the landscape, like a mountain. If you’re going from point A to point B and there’s a mountain in between, you’re not going to spend a lot of time complaining about the fact that the mountain is there – you’ll just allow for that and make a big detour when you come near it. But the cost of having to make that detour is very real.

In my discussions with these three entities, they of course have questions on what particular requirements or definitions mean, and naturally try their best to make sense of them. For example, they might say “Surely CIP-007 R2 doesn’t require that we have to check every 35 days, for every piece of software installed within the ESP, to find out if the vendor has released a new security patch! What if the vendor has never released a security patch in ten years? Or what if the software involved is fairly insignificant and has minimal impact on the BES? It only makes sense that we should be able to devote our resources and time to what poses the most risk to the BES.”

To which I will (sagely) reply “I totally agree it makes sense that you should be able to look at risk in how you comply with this requirement (and all of the other CIP requirements as well). But what makes sense has nothing to do with CIP compliance. The only thing that matters is the strict wording of the requirement. If something is allowed by the wording, that’s what you do. If something isn’t allowed, you don’t do it. And if the wording is ambiguous (which it is very often, of course), well…that’s for another discussion.”

I wrote a post about exactly this issue in 2016. I just reread it, and it’s just as relevant now as it was then (in fact, the question I discussed in the post was about the cloud. I agreed then that it would absolutely make sense if NERC entities were free to entrust their BCSI, and their BCS, too, to cloud providers that had demonstrably good cyber security practices – but of course this just wasn’t allowed by CIP. If I’m not mistaken, this is as much an open issue today as it was in 2016, in fact much more so).

However, I’m pleased to say that there’s been some slow progress on addressing this issue. I pointed out in the post that the reason why NERC entities can’t apply reason very often in CIP compliance is that most of the CIP requirements are prescriptive. This is still the case, but it’s also a fact that every significant new CIP requirement developed since CIP v5 has been what I call plan-based, and what others call objective-based: That is, the requirement mandates that the entity develop a plan to achieve a particular objective. The means of achieving it are up to the entity, as long as what you propose in your plan is – are you ready for this? – reasonable. Isn’t that amazing? Not only can you use reason in developing your plan – that is the criterion by which the plan will be judged!

These requirements take different forms, but fortunately they all come down to developing a plan to achieve an objective. The current plan-based requirements are (in order of their development):

CIP-007 R3, Anti-Malware: This was developed with CIP v5. It doesn’t specifically require a plan, but it does definitely state an objective: mitigating the risk posed by malware. You have to go through a planning process to achieve that, since you need to do this for each BES Cyber System, EACMS, PACS and PCA, even though the appropriate means of risk mitigation may be different for different devices.

CIP-011 R1, Information Protection: This was also developed with v5. It requires you to develop an information protection program (same as a plan, as far as I’m concerned) for protecting BES Cyber System Information in storage, transit, and use.

CIP-010 R4, Transient Cyber Assets and Removable Media: This was developed with v6.  The entity must develop a plan to mitigate the risks caused by use of TCAs and RM within the ESP.

CIP-003 R2, Assets containing Low impact BCS: In the v7 version due for compliance on 1/1/20, the entity needs to develop a plan for protecting assets containing Low impact BCS in five different areas.

In addition, there’s CIP-013, which is due for compliance on 7/1/20.  It is the first CIP standard (in fact, probably the first NERC standard, period) that explicitly allows consideration of risk. It does this because FERC knew, when they wrote Order 829 in 2016, that there is no way for a utility to cost-effectively mitigate supply chain security risks if they don’t develop a plan that is based on risk.[i] CIP-012, currently being balloted, is also plan-based.

And this isn’t the end. The CIP Modifications Standards Drafting Team is working on (and currently has out for comment) revised CIP standards and definitions to officially permit CIP compliance for virtualized systems (as opposed to NERC’s current “Don’t ask, don’t tell” policy for virtualization, as well as any other area where the current standards are either ambiguous or just don’t reflect reality).

One key component of this effort is rewriting the most prescriptive requirements, like CIP-007 R2 and CIP-010 R1, as objectives-based. While this is being done specifically to address virtualization, I am sure all NERC entities will welcome this development, regardless of whether they have virtualized systems in their OT environment or not. That's the good news. What's the bad news? The changes the SDT is talking about now are years away from coming into effect. In the mean time, everyone still has the prescriptive requirements they love so much.

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, including 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 my services, please email me at the same address so we can set up a time to talk.

---

[i] And I would take this one step further: There’s no way that a utility can cost-effectively mitigate any security risks except by developing a plan that is based on risk. So what about all the risks addressed by the current prescriptive CIP requirements? They are being effectively mitigated now, but at a cost that is much higher than is needed, simply because the prescriptive requirements don’t allow for any consideration of risk. More importantly, there are a number of major risks – phishing, ransomware, APTs, etc. – that aren’t addressed by CIP at all now, and there’s no appetite on FERC or NERC’s part to go through the long and painful standards development process to incorporate these risks into CIP. If all of the current prescriptive CIP requirements were replaced by a single requirement that mandated that the utility develop a plan to achieve the objectives of mitigating each of the risks currently addressed by the prescriptive requirements, as well as other risks not addressed at all now, then the utility could decide how to allocate its resources, based on risk, so that the maximum amount of total cyber risk was mitigated, given the dollars available to spend. In my opinion, this would be the ultimate solution to CIP’s problems.