In my last post, I discovered – to my surprise, I’ll admit – that auditors are expecting NERC entities to patch device drivers to comply with CIP-007-6 R2, despite the fact that this won’t always be easy. However, there’s a related question: are they also expecting entities to include device drivers in the configuration baselines they develop for CIP-010-2 R1 compliance?
The answer to that question is yes. And here I can quote Lew Folkerth of RF, an ex-auditor now leading outreach for CIP at RF (and a major contributor to what must have been at least 20-25 of my posts, although it seems more like 500). He says:
“Device drivers that are not included in the operating system are software that should be identified in the baselines and patched accordingly. The entities I’m familiar with handle these device drivers as part of normal patch management. You identify any drivers in use that are not part of the OS as separate software in the baseline. You identify a patch source for the driver, usually the card or device manufacturer. Then you monitor that patch source on a monthly basis.
Some vendors will track patch sources for device drivers as part of their automated service. I’m sure pricing will vary.”
Note that Lew limits this to drivers that aren’t included in an O/S. He says this in part because the Guidelines and Technical Basis[i] for CIP-010-2 R1 includes the sentence ““The SDT does not intend for notepad, calculator, DLL, device drivers, or other applications included in an operating system package as commercially available or open-source application software to be included.”[ii]
But here’s another question: Does this “exemption” for drivers that are part of the O/S (and also open-source application software) apply to CIP-007 R2 as well? Lew’s answer – as well as that of an experienced auditor from another region – is a definite yes. So I may have been wrong in assuming that having to cover device drivers under R2 would present a huge burden to NERC entities. It seems that what they need to track are primarily hardware device drivers not included with an OS – and this should be a much more manageable quantity.[iii]
The quote below is from an email that one of the auditors mentioned in my previous post sent me while I was writing the post. It expands on his thinking regarding device drivers in CIP-007 R2:
“CIP-007-6 / R2 requires a patch management process for tracking, evaluating, and installing cyber security patches for applicable Cyber Assets. Nowhere in that Requirement statement is there an exclusion for device drivers. Device drivers are software and they are just as vulnerable and just as exploitable as any other installed software.
“Device drivers come in two flavors. Many, but not all, are included with the operating system (e.g., Microsoft Windows 7). If you are tracking patches for the operating system, then you will also encounter patches for the drivers included in the operating system.
“Some drivers, especially network interface drivers, are separately installed. Just as they need to be separately baselined because they are not included with the Operating System, they need to be tracked, evaluated, and patched like any other software. Typically, the correct patch source for a driver patch is not the manufacturer of the peripheral device; rather it is the OEM manufacturer of the Cyber Asset the peripheral is installed in. A very good example of device drivers you do not want to pick up from Microsoft are drivers for your display subsystem and your networking subsystem. You want to get drivers that are certified by HP, Dell, etc., for the Cyber Asset you acquired from the hardware vendor.
“If a Registered Entity chooses to not install security patches because “it is too hard”, “it takes too many resources”, “don’t think it is necessary”, etc., and they do not mitigate the vulnerability that is not being patched, then they will be awarded a Potential Non-Compliance and may receive “Intentional Non-Compliance” as an aggravating factor when determining the sanction.
“I would remind (your readers) that 80% or more of all successful system compromises result from failure to patch, failure to use effective anti-malware processes, and failure to limit system access to only that needed (both access in general and access permissions for those users so authorized). If entities are not patching their drivers, then not only are they not compliant, they are not secure.”
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.
[i] NERC now may – or again, they may not – be saying that the Guidance and Technical Basis included with the CIP v5 and v6 standards has a lesser status than Implementation Guidance, like the document developed by the CIP-013 SDT. I believe this ranking of the levels of guidance documentation is meant to be analogous to Dante’s Seven Circles of Hell. I will explore this interesting issue in an upcoming post. Don’t miss it!
[ii] I want to thank a NERC compliance person at a large NERC entity for pointing this sentence out to me.
[iii] On the other hand, I’m not going back one inch from what I said in the last two paragraphs of the previous post: Having to comply with mandatory prescriptive standards like CIP-007 R2 and CIP-010 R1, that can require huge amounts of work and money for compliance, is inevitably forcing NERC entities to spend less on security practices that aren’t part of CIP, such as phishing and ransomware. No entity that I know of has a blank check to spend every penny of their revenue on CIP compliance. Choices have to be made, and prescriptive standards force the entity to over-allocate resources to what’s required by CIP, and under-allocate to anything that isn’t required, no matter how important it might be. Security suffers from this arrangement, instead of one (which I’m gradually proposing) in which what is mandatory is that the entity spend a sufficient amount of money and effort to address the most important security threats it faces.