An Interesting CIP Compliance Question

I have known Monta Elkins of Foxguard Solutions for three or four years, and have a lot of respect for him. If you’ve never seen his demonstration of hacking into a power drill and making it play the Darth Vader theme, you’ve missed something! So I was intrigued when he contacted me last week and said he wanted to discuss an interesting CIP compliance question he’d come across, which relates to the new Spectre and Meltdown vulnerabilities in Intel (as well as other) chips, and to Microsoft’s efforts to patch them. I’ll tell you up front that I’m not sure about the answer to this question. But here are the facts[i]:

1. Two weeks ago, Microsoft released a software update to address these two vulnerabilities (as well as other unrelated issues). However, they warned that, once the update was installed, some antivirus software packages would cause the “Blue Screen of Death” and refuse to boot the PC.
2. To show that their software is safe to use with the new update, Microsoft is requiring that A/V vendors set a particular Windows registry key, although it is also possible for the user, or an organization, to set it apart from the A/V vendor.
3. But here’s the kicker: If the user tries to install the update without the registry key being set, none of the patches will be installed. Moreover, since Microsoft’s monthly software updates are now cumulative, no further patches will be installed in subsequent months, until Microsoft changes the requirement for the registry key.
4. While the majority of A/V vendors do now seem to support the update and have updated the key, some have not. And this leads to our NERC CIP question.
5. CIP-007 R2 requires the NERC entity to designate a patch source; it will often be the vendor of application software running on a BES Cyber System –and the BCS in question here will often be an HMI (human-machine interface). That vendor will approve Microsoft patches for installation with their product; if they don’t approve them, you won’t install them.
6. Often, the vendor will also require your organization to use a particular brand of A/V software. There are three cases to consider:
7. First, let’s say your HMI vendor requires you to use an A/V vendor that has set the registry key. In this case, you don’t have to worry – your Windows patches will continue uninterrupted, as long as you have applied the most recent A/V update before you apply the Microsoft update. There will obviously be no change in your CIP-007 R2 compliance status.
8. Second, let’s say the vendor requires you to use an A/V vendor that has not set the registry key, and you (or your organization) don’t want to set it yourself (I know I would certainly have issues with doing that on my own!). In this case, since Windows patches are likely to cause serious problems, the software vendor won’t approve any patches for release, until either a) Microsoft relaxes their policy or b) the HMI vendor decides to find a different A/V vendor, one that will set the registry key. Since the vendor is your patch source and they’re not releasing any Windows patches, you don’t have any obligation to install Windows patches (or even consider them as applicable) under CIP-007 R2.
9. Finally, let’s say your HMI vendor doesn’t require that you use any particular A/V software, and you chose an A/V vendor that has not now set the registry key. This is where the compliance question comes in. The HMI vendor will presumably continue to approve Windows patches and send them out, but you won’t be able to install them, unless you change your A/V vendor. If you can’t change your A/V vendor for some reason, what do you need to do to comply with CIP-007 R2?

I must admit that, when I started writing this post, it seemed to me this was a question that didn’t really have an answer. But now that I’ve written it, the answer seems fairly clear: Under CIP-007 R2.2, you would likely determine that this patch is applicable (after all, it was released by the vendor of your HMI). You of course can’t install it, so you need to develop and implement a mitigation plan for whatever vulnerabilities were addressed by the patch, per R2.3.

If you have any other ideas about this, I’d like to hear them. 

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. 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.

---

[i] A lot of this discussion is based on this article from Computerworld.