Defending ICS Against Dragonfly Attacks

Monday, December 15, 2014 @ 05:12 PM gHale


By Heather MacKenzie
The malware campaign known as Dragonfly surprised those of us concerned with industrial cyber security on several fronts. Initially, it was notable as the first malware since Stuxnet in 2010 to specifically target Industrial Control Systems (ICS) components.

Then, research conducted by Joel Langill of RedHat Cyber, showed its target was most likely the pharmaceutical industry, rather than the energy industry as initially reported. This represented the first time that a sophisticated attack vector had gone after the discrete manufacturing sector.

RELATED STORIES
Securing Industrial Wireless Applications
7 Questions for Industrial Wireless Security
Dragonfly: Offense in Depth
Dragonfly: Pharma Industry Targeted

Next, although Dragonfly collected information on industrial control systems, it did not harm these systems. Instead, it gathered information for the likely purposes of counterfeiting or competitive intelligence.

Dragonfly was also remarkable because of the devious methods and pathways it took to get to the control system. Joel coined the apt term “Offense in Depth” to describe the diversified arsenal of attack vectors it employed.

Impact of Dragonfly on ICS
Let’s be clear, Dragonfly did not directly impact the performance of ICS systems and did not install malware on mission-critical ICS devices. Instead, it installed its malware on HMIs and engineering stations that would have had direct connections to critical process assets. The ultimate consequence of its attacks was likely the theft of valuable proprietary information.

Having said that, there are lessons to be learned for any security risk assessment. In particular, it is very useful to understand how the techniques and breaches the Dragonfly attackers used could potentially damage manufacturing systems in the future. These included:

Allowing malicious code to execute on the systems by users not authorized to do things such as install or update applications. This made it possible for any user – be it engineer or operator – to install damaging software on any industrial system regardless of the permissions officially granted to them.

Establishing persistence on internal ICS hosts, especially mobile and remote access computers, to take advantage of the Internet access these computers may have on occasion.

Focusing on Windows XP-based computers, widely used by industry, difficult to migrate away from and now impossible to patch.

Extracting sensitive information, such as passwords, that could be re-used at a later time to allow unauthorized remote access to critical systems.

Exploiting trusted and authorized remote access systems (used by suppliers or maintenance groups) to give the attackers a pathway to multiple control systems.

Demonstrating a proof-of-concept for providing unauthorized write access to control functions, in this case using the OPC protocol.

Exploiting the trust end users have for software products supplied by ICS vendors in order to bypass security controls, such as whitelisting and antivirus software.

Ineffective Dragonfly Defenses
Dragonfly’s operators were particularly devious in the ways they used “insider” tactics to penetrate their victims’ ICS. They had innocent authorized personnel initiate their actions in each phase of the attack, using components obtained from trusted suppliers and “assumed” authentic.

As a result, many common security measures were ineffective against Dragonfly. For example, consider application whitelisting (AWL). It is one of the most commonly proposed solutions to defend against today’s sophisticated threat actors.

Dragonfly was able to bypass AWL because it trojanized software from credible ICS vendors. Users thought the software they were installing was legitimate and, thus, would have deliberately disabled their AWL defenses when installing upgrades.

In theory, this “window of opportunity” for malware to bypass AWL controls can end up countered by using traditional antivirus (AV) or “blacklisting” applications. Unfortunately, the leading AV suppliers did not release signatures for the malware until mid-2014, past the peak window of activity for Dragonfly.

Effective Dragonfly Defenses
Unlike application whitelisting, the concept of network whitelisting is to tightly control the types of messages any device or computer can send or receive on a network. At its most basic, a computer might have host firewall rules to limit the TCP and UDP port numbers it can send or receive to only those protocols needed for proper ICS operation. This is a limited defense, however, because if the computer is compromised by malware, then it’s likely its firewall settings will be changed to open up network access.

For this reason, it is recommended network whitelisting be managed externally from any device that might be an attractive attack entry point (such as computers used for remote access). To achieve this external control of traffic, a transparent or bridged firewall can be very effective.

TCP/IP rules in these devices can tightly limit what the computer can transmit into the network and who it can talk to. Security devices can also warn when the computer suddenly tries to send new protocols or scan new ICS devices. In the case of Dragonfly, the traffic its protocol scanning modules sent would have been an immediate indication that something was very wrong on the ICS network.

Protocol Whitelisting
TCP/IP level network whitelisting also has limitations. This method of whitelisting only blocks unauthorized protocols from entering the network. It does not provide the ability to limit the functions that each of these protocols can perform.

This requires the ability to filter based not only on the TCP and UDP ports used, but also the actual high-level application content. Deployed on a network, this is commonly referred to as Deep Packet Inspection (DPI), and it provides the ability to restrict messages on the network to those performing approved functions, such as reading a specific PLC register.

For example, a controls engineer may use DPI to limit Modbus/TCP functions to read-only services to a critical PLC. This requires a device that can be installed in industrial environments and has application awareness of the industrial protocols used.

Such devices typically deploy close to the equipment they are protecting.

Defending ICS
The defenses listed are but a few of the ineffective and effective tactics for Dragonfly.

Eric Byres has this conclusion about how organizations need to defend themselves from advanced persistent threats: “If Dragonfly has taught us anything, it is that when defending ICS systems from today’s sophisticated attackers, the ‘usual’ security solutions may not be the right security solutions. Technologies and procedures like restricted user accounts, patching and VPNs actually played into the attackers’ hands.

“Instead of deploying security policies because ‘everyone does it this way’ or the ‘check list tells us to,’ ICS security needs to be evaluated on a holistic risk basis. And in that analysis, we have to assume that the bad guys will breach our defenses at some point.

“Preventing breaches is desirable, but being able to detect and address a breach rapidly and effectively will prove to be a more important capability for every industrial company in the next few years.”

Although Dragonfly had the means to damage critical control systems, the good news is there are techniques and technologies that can defend against advanced malware campaigns.
Heather MacKenzie is with Tofino Security, a Belden company. Click here to view her blog.



Leave a Reply

You must be logged in to post a comment.