Cloud CIP, Part 6: The multi-tenancy problem

Drafting of the NERC CIP version 1 cybersecurity standards started in 2006. At that time, there was little thought about control systems being implemented anywhere besides the premises of the NERC entity, or else in an “application hosting” environment in which the entity owned and had full control of all devices that held their data. Cloud computing was certainly being talked about at the time (Amazon had launched the first commercial cloud service in 2006) but it was regarded as an experimental technology that was literally unthinkable for critical infrastructure applications.

In fact, I think it’s only been in the last 4-5 years that there has been serious talk about using the cloud for Bulk Electric System (BES) operations. And even now, there is very little use of the cloud for the OT side of the electric power industry – although, like in most industries, the IT side is making heavy use of it.

So, now that we’re talking seriously about putting power industry workloads in the cloud, cybersecurity issues that were never even thought about before – but were always present in the cloud - are suddenly becoming quite important.

One of those issues has to do with software as a service (SaaS) – specifically, the fact that software that was formerly available strictly for on-premises use by a single organization is now available for use by organizations of all types, located all over the world. Because of the huge economies of scale that can be realized through doing this, many software products that were formerly installed exclusively on-premises are now moving to the cloud; in many cases, the software is now, or will soon, only be available in the cloud.

When software originally written for on-premises use is made available in the cloud, the big problem that arises has to do with the customer database. It's safe to say tha most SaaS applications store customer data. When the application was on-premises, the database was almost always built on the assumption that it would be used either by a single organization (which might have multiple divisions that act like different companies) or by a homogenous group of organizations (e.g. the members of a single industry association); there would almost never be a case where a single database installed on the premises of one organization was used by organizations all over the world and in many different industries.

However, this is exactly what can happen – and is happening now – with many SaaS applications, since they’re often based on the on-premises version of the software. Even though a SaaS application is probably doing a good job of protecting each organization’s data from access by other organizations, the fact that there might be many different types of organizations, from many different countries, utilizing the same database is enough to give some people the willies. This is especially true for organizations, like electric utilities and independent power producers, whose data is critical and is well protected while on premises. When using shared services like SaaS, they're always concerned that, if other organizations don’t have good security, they can become the vector for attacks on organizations that do.

But here’s the question: Is this really a problem? After all, databases and the applications that use them have a huge array of security controls at their disposal. In fact, users of an application usually have no direct access to the database. I’m sure there are ways to get around these controls, but let’s stipulate for the moment that it would be very hard for a user of a SaaS application to access another user’s data.

Even with that stipulation, I still think a lot of power industry organizations won’t want their data to reside in the same database as organizations with varying security postures, located all over the world. If nothing else, there could be an outcry in the popular press, and then probably in Congress, about this, if it became public. That outcry alone, no matter how unjustified, could end up being very damaging – perhaps resulting in prohibitions on any cloud use for OT purposes by the power industry.

On the other hand, asking a SaaS provider to provide a single database instance for every power industry user will almost definitely result in the price going up or service being denied, or both. There needs to be some middle ground.

I have discussed this issue with my friend Kevin Perry, who was co-leader of the team that drafted CIP versions 2 and 3 and was for close to a decade the Chief CIP Auditor for SPP Regional Entity. He suggested that SaaS providers could give NERC registered entities their own database instance.

He points out:

The industry is already accustomed to this to a limited extent on the market systems side of the house.  Many utilities contract with a service provider for OASIS for Transmission system reservations, where their data is co-resident in one database.  Service providers similarly provide scheduling systems, which are required to schedule and move power over the reserved Transmission system capacity.  Even utilities who do not participate in a market still need to use OASIS and scheduling systems to sell surplus power to their neighbors.

Given that the power industry has a higher level of security than most other industries outside of probably defense or the intelligence agencies - due in no small part to having to comply with the NERC CIP standards - this one measure might help stave off the threat of an attack on the industry by members of Congress. That could be much more damaging than any cyberattack!

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.