If you're looking for my
pandemic posts, go here.
This is the second part of my post
discussing FERC’s Notice of Inquiry on “Potential Enhancements to the Critical
Infrastructure Protection Reliability Standards”. The NOI discusses areas in
which FERC staff believes the current NERC CIP standards may be inadequate and
might need to be enhanced; the NOI calls for comments on these areas. The two
broad area that FERC identifies are a) insufficient coverage of the various
categories of risk listed in the NIST Cybersecurity Framework (CSF) – the staff
identified three categories that may be insufficiently addressed by CIP - and
b) the risk of a “coordinated cyberattack on geographically distributed targets”.
The first
part of this post leveraged a LinkedIn post by Dale Peterson and delved
into the first of those two areas. I questioned (as Dale did in his post) the
concept of mining a risk management framework (which is what the CSF is, of
course) to develop a set of recommendations for individual requirements, as if
the CSF were a best practices guide. In this second part of the post, I will look
at some of the “recommendations” made by FERC staff for possible implementation
of new requirements based on the CSF. I will also discuss how the risk of a
coordinated attack might be addressed. As usual, I will look at these through a
Big Picture lens because – hey, I’m a Big Picture kind of guy.
The whole premise of FERC’s examination
of the CSF seems to be that the CIP standards already do a fairly good job of
addressing a large number of cyber threats to the BES, and that just adding a
few more standards or requirements might make it close to complete (unless they
plan on issuing one of these NOI’s every six months or so, which I don’t
believe is their plan). To that end, they ask a number of questions, related to
the three CSF categories which they don’t think are adequately addressed in the
CIP standards now. These include:
1.
Protecting information integrity for Low impact
BES Cyber Systems (p. 12 paragraph 13). They correctly state that information
integrity for Medium and High impact BCS is probably adequately addressed by
CIP-011-2 R1 now (which I agree with), but they point out that this doesn’t
apply to Low BCS – they ask if there should be an information integrity
requirement for Lows. I don’t dispute that this is probably a deficiency,
although I question how big a risk this is.
2.
Incident response requirements for Low BCS (p.
13 paragraph 16). Again, this is currently well covered for Medium and High BCS,
but not for Lows. They wonder if it should be extended to Lows in some way. I
think this might be justified, if this is deemed to be a sufficient risk.
3.
Vulnerability management and mitigation for Low
BCS (p 14 paragraph 18). The NOI says that CIP-10 already adequately addresses this
for Mediums and Highs. I have no idea what they’re talking about here. As far
as I’m concerned, neither CIP 10 nor any of the other current CIP standards addresses
vulnerability management at all, except for the single case of software or
firmware vulnerabilities for which a patch is available – and CIP-007 R2 goes
way overboard in mitigating that threat. Vulnerability management should be
addressed for Highs, Mediums and Lows.
But there are still vulnerability management risks that aren’t addressed at all in CIP now, including a) the risk of unpatched vulnerabilities in purchased software (which will be partially addressed in CIP-013 R2.4, and should – in my opinion – be addressed as one of the risks identified in CIP-013 R1.1); b) the risk of unpatched vulnerabilities in third-party or open source components of purchased software (which I also recommend that my clients address in R1.1); and c) the risk of unpatched vulnerabilities in software written by your organization or custom-developed for you (this risk isn’t in scope at all for CIP-013, since that standard only covers products and services that are procured from outside sources. I was at a supply chain cybersecurity meeting in McLean, VA in 2018, at which a bunch of Federal cybersecurity contractors expressed amazement that CIP-013 didn’t cover in-house-developed software).
Regarding coordinated attacks on
geographically distributed targets, I think this is also a legitimate area to
look into, although I find it almost impossible to believe that this could be
anything other than a supply chain attack. And I don’t want to see another
minute wasted on a discussion of hardware vulnerabilities that could somehow be
built into a bunch of non-intelligent transformers with no connection at all to
the outside world – thanks to the EO,
we’ve already wasted, and will continue to waste, lots of time on that
discussion.
There are two serious threats of
coordinated distributed attacks on the grid today. The NOI points out one of
them (on page 20 paragraph 27) – the Worldwide
Threat Assessment put out by the ODNI, FBI and CIA in January 2019 (which
interestingly enough hasn’t been updated yet for 2020, even though it’s
supposedly an annual report), which pointed to the statement that the Russians are
able to cause temporary outages of several hours at various points in the grid.
To be honest, I’m pretty tired of various government officials stating that
this is a big
threat – which it is – yet also being perfectly willing to leave the whole thing
uninvestigated, since no government or industry group has even bothered to try
to figure out whether these statements are true or not. Maybe FERC will decide
that they should do this (after all, if the statements are true, there’s
Russian malware sitting out there in a number of control centers today. Wouldn’t
it be nice to know what malware to look for, so the industry could eradicate
it?), but I’m not holding my breath at all on this one.
The other serious threat of
coordinated distributed attacks on the grid is the software supply chain. There’s
at least a possibility that a foreign adversary could have figured out a way to
plant backdoors in software that is used at multiple locations on the grid and
might be connected in some way to the outside world. It’s at least larger than
the pure fantasy
that there could be a distributed attack on transformers.
So the NOI points out at least some
potentially important threats that might be worth considering for a set of “enhanced”
NERC CIP standards. But why stop there? How about addressing some very serious threats
to the BES that have been around for a long time, yet nobody – and especially
not FERC – has even suggested that these threats be included in CIP? These
include ransomware, phishing and advanced persistent threats. I’d say the first
two of these are the most serious cyber threats in the world today. Shouldn’t
they be considered, too? I could probably quickly think up 5-10 more important threats
that simply aren’t addressed at all in CIP today – and I’m sure you could as
well.
So here’s the deal: There are lots
and lots of threats that should at least be considered if we want to “enhance”
the NERC CIP standards. Even more importantly, new ones are appearing all the
time. Currently, the only way to incorporate any of them into the CIP standards
is by using the NERC standards development process, which includes developing a
SAR (standards authorization request), constituting an SDT, going through a
number of ballots and comment periods, getting approval from the NERC Board of
Trustees, submitting the new or modified standard to FERC, waiting 6-18 months
for them to approve it, and finally going through a 6-24 month implementation
period. Then voila! Two to six years later, the new standard will be in
place.
As an example of the lightning
speed at which the standards development process operates, the risk posed by
plugging an insecure laptop into a corporate network has been clear since the
late 1990’s. When did the first CIP requirement addressing this risk (CIP-010
R4) come into effect? 2017. It took 20 years. Phishing has been a threat more
than ten years, and ransomware not much less than that, yet – again – there’s
no discussion of even considering a requirement to address these two very
serious risks, from FERC or anybody else (and FERC had a conference on
ransomware about three years ago). The standards development process is so burdensome
that nobody wants to even bring up the idea that there should be a new
requirement.
The fact is that there needs to be
some group (consisting of NERC entities, NERC staff, FERC staff, perhaps trade
organizations like NRECA and NATF, and maybe even representatives from Congress
or the general public) that regularly meets to survey the whole range of
cyber threats to the BES and decide which are the most important ones. Only by
taking a comprehensive look at all the risks can anybody make a decision on
what’s important or not.
This group would be charged with regularly
updating the list of cyber risks and providing it to all NERC entities (or at
least those with BCS) – as well as providing guidelines for mitigating the
risks. Each entity would be required to consider each risk and determine the
likelihood that it applies to their BES environment. They would need to mitigate
the most important risks and document why they don’t think the others are
important enough to mitigate. They would be audited on how well they did this
(which will be something like how CIP-013 will be audited, assuming that goes
well).
Until a group like that can look
at the universe of risks as a whole and identify the most important ones, and until the current CIP requirements can all be replaced with risk-based ones, I frankly think it’s a waste of time to even talk about developing new requirements to address
a few risks, no matter how important these may seem to FERC or anybody else.
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.
Are
you hot at work – or should be – on getting ready for CIP-013-1 compliance on
October 1? Here is my summary of what you need to do between now and then.
No comments:
Post a Comment