In two
recent posts (here
and here),
I laid out the case for saying there will be no further development of the CIP
standards in their present form, except for compliance with future FERC orders.
But why is this a problem? Maybe NERC CIP is just fine as it is….No, I’m afraid
that’s not the case.
In those two
posts, I discussed one serious consequence of this situation: that NERC
entities will never have definitive answers to any interpretation questions
about CIP v5 and v6. And there are many of these!
This is of
course a serious problem for NERC entities subject to the CIP standards, but it
isn’t for the general public. The degree of protection against the consequences
of a large-scale cyber attack that the CIP standards afford them (and I have said
multiple times that CIP compliance has clearly made the industry much more
secure than it would be otherwise; the problem is the huge and rising cost that
goes along with the current prescriptive CIP compliance framework) is in no way
diminished by the fact that there has been so much confusion over what the v5
and v6 standards mean. The lights will stay on, regardless of how many CIP
compliance professionals spend long nights trying to figure out how to comply
with ambiguously-worded requirements.
But there
actually is another very serious problem that ultimately can and will affect
the general public, due to the fact that CIP won’t ever be expanded: CIP will
never be amended or expanded to address threats that the standards don’t
currently address. CIP already doesn’t address some of the most important cyber
threats today, and that problem will keep growing, since new threats are always
appearing.
I’ll admit
this is a problem that’s been around for a long time. Exhibit A is phishing – a
threat that was probably recognized about 7 or 8 years ago (I don’t believe I’d
ever heard this word until then, perhaps later than that). The current
standards do nothing to address phishing (and don’t tell me that quarterly
security awareness efforts are in any way adequate to mitigate any of the risk
posed by phishing!); this isn’t surprising, given that the framework for CIP v5
and v6 was laid in 2008. That was when FERC issued Order 706, which approved
CIP v1 but also ordered NERC to make a number of changes; CIP v5 was the
culmination of the effort to address the directives in Order 706 (indeed, the
drafting team that was put in place after 706, which drafted CIP versions 2
through 5, was called the CSO 706 drafting team, where CSO stands for “Cyber
Security Order”).
A standard
practice for NERC, in drafting a SAR for a new drafting team to address a FERC
order, is to keep that SAR as narrow as possible – if possible, only including
what is in the order itself. And with Order 706 – which weighed in at over 600
pages – NERC had all sorts of motivation not to go beyond the order. Even
addressing what was in the order – or as much of it as NERC felt they could
address – took five years! So, even though phishing quickly grew in importance
as the years went on, NERC never even considered adding it to the threats
addressed in CIP, since it wasn’t mentioned in Order 706. This means that now
we have the situation in which at least one study
found that 91% of cyberattacks start with a user clicking on a link or
attachment in a phishing email (and both of the Ukraine attacks started that
way!), yet CIP has absolutely nothing to say about phishing.
Of course,
I’m not at all saying that utilities aren’t hyper-vigilant about phishing; in
fact, the same study found that utilities had the third-lowest phishing success
rate of the ten industries studied. I have heard of one large utility that has
a “four strikes and you’re out” policy. Pursuant to that policy, regular test
emails are sent to all employees. An employee who clicks for the first, second
or third times is sent to increasingly serious training and given increasingly
explicit warnings. On the fourth click, they’re fired, with no appeal possible
(and in theory, the CEO isn’t exempt from this!). This may seem pretty harsh,
but given the serious threat that phishing poses to any organization, in my
opinion this is appropriate.
And phishing
certainly isn’t the only threat not addressed by CIP. How about ransomware? How
about purely destructive non-ransomware, exemplified by Not-Petya?
How about the many possible threats that come with virtualization? How about
the many threats attendant on storing BCSI in the cloud (which, as I discussed
in a series of posts this year starting with this
one, is allowed by CIP v5)? I’m sure there are a lot more that don’t come
to mind at the moment.
None of
these are new threats, yet not only are they not addressed by CIP now, none of
them except virtualization have even been included in a NERC SAR (and as my
recent post on virtualization asserted, the drafting team whose SAR this is
included in will almost certainly never even submit the required new
requirements and definitions to the NERC ballot body for approval). I think the
last new threats that were addressed in CIP are the threats posed by Transient
Electronic Devices and Removable Media; and these were only addressed because
FERC ordered this (in Order 791
for Medium and High assets, and Order 822
for Lows).
And why
aren’t these threats addressed in CIP v5 or v6, or at least set to be addressed
by the CIP Modifications drafting team? Because addressing a new threat
requires a tremendous multi-year effort: coming up with 3-4 major drafts of the
new requirements and definitions, submitting these to the NERC ballot body,
responding to the voluminous comments on each draft, submitting the final
approved draft to the NERC Board, and finally to FERC for their approval. And
should FERC decide they want some changes in the new requirements or
definitions, a new drafting team (or perhaps the original one) will have to go
through the same process again. It isn’t at all surprising that NERC
practically has to have a gun at their head before they’ll propose that CIP be
expanded to address a new threat.
Of course,
NERC does have other ways of dealing with new threats, most notably the NERC
Alerts, which have been used in the cases of the Aurora vulnerability and the
Ukraine attacks, as well as in other cases. These aren’t mandatory standards, but
they require NERC entities to report on what they are doing to address these
threats – which is pretty close to mandatory, in my opinion. And as I said,
probably all of the larger NERC entities are very attuned to new threats, and
consider any new warning from the E-ISAC or other industry bodies as something
that needs to be acted on.
But this
just means that, in today’s utility environment, cyber threats are addressed
using a hodge-podge of mandatory requirements (the CIP requirements),
non-mandatory “requirements” (the NERC Alerts), and all sorts of different best
practices. Except for CIP compliance, there is very little uniformity in how
NERC entities are dealing with these threats, and even with CIP there is lots
of variation among entities in how they comply.
Just as
importantly, the fact that there isn’t any uniformity in how NERC entities deal
with threats – both old and new ones – means that entities will almost always
spend most of their time and resources on the threats included in the CIP standards
(malware, remote access, etc), and less time and resources on threats not
included in CIP (phishing, ransomware, etc). This is frankly a mis-allocation
of resources, since in an ideal world each entity would look at all the threats
it faces, rank them based on their potential impact, and prioritize their
spending accordingly. Prescriptive CIP requirements inevitably result in too
many resources being spent on certain activities, compared to others that might
be of equal benefit but aren’t included in CIP at all. My poster children for
this are CIP-007 R2 Patch Management and CIP-010 R1 Configuration Management. Both
of these are important activities, but both consume disproportionate amounts of
resources (especially in large organizations) vs. addressing threats like
ransomware and phishing (if you have some time on your hands, you can find a
rather voluminous discussion of this problem in this
post).
You might
now ask how I would fix this misallocation problem, given that there have to
be mandatory standards (which I totally agree with). As some of you may know,
this spring I started advocating a new critical infrastructure compliance
regime that includes six parts:
1.
The process being protected needs to be clearly defined
(the Bulk Electric System, the interstate gas transmission system, a safe water
supply for City X, etc).
2.
The compliance regime must be threat-based, meaning there
needs to be a list of threats that each entity should address (or else
demonstrate why a particular threat doesn’t apply to it).
3.
The list of threats needs to be regularly updated, as new
threats emerge and perhaps some old ones become less important. Ideally, there
will be an industry body that meets regularly to assess new threats, as well as
document new mitigations. They will add important new threats to the list, and potentially
remove threats that are now of less importance.
4.
While no particular steps will be prescribed to mitigate
any threat, the entity will need to be able to show that what they have done to
mitigate each threat has been effective.
5.
Mitigations need to apply to all assets and cyber assets
in the entity’s control, although the degree of mitigation required will depend
on the risk that misuse or loss of the particular asset or cyber asset poses to
the process being protected.
6.
It should be up to the entity to determine how it will
prioritize its expenditures (expenditures of money and of time) on these
threats, although it will need to document how it determined its
prioritization.
Let’s focus
on parts 2 and 3, since these are the ones that are important for this post.
Part 2 essentially means that all of the CIP requirements should be replaced
with just one, which reads something like “On a risk-adjusted basis, take steps
to mitigate all threats on the current threat list, or document why a
particular threat doesn’t apply to your organization.” And part 3 calls for an
industry body to make regular updates to the threat list.
In my
opinion, this is the right approach because it requires the entity to do what
they would normally do in the absence of CIP: identify all current threats,
rank them by impact, and allocate resources to mitigate them according to that
ranking (with the stipulation that some threats may pose so little risk, or
they may not be relevant to the entity for some reason or another, that they
may be left out altogether – although the reasons for this will need to be
documented!). But this process will be mandatory, not just one of those
nice-to-haves that we all never quite get around to.
I hope you
see how the subject of this post – the fact that it’s very unlikely any further
cyber threats will be incorporated into the current NERC CIP compliance regime –
is addressed by my third point. New threats will be fairly easily incorporated
into my proposed new CIP compliance regime because there will no longer be any
need to develop new requirements, or modify existing ones. The single
requirement that I sketched out two paragraphs ago doesn’t ever need to be
changed, regardless of the new threats that come along. The industry body I’m suggesting
will be able to update the threat list simply through a majority vote (or
perhaps a super-majority vote) of its members.
So could all
of the problems with CIP be fixed by throwing out all of the current standards
and replacing them with my single requirement, as well as the six points? The
problem is that what I’m suggesting requires fundamental changes to NERC’s
Compliance Monitoring and Enforcement Plan (CMEP) and to its Rules of Procedure
(RoP), not just to the CIP standards.
Why do these
documents need to be changed? For one example, just consider my point 3. The industry
body I’m calling for would essentially have authority to modify what my single
CIP requirement covers, by updating the threat list. There is certainly no
provision in the two documents that would allow such a body to be constituted,
or to have this authority.
Even more
fundamentally, the way auditing would occur under my new compliance regime
would be radically different from the way it is described in CMEP and the RoP
now. These two documents describe auditing of requirements that mandate very specific
procedures (e.g. almost all the requirements in the NERC 693 or “O&P”
standards, as well as prescriptive CIP requirements like CIP-007 R2). These
requirements can be audited very simply: Did the entity do what was required?
If so, they are compliant; if not, they aren’t.
Think about
how an auditor would have to determine whether the entity had complied with my
single CIP requirement. Some of the components of that audit would include:
- Has the entity truly taken steps to address all of the
threats on the current list, eliminating only those that aren’t applicable
to it? And do I agree with the criteria the entity used to determine
applicability of the threats?
- Since the entity is required to address threats based on
the risk that each poses, have they developed a reasonable methodology for
determining risk? And is the “risk” addressed in that methodology the risk
to the Bulk Electric System, not to something else like the entity’s
finances (of course, the whole point of CIP is to protect the BES, nothing
more, nothing less)?
- Looking at each threat addressed by the entity, have they
deployed effective
means to address it? In other words, they may believe that a certain
chant, repeated daily, will prevent malware infection of their BES Cyber
Systems, but this isn’t an effective means of preventing malware.
I’m sure
there’s more to auditing my single CIP requirement, but I think you can see
that none of the three audit steps I’ve just listed would fit into the current
NERC CMEP and RoP, although in fact I contend that CIP auditors are already
partly moving in this direction. This is because some of the CIP requirements,
like CIP-007 R3 Anti-Malware and CIP-010 R4 Transient Electronic Devices, are
already non-prescriptive, objectives-based requirements. The only way to
effectively audit these requirements is to take an approach something like
this. But this situation – in which a few non-prescriptive CIP requirements are
audited using a very prescriptive auditing framework – simply can’t last. And
it would definitely not last if the current CIP regime were replaced with my
single requirement and my six points.
Of course,
we all know that the likelihood of CMEP and the RoP being so radically revised
by NERC is pretty small. Does this mean I’m wasting my time by proposing a new
compliance regime that will never be enacted? I don’t think so at all, and the
reason I don’t is that I think there will be steadily growing pressure – mostly
from Congress – on NERC and FERC to either a) make the necessary changes to the
NERC compliance regime so that new cyber threats can be easily incorporated
into CIP; or b) turn over cyber regulation of the electric power industry to another
government body that isn’t constrained by CMEP and RoP. Consider this
Congressional hearing sometime in the not-so-distant future.
Senate Committee Chairwoman: Thank you
for coming before us, Mr. High NERC Official. We’ve asked you to come here
today because we were disturbed to learn recently that the NERC CIP cyber
security standards still haven’t been updated to include such important threats
as phishing and ransomware. Can you explain to us why this is the case?
High NERC Official: I am pleased to
explain that to you, Madame Chairwoman. This isn’t due to our not considering
these threats to be of the highest importance. It is due to the fact that NERC’s
Rules of Procedure require a deliberate, democratic process for drafting and
approving proposed changes to the NERC CIP standards. We do intend to address
all of these threats in the future, but we are currently working on some other
changes to the CIP standards, such as new standards (ordered by FERC)
addressing supply chain security and protecting communications between control
centers. Once we have been able to draft and approve these and other new
standards and requirements, we will be pleased to turn our attention to other
threats like phishing and ransomware.
Senate Committee Chairwoman: Thank
you for your honest answer. How long do you think it will be before we have new
CIP requirements addressing these two threats, as well as other emerging
threats that we don’t even know about today?
High NERC Official: We have already
drafted the supply chain security standard and sent it to FERC for approval. We
still have a number of other new standards and requirements – including some
very important requirements regulating virtualization – that will take maybe
three years to draft and approve. But at that point, I think we might very well
be able to take up new threats like phishing.
Senate Committee Chairwoman: Excuse
me, but I don’t consider phishing a “new” threat. But let’s go on. You say in
three years you’ll be able to start addressing phishing. How long will it take,
after that point, for a new NERC CIP anti-phishing requirement to be in effect?
High NERC Official: I would think we
would have one in place in 2-3 years after we started drafting it.
Senate Committee Chairwoman: So it
will be 5-6 years before there will be a requirement addressing phishing, is
that correct? (HNO assents). And let’s suppose you could address ransomware on
the same timetable, so an anti-ransomware requirement would also be in place
5-6 years from now? (HNO assents) Of course, I also have to assume that a new
type of threat that appears say in 2018 will take much longer to address. Is
that the case? (HNO assents) Mr. High NERC Official, I have to ask you: Do you
agree that the North American Bulk Electric System is a critical national
asset, whose substantial impairment would have a huge negative effect on the
entire nation? (HNO assents) And do you agree that, while other methods are
important, there needs to be a mandatory compliance regime, backed by
substantial penalties, that will address all major threats to the security of
the BES? And that the BES isn’t well protected until CIP addresses all major
threats? (HNO assents, although he starts to look around nervously) Then how
can you say that NERC is protecting the BES, when there are such gaping holes
in the CIP standards – and there always will be such holes?
High NERC Official: (rising from his
seat) I’m sorry, Madame Chairwoman. I need a short break to confer with some of
my colleagues. Can we resume in half an hour?
Senate Committee Chairwoman: I’m
afraid we don’t have time to do that. I want to thank you for your honest testimony
today. I’m sure we will want to have further conversations with you in the
future. This session is adjourned.
Senate Committee Chairwoman (aside to
aide): Please contact the Secretaries of Homeland Security and Energy and ask
them to come before this committee to let us know if they might possibly be
able to address phishing and ransomware in something less than six years, if
they were given responsibility for cyber regulation of the BES.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte.
Tom,
ReplyDeleteI agree with what you are saying, and a risk-based approach to security is kind of the industry norm in general. It seems you are pitching a general risk assessment based review, gapped to current NERC-CIP mandates, with the addition of a running list of risk elements that can be added quickly. Risk assessments take into account something that NERC-CIP does not- business impact based prioritization due to risk (which includes cost).
Security is a constantly evolving landscape, and to document specific elements each time something new is developed seems to runs contrary to a general risk-based approach to security. In other industries, they follow a baseline compliance requirement (sometimes proscriptive, sometimes more general), yet most of the current compliance mandates do not touch elements such as phishing or ransomware. See below as examples:
PCI DSS v3.2 (No mention of Phishing or Ransomware)
ISO 27002-2013 (No mention of Phishing or Ransomware)
NIST SP 800-184 Guide for Cybersecurity Event Recovery (Discusses Ransomware, but only in context of data recovery efforts)
I don't think we can bullet-proof an approach that accounts for unknown new threats that is proscriptive as well, unless we require a general risk assessment that catches those new threats and identifies remediation actions (based on the risk assessment finding).
Compliance to a standard should be the baseline for all organizations, but not the only measurement of how to secure an organization. Due diligence and constant risk and compliance assessment are the best way to keep people on their toes. Just my very long two cents. :)