Note from Tom: I prepared this document for my discussion with Lew Folkerth of the RF NERC Regional Entity on Monday October 23, at RF's monthly Tech Talk. The Tech Talk is open to anybody and does not require registration. The event runs from 2:00 to 3:30 Eastern Time. Go here to find the agenda and the link to the webinar. RF never records the Tech Talks, so there will be no recording available (the small set of slides I'll use will be posted, though).
My and Lew's discussion will start around 2:30 to 2:45, but the previous two speakers are both very good, so I recommend you join the webinar as soon after 2:00 as possible. Note that Lew and I are speaking third, even though I'm listed second in RF's announcement.
If you would like a PDF of this post, please email me at tom@tomalrich.com.
Executive summary
This document is based entirely on the opinions of Tom
Alrich, owner of Tom Alrich LLC.
This document describes a possible path by which changes
could be made to the NERC CIP standards that would allow high and medium impact
BES Cyber Systems (BCS) to be implemented in cloud environments. It is not
meant to be an actual blueprint for achieving that purpose, but is more of a
“proof of concept” that this is something that could be achieved.
While achieving this goal will require that a Standards
Authorization Request (SAR) be prepared and submitted to the NERC Standards
Committee, the author believes it is still too early to do that, since any SAR
will need to guide the drafting team regarding a feasible path to achieve this
goal. Since no FERC order mandates what needs to be done (as has been the case
with almost all other new CIP standards or changes to existing standards), the
author believes it is up to the NERC community to come to agreement regarding
generally how to proceed.
When rough agreement has been achieved, a SAR can then be
prepared and submitted to the Standards Committee. When the SAR has been
approved and a Standards Drafting Team (SDT) has been seated, that team can go
to work on filling in the details of what is required. But the SDT should not
be required to come up with the overall plan; that is not the purpose of an
SDT.
This document proposes that:
1.
There will be two “tracks” for NERC CIP
compliance: Track 1 for “On-premises BCS” and Track 2 for “Cloud BCS”. Track 1 will
be almost identical to the current CIP-004 to CIP-013 standards. All on-premises
BCS will follow this track, meaning there should be few if any changes required
to existing CIP compliance programs, for on-premises BCS.
2.
Systems implemented in the cloud will follow
CIP-003, CIP-013, and a new standard (CIP-015?) that will apply only to medium
or high impact BCS implemented in the cloud. This standard will function a lot
like CIP-013, in that it will require a NERC entity with medium and/or high
impact Cloud BCS to develop and implement a cloud security risk management
plan.
3.
CIP-003 may be unchanged and will apply to both
on-premises and cloud based low impact BCS.
4.
CIP-002 will be where the two tracks diverge.
Some fairly small changes will allow CIP-002 to define both Track 1 and Track
2.
The new standard will require:
- That
CSPs be assessed by NERC or a NERC-designated organization every year,
- That
the NERC entity compare the results of the assessment to the criteria in
the entity’s cloud risk management plan, and
- That the CSP be assessed on other criteria identified by the NERC Standards Drafting Team, specifically related to how well they have mitigated risks to CSPs that are not now addressed in certification regimes like Fed RAMP.
I. What do we mean by “implement BCS in the cloud”?
We envision the following as one possible scenario for
implementation of BES Cyber Systems in the cloud, although there can certainly
be others as well. Note that the discussion below does not address issues with use
of SaaS applications that are in fact BCS in the cloud (e.g., outsourced SCADA).
It also does not address the issue of utilizing an EACMS that is hosted in the
cloud (as may be the case with a managed security service). Those two cases
need to be addressed separately.
1.
The NERC entity contracts with a major cloud service
provider (CSP) to host some of their BCS.
2.
The CSP agrees in the contract to provide to the
NERC entity the “Infrastructure as a Service” (IaaS) level of service defined
by NIST (currently, we’re restricting “CSP” to refer to an IaaS provider, even
though PaaS and SaaS providers are technically CSPs as well).
3.
The NERC entity (or a third party engaged by the
entity) installs the operating system and software required to implement one or
more Cloud BCS on the CSP’s infrastructure.
4.
The NERC entity will be responsible for implementing
and/or configuring cloud security controls in cases where these are not provided
by their contract with the CSP. The entity will also be responsible for all
controls – virtual firewalls, etc. - required to protect their own environment in
the cloud.
5.
The entity will be responsible for any
connectivity required between Cloud BCS and other systems or databases in the
cloud, and between Cloud BCS and systems outside the cloud. Important
considerations include the latency, security, redundancy, and reliability of
the connections.
A critical assumption behind this document is that there
will be separate “compliance tracks” for on-premises BCS (meaning the set of
systems in scope for CIP compliance today) and cloud-based medium and high
impact BCS (which are not being implemented in the cloud at all now, to our
knowledge). It is not envisioned that a NERC entity will need to do anything
different with respect to CIP compliance for its on-premises systems than it needs
to do today. Only if the entity wishes to implement one or more medium or high
impact BCS in the cloud will it need to implement different CIP compliance
processes and even then, it will only need to implement them with respect to
the cloud based BCS.
This does not mean it would not be good in the future to entertain
ideas for improvements to the current CIP standards with respect to on-premises
systems. However, it does mean that now would be the wrong time to entertain
those ideas, since it would greatly delay opening a path to CIP compliance for
medium and high impact BCS deployed in the cloud.
II. Why do we have this problem?
No CIP requirement currently forbids deploying medium and
high impact BCS in the cloud. In fact, none of the CIP requirements even
mentions the cloud. Despite that fact, there have been no reports of a NERC
entity deploying medium and/or high impact BCS in the cloud. If a NERC entity
were to do this, they would have to demonstrate during an audit that they have
remained compliant with every CIP requirement that applies to medium and/or
high impact BCS. Here are just three of the items that the NERC entity would
have to prove[1]:
·
That the CSP performed a background check on any
CSP employee who might have just walked by a server that contained a part of a
BCS anywhere in the US. This presumably might include every employee of every
data center in which some portion of the NERC entity’s BCS resided at any time
during the audit period. The background check must be according to the NERC
entity’s methodology. If more than one NERC entity implements medium and/or high
impact BCS in one CSP’s cloud, the check will need to be performed according to
the methodology of each of those entities. In other words, if the CSP has 20
such NERC entity customers, every employee of each affected data center will
need to have 20 separate background checks (required by CIP-004 R3).
·
That the CSP declared a PSP around every one of
their data centers that contains any piece of a medium or high impact BCS
during the three-year audit period, and put up card readers (controlled by the utility)
to which all their employees must badge in. If the CSP has ten NERC entities
with high and/or medium impact Cloud BCS as customers, each one of those
utilities will need to have their own card readers on every cloud data center
that might house even part of one of their BCS at any time. Every employee of
the data center will need to badge in – with a separate badge – to each
of those card readers, whenever they enter the building (required by CIP-006
R1).
·
That the CSP granted to each NERC entity with
high and/or medium impact BCS the ability to control which of the CSP’s
employees can enter any data center that houses any part of their BCS. It is
possible that each such NERC entity will need to approve every CSP employee’s ability
to enter the data center where they work and renew that approval periodically
(required by CIP-006 R1).
Of course, there is no way that a CSP could ever provide the
evidence required for a NERC entity to prove compliance with any of these requirements,
or with most of the other NERC CIP requirements and requirement parts that
apply to medium and/or high impact BCS. This lack of evidence means a NERC
entity that implemented medium or high impact BCS in the cloud might well be
found in violation of a large number of CIP requirements and requirement parts,
with each day – and each data center - for which there is no evidence counting
as a separate violation. Even though the NERC entity might assert that the CSP “more
than complies” with the CIP standards, the auditor would point out that, with
the NERC CIP requirements, the only meaning of “compliance” is being able to
provide evidence that the required actions were taken in every required instance.
Anything less than that is non-compliance.[2]
At this point, it should be clear that a lot of work – by NERC, the six NERC Regional Entities, and NERC entities themselves – will be required to make it possible for NERC entities to implement medium and/or high impact BES Cyber Systems in cloud environments. Three separate workstreams are required (they could be engaged in simultaneously). These are described in the three sections below.
III. Workstream one: Changes to the definition of BES Cyber System and to CIP-002
As mentioned earlier, there will be two NERC CIP “compliance
tracks”: one for BES Cyber Systems implemented “on-premises” (as is the case
with all BES Cyber Systems today) and one for BCS implemented in the cloud. The
two tracks will be implemented using two definitions of BCS, as well as some
changes to CIP-002.
1.
Definition of On-premises BES Cyber System
The definition of On-premises BCS will read something like,
“A BES Cyber System is one or more BES Cyber Assets logically grouped by a
responsible entity to perform one or more reliability tasks for a NERC
functional entity and deployed on the premises of the
Responsible Entity.”
2.
Identifying and classifying On-premises BES
Cyber Systems
The required steps for identifying and classifying
on-premises BCS will not be changed from the current steps. Unless re-deployed
in a cloud environment, every current BCS will become an on-premises BCS, once
the changes to CIP-002 take effect. Briefly (and omitting some steps that are
not crucial to this narrative), to identify its medium and high impact BCS, a
NERC entity must currently perform the following steps:
1.
Identify BES assets (most commonly Control
Centers, transmission substations and generating resources, including renewable
generation) in its footprint that contain or utilize Cyber Assets, defined as
“programmable electronic devices”.
2.
Classify these assets[3]
into high, medium and low impact, based on the criteria in Attachment 1 of
CIP-002.
3.
Identify Cyber Assets that meet the definition
of BES Cyber Asset (BCA), that are either
a.
“Used by and located at” any asset described in Attachment
1, Section 1 (known unofficially as “high impact assets”); or
b.
“Associated
with” any asset described in Attachment 1, Section 2 (known unofficially as
“medium impact assets”).
4.
Incorporate each BCA into one or more BES Cyber
Systems (BCS). A high impact BCS contains one or more high impact BCAs. A
medium impact BCS contains no high impact BCAs and one or more medium impact
BCAs.
5.
All other BCS are low impact if they are “associated
with” any of the asset types listed in section 3 of Attachment 1. They also
must “meet the applicability qualifications in Section 4 - Applicability, part
4.2 – Facilities”, of CIP-002-5.1A. Note that CIP-002 R1.3 says, “a discrete
list of low impact BES Cyber Systems is not required”, meaning a NERC entity
with low impact BCS should not be required to produce a list of low impact BCS,
as they are required to do for medium and high impact BCS.[4]
Note that none of the above steps are explicitly required by
CIP-002, but they are all implicitly required by the wording of CIP-002-5.1a
R1.1 – R1.3 and by the definitions of Cyber Asset, BES Cyber Asset and BES
Cyber System.
3.
New Cloud BCS definition
For high and medium impact BCS to be deployed in the cloud,
it is essential that the terms Cyber Asset and BES Cyber Asset not be
used in any new CIP requirements; this is because systems in the cloud are not
deployed on particular Cyber Assets (i.e., servers). The CSP will never be able
to provide compliance evidence showing every Cyber Asset (or Virtual Cyber
Asset) on which any component of a cloud BCS was deployed. Rather, BES Cyber
System needs to be the fundamental NERC CIP compliance term for systems deployed
in the cloud, since that term carries no implicit reference to any device.
However, even though the concepts of Cyber Asset and BES
Cyber Asset (BCA) are not required to identify cloud-based BES Cyber Systems,
the contents of the BCA definition are required. This is because, in the
current CIP ontology, the BCA definition provides the link between the system
and the BES. Therefore, the contents of the BCA definition need to be moved
into the Cloud BCS definition, which then might read, “A System that if
rendered unavailable, degraded, or misused would, within 15 minutes of its
required operation, misoperation, or non-operation, adversely impact one or
more Facilities, systems, or equipment, which, if destroyed, degraded, or
otherwise rendered unavailable when needed, would affect the reliable operation
of the Bulk Electric System. Redundancy of affected Facilities, systems, and
equipment shall not be considered when determining adverse impact.”
4.
Identifying and classifying high and medium
impact Cloud BCS
Neither “Cyber Asset” nor “BES Cyber Asset” is used in
CIP-002 (or anywhere else in the NERC CIP requirements). Thus, the following
minimal changes should be sufficient to allow a NERC entity to identify and
classify “Cloud BCS” in CIP-002. If the NERC entity also has on-premises BCS, it
will continue to follow the five steps outlined above to identify and classify
those systems. Note that, since BCS are always associated with a BES asset
described in Appendix 1 of CIP-002, and since whether the BCS is deployed on
premises or in the cloud should make no difference for its classification, no
big changes are needed for CIP-002 R1 or Attachment 1.
Below are the changes needed to accommodate Cloud BCS.
5.
Addition to CIP-002 R1
The following requirement parts should be added to CIP-002
R1 (phrases in red are new compared with the wording of R1.1, R1.2, and R1.3):
1.4. Identify each of the high impact Cloud BES Cyber Systems according to Attachment 1,
Section 4, if any, at associated with each asset;
1.5. Identify each of the medium impact Cloud BES Cyber Systems according to Attachment 1,
Section 5, if any, at associated with each asset; and
1.6. Identify each asset that contains is associated
with a low impact Cloud BES Cyber System
according to Attachment 1, Section 6, if any.
6.
Changes to CIP-002 Attachment 1
Since sections 1-3 of Attachment 1 deal with classification
of high, medium, and low impact BCS respectively (i.e., on premises BCS), there
need to be three new sections that deal with classification of high, medium,
and low impact Cloud BCS. As already stated, the classification of the BCS has
nothing to do with where it is deployed, so none of the “bright line criteria”
in Attachment 1 need to change for Cloud BCS.
New Section 4:
The first line of Section 4 should read, “Each Cloud BES Cyber System used by and located at[5] any of the following”
(followed by the same list found in Section 1). These Cloud BCS are high
impact.
New Section 5:
This section should begin, “Each
Cloud BES Cyber System, not included in Section 1 above, associated with
any of the following” (followed by the same list found in Section 2). These
Cloud BCS are medium impact.
New Section 6:
The section should begin, “Cloud BES Cyber Systems not included in Sections 4 or 5 above that are associated with any of the following assets and that meet the applicability qualifications in Section 4 - Applicability, part 4.2 – Facilities, of this standard” (followed by the same list found in Section 3). These Cloud BCS are low impact.
IV. Workstream two: Changes to the other existing CIP standards
After BCS and Cloud BCS are identified and classified in
CIP-002, the “On-premises” CIP track will follow CIP-003 through CIP-013.
However, the “Cloud” track will follow CIP-003 and then skip CIP-004 through
CIP-012; it will also include CIP-013.
CIP-003 will be in both tracks, although it needs to be modified to acknowledge that there are now both On-premises and Cloud BCS; it is likely that no further changes will be needed. No substantial changes are required because CIP-003 is dedicated to low impact BCS, and it has always been “legal” to locate low impact BCS in the cloud.
V. Workstream three: New CIP standard(s)
The Cloud track will need to include a new CIP standard (or
standards), perhaps numbered CIP-015. The purpose of this standard will be to
mitigate risks attendant on implementing medium and high impact BCS in the
cloud. Of course, this standard will apply to NERC entities, not to the CSPs.
The new standard will be drafted through the normal SAR/SDT process.[6]
One way of envisioning the new standard is to analogize to
CIP-013. Like CIP-013, the Cloud BCS standard will be aimed at mitigating vendor
risks (in this case, CSP risks), both during procurement of cloud services and
during use of those services. The NERC entity’s practices with respect to CSP
services (e.g., protection of access to the CPS’s cloud, coming through the
NERC entity’s networks) will also be in scope. The new standard will operate by
requiring the NERC entity that wishes to implement medium and/or high impact
BCS in the cloud to develop a cybersecurity risk management plan (in this case,
a Cloud Cybersecurity risk management plan instead of a Supply Chain
Cybersecurity risk management plan, as in the case of CIP-013).
In CIP-013, the NERC Entity is required to do the following:
1.
Develop a Supply Chain Cybersecurity risk
management plan to identify, assess, and mitigate supply chain cybersecurity
risks for medium and high impact BCS.
2.
Implement that plan.
3.
Review the plan annually (every 15 months).
One important deficiency of CIP-013 was that it did not list
the areas of risk that must be addressed in the plan. As a result, many NERC
entities took the default path of just focusing on the six items (found in
R1.2.1 through R1.2.6) that are specified in the standard, even though these
were never intended to be the entirety of CIP-013 compliance.
The NERC entity’s Cloud Cybersecurity risk management plan will
need to address two broad categories of cloud cybersecurity risk: general IT
risks and risks specific to cloud service providers. It is our opinion that auditing the general
IT risks is a waste of time if the CSP has a FedRAMP or SOC II[7]
audit report that can be made available for inspection[8].
However, since many NERC entities may request the same audit report(s) from one
of the major CSPs for CIP compliance purposes, it would be better if NERC could
examine the audit report(s) and disseminate the results of their analysis to
NERC entities that request them. It is also possible to have some trusted third
party examine the CSPs’ audit reports, rather than NERC itself.
In reviewing the CSPs’ audit reports, NERC would not make
a decision whether or not any NERC entity should use a particular CSP. Rather,
NERC would summarize the audit report(s) in enough detail for entities to make
their own decision whether a CSP had sufficiently mitigated the general IT
risks included in the report. The decision regarding which CSP(s) to use (if
any), as well as the degree to which they should be used, will be entirely up
to the NERC entity.
In addition to general IT cybersecurity risks (which apply
to many types of organizations), there are cybersecurity risks that apply almost
exclusively to CSPs; these are most likely not addressed in certifications like
FedRAMP. A few of these are described below. These and other cloud-specific
risks could be listed in the new standard as risks that the NERC entity needs
to consider in developing their cloud cybersecurity risk management plan (if
the NERC entity decides that one of these risks does not apply in their
situation, they can indicate in their plan that this risk does not apply to
them. However, they will not be free to ignore any of these risks altogether).
a.
Failure adequately to protect BES Cyber
System Information (BCSI). Because CIP-004-7 R6 and CIP-011-3 R1, which
both take effect on January 1, 2024, were developed specifically to address
this risk, the SDT may decide that these two requirements constitute adequate
mitigation for BCSI risk. However, the SDT may also decide that additional
controls are required, either on the NERC entity’s part or the CSP’s part.
b. Personnel risks. While it is likely that FedRAMP certification addresses most personnel-related general IT risks, it is also likely there are personnel risks specific to cloud providers that are not addressed in FedRAMP at all. For example, Paige Thompson, who breached Capital One after she was fired by her CSP employer, bragged online that she had been able to penetrate 30 other customers of the same CSP, who had made the same mistake in configuring their cloud controls that Capital One made.
Since it is likely that her access was removed from all accounts within a short time after she was fired, this indicates that access removal alone does not guarantee adequate protection for the CSP’s customers, after a knowledgeable employee has been terminated for cause. Additional steps may be needed, and they may not be adequately addressed by FedRAMP.
c.
Risks from third parties that sell access to
applications running in the CSP’s cloud environment. Third-party cloud
“access brokers” do not always have adequate security themselves. This could
potentially lead to cloud breaches that can compromise users of those third
party services. This may have been the vehicle by which the SolarWinds
attackers were able to penetrate that network and plant their malware in the
software development pipeline.
d.
Risks from misconfiguration of an organization’s
cloud environment. The major cloud service providers usually operate under
a “shared responsibility” model, in which the customer is responsible for most
of the security controls in their cloud environment (the CSPs may also charge
extra to assist customers who don’t wish to take responsibility for their
security in the cloud). Thus, a NERC entity may misconfigure their cloud
security controls and be breached as a result.
Some NERC entities may argue that they can only mitigate
risks that are “under their control” (as some have argued regarding CIP-013) –
meaning that, if a vendor won’t take the steps necessary to secure themselves,
the NERC entity can’t do anything about that.
However, important risks must be mitigated. If the cloud
provider needs to mitigate a serious risk but refuses to do so, the NERC entity
should utilize other means to mitigate the risk, including:
1.
Alternative mitigations if available;
2.
Escalating help desk tickets;
3.
Discussion of the issue in online forums; and
4. Legal action up to and including termination of the contract.
[1] Since there are currently no examples of NERC entities that have implemented medium and/or high impact BCS in the cloud, each of these three statements is speculative. However, it is possible that the current NERC CIP requirements, and the Measures listed for those requirements, would be interpreted to require these actions, as well as similar actions for most of the other CIP requirements and requirement parts, if a NERC entity were to try to implement medium or high impact BCS in the cloud.
[2] Of course, the fact that the NERC entity is found to have a huge number of violations does not necessarily mean they would face a big fine for each violation, although their total fine would almost certainly be huge. The bigger danger for the NERC entity is that they would be required by their state’s Public Utility Commission to stop providing electric power to customers in their service area, due to their massive violations of NERC standards.
[3] Technically, the assets themselves are not classified low, medium, or high impact, but the BCS associated with them are. However, since most of the NERC community finds it much easier to assign the classification to the asset, we have adopted that convention here.
[4] However, there are reports that at least one or two NERC Regional Entities do in fact require a list of low impact BCS from the entities in their Region. Of course, for low impact BCS deployed in the cloud, it would make no sense if the NERC entity did not have a list of them.
[5] Obviously, “located at” won’t work for BCS located in the cloud. On the other hand, removing those two words ignores the fact that the CSO706 SDT inserted them here for a reason: to prevent Cyber Assets in substations (and perhaps generating stations) that are “used by” the high impact control center from becoming high impact themselves. The new “Cloud SDT” should probably discuss this with members of the CSO706 SDT to identify a workable solution to this problem.
[6] The changes to CIP-002 and to the BCS definition will also go through the SAR/SDT process, but these don’t have to be addressed in the same SAR and with the same SDT as the new CIP standard. The changes to CIP-002 and the BCS definition are almost entirely a question of NERC process, while the new CIP standard will be entirely a question of cloud security. The required skill sets for SDT members will be different in the two cases.
Of course, as with all NERC meetings including SDT meetings, the meetings of both drafting teams will be open to any member of the public. This can include cloud security experts, security tool vendors and CSPs, as well as staff members of NERC entities.
[7] SOC II does not provide a set of required controls, but instead assesses whether the organization (in this case the CSP) has properly implemented whatever controls it has decided to follow. Therefore, proper assessment of SOC II audit results will require the CSP to provide documentation of the controls assessed.
[8]
Other certifications like ISO 27001 might also be acceptable. This will have to
be determined by the team that drafts the new CIP standard.
No comments:
Post a Comment