Few people doubt the benefits that cloud-based applications can bring to the industry in the coming years. Intelligent and distributed production systems will be a key piece of innovation in this sector. The flexibility, ubiquity of access and the large computing capacity of cloud-based systems will enable integrated management, not only of factories with each other but of the entire value chain from suppliers to the consumer.
However, for this promising paradigm to become a reality, there are several challenges that control systems have to face:
Availability and latency: Some of the industrial applications, such as reading measurements in real time through architectures such as defined in IEC_61499 or real-time process management systems, to use distributed cloud services must minimize the time of latency and therefore there must be some node in the vicinity of the control point. Keep in mind that certain security measures such as data encryption harm latency.
Integrity and security of data in transit and at rest: in SCADA systems in the cloud, which sometimes control critical infrastructure, the integrity of the data collected by the control network is crucial. Likewise, the security of the data must also be under control, for which it is advisable to implement from the beginning a “need-to-know” policy limiting the access to information to the personnel necessary for the realization of process.
Confidence and compliance with data protection regulations: When choosing the cloud provider we must evaluate the reliability and trust it gives us. There are numerous research projects in the line of systematizing the request for security and privacy guarantees to cloud providers, not only in contracts or SLA (Service Level Agreements) (eg some research projects funded by Europe, the CCM (Cloud Control Matrix) and the PLA (Privacy Level Agreement) of the Cloud Security Alliance), but also in the transparency protocols of the security methods they employ (eg the Cloud Trust Protocol CTP) Security Alliance).
Architectural options to apply to cloud deployment in a secure environment
Basically, SCADA systems can take advantage of cloud services in two different ways:
The security peculiarities for this architecture are the following:
- The SCADA application runs on a local server / s and connects directly with the centralized control network on the one hand and with the cloud on the other, for storage and distribution (visualization) of the control data.
- The control and performance of the SCADA system is within the organization. The information that is sent outside is treated through the cloud through SCADA SaaS applications for data visualization, but not control or action.
- In this type of architecture the cloud is usually public. The industry must request transparency from the cloud providers, for example through the CTP protocol, for this it must be considered that the provider can offer the following information:
- Initiation: identification and login of the evidence request service, transparently and between peers.
- Request for evidence: configuration, vulnerability analysis (hypervisor, recipient’s OS, virtual switches and virtual firewalls), status (geographical location and identification of units separated from the platform), audit, service management (indicator of changes in records of the services themselves) and provision of service statistics
- Provider assertions: list of capabilities offered by the cloud provider, both functionality (for example flexibility, configurations, etc.) and security (security and privacy practices and controls, audit reports, certificates, etc.)
- Supplier notification: alerts about confidentiality, integrity and availability events.
- Introduction to security policies: provision of policies for identification, authentication and authorization (AAA), configuration, location and alerts mechanisms.
- Extensions: any element, even security, that the client wants to extend to the cloud provider.
- User access to the application should only be read. The application (SaaS) should not perform any type of action to restrict the risk to the maximum (there is no command or action from outside to inside, analogous to the idea of a data diode).
The SCADA application runs in the cloud and connects remotely to the distributed control network. An example of this second option is the so-called SCADA as a Service, mentioned in the article My SCADA in the clouds.
The security peculiarities for this architecture are the following:
- In this case, remote control from the cloud is allowed. Security must be complete throughout the tour (end-to-end security). Security does not have to be cracked, from the use of industrial protocols that support authentication and encryption such as Secure DNP3, to secure processing and storage in the cloud.
- The latency generated by the incorporation of security mechanisms must be considered, since both critical and non-critical data frames are transmitted in communications.
- In order for a control from the cloud to the organization’s devices to exist, it is necessary to open the firewall ports that give access to the internal network. The opening must be justified, monitored and restricted to those authorized users and strictly necessary cases.
The fact that there is data traffic and control commands makes them more attractive communications to be attacked and may suffer “man in the middle” attacks (Man In The Middle), or even packet modifications along the way. This can cause the values that an operator enters in the cloud when they arrive at the device have a totally different value and could jeopardize the operation. In order to prevent such attacks, the encryption of the information is necessary.
In both cases, the cloud services provision model can be public, private or hybrid. And it is the second scenario that is expected to be massively adopted in the near future.
Whether the SCADA application is running locally (option 1) or in the cloud (option 2), when it comes to protecting security at the infrastructure layer, access to virtual resources must be controlled. There are several options to do this:
- Access through VPN (Virtual Private Network) or protect the internal network with an instance that acts as a front and add load balancers and a NAT (Network Address Translation) server.
- Configure the rules and security groups so that only explicit access is granted to the minimum ports required on virtual servers.
- Protect SSH access by using key pairs and modify the default SSH access port in the machine’s SSH configuration.
The fact of having all the data and the control in a single centralized point makes the use of the cloud very attractive, especially the second architecture shown. However, the latency of the data that needs to be read in real time and its security must be assessed. Before contracting with a cloud provider, it must be verified that it contemplates the security measures outlined in the article: authentication, encryption, secure protocols, etc. In addition, the infrastructure must have the appropriate characteristics so that it can use the cloud as in the case of Secure DNP3.
For all the comments, it is necessary to make an assessment of the infrastructure and services offered by the provider before migrating to the cloud.