Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:30 AM
Matt Cauthorn
Matt Cauthorn
Connect Directly
E-Mail vvv

How to Protect Industrial Control Systems from State-Sponsored Hackers

US-CERT recently issued an alert about Russian threat activity against infrastructure sectors. Is there a way to fight back?

On March 15, a significant alert was issued by the US-CERT regarding Russian state-sponsored threat activity against critical infrastructure sectors, including energy, aviation, and critical manufacturing. The attacks were not random; these were deliberate, multistage, focused attacks designed to gain a foothold within high-impact assets that can be used for any number of nefarious actions. 

A new approach to protecting industrial control systems (ICSs) is necessary. The only clear path is to start relying on network data analytics, which is far less vulnerable than other security tools to tampering and erasure by attackers and does not require challenging updates or software installation on legacy systems.

ICSs have always presented notoriously difficult security challenges because their microcode is often embedded within proprietary hardware or aging computer platforms that are difficult or impossible to monitor and secure. The attackers in this case used sophisticated tactics, techniques, and procedures (TTPs) to compromise sensitive systems, and to erase the evidence of their behaviors on the compromised systems.

To understand the inadequacy, or at least incompleteness, of current security mechanisms in ICS systems, note the "cleanup and cover tasks" section of the CERT alert:

In multiple instances, the threat actors created new accounts on the staging targets to perform cleanup operations. The accounts created were used to clear the following Windows event logs: System, Security, Terminal Services, Remote Services, and Audit. The threat actors also removed applications they installed while they were in the network along with any logs produced.

This classic behavior by the threat actors highlights the inherent weaknesses of relying on self-reported data such as logs that can be disabled or altered on compromised assets.

The Critical Role of Network Data
An entire industry has sprung up to try to address this problem, involving network segmentation and secure overlay networks that require no instrumentation on the ICS assets themselves. But these do not address the general lack of visibility into existing systems or the difficulty of maintaining a real-time view of what's happening in these difficult-to-monitor deployments.

The CERT alert made it clear that the vast majority of logs or on-system records of what happened were methodically deleted by the threat actors. What remained as evidence was a set of network-behavior based clues that could not be deleted. Monitoring the actual traffic in flight on the network is the only way to get a conclusive audit of any connected devices, services that are running, dependencies, and threat behaviors in progress.

There are many mechanisms by which network behavior can be used to detect and investigate ICS breaches.

● Any login event by an unusual client to a system containing ICS data can be seen on the network and should raise an alarm. If a new user or client logs in, it's worth investigating. The CERT alert described a privilege-escalation scenario in which the attacker attempted to create a new administrator account, using the Remote Desktop Protocol (RDP). New account creation, especially an administrative account on a sensitive system, is always worth extra scrutiny, and a network analytics platform that can decode RDP could provide real-time warning of this type of event.

● Any traffic from an ICS system to an unusual external IP space can be detected on the network and is worthy of immediate investigation. In this CERT alert, the attacker gained access to screenshots and schematics of flow diagrams detailing ICS output data and how the ICS system was configured. This sensitive data had to be exfiltrated off the network of origin and moved to a system controlled by the attacker. That exfiltration happened across the network and would be extremely noticeable to a network-data based anomaly-detection system.

● If an unusual client attempts to access a database containing ICS data, that may not be a sign of malicious intent per se. However, that client's immediate behavior can indicate whether they're malicious. For example, if that client transmits a SELECT command to the database, requesting sensitive data, that would be cause for alarm. Even more alarming would be a DROP command against the audit table of that database, removing the log of recent access from the database. The content of these queries would still be visible on the network to the right analytics platform but would be invisible to anything relying on logs from the database or associated devices.

● Similarly, visibility into Layer 7 transactions on the network can differentiate between "unusual, but acceptable" and "malicious" access to file storage systems. By reading the contents of queries in the CIFS/SMB protocol, a network data analysis service could help a security staff know quickly whether a given file-access event was worth investigating.

The list above is just a sampling of threat behaviors that are visible on the network. All of the hallmark behaviors of a malicious attack leave tracks on the network that the attacker cannot erase, including malicious payload delivery, command and control traffic, lateral movement, and data exfiltration.

Ultimately, it is critical to have a way to monitor and parse this traffic at the Layer 7 transaction level for network protocols used in ICS systems, including Modbus TCP/IP, DNS, CIFS, and more. Log-based analytics, while valuable, have crucial blind spots that only network analytics can shed light on.

This US-CERT alert describes a serious, ongoing threat to our national security. Compromises of our energy grid, manufacturing, air traffic control, and even roadway traffic control can be used to affect our way of life and make us vulnerable. Above all else, these attacks must serve as a wake-up call that the current security status quo isn’t working. Traditional methods can’t keep up with today’s threats. It's time to rethink how we secure our most critical systems and assets.

Related Content:

Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry's most knowledgeable IT security experts. Check out the Interop ITX 2018 agenda here.

Matt Cauthorn is VP of Security for ExtraHop, where he is responsible for all security implementations and leads a team of technical security engineers who work directly with customers and prospects. A passionate technologist and evangelist, Matt is often on-site with ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.