ICS Network Segmentation

As ICS and SCADA hackers, why should we care about the Purdue Enterprise Reference Architecture (PERA)?

Let me try to explain it as simply as I can.

PERA is used as the industry standard for segmentation of industrial networks. It allows the collection of data from the (operational technology) OT environment to be monitored safely without exposing critical assets to possible accidental or malicious manipulation. 

Having a solid understanding of the PERA model will allow hackers to assess which parts of an industrial network are open to manipulation or intrusion. Knowing which kind of servers are running at each level will help craft a possible attack path, leading a hacker to the critical devices being monitored and controlled by the network. 

For example, a compromised remote access server could be allowing access to a workstation and historian server that is logging device data. It’s all located in the industrial DMZ and would be connected directly to the OT layer. That allows attackers access to critical SCADA that’s data needed to craft a more malicious attack!

It normally comprises four zones, comprising six layers in total.

Here, I will briefly detail the use of each zone.

---

Internet DMZ

Level 5

This is the public facing section of the PERA Model, here you will find the web and email servers.

This is most likely where an attack would start. Port scanning and enumeration of staff portals and so on here should be monitored. Because anyone gaining access to lower levels of the PERA, and using tools such as Nmap could potentially cause critical devices to fail!

---

Enterprise zone

Level 4

This is where corporate IT infrastructure and applications reside. Segregation between this level and the ICS environment is essential. The risks posed by allowing access to the ICS environment are extremely high and should be discouraged!

Services such as email, reporting, inventory management, operational and maintenance management, printing services and phone systems are located here and operated by the IT team.

---

DMZ industrial zone

Level 3.5

The DMZ (demilitarized zone) is a segregated sub-network that separates the Local Area Network( LAN) from the higher untrusted levels of the network. Normally anything connected directly to the internet that would pose a direct risk to operations further down the Purdue Model.

---

Industrial zone

Level 3

Level 3 is an interesting one, and is responsible for managing ICS operations. This level contains the industrial historian, engineering workstations, remote access services, file servers and the Active Directory, DNS (Domain Name Server) and the DHCP (Dynamic Host Configuration Protocol).

Systems on this level communicate directly with the lower OT levels of the network. Communication to the higher levels is achieved via the DMZ, and should never be able to communicate to the enterprise level directly.

---

OT zone

Level 2

Level 2 is an important layer. It includes the ICS Human Machine Interface (HMI), which is used in real time to monitor actions being undertaken by the plant controls. Engineering workstations live here, and are used to control the Programmable Logic Controllers (PLC), Remote Terminal Units (RTU) and Distributed Control Systems (DCS), each device having its own vendor-specific OS and vulnerabilities. 

Again, communication to the upper levels of the Purdue Model is achieved from this level via the DMZ, to provide secure remote access to engineers.

Level 1

Level 1 is where the control devices are. The PLC, RTU and DCS are all in this level, and would typically not be connected to any level higher than level 2. 

PLCs are sometimes connected directly to the internet, bypassing all levels of the Purdue Model. This is highly dangerous and should never happen, but sadly it’s all too common.

Level 0

This level features connected devices which include instruments critical to the operation of the plant. These devices are made up of solenoid valves, motors, sensors, and the like.

These devices are the "Golden Egg" in the majority of cyber attacks, and should be thought of as such when building your network segmentation. Creating an air gap between this level and internet connected devices is critical to protecting your devices from malicious manipulation.

---

Safety critical zone

This zone is mainly used for extremely critical infrastructure such as nuclear power stations. The Stuxnet worm was spread to this layer via human error and the use of unvetted removable storage devices. It’s not normally part of the Purdue Model found in 95% of installations.

Securing access

Here I will lay out a few things you should take into consideration to secure your ICS network from malicious intrusion.

This is normally achieved via firewalls in most networks. A DMZ has a firewall preventing access directly from the internet into a company's secure IT network. If you work in the cybersecurity field, bypassing WAFs (Wireless Access Firewalls) is a daily task. 

However, in an ICS environment, this just isn’t enough to protect layers from intrusion. An IDS with great packet filtering is also needed to filter out the malicious packets being sent into the network. All traffic passing through the IDS should be inspected vigorously. Inbound and outbound traffic through the VPN should always be treated suspiciously, especially outbound traffic. Threat actors are able to implant malicious scripts within PLCs that can be activated at any time to retrieve the data needed to craft a more advanced attack at a later date. 

Authenticated users accessing the VPN cannot always be trusted. An employee may have been the victim of an OSINT attack and could have their phone spoofed and password guessed as a result. Using 2FA is great, and I would recommend this as a basic security implementation for all employees accessing any level of your network. But it isn’t a perfect solution. Analyzing traffic sent from your OT network to remote users through your IDS is critical to understanding what is being sent and received to your devices. 

Using an encrypted VPN along with a token device that would produce a one-time password (OTP) or pin for remote login is perhaps the best way to ensure that the person you give access to is the person accessing your network. All data sent via remote access should always be encrypted. Never allow cleartext to be sent across your network, and always grant access via the DMZ.

ICS systems will typically generate a huge amount of events on an hourly basis. Anything that is suspicious should be sent to a central logging server for analysis by a SOC engineer. It’s critical that enough space is allocated in these servers to prevent data loss. Carefully monitor failed login attempts, and privilege escalation. A log server will contain sensitive information such as usernames from login attempts, IP addresses, time stamps and how access was granted or attempted, such as through SSH or FTP.

The current Purdue Model isn’t ideal for the kinds of attacks we are facing. Modification of the above model with extra security layers and safety zones is essential moving forward. Physical separation of devices from internet connected layers may become the norm in the future if things don’t improve in the cyber realm.

Further information relating to ICS and SCADA Access and vulnerabilities will be posted here in the future.

I hope you have found this basic introduction to the Purdue Model network segmentation interesting and informative.

 

Learn more on Hack The Box's blog

Barry "8balla" Murrell previously shared his ICS expertise in What you must know about ICS cyber attacks. Check it out!