CIP-007 R2
is my poster child for an overly prescriptive requirement; I know many NERC
entities are spending huge amounts of time complying with just this
requirement. So I always have my antennae up for policies that might make the
burden even greater than it needs to be.
In a post
at the end of March, I reported on a presentation by Eric Weston, one of the
WECC CIP auditors, at their spring CIP User Group meeting. In that
presentation, Eric stated that the phrase “security patches” in CIP-007-6 R2 means
more than just vendor patches that are explicitly designated as such. He said
it is the entity’s responsibility to read the descriptions of all patches
issued by the vendor – that apply to the system in question – to determine
whether they patch a security vulnerability. If a patch does address a
vulnerability, then it is a security
patch and needs to be treated as such.[i]
At first, I
was upset by this, since it seemed to me that this meant that the entity could
be found in violation if they had missed a security patch that wasn’t
explicitly identified as such. But Eric explained that, as an auditor, he
wanted to make sure that the entity’s patch program entailed finding more than
just patches that were explicitly labeled as security ones, but that the entity
wouldn’t necessarily be held to be in violation if they had missed a patch that
addressed a security vulnerability but hadn’t been labelled a security patch.
That seemed fair to me.
Another
auditor had a slightly different take on this, although I don’t think he
differs in principle from Eric. He said
“We all know
that vendors do not always identify software updates as security related. A Microsoft Service Pack will most definitely
include security patches. A Cisco IOS
update may or may not include a fix to a vulnerability. A SEL update most likely will not, but it has
happened. You need to read the release
notes and other available information, and not just rely on the title or
abstract description of the update.
“Some folks
rely on the National Vulnerability Database to identify vulnerabilities and tie
them to available updates. That works
only to the extent that the vendor posts information to the NVD. You need to fill the gaps with other sources.
“If you do not look at updates released by your favorite
vendor, how do you know if any are security patches or are version updates that
include security fixes? If you do not look at release notes, the NVD, or
other available documentation on a software patch or update, you have no way of
knowing which updates are applicable security patches. So either do the
research or install everything just in case. And, yes, if you miss something
and my team can determine that, there will be a finding. If your process
is faulty and you are at risk of missing something in the future, there will be
an Area of Concern.”
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte.
[i]
However, this does not apply to functionality enhancements that provide a new
feature that can be used to improve security on a device – for example,
extending the maximum password length. I wrote a post
on this distinction in 2015. Functionality enhancements are of course important
to apply from a good security practice point of view, but this isn’t a
requirement of NERC CIP.
An auditor elaborated on this question when he said “First
of all, a patch fixes a bug. Ergo, a
security patch fixes a security bug.
That is an exploitable defect in the code. A feature update is not a security patch,
even if the new feature improves overall security. A feature update is not correcting a
vulnerable code defect. That said, I will discuss with the entity the
difference between focusing on compliance as opposed to focusing on protecting
their systems when they argue that have no obligation to do anything with the
new feature because the CIP Standards do not require it.”
No comments:
Post a Comment