Understanding and minimising your HMI/SCADA system security gaps
Being at the heart of an operation’s data visualisation, control and reporting for operational improvements, HMI/SCADA systems have received a great deal of attention, especially due to various cyber threats and other vulnerabilities. The focus on HMI/SCADA security has grown exponentially in the last decade and, as a result, users of HMI/SCADA systems across the globe are increasingly taking steps to protect this key element of their operations.
The HMI/SCADA market has been evolving over the last 20 years with functionality, scalability and interoperability at the forefront. For example, HMI/SCADA software has evolved from being a programming package that enables quick development of an application to visualise data within a programmable logic controller (PLC) to being a development suite of products that delivers powerful 3D visualisations, intelligent control capabilities, data recording functions and networkability. With HMI/SCADA systems advancing technologically and implementations becoming increasingly complex, some industry standards have emerged with the goal of improving security. However, part of the challenge is in knowing where to start in securing the entire system.
SCADA security in context
The International Society of Automation (ISA) production model demonstrates the layered structure of a typical operation and shows that HMI/SCADA security is only one part of an effective cybersecurity strategy. These layers of automated solution suites share data, and wherever data is shared between devices, there is a possibility for unauthorised access and manipulation of that data. This article concentrates on the HMI/SCADA layer, but unless other potential weaknesses at other levels are covered, the operation as a whole remains vulnerable.
Component vulnerabilities within an HMI/SCADA system
To minimise existing security gaps, companies need to first understand where potential vulnerabilities typically lie within the system. Powerful software features, along with the advancements in automation hardware and industrial communications, have made control systems multilayered, complex and susceptible to threats. An HMI/SCADA system’s level of security is best understood if broken down into two major elements: communication and software technology.
Communication advancements have made large-scale HMI/SCADA system implementations successful for many industry applications. 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; however, 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 standardised common protocols to transfer data - all of which are largely unencrypted, requiring only weak or no authentication.
Field: HMI/SCADA implementations frequently consist of a number of widely dispersed remote sites with a control or data-gathering function, all connected to a central control and monitoring point. Data has to be passed between the control room and the remote terminal units (RTUs) over a network (which may be fibre optic, telephone or wireless), and the protocols for passing this data have frequently been developed with an emphasis on reliability and ease of implementation rather than security.
Modern computing facilities have made secure practical encryption almost impossible to defend against a determined hacker, so communications between devices need to employ several layers of defence with the primary aim to make access to the data difficult, and detect if the data has been compromised.
Software over the years has largely become feature-bloated as companies keep adding 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.
HMI/SCADA software: Most HMI/SCADA software installations have either external network connections or direct internet-based connectivity to perform remote maintenance functions or to connect to enterprise systems. While these types of connections help companies reduce labour costs and increase the efficiency of their field technicians, it is a key entry point for anyone attempting to gain access with a malicious intent.
Platform operating system: Operating systems that employ elements of consumer or open source operating systems such as Windows Server, Linux and Unix variants are increasingly popular since they help reduce costs. This trend towards open technologies has made proprietary custom, closed, highly secure systems a direction of the past, but it increases the risks.
Also, due to the fact that HMI/SCADA systems are complex and contain multiple layers of technology, even a simple system patch is a major undertaking that requires planning, funding and time. The risk elements are also substantial because many systems now rely solely on their HMI/SCADA system for visualisation, data recording and some control elements. Some companies hold back on patches, service packs and upgrades, while others choose not to apply any new patches, employing an ‘if it works, don’t touch it’ policy. Furthermore, software patches have generally been developed to cover for a security breach that has already occurred.
Some would say that even if companies could keep their platforms current, with the fast pace of consumer-based operating systems and large number of system exploits, platform operating systems are the single largest security risk in the system.
The inherent security of system designs minimises some risks
The good news is that some vulnerability is minimised by the nature of system design and HMI/SCADA software design, whereby the 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 described referring to the software and hardware levels.
While many view HMI/SCADA software as a visualisation tool that provides a means for dynamic operator input and visualisation as a flexible information terminal, the reality is that HMI/SCADA software capabilities are much more exhaustive. When elements are added such as control and logic capabilities, system engineers must examine the risk from a potential failure standpoint and the extent of control that is allowed without being in sight of the area being controlled.
Software is also developed from the operator’s perspective and uses company guidelines throughout the application to ensure the operator is controlling with intent. While this doesn’t necessarily bring additional security from external intruders, it does provide enhanced protection against mistakes. For example, the ‘select before operate’ design philosophy is typically used in HMI/SCADA applications, which requires the operator to select an item on the screen, pull up the controlling elements, operate the item and finally confirm to send the command. While this may seem like a simple ideology or a drawn-out process, this intentional design ensures that an operator’s actions are deliberate as opposed to a hasty reaction to an urgent situation.
At this level, design engineers employ many techniques to ensure safe control, either physically or by the HMI/SCADA software. Thousands of individual devices and RTUs can exist in a system and are typically 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.
Additionally, 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.
Taking into account the general design rule that system engineers apply for all levels of a system can be summarised by: ‘if a single point of failure exists, protect it or provide secondary means’. Therefore, design philosophies typically 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.
Be proactive: enhance your security with software capabilities
Even the safest system design and industry standards cannot secure a system 100% and, therefore, companies should not rely on them wholly to protect their systems. Instead, they should take a proactive approach to enhancing security, and a good starting point is in knowing what technologies are available to help them best meet their needs.
Selecting a trusted solution provider with deep expertise, experience and advanced technologies is also critical. Off-the-shelf HMI/SCADA solutions have successfully helped companies minimise their security gaps with a broad range of security-based software technologies, including:
- Biometrics - When biosecurity elements are integrated to the system, customers can program their system to require finger scans to perform specific functions such as switching on and off the grid’s main switchgears, which ensures that the appropriate person must be physically present to execute the order. This type of integration eliminates the possibility of a hacker performing the same operation virtually.
- Electronic signature - Many view this option as a simple reporting tool; however, the features are much more comprehensive. For example, it can introduce authentication potential at the command level to verify the user performing the operation with a username and password as well as a separate authentication, typically a manager, for verification. The information is then stored in a system audit trail that can be recalled in the future; some users also choose to integrate this feature with biometrics to eliminate the use of a single, widely known username and password.
- Authorised connections and client/server data encryption - Many off-the-shelf HMI/SCADA software products now have built-in features that limit the allowable client connections to known computers and use integrated data encryption for client communications. This protective capability eliminates the possibility of a hacker simply loading the HMI/SCADA client and connecting over the network.
- Domain authentication - To leverage complex alphanumeric passwords at the HMI/SCADA level, some software packages offer an add-on capability that introduces Windows domain authentication security integration. For example, GE features an application add-on that maps group memberships to its Proficy HMI/SCADA software roles and, when integrated, the users and subsequent passwords are managed at the IT level. This allows for the HMI/SCADA application to leverage existing group IT-level policies, which are typically very stringent and can exceed industry requirements.
Funding in today’s business climate
Improving an overall system’s security can be a costly endeavour, and companies must find the right balance between spend, design and process to make their systems safe. This is especially true as companies face increasing cost reductions mandated in today’s challenging economic environment. In response, off-the-shelf HMI/SCADA vendors have developed industry solution packs that include specifically tailored tools to help reduce development and overall system costs.
The cost of implementing an HMI/SCADA security policy should also be evaluated against the risk of a security breach - in terms of reputation, liability and intellectual property. Companies may discover a proactive approach actually reduces overall costs by ensuring business continuity when compared to the potential operational and financial loss that can occur due to the exposure of an unprotected system.
The vulnerabilities of HMI/SCADA systems pose a serious threat, and the complexity of multilayered technologies makes it difficult to completely secure an operation. As discussed in this paper, the inherent safe design of most HMI/SCADA systems offers some protection, but they are by no means enough to fully protect systems.
That’s why it’s important for companies to better understand where vulnerabilities exist within their systems and to take a proactive approach to address those susceptible areas. Off-the-shelf HMI/SCADA vendors offer software solutions with security-based capabilities, which can help companies enhance the protection of their critical infrastructure assets and reduce costs for a sustainable competitive advantage.
Considerations when critically examining your system
1. Examine your field assets, particularly older, remote components
- How does the SCADA 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?
2. Examine your IT assets
- Are the services/software running on an asset the minimum needed to maintain functionality?
- How secure is that 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?
3. 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 antivirus 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?
4. 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?
Variable speed drives can be a valuable source of data that can be used for condition monitoring,...
As the world outlook has become increasingly uncertain, many mining operations have implemented...
By considering a few basic requirements of your application, you can easily find the right valve...