In part 1 of this 2-part blog series, we discussed why the Havex Trojan is a significant and concerning industry milestone. Here, in part 2, we look at how you can mitigate your exposure through the combination of good practices and next-generation firewall technology.
In my initial engagements with control systems operators interested in our technology, two security objectives, both linked with the objective of keeping uptime high, frequently come up.
First, the operations manager, or person responsible for security in the operational technology (OT) environment, is 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 is 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 cyberthreat as an incident malicious in nature.
Second, there is a concern that malware, especially APTs that have never been seen in the wild, would, by accident or on purpose, get introduced into the network disrupting service availability.
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 that 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 cyberincidents. So what are some of these options?
Set Yourself Up for Success With Proper Segmentation
Technology is a critical piece of the cybersecurity equation, but its benefits are limited 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 be 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 be done 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.
Advanced Segmentation and Access Control with App-ID, User-ID and Content-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. The great thing about the Palo Alto Networks platform is that it was designed from the ground up with this concept in mind.
Our App-ID, User-ID, and Content-ID technologies are at the heart of our 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. App-IDs not currently in our Applipedia database can be built by users on-box as custom App-IDs. Alternatively, users can request Palo Alto Networks to create widely available App-IDs that would then become part of our Applipedia repository.
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. Finally, Content-ID is what is used 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.
Let’s take an example of how App-ID and User-ID may be 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 that 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, the Palo Alto Networks appliance uses 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 3rd party vendor that needs to access your network to service their products that do not use OPC. To limit the risk of the 3rd 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 3rd 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.
Block Known Threats
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, which is at the heart of our Threat Prevention service. 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.
As far as our ability to block Havex, you can see from John Harrison’s recent blog that users of Palo Alto Networks are protected from threats associated with Havex with mitigations for AV, Spyware/CNC, and URL/Domain. John also gives best practices for leveraging the full threat prevention capabilities of our platform.
Detect Zero Day Attacks and Quickly Convert Them to Known Threats
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. Our Wildfire service isolates suspicious payloads entering your network, detonates them in a virtual sandbox environment, and determines if payloads are benign or malicious in nature. Subscribers to the Wildfire service get protections against malicious payloads in as little as 30 minutes. Wildfire is available as a public cloud based service or as an on-premise, private cloud version called the WF-500.
As far as Wildfire’s ability to detect Havex as a zero day, John Harrison’s earlier blog also discusses how Wildfire has seen various samples of Havex with successful determination of the samples as being malicious.
Building a Better Bear Trap with Endpoint Security
Palo Alto Networks recently acquired startup Cyvera, whose innovative endpoint protection technology changes the game in terms of client protection against advanced threats. The way the technology works is rather than 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.
We look forward to the General Availability of our endpoint security products later this year. Customers on our platform will have true end-to-end security, which spans the network all the way to SCADA endpoints such as HMIs, SCADA/MES/EMS servers, workstations and PLCs.
The Palo Alto Networks platform provides tremendous capabilities in securing ICS and SCADA networks from advanced threats like Havex. Furthermore, it has the flexibility to adapt and be just as effective in securing networks as these threats inevitably evolve.
Learn more on how Palo Alto Networks secures ICS & SCADA
Related Malware Resources
Threat Research
Threat Actor Groups
Get updates from Unit 42