Industrial Control Systems (ICS) have evolved over the years and now have a lot in common with traditional IT systems. Low-cost Ethernet and IP devices are replacing older, proprietary technology, which opens up new possibilities to improve connectivity and remote access. However, it also increases vulnerability to cyberattacks and incidents since the system is no longer segregated. Due to the nature of ICS, they differ from other IT systems. A compromised system can cause severe damage to the environment, incur substantial financial and production losses, and negatively impact an entire nation.
The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), an organization that strives to identify ICS vulnerabilities and provide mitigation strategies, has recorded similar growth trends between new vulnerabilities found in IT systems and ICS. As a result, implementing an ICS security policy has become necessary, but securing an ICS can be challenging. There are many aspects to consider, but security must not hinder operations.
This blog post will look at how an ICS can be compromised, why implementing a robust security policy is important, and how NXLog can be part of your strategy.
Brief ICS overview
ICS is an umbrella term for systems used to control industrial processes, including Supervisory Control and Data Acquisition (SCADA) systems and Distributed Control Systems (DCS). They can vary from small systems with just a few controllers to large distributed systems with hundreds of local and remote components.
These systems comprise various components, including a Master Terminal Unit (MTU), which acts as the control server, Programmable Logic Controllers (PLCs), a Human Machine Interface (HMI), Remote Terminal Units (RTUs), and a data historian for recording process data. Together, these components achieve an industrial objective.
ICS are split into two categories:
-
Manufacturing systems are found in factories and control processes that assemble products, such as food and beverage production, and chemical manufacturing. Communication between the components of a manufacturing system occurs over high-speed LAN connections that are more reliable.
-
Distribution systems are geographically dispersed. They control processes such as power generation, gas distribution, and water/wastewater management. These systems use less reliable WAN and wireless/RAF technologies that are optimized to minimize latency and data loss. Security takes the back seat in such systems, making them more vulnerable and prone to attacks. This is of concern because distribution systems are a critical infrastructure whose compromise would result in devastating consequences.
ICS protocols
Both manufacturing and distribution systems use standard and proprietary protocols for exchanging data between components, e.g., the control server and field devices (sensors or actuators). The most common industrial communication protocols are:
-
BACnet/IP
-
DNP3
-
Ethernet/IP
-
Modbus
-
Profinet
-
IEC 60870-5-104
-
IEC 61850
Unfortunately, protocols commonly used in ICS offer poor or no security and can allow a hacker to send remote commands to devices without any form of authentication.
ICS vulnerabilities and threats
There are several ways that an ICS can be compromised. Therefore, knowing the vulnerabilities of your ICS is imperative to implement security measures that help prevent and detect threats. Possible attack vectors in ICS networks include:
-
Backdoors in the network or applications
-
Vulnerabilities in communication protocols
-
Man-in-the-middle (MITM) and replay attacks
-
Denial of Service (DoS)
-
Hijacking field devices
-
Database attacks
-
Compromised privileged accounts
Not to mention intentional or unintentional misuse by internal personnel or a technical or physical malfunction. Several factors enable these threats in an ICS; let’s look at them one by one.
- Insufficient segregation
-
Lack of segregation between IT and OT networks is one of the most typical reasons for a compromised ICS. For example, a compromised device on the IT network can open access to devices on the ICS grid. Additionally, malware that makes its way to the corporate network may propagate to the OT network.
- Exposure over the internet
-
Organizations may need to expose their ICS, or part of it, over the internet to integrate with other platforms or provide remote access to employees or third parties. Vendors accessing the system for maintenance might not have policies that adhere to strict security practices. An insecure VPN connection might be just the opportunity an attacker is looking for to gain backdoor access and penetrate the ICS. HTTP is also a frequently used transport protocol for many manual attacks and automated worms.
- Application and device vulnerabilities
-
Applications associated with ICS and HMI may be vulnerable to web-based or client-based attacks such as SQL injection, command injection, or variable manipulation. Cross-site scripting attacks can also lead to session hijacking. Vendors continuously release patches to address known vulnerabilities. However, downtime in ICS affects productivity and must be planned ahead of time. Critical systems that cannot afford to be down at all require redundance systems to be in place, ready for failover. Delaying the installation of patches to avoid system disruption exposes it to known vulnerabilities and makes it prone to cyberattacks.
- ICS protocols vulnerabilities
-
Many of the protocols used in industrial networks have significant security vulnerabilities. Since these protocols were designed when industrial systems were isolated, they do not meet today’s security requirements. For instance, some protocols employ cleartext transmission without encryption, which allows an eavesdropper to gather information about the system and use it maliciously. Another common vulnerability is the lack of authentication, which could allow an intruder to easily reconfigure the system.
- Lack of security awareness
-
Due to a lack of awareness, employees frequently become victims of social engineering, phishing, and spearphishing attacks. All it takes is for an unaware employee to click on a malicious link. Once an attacker gains access to a device, they can proceed further into the network and the ICS. For example, Stuxnet, a malware targeting Siemens ICS, is one of the first known attacks caused by an engineer using a personal pen drive at the workplace.
The consequences of these exploited vulnerablities could include:
-
Delayed or denial of access to the control system
-
Reconfigured devices
-
Spoofed system status information
-
Manipulation of control logic
-
Modified safety mechanisms
You can easily imagine the repercussions of these events, especially in distribution systems. For example, an entire geographical area could have its power or water supply disrupted, with personnel unable to restore the service due to denied access to the control system.
Securing an ICS
There is no single product or solution that can protect an ICS. Your security policy must consider all aspects of the ICS and define a set of relevant controls. An effective security policy includes monitoring, logging, and auditing activities of all components and networks. Strong ICS monitoring is important to define a baseline of the system, which allows you to detect when security is violated, and if the system is compromised. Additionally, logging is necessary for forensic analysis and troubleshooting system malfunction. Security controls typically used in ICS include:
-
Firewalls
-
Creation of a DMZ
-
Intrusion Detection/Prevention Systems (IDS/IPS)
-
Role-based access control
-
File integrity monitoring (FIM)
-
Passive monitoring
-
Physical security
A SIEM solution should be employed to analyze and correlate events from various log sources and generate alerts when it detects abnormal activity. Since IDS and IPS software is resource-intensive and can cause performance degradation, passive network monitoring is ideal for recording traffic flow on the ICS network and letting the SIEM analyze it for intrusion attempts. Passive monitoring is also recommended because active monitoring solutions have been known to disrupt ICS operations and negatively impact the system.
How can NXLog help?
NXLog is a diverse log collection solution that can help you streamline your logging requirements. It provides various features that apply to log collection in an ICS environment, including:
-
Log collection from different sources, including Windows Event Log, file-based logs, and databases
-
File integrity monitoring that works at the filesystem level
-
Passive network monitoring supporting ICS protocols such as Modbus, PROFINET, DNP3, S7Comm, IEC 60870-5-104, IEC 61850, and BACNet
-
Event processing, filtering, and correlation capabilities
-
Regular expression support for parsing custom log formats
-
Parsing and outputting logs in standard data formats such as JSON, XML, and CSV
-
Forwarding logs to most SIEM solutions and log analytics platforms
-
Execution of custom scripts and applications
Detecting ICS exploits with NXLog - a practical example
NXLog’s im_pcap module has the built-in capability to decode ICS/SCADA protocols for passive network monitoring. By comparing expected against unexpected behavior, you can configure NXLog to detect anomalies in protocol commands, message structure, or frequency of operations. For example, knowing exactly how a protocol message should be formatted allows you to use correlation to detect and react to undesired events.
Since ICS/SCADA security is all about protecting the processes, let’s take a violation of such a principle as an example.
Denial of Service to PLCs: The Modbus protocol would be a very straightforward way to DoS a PLC.
The diagnostic function (or code 8) in Modbus allows for a sub-function or command (subcode 04) to change the mode of a PLC to "Listen Only."
If you’re using such a device for controlling temperature, pumping, or any other mission-critical operation, this is a problem since it will render the device useless.
With NXLog, you can detect and even revert this attack. Traffic monitoring can begin on a segment of the ICS network and look for Function 8 and subcode 04 in network packets. Assuming this is undesired behavior in typical circumstances, you can trigger a custom warning such as:
WARNING: PLC <PLC_Name> has been switched to "Listen-Only" mode, ensure this change is approved or take action immediately.This message, in turn, could be fed straight into a SIEM for security analysts to examine.
Nevertheless, more is possible if you use NXLog’s capability of executing custom scripts once a condition is triggered:
-
Email: In addition to making this information available to the SIEM (security analysts may or may not respond to the threat immediately), you can trigger an email alert to the administrator by using the xm_exec module.
-
Remediation: Specifically to this scenario, the restart communications function (
subcode 01) is the only one able to remove the device from listen-only mode. You can invoke a Python script with xm_python and use a packet crafting tool like Scapy to send a packet with the restart communications command and revert the hacker’s action automatically.
Conclusion
Considering the criticality of ICS and SCADA systems and the physical risks involved, taking measures to protect such environments is only logical. Operations technology has been consistently hacked since the early 2000s. Surprisingly, many environments and protocols have remained the same since then, even though industrial systems are exposed to greater threats today.
This blog post highlighted some vulnerabilities that could expose your ICS to an attack. These vulnerabilities prove that implementing a robust security policy that caters to all facets of an ICS has become increasingly important. We have also provided a practical example of how NXLog Enterprise Edition can alert you on possible threats and execute remediation actions. With NXLog’s rich feature-set, we are confident it will meet your log collection and processing needs and help simplify your threat detection and response strategy.
