Few people deny that cloud-based applications will bring extensive benefits to industry over the next few years. Intelligent, distributed production systems will play a key role in innovation in this sector. The flexibility, ease of access and great computational capacity of cloud-based systems will make integrated management possible, not just for factories but for the entire value chain, from the provider all the way up to the consumer.
However, in order for this promising paradigm to become a reality, control systems are going to have to overcome a number of challenges:
- Availability and latency: In order to use services distributed from the cloud, some industrial applications, such as reading measurements in real time using architectures like that in IEC_61499, or real-time process management systems, must minimize latency time. For this, there must be some kind of node near the control point. It must be noted that certain security measures, such as data encryption, have an adverse effect on latency.
- Data security and integrity in transit and at rest: cloud-based SCADA systems sometimes control critical infrastructures, and the integrity of the data collected by the control network is crucial. Similarly, data security must also be controlled. For this, a ’need to know’ policy is advisable from the outset, meaning staff are only able to access the information they need in order to implement the process.
- Trustworthiness and compliance with data protection regulations: When choosing a cloud provider, its reliability and trustworthiness must be evaluated. Many research projects exist to systemize demands that cloud providers give privacy and security assurances. This applies not only to contracts and Service Level Agreements (SLA) (e.g. some research projects financed by the European Commission, the CCM (Cloud Control Matrix) and the PLA (Privacy Level Agreement) of the Cloud Security Alliance), but also to protocol transparency for the security methods used (e.g. the CTP (Cloud Trust Protocol) in the Cloud Security Alliance).
Possible architectural options for deploying the cloud in a secure environment
Essentially, SCADA systems can use cloud services in two different ways:
The security characteristics of this architecture are as follows:
- The SCADA application runs in the local server(s) and connects directly to the centralized control network on the one side, and to the cloud on the other, to store and distribute (display) control data.
- The organization retains the power to control and actuate the SCADA system. Sent information is dealt with in the cloud, using SCADA SaaS applications to display the data, but without the power to control or actuate it.
- In this type of architecture, the cloud is often public. The industry must ask its cloud providers for transparency e.g. using the CTO protocol. For this, it is worth noting that the provider might offer the following information:
- Introduction: identification and beginning of the evidence request service session, transparently and between pairs.
- Request for evidence: configuration, vulnerabilities analysis (hypervisor, recipient OS, virtual switches and firewalls), status (geographical location and identification of the separate platform units), auditing, service management (indicator of changes to in-house service records) and statistics for service provision
- Statements from the provider: list of services offered by the cloud provider, relating to both functionality (e.g. flexibility, configurations, etc.) and security (security practices and privacy and security controls, auditor’s reports, certificates, etc.)
- Notification of providers: alerts on events concerning confidentiality, integrity and availability.
- Introduction to security policies: provision of policies for mechanisms concerning access, authentication and authorization (AAA), configuration, localization and alerts.
- Extensions: any element, including security, which the client wants the cloud provider to extend.
- User access to the application should be read-only. The application (SaaS) should not take any kind of action, so as to limit the risk as far as possible (commands or actions flowing in from the outside are impossible, similar 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 the second option is called SCADA as a Service, and is discussed in the article My SCADA in the cloud.
The security characteristics of this architecture are as follows:
- In this case, remote control from the cloud is allowed, and there must be end-to-end security. This security must be airtight, from when industrial protocols are used to support authentication and coding such as Secure DNP3 up to processing and securely storing in the cloud.
- It is important to note the latency caused by incorporating security mechanisms, since both critical and non-critical data frames are transmitted in communications.
- To allow for cloud control over the organization’s devices, the firewall ports that allow access to the internal network must be opened. This access must be well justified, monitored and restricted only to those users who require it, and only when strictly necessary.
- Data traffic and control commands make communications more attractive to attackers, and they can experience attacks from the “Man In The Middle", or even modifications to the packages along the way. This could mean that the values that an operator inputs to the cloud could be completely different by the time they reach the destination device, possibly putting the operation itself at risk. Information encryption is therefore needed, to prevent these types of attacks.
In both cases, the cloud service provision model could be public, private or hybrid. The second scenario is expected to occur on a massive scale in the near future.
Whether the SCADA application runs in the local server (option 1) or in the cloud (option 2), access to virtual resources must be controlled in order to safeguard security at the level of infrastructure. There are a number of possible ways to do this:
- Accessing via a VPN (Virtual Private Network) or protecting the internal network it by making it front-end and adding load balancers and a NAT (Network Address Translation) server.
- Configuring the rules and security groups so that access is only granted to the minimum number of ports necessary in the virtual servers.
- Protecting SSH access using key pairs and automatically modifying the SSH access port in the SSH machine configuration.
The cloud, having all data and controls in a single centralized location, is a very attractive option, particularly in the case of the second architecture discussed. However, latency for data that must be read in real time must be assessed, along with data security. Before contracting a cloud provider, the security methods discussed in this article must be considered: authentication, encryption, secure protocols, etc. Furthermore, the infrastructure must have the characteristics needed to use the cloud, such as Secure DNP3.
In light of the above, the infrastructure and services offered by the provider must be evaluated before moving to the cloud.
In short, if you’re looking to have more latency time and greater control over security, you should opt for an on-site architecture. If, on the other hand, there are few latency restrictions and you want to control industrial processes from a single location – as is the case, for example, for organizations spanning a very large area – then this is the option to go for.