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.