If you're looking for my
pandemic posts, go here.
I’ve been intending to provide my
opinions on FERC’s recent Notice
of Inquiry regarding possible changes to the NERC CIP standards. Today, Dale
Peterson, founder of Digital Bond and the S4 conference, gave me a nudge by
posting his own comments on
LinkedIn. Dale essentially said about half (really more than that!) of what
I was going to say about the NOI, although we have some differences that I’d
like to explain. The second part of this post will discuss my other observations
on the NOI.
In the third paragraph of the NOI,
FERC discusses the NIST Cyber Security Framework (CSF). They point out that there
are three sections of the CSF that they think aren’t adequately addressed in
the current CIP standards: “(i)
cybersecurity risks pertaining to data security, (ii) detection of anomalies
and events, and (iii) mitigation of cybersecurity events.” FERC proceeds to
examine each of these areas in detail, and to point out particular risks within
each of these three areas that they say aren’t adequately addressed in the
current CIP standards. They then ask for comment from the industry on a)
whether they agree that these are deficiencies and b) whether these
deficiencies in fact pose risk to the Bulk Electric System.
The problem with FERC’s approach to
the CSF is it doesn’t look at what the CSF is, and how it differs so much from
the current CIP standards. A framework is very different from a set of
mandatory prescriptive standards, which is what the CIP standards are for the
most part (CIP-013 being one exception to that statement). Frameworks deliberately
look collectively at the whole universe of risks (in the case of the CSF, it’s
cybersecurity risks to critical infrastructure), and try to be as comprehensive
as possible. That is, they don’t consider risk in deciding what areas of
risk they will address in the framework – they include every area of risk that
might possibly be important.
The whole idea of a framework is
that the entity that follows it will assess each area and decide what degree of
risk that area poses to their organization. They will then allocate their
mitigation resources to the areas that pose the greatest risk, and either
ignore or devote minimal resources to areas that don’t pose much risk to them.
On the other hand, a set of mostly
prescriptive requirements like NERC CIP doesn’t give the entity any option for
how they allocate mitigation resources between different areas of risk, or even
within one area of risk. For example, a NERC entity can’t tell their CIP
auditor they think that in general, requiring that they check every 35 days,
for every software package – and every version of every software package – in their
ESP, to determine whether or not there is a new security patch available is a
misallocation of resources.
The entity might reason that there
are undoubtedly some software products that rarely if ever have security
patches issued. For these, checking every 3-6 months might be a fine interval.
There are also some software products like EMS where 35 days is arguably too
long an interval – they should really check say every 15 days for that. If the
entity asks the auditor whether it would be a reasonable practice to decide the
interval based on risk, the auditor will probably agree that yes indeed this is
reasonable – while they’re writing out the Potential non-Compliance notice. Something
may be reasonable, but when it comes to prescriptive standards, that makes no
difference. If the standard says every 35 days for every piece of software, the
entity has to do that; anything else is a violation.
And if the entity thinks that the
CIP standards cause them to over-allocate mitigation resources between
different areas of risk (rather than within one area, as in the above example) –
so that the could use those resources much more effectively if they could
decide for themselves whether or not say checking every 35 days for new patches
for all software was more important than auditing their in-house-developed
software for vulnerabilities (which isn’t required by CIP at all now) - they’re
also out of luck. Every requirement in CIP needs to be fully complied with, no
matter what opinion the entity might have as to whether or not the risk addressed
by one requirement is more important than that addressed by another.
Dale provides a great example of
this point, although he used it in a somewhat different context: “I doubt you
would want to spend…time making sure every running service and every listening
port on a large number of cyber assets is documented correctly. Especially
since "CIP needed" ports and services by the system are often all the
attacker needs. You likely would want to look closely at what is allowed
through the security perimeter and the RTO and recovery tests that verify the
RTO can be met.”
I believe Dale is implicitly saying
that he thinks a lot of the effort expended on compliance with CIP-005 R1.3 –
the “ports and services” requirement – is wasted, compared to what could be
achieved by examining (perhaps with a layer 7 firewall?) all traffic that enters
the ESP for malicious content, as well as verifying that a recovery time
objective can be met for applications that might be brought down in an attack. In
other words, Dale thinks R1.3 could be rewritten or even removed, and two new
requirements (or requirement parts) should be developed to address the two more
important issues that aren’t addressed at all in CIP currently.
These kinds of risk-based
decisions are easily handled when following a framework like CSF. However, FERC
isn’t really looking at the CSF as a framework, where the entity uses risk to
guide their mitigation decisions; they’re looking at the CSF as a source of potential
prescriptive requirements (this is what the GAO did in their 2019 report, and FERC refers to
that in the NOI). In FERC’s and the GAO’s thinking, if an area of risk is
included in the framework, it needs to be considered for new prescriptive
requirements. But why stop there? Why not add Dale’s two suggestions as well,
since I don’t believe either of them falls under the three areas that FERC
identified. And I’m sure we could all think of other requirements to add on top
of these.
However, the window for adding new
prescriptive NERC CIP requirements closed a long time ago. The last time a CIP standard
drafting team developed a new prescriptive CIP requirement was during the
development of CIP version 5, which concluded with final balloting in 2012. Since
then, every new CIP requirement or standard has been non-prescriptive
and risk-based (even though some of them don’t actually mention risk). This includes
CIP-010 R4, CIP-003 R2, CIP-014 and of course CIP-013 (plus CIP-012 is
definitely risk-based as well). And the biggest driver of this change has been
FERC itself, which has ordered – at least for CIP-013 and CIP-014 - that the
new standards not be “one-size-fits-all”, which means they should be risk-based.
Does this mean that FERC should require
NERC to add three new requirements or standards to address the three NIST CSF
areas that they identified as missing, but they need to also order they be
risk-based? Well, the individual requirements or standards do need to be
risk-based, but that’s not enough. Before we add even more CIP standards and
requirements, all of the prescriptive requirements need to be rewritten
as risk based. And then there needs to be some overall framework to let the
NERC entity decide how best to allocate their resources among the different areas
of risk, while at the same time achieving some basic level of security (e.g. an
entity wouldn’t be allowed to say only check for new patches once a year. There
would be guidelines to help the entity avoid mistakes like that).
Dale concludes his post by saying
NERC CIP, or any regulation, should not define and test an
entire 'good practice' cybersecurity program. This is highly inefficient and
has diverted resources from actually improving cybersecurity in the BES. The
audit should verify that a cybersecurity program exists, it is being followed,
and it has the most important controls, from a risk reduction standpoint, in
place through sample audits.
The NIST CSF could be used. There could be a requirement for
a utility to have a Current Profile, a Target Profile and an action plan with
dates to close the gaps. The existence of and compliance with these documents
is easily audited in a similar way we audit secure development lifecycles
(SDL). Most vendors have a SDL that they can show you, and you can ask for
evidence the SDL must create for a development project and quickly determine if
it is actually followed or not without being a developer.
Dale and I both agree that the
current primarily prescriptive set of NERC CIP requirements needs to go. Dale’s
proposal about requiring the utility to gradually close gaps between their
current profile and their target profile is a very good suggestion for
replacing it, but I think that would require a wholesale revision of the whole NERC
program for monitoring compliance with the CIP standards. I think a more realistic
near-term replacement is to essentially make every standard or requirement like
CIP-013: it requires entities to “identify, assess and mitigate” (although the
word mitigate was left out, as I discussed in a series of posts including this
one) BES supply chain cyber security risks. There could also be requirements
to identify, assess and mitigate risks due to unpatched software
vulnerabilities, risks due to inadequate access control, etc. While I think there
will definitely be auditing problems with CIP-013 (perhaps like some of those
that arose with CIP-014),
I do think it can be audited without having to change NERC’s Compliance Monitoring
and Enforcement program, which isn’t in the cards at the moment.
On the other hand, just rewriting
the CIP standards like I’m proposing is going to be a major step. Maybe it’s just
as well to do it all at once. In any case, Dale and I agree that a major change
is needed. And that FERC’s idea of essentially adding more individual
requirements and standards (even if they’re risk based) is simply the wrong
approach.
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