Mitigating Havex, an ICS Threat

Wednesday, July 30, 2014 @ 10:07 AM gHale

EDITOR’S NOTE: This is an excerpt of the second in a two-part series from Del Rodillas at Palo Alto Networks discussing the Havex campaign and its effects on industrial control systems. In part one of this series, Del discussed why the Havex Trojan is a significant industry milestone. This week, he looks at how to mitigate exposure through the combination of good practices and next-generation firewall technology.
By Del Rodillas
In my initial engagements with control systems operators two security objectives, both linked to keeping uptime high, frequently come up.

First, the operations manager, or person responsible for security in the operational technology (OT) environment, remains concerned over whether only the approved users are using the right applications and resources in the specific usage model intended for SCADA. This person, at the very basic level, would want to be able to validate that the system ends up used only in a way that aligns with the business objectives, ultimately with the goal of implementing role-based access control. In this person’s mind, an internal user accidentally causing system downtime is as much a cyber threat as an incident malicious in nature.

Second, there is a concern that malware, especially advanced persistent threats (APTs) that have never been seen in the wild, would, by accident or on purpose, get introduced into the network disrupting service availability.

RELATED STORIES
Havex an ICS Game Changing Threat
Havex Varient Brings Attack via OPC
Malware Analysis from ICS-CERT
Energy Sector Alert: Dragonfly Attack

Not surprisingly, I often find that a couple of core capabilities critical for achieving these security objectives, namely protocol/application layer visibility and Zero Day threat detection, are not yet deployed in their OT environment.

Most operators only have legacy stateful inspection firewalls (port-level visibility) plus add-ons like IPS/AV (block known threats). Whether they’ve been lax in upgrading their technology, or for some other reason, these operators are finding their technologies have simply run out of steam and cannot provide the type of visibility, security controls, and threat prevention required to combat advanced threats. It is imperative that asset owners take a fresh look at better techniques and tools that can help improve security posture to the required level and reduce downtime due to cyber incidents. So what are some of these options?

Proper Segmentation
Technology is a critical piece of the cybersecurity equation, but its benefits have limits if you don’t have a clear understanding of risk, if you don’t have a clear set of access control policies, and/or if you haven’t segmented your network in a way that aligns with these risks and policies. As always, the IEC 62443 standard is the gold standard for network segmentation in industrial control systems.

Segmentation and access control, especially when done with a least-privilege approach, are key in that they reduce your attack footprint and establish a baseline from which anomalies could end up easily detected. In the context of the security concerns raised by Havex, some basic but important questions to ask yourself around access control and segmentation include:
• Do you have enough security zones and points of inspection between zones, a.k.a. conduits in IEC 62443 terms, to validate compliance to policy or to be able to implement controls? For example, while you may isolate the OT from IT with a perimeter firewall, are you able to observe intra-OT traffic such as HMI/Workstation to Server, PCN to Plant/PLC, and interplant traffic? It will be very difficult to see the fingerprints of APTs if you have a flat SCADA/ICS network.
• Have you clearly defined which users and machines are allowed to access which applications, and from which zones these policies are relevant? What file/data types are allowed to traverse your network?
• If direct Internet connectivity is allowed, do you have a list of which domains/IP addresses are allowed, and which users are allowed to access those sites? You may be clear on what is and isn’t allowed to enter the ICS environment, but what about what goes out?

These aren’t easy tasks, but they have to occur up front. The fact that SCADA/ICS systems are purpose built with a very specific set of users and applications should help in terms of containing the effort of creating access policies.

It’s all about the ID
Clearly, effective segmentation and access control is dependent on the ability to control protocols/application based on user and the ability to inspect content.

App-ID, User-ID, and Content-ID technologies should be the heart of the platform. App-ID provides visibility to protocols and applications, versus just ports/services. For example, App-ID is able to identify ICS protocols such as OPC, DNP3, Modbus, BACnet, OSIsoft PI, and others. Functional App-IDs are also available for some protocols like Modbus and IEC 60870-5-104 to enable resolution at the read/write level.

User-ID is the technology that allows role-based access control by mapping IP addresses to user (or user group). A variety of user information repositories and authentication events could be used for this purpose.

Content-ID is able to inspect the payloads (e.g. files, data types, URLs, threats). It is important to note that packets are processed for App-ID, User-ID, and Content-ID in parallel, and in a single pass providing not only high-performance, but also shared context. which is equally as important in terms of correlation analysis.

Here is how App-ID and User-ID may end up applied in unison to enable role-based access for OPC. Actually, your OPC policy within the SCADA may be very different from the OPC policy you have at the IT-OT boundary. For example, at the perimeter you may allow only a certain set of users, say finance users in the Active Directory group “SCADA_finance” access to the OPC application so they can get access to a primary or replicated historian in the SCADA zone or SCADA DMZ zone. This can all be defined in single policy that involves no opening up of ports. Furthermore, a network appliance could use a positive enforcement approach meaning no other traffic but that allowed in policy will pass through by default.

Within the OT, you might allow all users in the “SCADA Ops” AD group access to OPC. This might be very different for a third party vendor that needs to access your network to service their products that do not use OPC. To limit the risk of the third party accidentally or intentionally accessing resources via OPC while letting them do their job, one could also define another role-based policy. For example, you could define a rule that allows the vendor access to another ICS protocol only between relevant security zones. You could also define a third party zone that has jump servers and another PLC Zone where that vendors products reside. While we use OPC as an example, these same kinds of policies could just as easily be applied for other ICS protocols and applications as well as common administrative protocols, such as SSH, FTP, and SNMP, that are often used in SCADA networks.

Access control via App-ID and User-ID helps to reduce your attack footprint as well as the risk of accidental cyber incidents such as erroneous programming by less experienced personnel. This takes us to the next core technology, Content-ID. This service blocks malicious payloads, such as exploits, viruses, and spyware/CNC (command and control), and also helps to further reduce your footprint by controlling access to URLs/Domains.

Finding Zero Days
Okay so what about the never-before seen variants of Havex? The next thing to put in place is a means to detect Zero Day malware. There are services that isolate suspicious payloads entering your network, detonates them in a virtual sandbox environment, and determines if payloads are benign or malicious in nature. Service subscribers get protections against malicious payloads in as little as 30 minutes.

End point security remains a vital cog in securing a network. One way a security solution could work is instead of the technology trying to block the large and quickly growing universe of known malware and exploits, it blocks the techniques themselves. The universe of techniques is on the order of a couple dozen and grows very slowly, therefore this approach much more effective.
Del Rodillas is a senior product manager for SCADA & Industrial Control Systems at Santa Clara, CA-based Palo Alto Networks.



Leave a Reply

You must be logged in to post a comment.