Sunday, July 16, 2017

Are you Patching Device Drivers?

I’ve known for a while that in theory CIP-007 R2, the patch management requirement, applies to device drivers, and that could potentially pose problems. However, I hadn’t thought about this very much until last week, when a CIP compliance person at a large NERC entity inquired whether I knew if other entities were including device drivers in their CIP-007 R2 programs. In other words, do other NERC entities do the following tasks for device drivers: get an inventory of all that are installed on any device within the ESP every month; every 35 days, contact the vendor of the driver to determine whether there is a new security patch available; if there is a patch available, download it and determine whether it is applicable or not; if it is applicable, within another 35 days either install the patch or develop a mitigation plan for the vulnerability(ies) addressed by the patch and; implement the mitigation plan?

The entity pointed out that it is very difficult to comply with this requirement for device drivers because they are often made by small, obscure companies, and the system vendors don’t always automatically provide information on all of the drivers that are included with their systems. Moreover, security patches aren’t released as often as for other software, meaning it’s certain that on many months there will be no new patch available.

I honestly thought the answer to this question was a no-brainer. I had never heard a single entity complaining about this issue previously (although I’ve heard a lot of complaints about CIP-007 R2 in general). I automatically assumed this was a “Don’t ask, don’t tell” issue, in which there is tacit agreement among NERC entities and the auditors that patching device drivers won’t be discussed in audits.

It turns out I was wrong! I reached out to auditors in two regions, and they both said similar things: 1) Patching device drivers is required by CIP-007 R2; 2) It’s also required by good security practices; and 3) Any entity that isn’t doing it now would be well advised to get cracking on device drivers now, or big penalties loom in the future.

Of course, the fact that the auditors said 1) and 2) doesn’t surprise me; what else could they say? However, I was surprised at 3), since I’m sure there are other entities (including large ones) that aren’t patching device drivers now. But if auditors from two regions – both of whom I have great respect for - say they won’t take any excuses for not patching device drivers, then that constitutes solid evidence that NERC entities shouldn’t test them. QED.

However, I think this illustrates a much larger point. First, let’s assume that the entity that contacted me about this was right, and having to go through the CIP-007 R2 process every month for every device driver installed in the ESP is a) very burdensome and b) not necessary, since drivers aren’t patched very often. Wouldn’t it be nice if a NERC entity could balance the need to patch device drivers against all of the other things they need to do on a regular basis to maintain good cyber security, and say “Well, given that new device driver patches aren’t likely to come out most months, we’ll put them on a schedule of just checking for availability every six months? This will allow us time to address some other very urgent cyber issues, such as the need to develop and implement a strategy for preventing ransomware infections”?

Of course, we know what the answer from any NERC auditor will be to this suggestion: “The requirement is the requirement. If you don’t follow the requirement, you will be fined.” Is this because all NERC auditors are big meanies? No, it isn’t. It’s because they have to follow the NERC practices outlined in the Rules of Procedure and especially the Compliance Monitoring Enforcement Plan (CMEP). And those practices say that if an entity makes a decision not to comply with part of a requirement, they’ll get the book thrown at them.

What this means is that, because the NERC CIP standards are often prescriptive and are always enforced in a prescriptive fashion (since that’s what CMEP is based on), NERC entities will, in deciding how they are going to spend their allocated cyber security dollars, spend money first on complying fully with the NERC CIP requirements. This will happen no matter how expensive it may be to do this or how – in some cases – the entities will end up spending much more money on tasks like patching device drivers (because they’re required by CIP) than on items like preparing for ransomware attacks (because they’re not), even if they might believe their risk from ransomware is much greater than their risk from attack on a device driver.[i]

What can be done to change this situation? At one point, I thought just rewriting all of the NERC requirements as non-prescriptive ones would do the trick. But then I realized that this wasn’t enough – the whole NERC compliance regime (especially CMEP) would have to be altered, at least for the CIP standards. But that assumes that NERC is an old dog that can easily learn new tricks, and it can easily make the transition to having one division (the one that audits the Operations and Planning standards) that deals solely with prescriptive standards, and another division (that audits the CIP standards) that takes a very broad, holistic view of the entity’s cyber practices in total, and decides on a risk-informed basis whether the entity is doing a good job of allocating its limited cyber funds to adequately protect the BES. Is this a good assumption?

And even more importantly, maybe the real problem is the fact that currently cyber regulations are very different, and enforced by different bodies for each critical infrastructure sector. Attacks like Wannacry and Not Petya haven’t focused on just one sector – they’ve been wonderfully ecumenical and attacked every sector where there were vulnerabilities. Maybe there should be a single agency regulating cyber security for all critical infrastructure? In fact, there was an Op-Ed piece in the Wall Street Journal last week[ii] that called for a US Department of Cybersecurity. While I would have ridiculed the idea just a few months ago, Wannacry and Not Petya have made me think this is worth considering.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

[i] For a lengthy discussion of this idea, see this post.

[ii] It was called “America Isn’t Ready for a ‘Cyber 9/11’” and appeared on July 12. Since the WSJ’s online service is behind a paywall, I can’t include a link to the article, but you may be able to find it the old fashioned way – go to your local library! If they still have those anymore, that is. 

No comments:

Post a Comment