I have written multiple posts
recently (including this
one and this
one) on why CIP-007 R2, the NERC CIP patch
management requirement, needs to be rewritten as a risk-based (or
“objectives-based”) vulnerability management requirement. My two main reasons
for saying this are:
1.
The inordinately high
cost of documenting compliance with CIP-007 R2 causes NERC entities with high and
medium impact BES environments to invest a lot of resources in activities that
don’t yield much of an increase in security. The same can be said for CIP-010 R1.
2.
CIP-007 R2 and CIP-010
R1 are very likely the two largest obstacles to implementing medium and high
impact BES Cyber Systems (BCS), Electronic Access Control or Monitoring Systems
(EACMS) and Physical Access Control Systems (PACS) in the cloud today. This is
because a cloud service provider may be required to provide compliance evidence
for these two requirements on an individual device (both physical and virtual
device) level; that will be quite difficult for the CSP to do.[i]
I’ve stated many times since CIP
version 5 came into effect in 2016 that CIP-010 R1 and CIP-007 R2 are the two
biggest examples of the high cost of complying with prescriptive CIP
requirements. One NERC entity with high impact Control Centers told me that, of
all the documentation they must generate for compliance with all NERC
requirements (not just NERC CIP requirements), half of that is due to CIP-010
R1 and CIP-007 R2. While it’s indisputable that security measures need to be
documented, a number of NERC entities have also told me they think half of the
CIP compliance documentation they produce doesn’t improve security at all.
Cybersecurity is a risk management
exercise. This means the objective of any cybersecurity requirement should be
to reduce risk. My main problem with CIP-007 R2 is that its objective, patch
management, doesn’t address a risk at all. Instead, it’s a mitigation
for an important cyber risk that isn’t directly addressed in CIP today: the
risk posed by unpatched software vulnerabilities in BCS, EACMS, Protected Cyber
Assets (PCA) and PACS. Since there are other mitigations for this risk besides
patch management, and because in many cases the risk posed by an unpatched
vulnerability is so low that it’s a waste of time for a user organization to
apply the patch for it, CIP-007 R2 needs to be rewritten as a vulnerability
management requirement.
How should CIP-010 R1, the CIP
configuration management requirement, be rewritten as a risk-based requirement?
As with patch management, configuration management is a mitigation for a
cybersecurity risk, not a risk in itself. What is the risk that configuration
management mitigates?
Think about what happens if you
misconfigure a system – for example, you disable authentication while working
on the system and forget to re-enable it. This leaves the system vulnerable to exploit
in a similar way to how a software vulnerability leaves the system vulnerable
to exploit. In other words, the purpose of configuration management is to
prevent vulnerabilities that are due to accidental misconfiguration, just as
the purpose of patch management is to prevent vulnerabilities that are due to
software flaws. Does this mean that CIP-007 R2 and CIP-010 R1 address the same
problem: risk due to unmitigated vulnerabilities?
I don’t think it does, and here’s
why: There is usually little or nothing that most organizations can do to
prevent vulnerabilities from being present in software they didn’t develop.
However, there is a lot that an organization can do to prevent configuration
vulnerabilities. In fact, that’s the purpose of CIP-010 R1: to prevent a
configuration error from leaving the system in a vulnerable state.
Given that’s the case, you might
wonder why I’m making such a big point about CIP-010 R1. Since its purpose is
to prevent misconfigurations from occurring in the first place, why does the
requirement need to be rewritten? Obviously, if there are no misconfigurations,
there’s no risk from misconfiguration, right?
Unfortunately, no. No true risk
can ever be completely “prevented”. I can prevent the risk of food poisoning by
not eating, but I don’t know many people who would think that’s a good idea. Similarly,
the way to prevent the risk of computer misconfiguration is not to use
computers at all, but that’s neither possible nor desirable for most of us.
Any risk management exercise needs
to begin by acknowledging there is no way to reduce the risk to zero. Even if a
NERC entity follows every letter of CIP-010 R1, it’s always possible that
someone on the staff will have a bad day and forget to do something really
basic, leaving the NERC entity exposed to both cybersecurity and compliance
risk.
Of course, you could substantially
reduce the risk of a bad day making someone forgetful by hiring two staff
members for every position and making sure that each person is always watching
the other. If that doesn’t work, you could hire three staff members for each
position – although even that isn’t guaranteed to work…
You probably get the idea: If
you’re willing and able to throw more resources into mitigating a risk, you can
probably reduce it to as close to zero as you want, but at an increasingly
higher cost per amount of risk mitigated. At a certain point, your boss will
tell you the company has better uses for its resources than trying to reduce this
particular risk to .00000001%. In fact, your boss might accompany that message
with a pink slip.
This is why it’s so important that
all the NERC CIP requirements be made risk- (or objectives-) based: If an
overzealous auditor wants to require a NERC entity to ignore all other options
for use of its time and money and focus the whole organization on mitigating
one particular risk (which might be the risk of computer misconfiguration), the
entity can argue that the auditor is being unreasonable.
However, there are a small number
of prescriptive CIP requirements that mandate certain actions come hell or high
water. For example, CIP-007 R2 requires you to apply or develop a mitigation
plan for every applicable security patch that’s been released for a software
product used in the ESP within the last 70 days. Even if the vulnerability
addressed by the patch has never been exploited in the wild since it was
discovered ten years ago – which means the vulnerability addressed by the patch
poses very little risk to the organization – it still is in scope for this requirement.
Fortunately, besides CIP-007 R2
and CIP-010 R1, I think all other CIP requirements are risk-based, even when
they don’t mention risk. For example, the many CIP requirements that point to a
plan or process as their objective are risk-based, since developing and
following a plan always requires identifying and managing risks.
I’m proposing that CIP-007 R2 and
CIP-010 R1 both be rewritten as risk-based requirements. You might ask why I
want to change them now, since the Risk-Management-for-Third-Party-Cloud-Services standards drafting team may well decide to change them on
their own. I agree the SDT will feel compelled to revise these two standards themselves,
but I also believe it
will be 2031 (or even later) before all of the new
and/or revised CIP standards they develop will come into effect.
CIP-007 R2 and CIP-010 R1 have been
a burden on NERC entities for years, even without any consideration of using
them in the cloud. Removing them from the Cloud Drafting Team’s agenda and creating
a separate drafting team for them could easily cut 2-2 ½ years off the Cloud
SDT’s work, as well as make it possible for NERC entities to comply with the two
new risk-based standards at least 2-3 years before they would otherwise be
able to. Even NERC entities that don’t plan to put BES Cyber Systems in the cloud
anytime soon will benefit from this.
Any opinions expressed in this
blog post are strictly mine and are not necessarily shared by any of the
clients of Tom Alrich LLC. If you would like to comment on what you have
read here, I would love to hear from you. Please email me at tom@tomalrich.com.
My book "Introduction to SBOM and VEX" is available! For context, see this post.
[i] I
used to say it’s impossible for CSPs to provide this evidence. I now say it’s difficult,
but not necessarily impossible.
