There is widespread agreement in the NERC CIP community that it’s time – in fact, way past time – to fix the biggest problem with the CIP standards: the fact that, because they’re based on the template established when CIP version 1 was drafted in 2006 and 2007, they unintentionally prevent medium and high impact BES Cyber Systems and EACMS from being installed in the cloud (note that low impact BCS – there are no low EACMS – have always been completely “legal” in the cloud).[i]
It is also important to remember that
the current “prohibition” of medium and high impact BCS and EACMS has nothing
to do with concerns about the security of cloud service providers, although probably
nobody thinks that CSPs should get a “free ride” regarding cybersecurity, even
if they have every certification known to man. The prohibition is in place
simply because in 2006 when drafting of CIP version 1 began, use of the cloud
was still nascent and a “computing system” always consisted of one or more
physical devices. There’s no NERC definition of a physical computing device,
but my operational definition is that it’s a computing system that, if you drop
it on your foot, will hurt. In contrast, if you could even figure out how to
pick up and drop a cloud-based system on your foot, it certainly wouldn’t hurt
(physicists still don’t think that bits and bytes have mass, although bits are
becoming more important in physics all the time).
Addressing this problem (or more
specifically, three problems: BCS in the cloud, EACMS in the cloud, and SaaS in
the cloud) requires some major changes to the CIP standards (or perhaps a new
standard). Changing the standards requires that a Standards Drafting Team (SDT)
be constituted from subject matter experts among the NERC entities (preferably
ones who are still breathing and are willing to make the substantial time
commitment required). They draft the new or revised standards and submit them
to the NERC ballot body for multiple ballots, each one followed by a comment
period in which the SDT members must respond to the questions submitted, followed
finally by approval by the NERC Board of Trustees and ultimately FERC.
However, before the SDT can be
constituted, a Standards Authorization Request (SAR) needs to be drafted by organizations
or individuals with an interest in the changes and submitted to the NERC
Standards Committee for approval. Recently, a SAR for BCS and EACMS in the
cloud, titled “Cyber Security - Risk Management for Third-Party Cloud Services”,
was submitted to the SC; it will be considered (although not necessarily voted
on) at the SC meeting.
The main purpose of a SAR is to
provide the SDT with “marching orders” that provide sufficient guidance on what
the SDT should do. That is, the SAR can’t read, “Hey, please figure out how we’re
going to solve the cloud problem and then write a standard to implement that.”
It needs to lay out a specific direction for the SDT to follow, without
prescribing for them how they’re going to proceed in that direction or what needs
to be the result when they get there.
The new SAR (which I believe is
the first one regarding the cloud and CIP that has been considered by the Standards
Committee) was drafted by three parties, although two joined forces for this
effort:
1.
ISO New England and
the ISO-RTO Council IT Committee, and
2.
EDF Renewables
While I don’t think the SAR is
perfect, I believe it provides enough of a roadmap that the SDT won’t wander in
the wilderness when they set out to put pen to paper to develop the cloud standard(s).
Moreover, I think the authors have described the most important elements of a solution
to the problem, which I tried to describe in this
post. These elements include:
1.
A requirement for some
sort of certification like FedRAMP or SOC II. The point of having this isn’t
that certification is a cure for all problems, but that it almost certainly
covers the main IT risks. What is not well addressed by certifications like FedRAMP
is risks that apply only to CSPs.
2.
A new scope for CIP. In
my opinion (and I think that of the authors of the SAR), the big problem is
what I said above: the CIP requirements are applicable to devices, not systems,
and a cloud provider can’t track what data are on what devices; their whole
model is based on systems. This is not my idea, nor that of the SAR drafters. I
got it from the CIP Modifications drafting team, which in 2018 developed a proposal
to do away with the concepts of Cyber Asset and BES Cyber Asset (which are the
basis of BES Cyber Systems currently), and instead base the standards on BCS
from the start. By making BCS the basis of compliance, that means it suddenly
doesn’t matter whether the BCS is implemented in physical hardware on premises,
in virtualized systems, or in the cloud – a single BCS remains the same if it’s
implemented in any of the three environments, or even in all three at once. Unfortunately,
that proposal got shot down because a number of large utilities didn’t want to
throw away most of the software, training, and procedures they had developed
for CIP compliance and go to something completely different. This leads to the
next element of the solution:
3.
Two “tracks” for CIP
compliance, one for on-premises systems and one for cloud-based systems. In writing
the blog post that I linked earlier, I realized it would be very easy to
implement this bifurcation in CIP-002 R1 and Attachment 1. This is because the
terms Cyber Asset and BES Cyber Asset are not used anywhere in CIP-002 and
haven’t been used there since CIP version 5 (which introduced the concept of
BCS in the first place) was implemented in 2017. Instead, CIP-002 starts and
ends with BES Cyber Systems; very little of substance needs to change (the big
change would be in the BCS definition, which would change from its current
minimalist definition to one that incorporates most of what is today the BES
Cyber Asset definition).
4.
A new CIP standard
applicable to BCS and EACMS implemented in the cloud. While the SAR doesn’t say
this, I believe the new standard (which might be called CIP-015) needs to focus
on the risks that apply specifically to CSPs, since “general IT” risks are already
well covered by certifications like FedRAMP.
5.
The standard should
include a requirement for the NERC entity to develop a plan to identify, assess
and mitigate risks attendant on implementing BCS (and other asset types like
EACMS) in the cloud, including risks due to the cloud provider(s) it uses. This
would be modeled on CIP-013 R1, although unlike that requirement, it would provide
an itemization of areas of cloud risk (e.g., how does the CSP vet the security
of third parties that serve as “access brokers” for services in their cloud?)
that need to be discussed in the NERC entity’s plan. The plan would not have to
mitigate any particular risk, if the entity can show that the risk is so low
that it doesn’t apply to them.
6.
The new “Cloud CIP”
compliance regime will need to solve the problems with both medium and high
impact BES Cyber Systems (BCS) and Electronic Access Control or Monitoring
Systems (EACMS), both of which are currently not “allowed” in the cloud at all.
However, the EACMS problem is easier to solve, since not as many CIP
requirements apply to EACMS as apply to BCS, yet the negative impacts of the
EACMS problem (especially on grid security, which of course is exactly what CIP
is supposed to be protecting, not undermining) are almost as important as the negative
impact of the BCS problem. The SAR suggests that the EACMS problem could be tackled
first.
7.
“(The) implementation
plan is to allow the possibility for early adoption ahead of any proposed
enforceability date.” This is very important. The SAR suggests that the SDT
target completion of the new or revised standard(s) and submission to FERC
within 12 to 18 months from the “start of SDT deliberations.” This is lightning
fast by NERC standards, but after FERC approval (which itself can take up to a
year) there is usually a 1-2 year implementation period (that period was two
years in the case of the two revised standards that will allow BCSI in the cloud
and will take effect on January 1, 2024). Given how long NERC entities have
waited to be allowed to implement BCS and EACMS in the cloud, it seems
especially cruel to make them wait another two years after FERC has approved
all the required changes. “Early adoption” will allow NERC entities who are all
ready to move some of their assets to the cloud to do so, while at the same
time those who are in no hurry, or have no plans to move any assets at all, don’t
have to change anything they’re doing now.
To conclude, I think the SAR now
before the Standards Committee should be approved. It’s past time, nd frankly, the
costs of not being able to use the cloud are growing all the time. No time like
the present!
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.
I lead the OWASP SBOM Forum. If you would like to learn more about what that group does or contribute to our group, please go here.
[i] Software-as-a-Service (SaaS) use in the cloud has also been “prohibited”, at least with medium and or high impact BCS. However, the only thing “illegal” about SaaS currently has to do with the fact that SaaS use with BCS will almost always require BES Cyber System Information (BCSI) to be transmitted to and stored in the cloud. For completely different reasons than BCS, BCSI has also officially been “prohibited” in the cloud – although, truth be told, there is at least one SaaS provider that has had customers with medium and/or high impact BCS for at least six years.
My expectation was that the two revised CIP standards
that will come into effect on January 1, 2024 – CIP-004-7 and CIP-011-3 – would
fix the SaaS problem once and for all. However, at the moment it seems that may
not have happened, due to what seems to be an inadvertent omission in the wording of CIP-004-7 R6. I will write more about that soon.
No comments:
Post a Comment