In this recent post, I explained why I think low impact BES[i] Cyber Systems (specifically, those LIBCS that are found in low impact Control Centers) can be deployed in the cloud without any CIP compliance implications today. My reason for saying this is I don’t think low impact BCS are even defined in the cloud, because of wording in CIP-002-5.1a. In fact, I think there would not be a CIP compliance obligation if a NERC entity deployed their entire low impact Control Center in the cloud.
However, I got pushback from a former NERC CIP auditor on that
post. He thinks my readers who put LIBCS in the cloud, and especially a low
impact Control Center in the cloud, will be at compliance risk if they don’t comply
with the low impact CIP requirements. He based his statement on the NERC definition
of Control Center.
While I didn’t agree with my friend’s reasoning in this
matter, I realized I may be making a false analogy between medium/high impact
requirements and low impact requirements. I don’t see any way that medium or
high impact BCS (let alone Control Centers) can be implemented in the cloud
today without a) putting the NERC entity in violation of many CIP requirements,
or b) requiring the CSP to break the cloud model by enclosing all of the
systems that hold the entity’s BCS within a Physical Security Perimeter and an
Electronic Security Perimeter.
My mistake was making the same assumption about the CIP
requirements that apply to low impact BCS (LIBCS). It took a long exchange of
emails, but my friend – Kevin Perry, retired Chief CIP Auditor of the NERC SPP
Regional Entity – finally convinced me that it’s in fact possible for a NERC
entity to deploy a low impact Control Center (LICC) in the cloud, and also
comply with the same set of CIP requirements that an on premises LICC would
need to comply with; more specifically, it will be possible for the CSP to
provide the NERC entity the evidence they need to prove compliance with each low
impact requirement. Here’s why I now think this is possible:
1.
All the CIP requirements that apply to LIBCS are
found in CIP-003-8. Three of them are simple to understand; the CSP will have
no problem providing compliance evidence for them:
a.
Requirement R1 mandates that the entity develop
security policies.
b.
Requirement R3 requires designation of a CIP Senior
Manager.
c.
Requirement R4 prescribes development of a
policy for the CIP Senior Manager to delegate their authority in certain circumstances.
2.
However, one of the requirements isn’t as simple
to understand. It’s Requirement R2, which states that a Responsible Entity with
LIBCS needs to develop and document a plan “that include(s) the sections in
Attachment 1.”
3.
Attachment 1 appears on pages 23-25 of
CIP-003-8. It consists of five Sections. Despite the terminology that’s used, I
believe it’s better to think of each Section as a Requirement Part of CIP-003-8
Requirement R2.
4.
There are four Sections that prescribe policies
or practices that the Responsible entity needs to have in place: “Cyber
Security Awareness” (Section 1), “Physical Security Controls” (Section 2), “Cyber
Security Incident Response” (Section 4), and “Transient Cyber Asset[ii]
and Removable Media[iii]
Malicious Code Risk Mitigation” (Section 5).
5.
All four of the above are functionally
equivalent to policies and practices that the CSP is certain to have in place
now, perhaps in the wording of standards the CSP has been certified on, such as
ISO 27001[iv].
It will be up to the NERC entity to demonstrate that the CSP’s policies and
practices address each of the above requirements, based on evidence provided by
the CSP.[v]
CIP-003-8 Requirement 2 Attachment 1 Section 3 is different
from all the above requirements in that it’s a technical requirement. A few of
the technical requirements that apply to medium and high impact systems,
including CIP-007 R2, CIP-010 R1 and CIP-005 R1, are literally impossible for a
CSP to comply with, since they require tracking the actual devices (physical
and virtual) on which BES Cyber Systems reside – and then providing evidence
showing that the literal wording of the requirement was applied to every device
on which the BCS resided over the 3-year audit period. Since systems in the
cloud move from device to device and datacenter to datacenter all the time, this
is impossible.
However, CIP-003-8 Requirement 2 Attachment 1 Section 3 doesn’t
apply to individual devices. This is because requiring an inventory of low
impact BCS is strictly prohibited by wording in CIP-002 and CIP-003. Section 3
requires the Responsible Entity to inter alia implement electronic
access controls that “Permit only necessary inbound and outbound electronic
access… for any communications that are... between a low impact BES Cyber
System(s) and a Cyber Asset(s) outside the asset containing low impact BES
Cyber System(s)…”
Although I’m not an auditor, it seems to me that the CSP
will need to provide evidence like the following:
·
A list of all routable protocols used to communicate
between any low impact BCS in the Control Center (without identifying which BCS
use which protocols) and any system outside of the CSP’s cloud (without identifying
those systems, where they’re located or who they belong to).[vi]
·
Documentation showing how the Responsible Entity
manages the virtual firewalls to ensure that only necessary inbound and
outbound electronic access is permitted (the NERC entity will probably be
responsible for this evidence, assuming they are allowed to manage the firewalls).
This evidence seems to me to be very much in the realm of
possibility. Thus, it seems it’s possible to implement a low impact Control Center
in the cloud and be fully CIP compliant at the same time.
Are you a vendor of current or
future cloud-based services or software that would like to figure out an
appropriate strategy for selling to customers subject to NERC CIP compliance? Or
are you a NERC entity that is struggling to understand what your current
options are regarding cloud-based software and services? Please drop me an
email so we can set up a time to discuss this!
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]
BES stands for Bulk Electric System.
[ii] Transient
Cyber Assets are usually laptops of third parties that are used for less than
thirty days on the NERC entity’s network.
[iii]
These include thumb drives, removable optical drives, etc.
[iv]
If you’re wondering why I don’t also mention FedRAMP, I need to point out that the
CSP isn’t “certified” as “FedRAMP-compliant”. FedRAMP is a means of approving a
federal agency’s use of a third-party service, such as a cloud service. It isn’t
meant to provide an overall certification of the service’s security for the private
sector, as are ISO 27001 and other certifications.
[v] Since
the CSP won’t be able to provide evidence of compliance with the exact wording
of any of these requirements, it’s likely that some other NERC ERO document,
like a CMEP Practice Guide, may need to be in place to “legalize” all of this. The
Regions (including the auditors) need to draft and approve CMEP Practice Guides;
that might take 6-9 months. But that’s still a lot better than the approximately
six years that I estimate
will be required before changes to the CIP standards to “legalize” full cloud
use will be in effect (the Standards Drafting Team started that process in
August).
[vi] I
admit it’s stretching a point to say that “outside of the CSP’s cloud” is the equivalent
of “outside the asset containing low impact BES Cyber System(s)”. The latter is
really longhand for “low impact asset”. That means one of the six BES asset
types listed in CIP-002-5.1a R1, which wasn’t already classified as high or
medium impact in CIP-002-5.1a R1 Attachment 1. Of course, the cloud, or even a
cloud data center, isn’t one of those six asset types, although I think it
could well be considered to be such.
My guess is there will need to be a CMEP Practice Guide
to clarify this point. Again, waiting the 6-9 months required to draft the
Practice Guide is a lot better than waiting six years for a full rewrite of the
CIP standards (although, since I’ve already advocated for two Practice Guides
in this blog post - and others, including Guides regarding BCSI and the meaning
of “access monitoring” in the EACMS definition, will be required as well - there
probably needs to be some organized effort to draft and approve the Guides,
with multiple approvals in process at the same time).
No comments:
Post a Comment