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:
- 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?
- 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.”
- 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.
- 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?
- 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.
- 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).
- 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.
No comments:
Post a Comment