SaaS doesn’t have to “comply” with NEC CIP. Unless the first S stands for “Security”.

I have known for a while that there’s no single “CIP/cloud problem”. Instead, there are different problems based on different cloud use cases; each of these problems has its own solutions, both short- and long-term. For example, I have usually treated SaaS (software as a service) as a monolithic entity. A SaaS implementation could never meet the definition of BES Cyber Asset, since if it is “…rendered unavailable, degraded, or misused…”, there is no way that a SaaS product in itself will adversely impact the power grid.

Therefore, I have said that the CIP use case for SaaS only impacts the requirements that have to do with BES Cyber System Information (BCSI). If the SaaS provider can give their NERC entity customer the information they need to comply with the “BCSI requirements” (CIP-004-7 R6, CIP-011-3 R1 and CIP-011-3 R2 and their respective Requirement Parts, about seven in all), the customer will be able to fulfill their NERC CIP compliance obligations regarding their use of the SaaS product.

This is true, but with one big exception: when the SaaS implementation is a managed security service, either for physical or electronic security. A few examples of this are:

1.      A cloud-based service that monitors Electronic Security Perimeter(s) for intrusions and other unauthorized access attempts. This service meets the definition of Electronic Access Control or Monitoring System (EACMS): “Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems.”

2.      A cloud-based physical access control system which meets the definition of Physical Access Control System (PACS): “Cyber Assets that control, alert, or log access to the Physical Security Perimeter(s)…”

3.      A multi-factor authentication service based in the cloud, which controls access to on-premises BES Cyber Systems. This is also an EACMS.

Can a NERC entity that uses one of these services today still be compliant with all applicable CIP requirements? Probably, but the security service provider will need to provide the NERC entity with evidence of compliance with not just seven Requirements and Requirement Parts (as in the case of non-security SaaS providers), but over 120 Requirements and Requirement Parts, in the case of EACMS in the cloud. PACS in the cloud will not require that much evidence, but there are special problems with PACS in the cloud (having to do with the Physical Security Perimeter, of course) that may not be easily solved.

You might wonder why a NERC entity that was evaluating services like this would even choose a cloud-based service; in fact, they probably wouldn’t do that. However, the big problem today is the number of on-premises security services (especially SIEM) that are announcing a move to being entirely cloud-based or are at least deprecating the on-premises service. That is, they will still offer an on-premises service, but all new features and upgrades will be aimed at the cloud service.

Of course, the big question is whether a SaaS provider will be willing to provide the compliance evidence for 120 Requirements and Requirement Parts, especially when they look at the current Version 8.1 of the NERC CIP Evidence Request Tool and learn what they will have to provide. Providing this evidence isn’t a promise that the SaaS provider should make lightly, but it’s also not impossible.

I’ve been making the point that the “full solution” to all aspects of the CIP/cloud problem is unlikely to be in effect much before 2031. I’m sure some NERC entities will be content to wait that long, but I’m also sure that many NERC entities (such as the 600 attendees at NERC’s recent Cloud Services Technical Conference on November 1) are chomping at the bit now to start using the cloud for their OT systems – if they can maintain CIP compliance when they do that.

The good news is that, at least for SaaS services that use BCSI and for cloud-based security services that meet the definition of EACMS, it’s possible for a NERC entity (whether they have low, medium or high impact BES Cyber Systems) to utilize them in the cloud today - if the provider of the service is willing to make the extra effort needed to gather compliance evidence.

Moreover, it is now clear (at least to me) that, at least for SaaS and cloud-based managed security services, there is no need for the service provider to lock the systems that provide the service in a single room with a defined PSP and ESP, as some people (including me) were saying less than a year ago. That is certainly a way to ensure compliance, but it also breaks the cloud model. At that point, the service effectively becomes an offsite data center.

While that model may still be required if a NERC entity wants to literally outsource their BES Cyber Systems to the cloud, it shouldn’t be necessary for SaaS or cloud-based MSSPs - if the SaaS provider is willing to work with their customers to provide the compliance evidence they need.

If you work for a SaaS or Managed Security Service Provider and would like to discuss this post, please drop me an email.

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.