ICS Cybersecurity Vulnerabilities
What is Vulnerable?
Previously, ICS interconnections focused primarily on enabling communications between the processor and controller, and were isolated. The introduction of modern information technologies and operating systems into the ICS environment has provided much needed system integration capabilities, but at the cost of exposing ICS to security threats previously known only to IT systems.
Consider a simple situation where a globally popular operating system is used as the foundation for deploying mission-critical ICS software applications. Each and every time a vulnerability is found in that operating system, the ICS using it is also vulnerable. As more ICS migrate toward using ubiquitous IT solutions, the risk of having critical infrastructure systems vulnerable to the same types of threats as IT systems rises.
Open Systems Interconnection
Well-known vulnerabilities exist in each of the seven layers of the Open Systems Interconnection (OSI) model. As ICS migrates away from traditional and proprietary protocols, the use of new and efficient operating systems can make them vulnerable to attacks.
The vulnerability lies with the transparency of the OSI model, as opposed to the obscure proprietary ICS frameworks known only to those who had designed them, or to those with specialized training.
As we leverage well-known IT communications protocols (which can be insecure) and use them in a manner that takes advantage of current networking functionality (which can also be insecure), we expose critical infrastructure systems to attack.
ICS Attack Targets
Any hardware or software processing, storing, or transmitting information digitally is vulnerable to cyberattack. Whether the system can be compromised is dependent on whether the vulnerability is exploitable. In other words, any system can be attacked, but not every attack will be successful. In control system environments, several types of digital assets can be targeted by a cyber adversary:
- Networking devices
- Programmable logic controllers (PLCs)
- Remote terminal units (RTUs)
- Human-machine interface (HMI) workstations
- Data acquisition servers and historians
- Engineering workstations
- Remote access devices
- Authentication and authorization servers
Even integrated safety systems could be vulnerable, and there is risk if connected directly to the control system network.
There are many pathways to communicate with an ICS network and its components using a variety of computing and communications equipment. These pathways can be used by anyone knowledgeable in process equipment, networks, operating systems, and software applications to gain access to the ICS.
Poor Code Quality
One of the primary causes of security vulnerabilities in control system software and firmware is the use of poor programming techniques. Most developers do not intentionally write code with security flaws. However, ICS are developed with a focus on system availability and resiliency. When the requirement for high availability is the top priority, security is often not considered during the development lifecycle.
Code issues are often exacerbated in control systems that may be decades old, and running code that has not been updated since its installation. Changing coding practices or rewriting the source code for a flagship product can be expensive for vendors and customers, and applying patches in an operational environment is often difficult.
ICS owners should request that vendors certify their developers are trained in, and use, secure coding practices as part of their quality control process. ICS owners should also ensure they create the necessary communication paths needed to quickly learn of any code-based security problems, and to receive and deploy patches in an effective way.
Increasing cybersecurity awareness and its importance in the system and software development life cycle helps asset owners and vendors understand the need to proactively build security into the system, which will significantly increase the security of their ICS products.
Network Design Vulnerabilities
ICS networks are typically designed to support real-time data communications. It is common for security best practices to be excluded when designing ICS architectures. The network infrastructure environment within the ICS is usually developed and modified based on business and operational requirements, with little consideration for the potential security impacts of the changes.
Some ICS network architectures use flat networks with no zones, no port security, and weak enforcement of remote access policies.
To compound this problem, ICS networks may be directly connected to corporate environments without firewalls and zones, or allow direct connections to the Internet. Over time, security gaps may have been inadvertently introduced. Without remediation, these gaps introduce vulnerabilities into the ICS.
Web-Based and Remote Service Vulnerabilities
Improvements and modifications to control system functionality are usually the result of customer demand. Embedded Web services, remote diagnostic tools, reporting features, and other value-added capabilities traditionally not used in control system solutions are increasingly being seen in the field. While Web-based and remote services allow ICS operators to more efficiently manage, monitor, and control the systems, this approach may introduce significant security vulnerabilities into the control system architecture.
For example of this, many control system vendors meet the demands of their customers by integrating easy-to-use interfaces for managing equipment. An example is incorporating simple and inexpensive Web services directly into their field devices. This allows operators to control and administer critical equipment from anywhere through a Web or Internet browser. Without a proper security analysis of that Web interface, it could be used as an attack vector into field equipment.
Vulnerabilities unique to such remote services are now built into many control system vendor solutions. If exploited, such vulnerabilities can reveal significant information to an attacker or provide them with access to the device itself.
The convergence of IT and ICS creates new pathways that can be used to exploit a large number of cyber vulnerabilities.
- Requirements for rapid information exchange, such as data moving from plant operations to executive decision makers, can limit the effectiveness of adequate defense-in-depth strategies or recommended best practices for ICS cybersecurity.
- Requirements for near real-time accessibility to critical operations may facilitate the use of remote access solutions focusing on availability and not necessarily security.
- To optimize performance and resiliency, asset owners often provide direct access to the operational environment for their vendors and integrators, thus opening possible channels of attack.
Root Causes of Vulnerabilities
Legacy Control Systems
Because replacing an aging control system can be expensive and disruptive to operations, the life cycle of many control systems is 15 years or longer. These legacy systems are not designed to provide protection from modern-day attacks, or may not be updated to provide the protective mechanisms developed since being placed in service. Ongoing assessments, independent cybersecurity research, and self-disclosure from vendors suggest there are inherent security vulnerabilities in ICS that are residual from past engineering and development activities.
These did not start as vulnerabilities, as they were originally system features designed to facilitate the efficient and safe operation of mission-critical systems required to be available all the time (high availability). They were also designed to be used on systems isolated from untrusted networks.
Today, many of these same features could be used to seriously damage the system if used by operators who have become disgruntled, or if an adversary or attacker is able to acquire the role of the authorized user.
Legacy Systems: Plain Text Traffic
Few ICS manufacturers and vendors deploy data obfuscation and cryptography to prevent traffic eavesdropping, and plain text protocols are ubiquitous across almost all control systems. ICS protocols were originally designed for use in isolated environments, and because availability was the highest priority, there was no need to defend these systems from data theft. More importantly, plain text makes it easier to integrate disparate systems. As owners, vendors, and integrators push for interoperability, plain text traffic remains common. Plain text protocols are also simpler and faster to troubleshoot than encrypted protocols.
Adversaries with access to control system networks can potentially perform real-time traffic analysis, as well as harvest network traffic for offline security testing. Considering the trust relationships in control system environments (e.g., between operator consoles and field equipment, or database-to-database), an attacker who has captured a plain text password can exploit these relationships by impersonating trusted cyber assets or injecting data into the data stream, causing an undesirable event.
Access to control traffic in plain text allows a threat actor to execute numerous attacks–including denial of service, man-in-the-middle, session hijacking, and other network-based attacks, ultimately impacting integrity and availability.
Legacy Systems: Hard-coded/easy passwords
Password management is a fundamental component of any security program. However, few ICS operators have provisioned their systems with unique passwords supported by robust security policies, such as routine password changes—especially default passwords. Because ICS are always on, most ICS asset owners use an easily remembered, shared password for all operators; or the default passwords are never changed after installation. While this ensures operators can quickly access the system, it also makes it easy for an attacker to do the same.
Some vendors have designed their systems with hard-coded or unchangeable passwords. Hard-coded passwords are used internally by ICS programs needing authorization to communicate with other computer resources, such as databases, or are used to simplify software installations and program configurations.
For example, initial authentication credentials are exchanged between ICS historians using hard-coded passwords. It is trivial to discover most hard-coded passwords: they are passed in plain text across the network, or openly published in equipment manuals or the vendor website. Advanced malware has been developed to exploit hard-coded passwords in conjunction with other vulnerabilities, leaving systems using them at risk.
Legacy Systems: No Least Privilege
Coding methods previously used by ICS vendors emphasized availability because these systems were historically isolated. Availability, not security, was important for the associated applications and system, so they were run with unlimited privileges. This essentially gave operators complete administrative control of the system.
When the system is operating with administrator-level privileges, both vital and non-vital applications are running with a high level of authority. If threat actors compromise the system, they have administrative privileges to control and damage the applications and processes.
Many processes found in ICS do not need to run with unbounded privileges. Applying the principle of least privilege means running systems, processes, and applications with the minimal amount of authority needed, thus restricting the level of system access should the system be compromised. Typically, this is accomplished by having the user log into the system with a user level vs. administrator-level account, restricting which permissions are available to the user.
Legacy Systems: No Authentication
System functionality facilitating the addition of new applications without security checks is a common problem. ICS downtimes are few, and it is critical that local and trusted entities be allowed to install applications without delay.
However, as requirements and capabilities for control systems have matured, new and complicated third-party applications are integrated into the control systems, and not all can be trusted.
The malware group, Havex, replaced the normal installation files of third-party software with tainted copies. They surreptitiously installed a remote access trojan (RAT) on the computers of targeted companies through the ICS used to automate everything from switches in electrical substations, to sensitive equipment in nuclear power plants.
Legacy Systems: No Check
Data integrity checks ensure the ICS information an operator is monitoring is correct and has not been modified. When ICS were isolated with limited connectivity, there was little doubt the readings were accurate. As more ICS become interconnected, risks of critical operation data being altered increases.
For example, if an HMI is compromised, it could indicate to the ICS operator that a critical valve is closed, when it is actually open. The false information displayed by the system could cause a catastrophic incident. Ensuring data integrity in the HMI is of vital importance, especially as ICS are becoming more interconnected, escalating the risk of compromise.
Legacy Systems: Guaranteed High Availability
The primary focus for ICS, especially mission-critical ICS applications, is high availability. Unfortunately, coding a system for high availability differs from one designed to be secure. Designing high-availability systems often creates vulnerabilities easily discovered by an attacker.
Vendors do not want security vulnerabilities in their products any more than users and asset owners do. Yet a vendor may be slow to fix a vulnerability because of the level of effort required. As a result, the application may be vulnerable when the system or application is not designed to, for example, check for abnormal data inputs, which can be exploited using attacks such as denial of service, buffer overflow, or data injection. The public availability of easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability.
Legacy Systems: Easy Connectivity
As corporate entities and peer locations have a need to obtain real-time control system or process information, new methods for exchanging information between a trusted control system and an untrusted enclave are developed. An organization’s ability to obtain real-time data is important, because it provides management with accurate and timely information to make better decisions regarding the operations of their critical infrastructure systems.
While there is no doubt that interconnecting ICS with business systems has improved productivity, every data channel creates a potential vulnerability, increasing the risk to the control system. This includes database sharing, peer-to-peer communications, VPN access, remote vendor access, and any other conduit allowing direct access to mission-critical control system activities.
Often, postmortem analysis of cybersecurity incidents indicates these information-sharing channels are often the vectors used by malware, or to facilitate unauthorized remote access.
The functionality and capability of control system equipment, specifically field devices, have increased tremendously. Many vendors embed additional services in their control systems, including Web, file transfer protocol (FTP), simple network management protocol (SNMP) services, and other types of functionality designed to enhance operations.
While these features provide many easy-to-use services and increased functionality, they also introduce new vectors for an attacker to remotely configure and program these devices, or to modify the firmware. While this is not an issue for all vendors, it does pose a significant cyber risk. These devices are connected directly to ICS components, which monitor and control process equipment, creating a target-rich environment.
Current device programming technologies used include:
- Network enabled
- Remotely programmable
- Onboard I/O servers and Web servers
- FTP and SNMP enabled
- Physical cybersecurity devices
- Next generation directions
Device Programming – Field Device Issues
Historically, field devices have been deployed in a manner that assumes they will be placed in a secure environment, one not allowing for unauthorized access to the device in any way. If there is no risk of unauthorized access, the devices often use protocols devoid of authentication and authorization.
Why would you need authentication and authorization if the only people accessing the device were trusted users? This lack of access security is an artifact from the legacy control system environment where there really wasn’t a need for access across the network. As a consequence, ICS don’t always support access control.
In many architectures, any host can communicate with, and send commands to, any other device, provided they both use the same protocol. The design of some ICS uses a polling system. By design, a device’s onboard processing power may be insufficient to handle large amounts of data.
As a consequence, field devices are vulnerable to catastrophic failures because of data storms, packet flooding, malformed data, or other events caused by regular behaviors. The breakdown of such a critical piece of equipment can result in failure to deliver critical process information and loss of control.
Connectivity and Network Architecture
Engineers can easily bridge ICS networks and business networks with the adoption of IT designs and architectures. While the benefits may be significant, this push to integrate networks also creates one of the most significant sources of ICS vulnerabilities. ICS networks that were previously physically and electronically isolated may now be integrated and connected with other networks, including the Internet. As a result, exploits previously accessible by physical proximity only can now be delivered to a control system from anywhere in the world.
Many asset owners establish an electronic security perimeter around their ICS to protect from a cyberattack. This perimeter creates a trusted environment within the ICS network and protects assets from direct exposure to untrusted domains.
Historically, the level of trust between ICS domains mirrors the trust level between corporate operations and the Internet. However, as corporate requirements for real-time monitoring and analysis of ICS have become more common, the architecture must be designed to support a more trusted relationship.
To facilitate better communications, we see architectures built with a transitive trust between ICS and corporate networks. This relationship creates a need for more robust protection mechanisms and assurance that an attacker who has a presence on the corporate network cannot use this trusted path to access the control system network.
Connectivity – Trusted Connections
A DCS is not the only system that can be attacked by piercing the electronic perimeter. Any remote access providing engineers and technicians the ability to access the control system from an external network extends the electronic perimeter. Typically, VPN connections (the primary method for establishing remote communications), if properly installed and configured, are often safer than firewall exceptions. However, because the perimeter has been extended to a remote location, the network engineers do not have as much control over the end device as they do with workstations located on company premises.
One final point about trust: just like in the corporate environment, databases and third-party applications (such as document viewers) can be important components in an ICS. However, these third-party applications, if not properly secured and patched, can provide an exploitable vector. Attackers can also exploit the trusted relationship between databases replicating data between the control network and the business network.
The vulnerabilities listed below are repeatedly seen during site assessments, CISA Incident Response Investigations, and CSET® assessments.
- Credentials management: Includes weak password policies (no passwords, no enforcement of strong passwords, and use of default user names and passwords) and insufficiently protected passwords.
- Network design weakness: No security perimeter defined and lack of network segmentation.
- Lack of formal documentation: No security policy and procedures, and poor security documentation maintenance.
- Weak firewall rules: Firewall bypassed, firewall rules not tailored to ICS traffic, and specific ports on host not restricted to allowable IP address.
- Audit and accountability: Lack of security audits and logging.
- Permissions and privilege access control: Improper user permissions, open-network shares, and poor security configuration.