In this recent post, I noted that the “Project 2023-09 Risk Management for Third-Party Cloud Services” standards drafting team (SDT) has started drafting requirements for what I’m calling the “Cloud CIP” standards; this is the set of CIP standards, both new and revised, that will enable NERC entities with high and medium impact CIP environments to make full use of cloud computing services for their systems (BCS, EACMS, and PACS) that are in scope for CIP compliance.[i]
In the post, I described two types of requirements that are
under discussion (or will be at some point). The first is requirements for
controls that are probably included in ISO 27001 and FedRAMP today. It can be
assumed that all major cloud service providers have an ISO 27001 certification
and a FedRAMP authorization (which only applies directly to federal agencies
but can still be taken as a general assessment of the CSP’s security controls).
This includes controls that apply to both on-premises and cloud-based systems,
such as patch management, configuration management, vulnerability management,
etc. (the SDT is tentatively gathering new requirements in a draft standard
called CIP-016, but this doesn’t mean there won’t be any other new standards).
I recommended in the previous post that the SDT go through
the requirements of ISO 27001 and identify any that are worth including as new
CIP requirements. This might include requirements that match some or all of the
current CIP requirements, but they might go beyond those as well. Of course, like
all CIP requirements, these new requirements will apply to NERC entities, not directly
to the CSP(s). However, the CSPs will perform all of the activities required
for compliance.
To evaluate their CSP’s compliance with new CIP requirements
that are based on ISO 27001 requirements, the NERC entity will need to request
the CSP’s audit report for ISO 27001, as well as whatever compliance
documentation the CSP will provide for FedRAMP (the CSP should always be able
to provide these items, as far as I know). If they discover a negative finding
for any ISO 27001 or FedRAMP requirements that corresponds to a new CIP
requirement, the NERC entity should inquire how the CSP is addressing, or has
already addressed, that finding and track their progress in mitigating the
finding.
However, the NERC entity should not do their own investigation
of the CSP’s compliance status or even ask the CSP to fill out a questionnaire.
Instead, they should content themselves with reviewing what the auditing
organization (often called a Third Party Assessment Organization or 3PAO) included
in the audit report. If the entity asks to do their own assessment, the CSP will
almost certainly refuse to allow that – and rightfully so, in my opinion. The
3PAO probably brought in a small army of auditors and charged a lot of money
for the audit; the last thing the CSP wants is to have 100 NERC CIP customers
each demanding to do their own audit with slightly different interpretations of
the requirements.
The second type of cloud requirements described in the
previous post is requirements for controls that address risks that are mostly
or entirely found in the cloud. I provided three examples of these controls in
the post, but I want to focus now on the first of these: what I call the “multi-tenancy
problem”. I have written about this problem in two posts, the more
recent of which was a little more than a year ago.
This is a problem that only comes up when you have different
organizations using a single software product (and more specifically, the
database associated with that product); while that product might not necessarily
be deployed in the cloud, this is almost always how the problem is encountered
today. Of course, software deployed in the cloud is now commonly referred to as
SaaS or software-as-a-service. In the post I just linked, I explained the
problem this way (I received the author’s permission to make some minor changes
to the wording):
(The problem is due to) the fact that software that was originally
designed for on-premises use by a single organization is now available for use in
the cloud by organizations of all types; these can be located all over the
world. Because of the huge economies of scale that can be realized through moving
to the cloud, many software developers are moving their on-premises systems
there. In fact, in an increasing number of cases, the software is now, or soon
will be, only available in the cloud.
When software originally written for on-premises use is made
available in the cloud, a big question that often arises has to do with the
customer database. It's safe to say that most SaaS applications store some customer
data. When most software applications were used exclusively on premises, the
database was almost always built on the assumption that it would be used either
by a single organization or by a related group of organizations (e.g. the international
subsidiaries of one company). It was assumed there would almost never be a case
where a single database installed on the premises of one organization was used
by organizations all over the world and in many different industries.
However, this is exactly what can happen, and is happening
now, with many SaaS applications, since they’re often based on the on-premises
version of the software. Even though a SaaS application is probably doing a
good job of protecting each organization’s data from access by other
organizations, the fact that there might be many different types of
organizations, from potentially many different countries, utilizing the same
database is enough to give some organizations the willies.
This is especially true for critical infrastructure (CI) organizations
like electric utilities and independent power producers. When using shared
services like SaaS, those CI organizations are always concerned that, if another
organization using the same database doesn’t have good security, they can
become the vector for attacks on organizations that do.
In the post, I went on to ask (again, with paraphrasing), “Is
this really a problem? After all, databases and the applications that use them
have a huge array of security controls at their disposal. In fact, users of an
application usually have no direct access to the database, even though their
data are stored there.”
Of course, I’m sure there are plenty of people reading this
post that could argue quite convincingly that any multi-tenant database needs
to be considered insecure unless proven otherwise. On the other hand, there are
many other people (including me) who are willing to mostly concede their point
about security, while at the same time asserting that if we prohibit multi-tenant
SaaS databases, we will effectively prohibit most SaaS, period.
The fact is that most SaaS would be prohibitively expensive
if the provider had to deploy a separate instance of the software for every customer.
For example, if a standalone software product currently has 10,000 customers,
think of how expensive it would be to deploy and maintain 10,000 single SaaS instances
of that product. However, it’s not true that the only alternative to giving
every customer their own instance is to house all 10,000 customers’ data in a
single instance of the database. There are ways to group customers by country,
region, industry, security controls, etc. This would lower the number of customers
per instance, while at the same time decreasing the likelihood of one customer accessing
another customer’s data.
Of course, I don’t think it should be a heavy lift for the Cloud
CIP standards to require that organizations that must comply with one or more
NERC CIP standards not share a SaaS database with entities, whether public or
private, that are based in “bad actor” countries like North Korea, China, Iran,
Myanmar, etc. But should we go beyond that requirement? Here are two other
ideas:
2.
Require that organizations that must comply with
one or more NERC CIP standards not share a SaaS database with organizations,
public or private, that are not subject to mandatory cybersecurity
regulations (and not just data privacy regulations).
3.
Require that NERC entities in the US, Canada and
Mexico with high and/or medium impact CIP assets only share a SaaS database
with other NERC entities with high and/or medium impact CIP assets.[ii]
Who can solve this problem, and how will they solve it? This
needs to be addressed in the same way that similar cybersecurity problems without
clear solutions have been addressed by previous NERC CIP SDTs: through back-and-forth
discussion at the SDT meetings until a compromise is reached that (almost)
everyone can live with. The result might be adoption of one of the three
requirements just mentioned, but it might also be simply a decision not to address
multi-tenancy in the CIP requirements at all.
However, the SDT needs to have a conversation about
multi-tenancy, as well as other risks that apply only in cloud environments.
These are the questions that need to be answered before many NERC entities will
feel comfortable using the cloud for OT purposes.
My blog is more popular than
ever, but I need more than popularity to keep it going. I’ve often been told
that I should either accept advertising or put up a paywall and charge a
subscription fee, or both. However, I really don’t want to do either of these
things. It would be great if everyone who appreciates my posts could donate a $20-$25 (or more) “subscription fee” once a year. Will
you do that today?
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] I also
noted in that post that I think it’s a mistake for the SDT to start drafting
requirements without having at least tentative definitions for the systems that
the standards will apply to.
[ii] This
idea came from Kevin Perry, retired Chief CIP Auditor of the SPP Regional
Entity and co-leader of the drafting team that developed CIP versions 2 and 3. My
post
on multi-tenancy from 2024 included a quote from Kevin pointing out that many
electric utilities already utilize the OASIS SaaS application for Transmission
system reservations, where they share a single database with other OASIS users.
This might be considered a hybrid of the second and third options.
No comments:
Post a Comment