This past Wednesday, the NERC “Risk Management for Third-Party Cloud Services” Standards Drafting Team (SDT) emailed a document to the “Plus List”, which seems to be a starting point for discussions of a new CIP-016 standard to address the problems with use of the cloud by NERC entities.
While I admit I have not been able
to attend any of the SDT meetings for months, and while I also appreciate that
the team[i] is anxious to create
something – something! – that moves them forward, I regret to say I don’t think
this document moves them forward at all. Here are the main reasons why I say
that.
The primary problem is that the
draft standard is written like a NIST framework. That is, it seems to assume
that the NERC auditors will audit its requirements in the same way that a
federal agency audits itself for compliance with NIST 800-53. For example, control
AC-1 in 800-53 reads:
The organization:
a. Develops, documents, and disseminates to [Assignment:
organization-defined personnel or roles]:
1. An access control policy that addresses purpose, scope,
roles, responsibilities, management commitment, coordination among
organizational entities, and compliance; and
2. Procedures to facilitate the implementation of the access
control policy and associated access controls; and
b. Reviews and updates the current: 1. Access control policy
[Assignment: organization-defined frequency]; and 2. Access control procedures
[Assignment: organization-defined frequency].
This requirement assumes that:
i.
It is generally clear
to both the auditor and auditee what an access control policy should contain. More
specifically, it is clear to both parties what “purpose, scope, roles, responsibilities,
management commitment, coordination among organizational entities, and
compliance” should be addressed by the policy.
ii.
Both auditor and auditee generally understand
what procedures are required to “facilitate the implementation of the access
control policy and associated access controls.”
iii.
Auditor and auditee generally
agree on what constitutes an adequate “review and update” of access control
policies and procedures. For example, the auditor isn’t expecting the auditee to
rewrite the policy from the ground up, and the auditee isn’t expecting to get
away with skimming through the policy and just giving it their stamp of
approval.
As far as most federal government agencies
are concerned, the above three assumptions may well be valid. However, I
strongly doubt they’re valid for NERC entities, who usually take the “Trust in
Allah, but tie your camel” approach to dealing with auditors. Specifically, I
know that one reason some of the NERC CIP requirements are very prescriptive is
that NERC entities are afraid of requirements that give the auditors leeway in
determining what a requirement means. Moreover, the auditors often share this
fear, since they don’t want to be blamed for misinterpreting CIP requirements. Therefore,
they usually want CIP requirements that constrain them enough that there can’t
be much dispute over how a requirement should be interpreted.
However, while keeping in mind
that this document is just a discussion draft and will never get beyond that
stage, it’s important to note how it will likely result in many auditing
controversies if it were to become a standard. Here are three examples:
1. There are many statements that are clearly open to big
differences in interpretation. For example, Section 2.2 Scope reads, “CIP-016
applies to any systems, applications, or data stored, processed, or transmitted
in cloud environments or hybrid cloud infrastructures. Systems that remain
fully on-premise are not subject to this standard.”
Don’t “systems that remain fully
on-premise(s)” often use “applications, or data stored, processed, or transmitted
in cloud environments or hybrid cloud infrastructures”? If that use isn’t
subject to the standard, then what is? Yet, by saying that on-prem systems aren’t
subject to complying with CIP-016, it sounds like they’re immune to threats
that come through use of the cloud.
Is it really true that only systems
that are themselves located in the cloud (which today includes 0 high or medium
impact systems) are affected by cloud-based threats? If so, that seems like a
great argument for permanently prohibiting BES Cyber Systems, EACMS and PACS
from being located in the cloud. Of course, that’s exactly the situation we
have today. Why bother with changing the standards at all, since today they
effectively prohibit use of the cloud by entities with high and medium impact systems?
2. The draft standard relies heavily on 20-25 new terms, each
of which would have to be debated and voted on - then approved by FERC - before
the standard could be enforced. I remember the heated debates over the
relatively small number of new terms introduced with CIP version 5, especially the
words “programmable” in “Cyber Asset” and “routable” in “External Routable
Connectivity”. The debates over these two words were probably more heated than
the debates over all the v5 requirements put together. Moreover, the debates
over those two words literally went on for years; they were never resolved with
a new definition.
The lesson of that experience is
that it doesn’t help to “clarify” a requirement by introducing new Glossary terms,
unless those terms are already widely understood. This is especially the case
when a new Glossary term itself introduces new terms. For example, the undefined
new term “Cloud Perimeter Control Plane” in the draft CIP-016 includes another undefined
new term, “virtual security perimeter”. Both terms will need to be debated and
balloted multiple times, should they be included in an actual draft of CIP-016.[ii]
3. One interesting requirement is R12, which is described as “CIP-013
equivalent”. It reads:
The Responsible Entity shall
perform risk assessments of cloud providers and ensure that supply chain risks,
including third-party vendors and subcontractors, are mitigated. This includes
ensuring that all cloud providers comply with relevant security standards
(e.g., SOC 2, FedRAMP).
My first reaction is that this is
going to require the CSP to have a huge amount of involvement with each Responsible
Entity customer. This includes:
i.
Sharing information on
their vendors and subcontractors, so the RE can “ensure” (a dangerous word to include
in a mandatory requirement!) that those risks have been “mitigated”. How will
the RE do this? Surely not by auditing each of the CSP’s thousands of vendors
and subcontractors!
ii.
Providing the RE with
enough information that they can “ensure” the CSP complies with relevant
security standards. Of course, the CSP should already have evidence of “compliance”
with SOC2 and FedRAMP – although neither of those is a standard subject to
compliance (a better example would be ISO
27001).
iii.
However, the words “all
cloud providers” will normally include more than the platform CSP (e.g., AWS or
Azure). They also include any entity that provides services in the cloud – for example,
SaaS providers, security service providers, etc. Is the Responsible Entity
really going to have to ensure that each of these cloud providers “complies”
with SOC 2 and FedRAMP, to say nothing of other “relevant security standards?”
Of course, this document is just
meant to be the start of a discussion, so it would be unfair to treat it as if
it were a draft of a proposed new standard. However, I think there is one overarching
lesson to be taken away from this (which I have pointed out multiple times before):
Any attempt to address the cloud in one or more NERC CIP standards is
inevitably going to require changes to how the standards are audited. These changes
will in turn require changes to the NERC Rules of Procedure and especially CMEP
(the Compliance Monitoring and Enforcement Program).
Because of this, any draft of a new
CIP standard(s) to address use of the cloud needs to include a discussion of
what changes to the Rules of Procedure (RoP) and CMEP are required for the new
requirements to be auditable. The primary RoP change that will be needed – and it
has been needed for years – is a description of how risk-based requirements can
be audited[iii]. There is no way that non-risk-based
CIP requirements will ever work in the cloud.
Moreover, the process of making the
RoP changes needs to get underway as soon as possible after the new standard(s)
is drafted. RoP changes rarely happen, but it’s likely these changes will take
at least a couple of years by themselves. Since I’m already saying that the CIP
changes alone won’t come into effect before 2031 and since it’s possible the
RoP changes will not start until the CIP changes have been approved by FERC, this
means it might be 2032 or even 2033 before the entire package of both CIP and
RoP changes is in place. Wouldn’t that be depressing?
It certainly would be depressing,
but I’ll point out that it’s not likely the NERC CIP community will need to
wait until 2033, 2032, or even 2031 for new “cloud CIP” standards to be in
place. It’s possible they’ll come sooner than that, mainly because NERC could
be forced to take a shortcut. There’s at least one “In case of fire, break
glass” provision in the RoP, which allows NERC – at the direction of the Board
of Trustees – to accelerate the standards development process, in the case
where the lack of a standard threatens to damage BES reliability itself.
Needless to say, this provision
has never been invoked (at least not regarding the CIP standards). However, the
time when it’s needed may be fast approaching. See this
post.
Don’t forget to donate! To
produce these blog posts, I rely on support from people like you. If you
appreciate my posts, please make that known by donating here. Any amount is welcome!
If you are involved with NERC CIP compliance and would like to discuss issues related to “cloud CIP”, please email me at tom@tomalrich.com.
[i]
The email made it clear that this is primarily the product of one team member,
so it has no official status.
[ii] Of
course, there’s no assurance now that the new “cloud CIP” standards will include
a CIP-016 that looks anything like this one.
[iii]
NERC’s term for this is “objectives-based”. They are basically equivalent.
No comments:
Post a Comment