The vulnerabilities of human-machine interface/supervisory control and data acquisition (HMI/SCADA) systems can pose a serious security threat, and the complexity of multi-layered technologies can make it difficult to secure manufacturing operations. While the inherent safe design of most HMI/SCADA systems offer some protection, they are by no means enough to fully protect systems. So, it is important for companies to better understand where vulnerabilities exist within their systems and to take a proactive approach to address those susceptible areas.
The HMI/SCADA market has been evolving, with functionality, scalability, and interoperability at the forefront. These technology advances are also more complex; industry standards have emerged to help fill the void of improving security. Part of the challenge, however, is knowing where to start in securing the entire system.
To minimize existing security gaps it is important to understand where potential vulnerabilities often lie within the system. The inherent security of system designs does minimizes some risks. Fundamental principles and canons of engineering mandate safe and reliable systems. This ensures a basic level of security to protect against an intruder. Engineers design systems with intentionally broken automated chains – meaning in some cases functions require physical confirmation prior to the software performing commands and in other cases, the SCADA software only does a portion of the command, requiring one or many additional manual steps to execute the function. Inherent system security is best surmised at the software and hardware levels.
Four steps for identifying HMI/SCADA vulnerabilities
A general design rule system engineers apply for all levels of a system can be boiled down to “if a single point of failure exists, protect it or provide secondary means,” so design philosophies drive a holistically safe and secure environment, which can severely impede an intruder’s ability at the HMI/SCADA level to impact the entire system. There are four steps a manufacturer can take to identify vulnerabilities:
- Examine your field assets – particularly older remote components: How does your SCADA solution communicate with them? Can this be secured? Is the control network adequately separated from other networks? Where are the points of entry/failure? Are there redundant options?
- Examine your IT assets: Are the services/software running on an asset the minimum needed to maintain functionality? How secure is the software and does the software employ passwords, biometrics or retina protection? Do you have easy access to the operating system and SCADA system patches? Is this automatic?
- Examine your change management software policy: What is the policy for implementing an operating system and SCADA patches – does it cover all assets? Are all assets protected (covered by firewalls and anti-virus software)? How easy is it to manage user accounts across all layers of software – is there an integrated system that includes the operating system and software products or does each product have separate user accounts and passwords?
- Examine your access control: Does your SCADA software allow anonymous client connections? Is there a robust login policy with regular renewal of passwords? Does each user have an appropriate limit to their actions?
There are three major elements that can factor into the strategy – communications, software and hardware.
Communications: There are two levels of communication that exist within the system—information technology (IT) and the field, which have notable security level differences.
IT components of an HMI/SCADA system are modular, not only to allow for easy troubleshooting but also to distribute the computing load and eliminate a single point of failure. It is not uncommon to have multiple thick, thin, web, and mobile runtime clients connected to the main HMI/SCADA server hub over an internal Ethernet-based network. In some cases, systems may use external leased lines, modems, wireless, cellular, or satellite technologies as well. The main HMI/SCADA server hub also consists of multiple networked servers to distribute the load, ensure uptime, and store the mass amount of data. With these components all networked in some way, they use standardized common protocols to transfer data – all of which are largely unencrypted, requiring weak or no authentication.
Field implementations frequently consist of a number of dispersed remote sites with a control or data gathering function, all connected to a central control and monitoring point. For legacy applications, data has to be passed between the control room and the remote terminal units (RTUs) or PLCs over a network and the protocols for passing this data have frequently been developed with an emphasis on reliability and ease of implementation rather than security. Using modern protocols such as OPC UA fixes the problem as it does a great job at managing security, including certificates.
Communications between devices need to employ several layers of defense with the primary aim to make access to the data difficult and detect if the data has been compromised.
Software: Software has become feature bloated as developers add new capabilities while maintaining all of the existing ones, increasing the complexity of software security. There are two separate but dependent software technologies in the system, the HMI/SCADA software and the platform operating system, which have distinct differences when it comes to security.
Most HMI/SCADA software installations have external network connections or direct internet-based connectivity to perform remote maintenance functions and/or connect to enterprise systems. While these connections help companies reduce labor costs and increase the efficiency of their field technicians, it is a key entry point for anyone attempting to access with a malicious intent. Operating systems that employ elements of consumer or ‘open’ source operating systems are increasingly popular since they help reduce costs. But, open technologies have made proprietary custom, closed, secure systems a direction of the past.
Hardware: At this level, design engineers will employ many techniques to ensure safe control, either physically or through the HMI/SCADA software. Thousands of individual devices such as RTUs and PLCs can exist in a system and are often implemented with an area-based manual or automatic control selection; field technicians use manual control to perform maintenance or to address a software failure – locking out the software control and establishing local control.
When engineers design this level of the system, many hardware-based failsafes are built into the design, such as fusing or hardwire interlock logic to examine the local situation, so when components are commanded by the HMI/SCADA software, there is a hardware level of checks to ensure it can be executed. This protects the system from unsafe or even incorrect software control. Furthermore, many critical applications use triple and quad redundant logic controllers to ensure continuous operations.
HMI/SCADA security is only one part of an effective cyber-security strategy. There are many layers of automated solution suites that share data, and wherever data is shared between devices, there is a possibility for unauthorized access and data manipulation. There are a broad range of security-based software technologies, including biometrics, electronic signature, data encryption and domain authentication that can be implemented to augment any security positions manufacturers have implemented in the plant.
The key is to be proactive and enhance security using available software capabilities. However, even the safest system design and industry standards cannot secure a system 100%, and therefore, companies should not rely on them to protect their systems. Instead, they should take a proactive approach to enhancing security, and a good starting point is knowing what technologies are available to help them best meet their needs.
This article originally appeared on Control Engineering Europe’s website.