Secure Access to ICS Systems, or Risk Being Left in the Dark
by Karl Lankford •
23rd December 2015: an estimated 225,000 Ukrainian residents suffered from a significant blackout, which was later discovered to be the first blackout to be knowingly caused by hackers. Remediation was incredibly difficult, and energy suppliers were left to manually fix damage at impacted sites causing huge disruption across the region.
Following on from my last blog post in January, I wanted to walk through some of the findings in the SANS Analysis. I suspected this was caused due to poor or lacking security practice, and the subsequent investigation has highlighted some important points to consider.
From interviews with the three impacted organisations, the investigatory team quickly concluded the outages were caused by cyber intrusions at three regional electrical power distribution companies.
Some key points of the findings:
The attack could have only been possible as a result of extensive reconnaissance of the networks
The attacks all happened within 30 minutes of each other: it was synchronised and coordinated
Initial compromised access was the result of a spear phishing campaign, using malicious Microsoft Office documents
Some of the affected systems were embedded terminals for industrial systems
As part of the coordination, all of the attacks exhibited some of the systems having systems attacked using KillDisk malware to render the machines inoperable
Access to the control networks was through an insecure internal VPN
Once on the network, the attackers spent more time moving laterally around the network until they discovered the l00t - back office workstations connected with a VPN to the control room networks. The reconnaissance then continued, with the attackers watching and learning how staff controlled the system. The execution then started to wreak havoc, and in an effort to ensure maximum impact the attackers also disabled the back up power supplies to two of the three distribution centres. They then launched a DDoS attack on the organisations call centres to ensure no-one could report these faults.
As a result of the damage, the only way remediation was possible was manually - and even months after the attack, employees must still manually control the breakers at the impacted sites.
It is important to understand how this attack happened in order to implement your own security measures. At a very basic level, all privileged access to ICS systems should be secured by:
Secure Storage of Credentials - access should be limited, audited and tracked through a central scan
Rotation of passwords after each use - if attackers compromise a credential, it will be rotated after use and no longer be valid
Multi-Factor Authentication – require MFA for all privileged access
Controlled entry points to ICS systems - broker connections through a hardened access point, ensuring no direct connectivity and capturing all activity in a tamper proof audit trail
Reduce your attack surface - remove legacy remote access and administration tools from your network, ensuring that "air gapped" systems do not have a direct path of connectivity through VPN