What’s a Security Patch?

My recent post on patch management brought up a new issue having to do with CIP-007-6 R2. An auditor made this statement:

“Probably the biggest question is whether an update that provides for configuring and entering a complex password constitutes a security patch.  While I would dearly like to assert that it is, I cannot.  A security patch is an update that corrects a vulnerability in the affected code.  Modifying the code to allow a better password is a feature update and does not address a vulnerability.  Therefore, the patch that allows for stronger passwords is not subject to the CIP standards[i].”

Let’s unpack what the auditor is saying:

1. R2 says the entity needs to consider “cyber security patches” for application; by implication, any patches that may be released by the “patching source” (typically the software vendor) that are not “cyber security patches” do not need to be considered. So what is a cyber security patch?
2. I’m sure this will surprise you, but there is no NERC Glossary definition of this phrase. However, the Guidance and Technical Basis discussion of R2 says “The requirement applies to patches only, which are fixes released to handle a specific vulnerability in a hardware or software product. The requirement covers only patches that involve cyber security fixes and does not cover patches that are purely functionality-related with no cyber security impact.”
3. In the quote above, the auditor is saying that a hypothetical update that provides the capability of entering complex passwords (presumably to a device that previously didn’t have this capability) is a “functionality-related” patch, not a cyber security one. This means the entity isn’t violating R2 if they decide not to even consider applying this patch.
4. The auditor’s statement led two people – a cyber security and compliance professional at a NERC entity, and Prince Riley of Pinnacle Systems Group – to write in and say they didn’t see how the hypothetical patch couldn’t be called a security patch. After all, there aren’t too many patches that could enhance security more than one that made possible the use of complex passwords, right?
5. The important thing here is to look at what the SDT said in the Guidance: “A security patch is an update that corrects a vulnerability (italics mine) in the affected code.” Does the lack of complex password capability constitute a vulnerability? If you look at the previous post to the one cited above, you will see that one software vendor (quoted by Brandon Workentin of EnergySec in end note iii) states that "Security vulnerabilities involve inadvertent weaknesses; by-design weaknesses may sometimes occur in a product, but these aren't security vulnerabilities." If you follow their reasoning, the lack of complex password capability in a device is certainly not inadvertent. It is most likely there because, at the time the device firmware was developed, there was some reason why this capability couldn’t be provided. This position implies that a firmware patch that provided this capability isn’t a “cyber security patch” as defined by the SDT.
6. The discussion so far would seem to bring the whole question of whether the patch in question is or isn’t a security one down to the question of what is a “security vulnerability”. Of course, that’s not a defined NERC term[ii], which would normally lead me to say that this is a case just like the phrase “Programmable electronic device” in the definition of Cyber Asset. There is no NERC definition of “programmable”, nor is there likely to be some sort of definitive guidance on this anytime soon. So it is up to each entity to decide how they will determine whether a device is programmable or not[iii]. Similarly, the discussion so far leads me to want to say that, since there is no NERC definition of “cyber security vulnerability” (and since I have never heard that one is on the horizon – indeed, I have never even heard this issue raised until now), it is simply up to the entity to determine how they will determine whether or not a patch is a cyber security one or not. As in all cases of missing definitions or ambiguity, the entity needs to document a) how they resolved the ambiguity (e.g., by developing a definition) and b) that they have applied that resolution on a consistent basis (meaning they can’t, for example, use one definition for “programmable” in one case but a different one in another).
7. However, I’m not ready to say this. The reason for my hesitation is because of the second sentence in the quotation from the CIP-007-6 Guidance and Technical basis that I quoted above: “The requirement covers only patches that involve cyber security fixes and does not cover patches that are purely functionality related with no cyber security impact (italics mine).” Here, the SDT is saying that one of the criteria for a patch that isn’t covered by this requirement is that it doesn’t have cyber security impact. By implication, this means that any patch that impacts cyber security is subject to the requirement. Doesn’t adding the capability for complex passwords impact cyber security? It’s very hard to say no to that. This may be why the auditor stated in the previous post that it was likely other auditors would take the other side on this issue.[iv]

What’s the point of this discussion? It’s that there is a fundamental ambiguity in CIP-007-6 R2 that is unlikely to be resolved without a SAR. The term “cyber security patch” is simply not defined anywhere, and the Guidance can be read two different ways (plus the Guidance isn’t mandatory in any case). As with “programmable” and many other issues, it is up to the entity to a) decide how they will address the issue, b) document their decision, and c) apply that decision consistently in complying with R2.

Of course, doing all this will require a large amount of time, which is why I’ve said many times that the effort required for CIP v5 compliance is somewhere between 5 and probably 50 times more than what was required for v3 (and this is assuming the same number of assets are in scope. For many if not most NERC entities, there are many more assets that are Medium or High impact under v5 than were Critical Assets under v3. This only compounds the increased workload). I used to think there was a white knight that was going to come in and clear up all of the issues with CIP v5 that are making so many peoples’ lives (and budgets) much more complicated. But I don’t see any white knights on the horizon. If you see one, let me know.

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

---

[i] Of course, the issue of functionality vs. security patches would normally only come up in the context of firmware upgrades. I doubt there are many functionality updates that are pure software patches. They would normally be software upgrades, which aren’t in scope for R2.

[ii] The auditor pointed out to me that there is a definition of “security vulnerability” in NIST 800-30: “A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.” The auditor notes that, were this to be adopted as NERC’s definition, his opinion on the issue of the hypothetical functionality patch would most likely change 180 degrees. But he has to deal with what is in the standards now, not what he would like to see in them.

[iii] Notice that I’m not saying here that each entity has to come up with their own “definition” of programmable. This is because it’s not at all clear to me that there could even be a definition in the dictionary sense. I’ve written several posts on this issue, but the one I like best is the first one from September 2014. In that, a CIP professional discusses the method he developed – and documented – for distinguishing programmable from non-programmable electronic devices. As you can see, this is certainly not a dictionary definition, but it has worked very well for this person; a couple others told me they adopted it for their organizations.

[iv] I made this point to the auditor, and he said that—in his opinion—the Guidance for CIP-007-6 R2 as a whole supports the idea that a cyber security patch is one that addresses a specific vulnerability, not one that updates functionality. Of course, when an auditor sees ambiguity in the wording of a requirement (or in this case, in the Guidance), he or she should never issue a PV just because their personal opinion on the issue is different from that of the entity being audited. This means that, even if the auditor held the opposite opinion that the patch that increases password complexity should be implemented, he certainly wouldn't issue a PV to an entity that had decided they didn’t need to consider that patch.