Understanding and Minimizing HMI/SCADA System Security Gaps

[ad_1]

Understanding and Minimizing HMI/SCADA System Security Gaps
Understanding and Minimizing HMI/SCADA System Security Gaps

Being at the heart of an operation’s data visualization, control and reporting for operational improvements, human-machine interface (HMI) and supervisory control and data acquisition (SCADA) systems have received a great deal of attention, especially due to various cyberthreats and other media-fueled vulnerabilities.

The focus on HMI/SCADA security has grown exponentially, 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 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 visualize data within a programmable logic controller (PLC) to being a development suite of products that delivers powerful 3D visualizations, 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 knowing where to start in securing the entire system.

The purpose of this article is to explain where vulnerabilities within an HMI/SCADA system may lie, describe how the inherent security of system designs minimize some risks, outline some proactive steps businesses can take, and highlight several software capabilities that companies can leverage to further enhance their security.

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 unauthorized 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 minimize existing security gaps, companies need to first understand where vulnerabilities typically lie within the system. Powerful software features, along with 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

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 run-time 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 standardized common protocols to transfer data—all of which are largely unencrypted, requiring 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 fiber 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 defense with the primary aim of making access to the data difficult and detecting if the data has been compromised.

Software technology

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 connect to enterprise systems. Although these types of 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.

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 because they help reduce costs. This trend toward 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 visualization, data recording, and some control elements. And to this point, some companies hold back on patches, service packs, and upgrades, while others choose not to apply any new patches, employing a “it works, don’t touch it” policy. Furthermore, software patches have generally been developed to cover for a security breach that has already occurred.

The inherent security of system designs minimizes some risks

The good news is that some vulnerability is minimized 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 before the software performs 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.

Software: Although many view HMI/SCADA software as a tool that provides a means for dynamic operator input and visualization as a flexible information terminal, the reality is that HMI/SCADA software capabilities are much more exhaustive. When elements such as control and logic capabilities are added, system engineers must examine the risk from a potential failure standpoint and the extent of control that is allowed without being in line of 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 does not 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. This may seem like a simple ideology or a drawn out process, but this intentional design ensures that an operator’s actions are deliberate as opposed to a hasty reaction to an urgent situation.

Hardware: 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 fail safes are built in 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.

The general design rule that system engineers apply for all…

[ad_2]

Read More:Understanding and Minimizing HMI/SCADA System Security Gaps