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:
- 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:
- Requirement R1 mandates that the entity develop security policies.
- Requirement R3 requires designation of a CIP Senior Manager.
- Requirement R4 prescribes development of a policy for the CIP Senior Manager to delegate their authority in certain circumstances.
- 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.”
- 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.
- 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).
- 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).
