Lew covers Lows, and Tom rants

The September/October edition of RF’s newsletter contains another great article by Lew Folkerth[i]. He has been concentrating on CIP-013 (as I have) since late last year, but in this article he switched to the other big current concern of the NERC CIP community: Low impact assets, and specifically the two new versions of CIP-003 R2 that are coming out early next year. And per what we’ve come to expect, he covers Lows with typical Folkerthian (I’ve just coined a word. Remember, you heard it here first!) thoroughness.

Specifically, Lew discusses every CIP requirement that applies to Lows, both those in effect now and those on the way. And he provides good insights into everything he discusses. So where are the flaws in this article? Nowhere that I can see.

I’ve had a few people ask me lately what’s the deal with the two new CIP-003 versions: CIP-003-7, which becomes effective on January 1, 2020, and CIP-003-8, which comes into effect on April 1, 2020. Most people can’t tell the difference between them, which is quite subtle, I’ll admit. Here’s the story (and here I’m speaking more directly than Lew, being a NERC employee after all, is permitted to): You should really just consider CIP-003-7 as the next version, and ignore CIP-003-8[ii]. Literally the only difference between the two is that CIP-003-8 incorporates a small change that FERC ordered when they approved CIP-003-7, but it’s almost inconceivable that you won’t already have incorporated that change when you develop your CIP-003-7 program.

That change has to do with the Transient Cyber Asset (i.e. laptop) controls in Section 5 of attachment 1 of CIP-003. When FERC approved CIP-003-7, they pointed out that the suggested controls relating to TCAs owned by a third party (almost always a vendor, of course) in Section 5 of Attachment 1 just suggest that the entity review what the vendor has done to mitigate the risk of malware being on the TCA, not actually mitigate it. They ordered that NERC revise the requirement so that it also requires mitigation of the risk.

Therefore, Section 5 of CIP-003-8 Attachment 1 contains the sentence

5.2.2 For any method used pursuant to 5.2.1, Responsible Entities shall determine whether any additional mitigation actions are necessary and implement such actions prior to connecting the Transient Cyber Asset.

Let me reword this for you: CIP-003-7 stated that you should review the vendor’s controls on TCAs, but it didn’t explicitly require you to do anything if you didn’t like those controls. This means, for example, that you would

1. Discover that one vendor wasn’t doing anything at all to prevent malware on their laptops used at customers (which of course is highly unlikely in itself, since all vendors have lawyers who have told them in no uncertain terms the liability they’d face if one of their laptops infected – say – a critical substation and caused an outage).
2. However, FERC assumed you would do nothing more about this, without being prodded by the CIP standards. So you wouldn’t.
3. Then, when someone from the vendor came to your substation bearing one of those suspect laptops, you would just wave them through saying “Go ahead and connect to any device you want, even though there’s a good chance you have malware on your laptop. What could possibly go wrong?”

Of course, this is a ridiculous idea. Nobody who works in IT or OT, who isn’t literally insane, would do this. Yet FERC seemed to think this was a big problem, so they ordered NERC to change the requirement to make it clear the entity needs to do something when they have reason to believe a vendor isn’t doing what it should to protect its laptops from malware. This is roughly the equivalent of writing a law requiring parents to take action if they’re told their house is on fire and their children are trapped inside, based on the assumption that without such a law, they’ll just go about their business as usual, while saying “Really? Now that’s interesting….”

So FERC just ordered that NERC make this one change. But as you know, NERC can’t just edit a standard to put in a small change, then publish it and go out to lunch. To make the change that FERC ordered, NERC’s Rules of Procedure (RoP) require it to

1. Write a Standards Authorization Request for this change, and ballot that SAR;
2. Have a drafting team make the change (in this case, it was the CIP Modifications SDT, which drafted CIP-003-7 originally and which is still working today); then
3. Submit it for a first ballot by the NERC ballot body. There were 205 votes for and 30 against in that first ballot in the fall of 2018, yet the RoP doesn’t consider that final (not because this isn’t a sufficient majority, but because I believe there always has to be another ballot after any standard meets the required majority, for some reason). Thus, there had to be a “Final Ballot”, which was submitted and approved more than six months after the first one.
4. Of course, after that the NERC Board of Trustees had to approve CIP-003-8 at their next quarterly meeting, and finally FERC had to approve it, which took a few months in itself.

So now we have a new version of CIP-003 that differs by one sentence from CIP-003-7, and in practice literally requires entities to do something they’re all already doing for CIP-003-7 compliance. Yet NERC still has to go through the above process, which stretched out more than a year. Granted, I doubt anyone had to devote a huge amount of time to this, since it was all fairly routine. And since the SDT that had developed CIO-003-7 was still operating, NERC didn’t have to put together a new SDT, which would have been a big job in its own right. But the fact that everyone had to go through all these steps for what could easily have been a one-hour fix (which shouldn’t have even been needed in the first place) is pretty disappointing.

So who’s to blame for this? FERC deserves some blame, because they ordered the change. But the funny thing is that FERC always orders NERC to make changes to CIP standards that they approve (and there are few if any CIP approvals where they haven’t ordered at least one change), yet never admits that they know that NERC’s Rules of Procedure require it to go through the full standards development process for even the slightest change; instead, they just state that NERC should change the standard. Of course, I’m sure FERC isn’t allowed by law to consider NERC’s internal procedures when they decide a change is needed to a standard they’ve just approved.

So the real blame falls on the NERC Rules of Procedure – although not on any particular NERC employees. Since the above is the only way to make a change in a NERC standard that’s already approved, it’s a real inhibitor to improving existing standards (e.g. coming up with some “definition” of “programmable”, which NERC put in the SAR for the CIP Modifications SDT, but which they’ve never addressed and never will, perhaps because there really isn’t a workable definition of that word), as well as developing new standards to address new threats like phishing and ransomware.

Phishing and ransomware have both been around for many years (especially phishing) and are perhaps the two most destructive cyber threats today, yet there is now not even any discussion about developing new CIP requirements to address them. I think this is a problem, but I’m not at all inclined to suggest developing these two requirements now. In my webinar last week – for which the recording should be available soon – I described a mechanism for removing changes to CIP from the standards development process. Once that is done, then any important new threat could be easily incorporated into CIP – but this would also require that all of CIP be rewritten as non-prescriptive, risk-based requirements. But until that happens – and I think various pressures will drives this to happen, within a few years – trying to develop any more CIP standards not explicitly required by FERC will literally end up causing more harm than good.

Have a nice day. 

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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.

---

[i] There’s also a PDF that includes all 34 of the CIP/cybersecurity articles that Lew has written for the newsletter, starting in late 2015 (including this one). You can find that here.

[ii] Of course, you can’t really ignore it, since your compliance documentation will need to reflect that you were complying with CIP-003-7 for three months and then you became compliant with CIP-003-8. And don’t be snarky – like this post – and point out to the auditors that you were compliant with CIP-003-8 on January 1 anyway, since there was no way you could develop a CIP-003-7 program without also complying with CIP-003-8. Leave that to me.