Technology Is Available … Is The Will There?
Bryan Owen of OSIsoft defined, and perhaps coined, ICS cloud services as being open loop or closed loop. Securing open loop cloud services is simple. Just push the data out to the cloud for predictive maintenance, efficiency studies and other purposes. All the benefits can be achieved without putting the integrity or availability of the ICS at any additional risk by pushing the data through a data diode / one-way device that is available from Waterfall, Owl and others.
In the video below, Bryan provides examples of closed loop ICS cloud services. In closed loop services the cloud provider is able to send packets/commands/data/bits into the ICS.
The benefits of the ICS cloud services can be substantial, and the available services and benefits are almost certain to increase rapidly. Sure there will likely be some sectors and use cases, such as nuclear, where this will not happen anytime soon. And a small amount where the consequence of compromise is so low that simply putting in a VPN and trusting the cloud service provider will be sufficient. Most of the sectors and use cases will fall between these two extremes.
The closed loop ICS cloud service offerings I’ve seen through working with both cloud service providers and asset owners purchasing the cloud service have been based on trust. Trust that the cloud service provider is actually implementing the VPN, patching, two-factor authentication, background checks, physical security, that is described in the security section of the offering. There are two major issues with this.
- The cloud service provider is a big, juicy target that is even more attractive to an adversary as they sign up more customers. Get into the cloud service provider, in any way hack, bribe, extortion, nation state demand, physical attack, and the adversary now may have access to 1800 power plants or 680 factories or …
- The asset owner has to trust the ICS cloud service provider is following those nicely written security controls. In my audit experience to date, many are not. Shockingly failing audits that were pre-scheduled and performed in conjunction with the cloud service provider. This risk should decrease over time if more asset owners start auditing the promised security controls.
Most closed loop ICS cloud services do not require an all or nothing access decision. We should be using the existing ICS deep packet inspection (DPI) technology to implement granular least privilege access from the cloud to the asset owner ICS. This isn’t happening in most cases for three reasons:
- Asset owners are not requesting it, let alone insisting on it.
- It adds complexity to the project / service. It is an extension of why we still see most ICS deployed in a manner not following the ICS vendor’s own secure deployment guides, even in cases where the ICS vendor deploys the system. Deployment teams are already dealing with a great deal of complexity, and if the customer is not demanding security, the ICS will most often be deployed in the insecure by default configuration. Some vendors are offering secure deployment as an add on cost, but this does cause market angst. As in, you will deploy it in an insecure mode if I don’t pay you for this option?
- The stealth reason — if a secure gateway or edge device with DPI limits access from the cloud to the ICS to minimal protocols, function codes, and tags/points/coils/registers, it will be more difficult to add on new services. If the asset owner trusts an any time, all access “secure” connection why put in the limitation that will make selling and deploying future services more difficult?
As noted in the title, the technology exists. For example, a cloud service could be restricted to write (change a setting) on one or more boilers on certain coils/registers within a certain value range. And to check that the packets follow the protocol to stop malformed packet/protocol attacks. This has been available from ICS firewall/gateway products such as Tofino and mGuard for over a decade and there are a number of new entrants. A very security conscious client deployed Tofino to limit closed loop ICS cloud services to a small set of IP addresses, Modbus, write function code, and a small number or registers that could be written to. The benefit was worth the effort and expense of deploying Tofino themselves for this asset owner after the cloud service provider stuck to the anytime / all access required stance.
The parsing of ICS protocols is also a key technology in the detection products from Claroty, Nozomi and ~15 other companies pursuing this market. Perhaps some that have lost in the detection market should pivot providing a closed loop ICS cloud services gateway / edge device offering, ideally partnering with the cloud service provider. Again the technology is proven and available. It is the will that is lacking.
Even a high required access case such as SCADA Operations / Operators in the cloud, can have restrictions that would prevent changing logic, loading software and firmware, and perhaps controlling the highest consequence parameters.
One other benefit of this approach is the small attack surface available to the cloud service provider can be tested. If it is small enough and has protocol conformance checks it may even be able to be exhaustively tested.
This least privilege control approach is unlikely to happen until the asset owners demand it and make purchasing decisions because of it. A few years back a client wanted to take advantage of a fantastic predictive maintenance service being offered by the vendor. It wasn’t cheap, but it was win / win for both the vendor and asset owner. The discussion on how to provide the data to the cloud took almost a year and went like this.
Vendor: we need to VPN with admin account privileges to our server on Level 2.
Asset Owner: why?
Vendor: we need to access historical data.
Asset Owner: we can send you the historical data via a one-way device.
Vendor: that won’t work.
Asset Owner: why?
Vendor: we need to access historical data.
And on and on it went until eventually the vendor gave in, saw that it all works, and now offers this as a “high” security deployment option. I haven’t given up hope that an ICS cloud service provider will offer this without customer insistence. Until then asset owners need to understand and decide what to do with the risk of allowing a third party anytime, unrestricted access for cloud services.