I have written two recent posts about the need to replace
(not just revise) the patch management requirement CIP-007 R2. Since both posts
were written for other purposes as well, I’d like to summarize what they say
and add some context that I previously left out.
The
first post from October pointed out that the two most prescriptive CIP
requirements, CIP-007 Requirement R2 and CIP-010 Requirement R1, are without
doubt also the two most burdensome; this is because of the huge amount of
documentation that the NERC entity must produce to prove compliance with each
of them. The evidence must be provided for every physical (and soon, virtual)
device in scope.
Moreover, the two requirements pose the biggest impediment
to implementation of medium and high impact BES Cyber Systems in the cloud.
This is because no CSP could ever produce the required device-level evidence,
even if the CSP’s patch and configuration management programs in fact followed
all the steps mandated by the two requirements. As every NERC compliance
professional knows, “If you didn’t document it, you didn’t do it.”
I went on to point out that both
problems – the overwhelming documentation demands for on-premises systems and
the fact that it is virtually impossible for a CSP to provide the compliance
evidence required by the strict wording of the two requirements – can be solved
by replacing the current prescriptive wording of each requirement with a
risk-based (or “objective-based”, to use NERC’s preferred term) requirement.
Doing this won’t be hard for
CIP-010 R1, since the objective of the current prescriptive requirement won’t
change in the new risk-based version: reduction of the risk that an inadvertent
configuration change in a system will leave it vulnerable to a cyberattack. The
difference is that the objective will be achieved in the revised requirement
through risk management, not through providing careful documentation of each
instance of compliance, as is the case currently.
However, in the October post I noted
that the objective of the current CIP-007 R2 is to ensure that every security
patch released for any software or firmware product installed on a system in
scope is applied, or that the vulnerability is otherwise mitigated. There is no
consideration of the risk posed by the vulnerability that is addressed by the
patch; if the supplier (or other patch source) has released a security patch within
the previous 35 days, either the patch needs to be applied or the vulnerability
it addresses needs to be mitigated in some other way. The NERC entity doesn’t
have the option of pointing out that applying the patch will address little or
no risk, and therefore it would be better for them to spend their time applying
patches hat do address risk, even if they aren’t required for compliance with
CIP-007 R2.
In other words, the problem with CIP-007
R2 is that patching isn’t a security objective in itself; it’s a mitigation
of the risk posed by one or more unpatched software vulnerabilities. If CIP-007
R2 is going to be rewritten as risk-based, it must be a vulnerability risk management
requirement, not a patch application requirement.
2. In this
post in December, I asked what a CIP
vulnerability management requirement would look like. I pointed out how much
more efficient that would be than the current patch management requirement. This is especially true because at most 6-7
percent of all vulnerabilities (CVEs) are ever actively exploited. This means
that a policy of applying every security patch that is released for a software
product inevitably leads to a lot of wasted effort. However, this is the policy
that is required by the current CIP-007 R2.
As I pointed out in the December
post, the annual volume of newly identified software vulnerabilities (CVEs) when
the original CIP patch management requirement was developed was a small
fraction of what it is currently. This meant that organizations didn’t have a
big backlog of unapplied patches; therefore, it was possible to apply every security
patch that had been released for a software product.
Today, because of the huge volume
of newly identified vulnerabilities – 35,000 this year alone vs. about 29,000
in 2023 - the biggest concern in vulnerability management is prioritizing patch
applications, so they are as efficient as possible. In other words, risk needs
to be reduced by the greatest amount possible, given the resources available
for applying patches. This is why I stated in my December post that the new
CIP-007 R2 should require that the vulnerability risk management plan prioritize
patch applications “…according to criteria listed in the plan”.
Note that I’m not calling for the
CIP-007 R2 vulnerability risk management plans to require use of specific
criteria to prioritize patching vulnerabilities based on the degree of risk they
pose. However, if a NERC entity just follows the FIFO method (first in, first
out) for applying patches, they should be cited for that, since the patch’s time
of arrival isn’t an indicator of the risk of the vulnerability being patched.
The most widely used vulnerability
prioritization criterion today is probably CVSS score.
However, many vulnerability management professionals will tell you that CVSS
isn’t a measure of risk, but of severity. Risk is some combination of
likelihood and impact. CVSS assumes that likelihood = 100%, so it only estimates
the worst case impact. This doesn’t mean that CVSS should be ignored by an
organization that is trying to prioritize patches according to the risk posed
by the vulnerability or vulnerabilities they mitigate. But it does mean that
CVSS should never be the only criterion you look at, or even the first
criterion.
The best way to measure the risk
posed by a particular vulnerability is by determining whether it is currently
being exploited or is likely to be exploited, using these two measures:
1.
Whether the
vulnerability (CVE) is in CISA’s Known
Exploited Vulnerabilities catalog, and
2.
The vulnerability’s
current EPSS score, which provides the likelihood (as a percentage between 0
and 1) that the vulnerability will be exploited within the next 30 days[i].
Using one or both of the above in
your vulnerability prioritization methodology is much better than relying
solely on CVSS, but you can use other criteria as well. These can include:
A.
CVSS, or even better, one
or more components of the CVSS score. For example, one of the components
estimates the degree of effort required to exploit the vulnerability. You can just
pull out that component and include it as on of you criteria.
B.
A measure of the
importance of an asset. Of course, since we’re talking specifically about NERC
CIP compliance now, all assets will be important. However, some will be less so
(e.g., a system handling I/O to a purely distribution substation vs a primary
EMS server).
C.
A measure of the
exposure of an asset, such as whether it is directly exposed to the internet,
or whether it is in a DMZ vs. an ESP.
Of course, there are many other
possible prioritization criteria. An organization should decide the right
combination of criteria for their needs (and different areas of the
organization might use different criteria).
Replacing CIP-007 R2 with a vulnerability
risk management requirement will help accomplish three goals:
1.
It will reduce the
amount of software vulnerability risk experienced by NERC entities with high or
medium impact CIP environments, since entities will be able to prioritize their
patch management efforts according to the amount of risk mitigated by each
patch.
2.
It will greatly reduce
the amount of compliance documentation required for NERC entities with high or
medium impact on-premises CIP environments.
3.
It will go a long way toward
eliminating the biggest obstacle to deployment of CIP-protected systems in the
cloud today: the fact that CIP-007 R2 and CIP-010 R1 both require the CSP to
provide evidence of prescriptive actions taken on a huge number of individual physical
and virtual cyber assets over a three-year CIP audit period.
Of course, the Project
2023-09 Risk Management for Third-Party Cloud Services Standards
Drafting Team (SDT) is just about to start drafting revisions and/or additions to
the CIP standards that will finally make use of the cloud completely “legal” on
the OT sides of all NERC entities. Since that team will almost certainly need
to rewrite CIP-007 R2 and CIP-010 R1, why propose that these two standards be
rewritten separately from that effort? There are two reasons why:
1.
Since CIP version 5
was implemented in 2016, I have continually been told that CIP-007 R2 and
CIP-010 R1 are by far the most burdensome of all the requirements that apply in
on-premises CIP environments. In other words, we need to fix these two
requirements as soon as possible, regardless of any consideration of cloud use
in the future.
2.
I recently estimated
that it will be 2031 – i.e., seven years from now - before the new or revised CIP
standards for the cloud are implemented. Since I think that rewriting CIP-007
R2 and CIP-010 R1 alone will require around 2 to 2 1/2 years, and since this
needs to be accomplished as soon as possible, it makes sense to have a separate
Standards Authorization Request (SAR) and SDT for this purpose. In fact, taking
this item off the current SDT’s agenda will probably trim that agenda by two years,
meaning the final CIP “solution” for the cloud could be in place by 2029 instead
of 2031.
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.
No comments:
Post a Comment