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.
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