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]
Postscript
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.
No comments:
Post a Comment