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.”