This post is a second in series that describes hunting, discusses best practices and explains our approach and lessons. Because hunting in industrial infrastructure is important to all of us and with focus and effort we can accomplish it. Part 1
The network architectures and operational requirements associated with industrial requirements vary from traditional corporate networks. However, that doesn’t mean the lessons learned from the wider threat hunting community should be abandoned. In this post of the Dragos Threat Hunting on ICS network series, we look at how the unique characteristics of industrial networks can be used to an advantage as network defense professionals.
The Purdue Model
The Purdue Model is a five-level architectural summary developed in the 1990s by Dr. Theodore Williams from Purdue University. When referring to the Purdue Model, the standard level numbers assigned are level four for the business logistics systems level, level three for the manufacturing operations systems level (sometimes referred to as the supervisory level), level two for the control systems level, level one for intelligence devices level and level zero for physical process. When hunting on traditional IT networks, one of the key approaches a threat hunter will take is to break the network down into manageable chunks by what a given zone does. The Purdue Model provides an abstraction to help ICS threat hunters divide a network by industrial function. We will now look at each of the Purdue levels and the types of potential hunts that can be done within each level starting from the business logistics systems and transiting down to the physical process level.
Level Four: Business Logistics Systems
Level four of the Purdue Model is typically controlled by the IT staff and often refers to the overall corporate network. The protocols and systems encountered at this level mirror corporate networks found in typical large corporations. Because of this vendor makeup and the types of services users consume, hunting at the business planning and logistics level uses the same strategies as corporate networks. Attackers are likely to be successful on this level of the Purdue model with tools and techniques found in traditional malware variations. Attackers that don’t already have access to their target are likely to use traditional intrusion techniques like spear phishing and exploitation of corporate networks to gain an initial foothold into the target networks. This initial intrusion probably won’t result in immediate access to control systems but does serve as the first hop into the targeted organization’s network. Once on the corporate network, attackers focused on causing an impact to an industrial site’s operations will begin to search for valuable intellectual property both for blackmail purposes and to assist in the planning of future attacks.
Level Three: Manufacturing Operations Systems
Level three of the Purdue Model contains manufacturing operations systems for coordinating industrial site operations. Depending on the organization, this level might be handled by the IT staff or the OT staff. The major difference between level three and level four comes with the removal of many network services handled on the corporate level. Email is an example of one protocol found on level four that wouldn’t be found in level three. The types of systems and protocols found on level three are going to be like level four, making traditional IT threat hunting approaches very applicable. Attackers won’t likely be able to spear phish or exploit their way into level three from outside the targeted organization’s network. Ideally, level three services should only serve users and devices on levels two and four. Hunting at level three should focus on building behavioral baselines for protocols and systems and understanding what normal looks like on the network. This practice will answer the question of “what is happening” on your network and, more importantly, assist in helping you move to “why is this behavior happening.”
Level Two: Control Systems
Level two, also known as the control system level, is where the ICS specific hunting begins. Level two is managed by the operational technology (OT) staff as level two contains real-time controls, distributed control systems (DCS), human machine interfaces (HMI), and supervisory and data acquisition systems (SCADA). An organization’s policy of what software is permitted on level two becomes very restrictive because network and host disruptions at and below level two can negatively impact operations and potentially lead to serious injury in extreme situations. Unlike level three and four, where a threat hunter might be able to deploy a host-based agent or use traditional IT security tools, a threat hunter on level two might only get access to the passively tapped network and host data. At level two, each device serves a specific role on the network and should only be working with a subset of other hosts related to the task being performed. Context is again key at this level. Threat hunters working at level two need to develop a thorough understanding of the devices operating at level two and what resources these devices should be using.
Hunting at level two ideally consists of passive analysis of network and host data using traditional IT hunting tools to cover the traditional IT protocols present at this level and also OT hunting tools that can properly break down and analyze industrial protocols and host logs. One good thing to note about many of the HMI, DCS and SCADA systems at this level is that they still do run traditional operating systems, so many of the same host and network artifacts present in traditional IT networks are generated by hosts on this network. However, thorough threat hunting should include both IT and OT tools as the presence of traditional operating systems means attackers can still use IT malware at this level. Threat hunters should also be looking for devices acting outside their typical role from the protocol inspection perspective of what control system impacting actions is a device causing on the network. In the case of the 2016 Ukraine energy attacks, the CRASHOVERRIDE IEC 104 payload ran on windows and only sent one type of IEC 104 message. If your substation just sends one type of IEC 104 message, this analytic would be useful. However, it is more likely that you would quickly notice a drop in IEC 104 traffic types if you were performing deep packet inspection of industrial protocols. This analytic should be automated, and threat hunt efforts would continue to refine protocol analysis efforts to catch attackers modifying control system protocol traffic.
Level One/Zero: Intelligent Devices and Physical Process
Level one contains the intelligent devices commonly referred to as programmable logic controllers (PLCs) while level zero is almost entirely physical devices for instrumentation or actuation. PLCs can sense different aspects of a given environment and, with the help of control systems on level two, make changes to a process at an industrial site. Level one devices generally won’t be running Windows but instead will likely be running an embedded operating system. Level one devices often receive network updates during maintenance windows and sometimes even have exposed web interfaces. The benefit to threat hunters is that a very limited quantity and type of traffic should occur at level one. There shouldn’t be much variety of either at this level. If an attacker does pivot through the network to the point where they can push firmware to a PLC, this is the level where threat hunters would be able to see the originating IP addresses of who attempted to push the firmware update.
Hunting Between Levels
We’ve now gone through each of the levels but missed an important advantage of taking a Purdue model approach to ICS threat hunting: Activity within levels is valuable, but activity between levels can provide a potentially even more valuable area to look for attackers in a network. When performing a threat hunt, ICS threat hunters should examine the trust between Purdue model levels. One question you might ask is “how is the Windows domain separated between levels four, three, and two?” If you find that trust for a domain controller on a higher number level extends across a Purdue model level and Windows Remote Desktop Protocol (RDP) is permitted across the firewall between the level, an attacker might use stolen credentials and the inter-level trust to pivot through levels of security. Limiting the flow of protocols and hunting for abuse of protocols allowed between Purdue Model levels is a must for a threat hunt to be comprehensive. This was illustrated with the eternalBlue/Wannacry/NotPetya SMB vulnerability and the common reliance of SMB to traverse levels for various historian platforms.
Showing an attack of a field device in isolation is academic. Field devices do have vulnerabilities and have been shown to be easily exploited by an attacker. That said, a well-defended network will still provide threat hunters with a variety of opportunities to discover attackers while the attackers carry out the various steps of the IT and OT kill chain process. By understanding the levels of defense and monitoring between the internet accessible corporate network down to the field devices of the Purdue model, defenders significantly raise the level of effort and resources attackers must commit to intrusion efforts. A mature hunting program should focus on identifying potential areas attackers might take advantage of and apply defenses that improve visibility and increase the level of effort and resources attackers must expend to be successful. This is one of the key lessons of the ICS Cyber Security Kill Chain.
Wrapping Everything Up
Understanding how to apply the Purdue Model is a good start, but only represents the abstraction of an industrial network. In later weeks, we will dive down more into hunts. Now that we’ve talked about a basic framework to apply hunting to an industrial network, in the next part of the series we will discuss how to successfully plan a hunt. If you have any questions or topic suggestions, feel free to reach out to me on twitter, LinkedIn or via email at email@example.com.