Advice on CIP-010-3 R1.6

I met Richard Brooks, formerly of ISO New England and now with his own company, Reliable Energy Analytics, at the IEEE Smart Grid Security conference in December in Atlanta (remember when there were these things called conferences that people attended without the slightest thought about health risks? Ah, those were the days…). He and I both spoke at the conference. He’s a pretty interesting guy and seems to really know his stuff, especially about software security.

Richard emailed me this week about a post of his on Energy Central (where he contributes readily) on verifying integrity and authenticity for patches, in compliance with the upcoming CIP-010-3 R1.6, which is kind of the doppelganger of CIP-013 R1.2.5. Compliance with both requirement parts comes due on July 1 (BTW, if you read the post, I want to let you know that I object to Richard’s characterization of me as a High Priest. Maybe a First Deputy Associate Priest – something like that).

If you look through Richard’s post (and let me know if you have trouble getting into it. You should be able to, even if you’re not an Energy Central member), you’ll see that he’s suggesting a number of means of verifying software integrity and authenticity, none of which will be at all easy for someone who isn’t a real software geek (e.g. me).

Fortunately, R1.6 includes the provision “..when the method to do so is available to the Responsible Entity from the software source..” This means that, if the software supplier doesn’t provide a means to fairly easily verify that a patch came from them and wasn’t interfered with in transit (i.e. digital signature and hash value), you’re not obligated to take extraordinary measures like the ones Richard describes.

But remember that you also have to comply with CIP-013 R1.2.5, which requires you to have a process for “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System”. What’s the difference here? CIP-013 is a risk based standard; CIP-010 isn’t. In CIP-013, you need to consider the risk in every situation.

So let’s say you’re patching your EMS, and the supplier doesn’t provide a digital signature or hash value (not very realistic, I’ll admit. But bear with me). If you find something that looks like their patch on something that looks like their website, it certainly might be worthwhile taking some more extraordinary measures to verify it, given the importance that EMS poses for the BES.

Another difference between R1.2.5 and CIP-010 R1.6 is that R1.6 (like all of the other requirements in CIP-002 through CIP-011) applies to all BES Cyber Systems, not just ones that are being newly procured. CIP-013 just applies to BCS that are procured after 7/1/20 (as stated in NERC’s new CIP-013 FAQ).

And by the way, if you think all this verifying integrity and authenticity is a hoax, I’ll point out that one of my CIP-013 clients had an incident some years ago where a contractor downloaded a patch from what looked like the supplier’s site, but it turned out to be a fake site – and the patch had malware in it. Luckily, it got caught before it was installed (it was going on the IT network, not OT). But this can certainly happen.

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.