olly - Fotolia
The advent of the Internet of Things has given supervisory control and data acquisition, or SCADA, a run for its money. To give a network administrator a wider control of data from sensors, several vendors are offering options to migrate SCADA systems to a more IoT posture, using cloud-based components and predictive analytics.
Here are 10 factors to consider when migrating forward from "old-school" SCADA systems to SCADA plus IoT deployments:
1. Device types. Organizations must consider which IoT devices they will need in-house and/or in the cloud. Some devices collect data from temperature, motion controls and other types of sensors; others send data to data servers or storage devices, while some act as access paths between devices. All devices require security to protect data no matter where they might be -- whether within an organization or at a remote plant. As part of the device evaluation process, check the background (reputation) of the companies that manufacture these devices.
2. Device limitations. Memory constraints in IoT-suitable devices are primary limitations to security and encryption. Some products run a full Linux or similar stacks or use dedicated secure element chips for security functions. In more constrained scenarios, lightweight versions of full algorithms have been used; laptops, workstations and servers that have a much larger memory size can run the full versions of these cryptographic algorithms.
3. IoT standards. Some IoT standards appear to compete while others complement one another. Consider the OMG's Industrial IoT standards and activities. The OMG has issued a request for procurement on developing the Threat and Risk Model standard. This standard when implemented is expected to work with Data Distribution Service, a message middleware protocol that can publish from and subscribe to data from different sources in real time. Not to be overlooked are IEEE IoT-related standards; in particular, the IEEE is currently developing "Architectural Framework for the Internet of Things" to identify common areas between IoT domains. In any case, it's worth considering potential compliance and interoperability issues.
4. Network segmentation. If an organization's SDN-based network is large, the architecture should be checked for opportunities to divide into smaller segments. The segmentation advantage is that a security problem can be confined to a network segment rather than the entire, unsegmented network. If a segment begins to slow down due to performance issues, a network administrator should be able to route the traffic to a healthy segment before the affected segment completely shuts down.
5. Application behavior. A vendor-agnostic application that behaves perfectly well in-house may not work properly when used with IoT devices in-house or in the cloud. After making changes to the IoT application, it must be tested for new vulnerabilities that didn't show up in the original application. If the application is too complex to change, consider building a new application from scratch.
6. Antimalware products. Enterprises must make sure the antimalware products they use or plan to use in-house and/or in the cloud do not contain vulnerabilities. If a vulnerability is exploited, the antimalware will not work properly. One way of preventing this from happening is to use data exfiltration prevention from a third-party service. For example, enSilo found a critical security vulnerability (flawed memory page allocation) in three antimalware products and then contacted the vendors to fix the problem. Note that this vulnerability type may lurk in non-security products, as well.
7. Browser choice. Some cloud providers build their own IoT applications; others use IoT applications from an open source or a commercial vendor. Organizations should get a list of the applications and test them to find out if they are browser-specific or agnostic. They should also ensure their favorite browser can check the validity of webpage links, cross-site scripting, SQL injection and other vulnerabilities.
8. Predictive analytics. A plant machine breakdown can disable sensor-based IoT devices. The failure of the device's application to collect data will slow down the network and perhaps ultimately halt it. Instead of waiting for the machine to break down completely (and the resulting unplanned downtime), an in-house administrator or a cloud provider should have a predictive analytics tool in place that can help via a browser in predicting when and where the machine might start to break down. When the analytics data shows the machine is predicted to fall below an acceptable performance level, a network administrator should quickly get an alert on shutting down the affected IoT device and disabling it from the rest of the network.
9. Hybrid cloud strategy. Consider a hybrid cloud strategy of integrating private and public cloud services. A private cloud is the best option of providing security to sensitive data while satisfying regulatory requirements on data storage; a public cloud is the preferred way of cutting down the costs of scaling operations of non-sensitive big data. One hybrid strategy is to sign up with a single cloud provider that provides both private and public cloud services. An alternative is to sign up separately with a private cloud service provider and a public cloud service provider. The third option is to set up a private cloud service in-house and then sign up with a public cloud service provider.
10. Exit strategy. Organizations must find out whether they can negotiate an exit strategy with a cloud provider. A provider's cloud service lock-in policy can make it very difficult for organizations to exit when they are not satisfied with the cloud service. The policy may not allow an organization to transfer to its storage device the data generated by vendor-agnostic applications without paying high penalty fees.
Special migration considerations. A list of 10 factors your organization should consider when planning for SCADA/IoT migration from SCADA systems to IoT systems is a good start. As new technologies emerge and new vulnerabilities are discovered over time, organizations can add cost-effective factors to the list. This list should be part of the planning stage of the risk assessment process.