It’s well known in the NERC CIP community
that as of today, January 1, BES Cyber System Information (BCSI) will finally
be “legal” in the cloud. However, it isn’t as well-known (but it will be soon,
I’m sure) that a huge glitch has appeared that may well take away – at least
for now - the majority of the benefits the NERC community was expecting to
derive from this development. And it will surprise nobody who has been working
in the NERC CIP area for a long time that this isn’t due to some big,
fundamental problem like the cloud suddenly being found to be insecure. As usual,
the problem has little to do with security and everything to do with the
wording of one of the requirements, which as usual has produced consequences completely
unintended by the members of the drafting team that wrote the requirement.
I’ve only seen one mention of this
problem in writing – that’s in this
post I wrote in early December (the author told me he stands by what he said in
that post). Since I managed to bury the discussion of this problem far down in
the post, I’ll elaborate on it now: The problem with BCSI not being allowed in
the cloud before today was never due to a question of where NERC entities can
store BCSI. If that were the only problem, few NERC entities would have cared that
BCSI wasn’t allowed in the cloud. After all, there are lots of secure – and very
inexpensive - ways to store BCSI on premises.
The real problem has always been that
the effective “ban” on BCSI (which was itself caused by three words in previous
versions of CIP-004: “physical storage locations”) turned out also to be an
effective “ban” on software-as-a-service (SaaS) in the cloud – and that problem
is getting worse all the time. There are lots of cloud applications that NERC
entities with medium or high impact BES Cyber Systems would like to utilize,
that are more functional and/or less expensive in their cloud incarnations. These
cloud applications have been considered off limits until today.
Even worse, many applications are
now not available at all (or won’t be soon) anywhere but the cloud. More and
more notices are going out from software suppliers that they will:
1.
Freeze development of
their on-premises version at the current version and support all future
functionality upgrades only in the cloud; or
2.
Offer certain features
only in the cloud from now on; or (worst of all)
3.
Phase out their
on-premises version altogether over the next year, and only offer the software
in the cloud after that.
The reason why use of SaaS was verboten
in medium and high impact NERC CIP environments wasn’t that SaaS apps somehow met
the definition of BES Cyber System or Electronic Access Control or Monitoring
System; they can't do so, because otherwise they would need to be installed within
a Physical Security Perimeter and an Electronic Security Perimeter. Of course, that would currently be impossible for cloud-based systems.
Making BCS and EACMS “legal” will
require a fundamental rewrite of many or most of the current CIP requirements
(fortunately, that process finally took a baby
step forward in December, but it will probably be at least three years
before those rewritten requirements come into effect). But all along, it has
been thought/hoped that the BCSI and SaaS problems would be completely solved by
the fairly simple revisions found in CIP-010-3 R1 and R2, as well as the inclusion
of R6 in CIP-004-7.
The only reason why use of SaaS in
medium and high impact CIP environments hasn’t been allowed in the cloud until
today has simply been the fact that if the SaaS app needed to use BCSI, it couldn’t
have access to it until today. In other words, the real reason why FERC’s 2022
approval of CIP-004-7 and CIP-011-3 was significant wasn’t that BCSI itself
would be “allowed” in the cloud, but that apps that needed to use BCSI would
finally be able to operate in the cloud.
However, I heard in late November
that some CIP auditors were becoming concerned with the wording of the new CIP-004-7
R6, and specifically the wording of these two sentences in the first paragraph
of R6:
To be considered access to BCSI in
the context of this requirement, an individual has both the ability to obtain
and use BCSI. Provisioned access is to be considered the result of the specific
actions taken to provide an individual(s) the means to access BCSI (e.g., may
include physical keys or access cards, user accounts and associated rights and
privileges, encryption keys).
The three Parts of R6 - R6.1, R6.2
and R6.3 – describe actions that a NERC entity now needs to take with respect
to any individual that has “provisioned access” to BCSI. “Provisioned access” means
the individual can obtain and use BCSI; with encrypted data, that
usually means the individual would have to have access to the encryption keys (without
the keys, the individual could obtain the BCSI but not use it). Such
individuals need to:
1.
Per R6.1, be specifically
authorized by the NERC entity to have provisioned access to the entity’s
BCSI; and
2.
Per R6.2, be subject
to verification every 15 months that they have an authorization record, and they
still need provisioned access to BCSI to do their job; and
3.
Per R6.3, have their “ability
to use provisioned access to BCSI” removed by the end of the next calendar day
after a “termination action” (which could be just the individual’s resignation
or being transferred internally. It doesn’t have to mean the person was fired).
It was always understood that, starting
today, if a CSP employee that manages a SaaS app were to need provisioned access
to BCSI, they would be subject to these three requirement parts. In turn, this
would mean the CSP would have to furnish evidence to the NERC entity that these
actions were taken in every instance. It was acknowledged that at least some
CSPs would refuse to even consider doing this. But since it seemed unlikely
that CSP employees would ever need provisioned access to BCSI used by a SaaS
app, NERC entities and SaaS providers were not worried about R6.
However (cue the ominous music),
it seems somebody within the NERC ERO realized that a SaaS app won’t be able to
operate on BCSI if it is encrypted, since the app itself can’t decrypt the data.
Thus, some person who works for the CSP will need access to the encryption keys
for the BCSI for the short time that it takes to decrypt the BCSI and feed it
into the app. During this short time, that individual could conceivably copy
the BCSI to a thumb drive or some other nefarious device. Therefore, that person
will be subject to CIP-004-7 R6.1, R6.2 and 6.3; the CSP will need to provide
the NERC entity evidence that all three of these Requirement Parts were
complied with in all instances.
R6.2 and R6.3 probably don’t pose
a big problem for most CSPs, since the CSP likely already has pre-formatted reports
showing their policy regarding key access, as well as evidence showing that it
has been followed in all instances where BCSI was involved. However, R6.1 is a
different story, because it requires the utility to authorize certain
individuals by name (not just role), in order for them to be granted
provisioned access to BCSI. At least some CSPs may have a problem with this.
If you haven’t been steeped in
NERC CIP for a long time and/or if you have experience complying with any other
cybersecurity regulations, you might wonder why this is a problem at all. For one
thing, it’s very unlikely that a CSP employee would have any interest in obtaining
BCSI; it can’t be sold in some online marketplace and it’s also not at all
likely that a CSP employee would be able to utilize the BCSI for any attack on
critical infrastructure, no matter how much malice they harbored in their evil
heart.
And even if you stipulate that
this is really a threat, why should this pose a compliance problem? Couldn’t
the NERC entity just give the CSP permission to allow a certain small set of
employees (but not specifically named individuals, as specified in the strict
language of the requirement) access to the encryption keys for BCSI, only for
the few and short occasions when one of them needs to decrypt BCSI to feed it
into the SaaS app?
Most importantly, are these two
considerations by themselves so serious that NERC entities with high and/or
medium impact BES Cyber Systems must continue to be prevented from utilizing
SaaS apps that require access to BCSI? The answer to this question seems clear:
No. Yet, I’ve heard this is exactly what SaaS providers and NERC entities have
been told. Of course, if the CSP would be willing to promise to provide the documentation
necessary for the entity to comply with R6.1, R6.2 and R6.3, there would be a
workaround for this problem. But I’ve heard that so far, there are no CSPs who
have agreed to do this; at the moment, this is a “showstopper” problem.
I want to point out that, since it will be many months
before audits start for CIP-004-7 and CIP-010-3, it is possible that some workaround
will be found to this problem, which the NERC auditors are likely to agree to –
although my guess is at least some NERC entities with high or medium BCS won’t
even try to use SaaS until they’re comfortable that such a workaround is
available. That will probably require someone at NERC being willing to bend the
rules in some way – although that will never be acknowledged to be the case, of
course.
“Surely,” you might wonder, “…a
way can be found to fix this problem temporarily, at least until a Standards
Drafting Team can fix it for good.” I’ve wondered the same thing. Now, we have
to all wonder out loud. The message needs to be heard.
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 join or contribute to our group, please go here, or email me with any questions.
No comments:
Post a Comment