Introduction to ICS Security Part 2

The Purdue Model and Best Practices for Secure ICS Architectures

In Part One of this series, we reviewed the unique lineage of industrial control systems (ICS) and introduced some of the challenges in securing ICS. In Part Two, we will introduce readers to the Purdue Enterprise Reference Architecture (PERA), additional reference models and publications dedicated to ICS cybersecurity, and architectural and administrative best practices for securing these crucially important systems.

Recap: The Challenges of ICS Cybersecurity

In our overview of the “inherently insecure” nature of ICS, we identified the challenge of securing these systems with their high availability requirements and lack of intrinsic security features. Before operators and security practitioners wrestled with these challenges in Operational Technology (OT) environments, Information Technology (IT) administrators faced similar challenges. Administrators of first-generation IT networks addressed the challenge of security first at the perimeter, implementing the first firewall devices to segment their trusted local area network from untrusted wide area networks (and later, the Internet).

Securing ICS requires us to do the same thing: create a defensible environment. In this case, however, the IT/business network component of the organization represents the same untrusted zone to ICS/OT as the Internet represents to the IT network. Once again, segmentation is required, but along what lines? The Purdue Enterprise Reference Architecture helps answer that question.

Introduction to the Purdue Enterprise Reference Architecture

Created in the early 1990s at Purdue University, the goal of the Purdue Model was to define best practices for the relationship between industrial control systems and business networks (or to use the interchangeable terms, between OT and IT). In its first iteration, there were three components:

• Purdue Enterprise Reference Architecture
• Purdue Reference Model
• Purdue Implementation Procedures Manual

Over time, the model grew to include guidance for physical systems architecture and introduced the six network levels of the environment, depicting the systems and technologies that reside at each level:

Generally speaking, as you move down the hierarchy (from Level 5 to Level 0), devices have more access to critical processes but fewer intrinsic security capabilities. Devices at lower levels are therefore more reliant on network and architectural defenses, and those found in the upper levels, to protect them.

At this point, it’s important to note that PERA was never intended to be a cybersecurity reference model. It was conceived to depict best practices for managing the segmentation between the enterprise and industrial segments of networks in industrial sectors. Nevertheless, it has remained prevalent as a conceptual framework in IT/OT security because it shows where security measures can be added.

A key aspect of PERA is the boundary point between the ICS/OT systems represented at Levels 0-3 and the IT systems of the enterprise network at Levels 4 and 5. Historically, the way administrators protected the ICS systems was by minimizing, or even eliminating, any interconnects between the two environments. Subsequently, the boundary between OT and IT was often referred to as the “air gap” for architectures in which no interconnect existed between the two. As demands for more data from the OT side have increased, administrators have had to connect these two levels through firewalls that carefully control access with demilitarized zones (DMZs). The firewalls mediate all communication between IT and OT, with the goal of eliminating direct communication between the two environments.

Debating Purdue's Role in ICS Cybersecurity

A popular saying in cybersecurity circles is: “all models are wrong, but some are useful.” This certainly applies to the Purdue Model, which undoubtedly has limitations when considering how technology has evolved since the 1990s, prompting business goals and risk tolerances to change as well. As discussed in Part One of this series, technological advances and cost efficiencies have motivated organizations to pull more data from their ICS systems (residing in Levels 0-3 of PERA). For example, remote connections into ICS can lower both operator labour costs and response times. Additionally, information from ICS enables key business functions such as trending, optimization, and billing, helping to drive efficiencies but at the same time increasing ICS exposure to attack.

Some critics contend that PERA envisions the control system network as being separate from everything else, and that the increased demands for real-time OT data and the incorporation of cloud-based systems and services dispels the notion of a completely closed-off system with a rigid hierarchy. An excellent discussion on this topic took place at the 2019 S4 conference featuring Joel Langill and Brad Hegrat, viewable here. The topic of the discussion was “Is the Purdue Model Dead,” and Mr. Hegrat took the position that the Purdue model is essentially dead because “convergence killed it¹.” On the other side of the debate, Mr. Langill acknowledged that while “the architecture, from a network perspective, is probably dead,” the model was among the first to show “how these pieces are supposed to be layered and interoperate,” and “if we lose sight of that, we’re going to lose sight of why we created hierarchy in the first place².” Langill contended that while the model was never conceived as a security reference architecture, it nonetheless incorporates some risk ideas that help security practitioners understand how information flows organizationally and thereby helps identify and address potential attack vectors.

While the presumed “air gap” between IT and OT (between Levels 3 and 4 of the hierarchy) rarely applies to present-day architectures, the core components of industrial environments have not changed; they still include equipment with sensors and actuators connected to controllers that relay their data up a chain of systems in the organization. Additionally, while the advent of Cloud technologies may blur the lines geographically, the Purdue Model always segmented networks by function, which can still be applied to OT/IT environments with significant Cloud integration.

Both sides of the debate make valid points, but the consensus at the SANS Institute is that PERA remains a useful conceptual framework because it was among the first to classify control system components according to a well-defined taxonomy. Even if its hierarchical layers can no longer be uniformly applied to modern architectures, sorting ICS and IT devices and systems into distinct functional layers helps administrators and security practitioners determine where to apply security measures effectively.

The SANS ICS410 Reference Model

Expanding on the Purdue Model and some of the ICS cybersecurity frameworks that we will discuss in the next section, SANS created the ICS410 Reference Model for ICS410: ICS/SCADA Security Essentials. The ICS410 model is a publicly available, foundational reference architecture that adds explicit enforcement boundaries to the Purdue Model, helping to situate ICS devices and cybersecurity controls in a secure network architecture.

In general, the ICS410 Reference Model offers the following advantages:

• Introduces the concept of multiple cells/lines/processes in templated fashion and scaled across multiple sites.
  • This helps extend the Purdue Model to different ICS applications, from large site (e.g., plant, mine, manufacturing), to regional/distributed networks (e.g., electric, oil/gas, water).
• Includes controls encompassing Wide Area Network (WAN) communication
• Includes safety systems

The ICS Reference Model also offers more details on the enforcement boundaries between network segments by:

• Subdividing some of the Purdue Levels (for example, Level 3 is divided into sub-segments for management servers, HMIs, engineering workstations, testing/staging systems, cybersecurity operations, remote access, and more)
• Defining multiple DMZs and requiring all connections between IT and OT to terminate in a DMZ (i.e., push one way, pull the other).
  • The Purdue Model does not include DMZs, even though they are commonly used in practice.
• Introducing minor enforcement boundaries between Levels 2 and 3 that protect:
  • Level 2 devices in different cells/lines/processes from each other.
  • Level 2 devices and below from a malicious actor who has made it past the upper-level controls and into the OT environment.
  • Level 3 systems from malicious actors leveraging physical access at lower levels.
• Making enforcement boundaries explicit, which create natural choke points where additional security controls can be applied.

Finally, the ICS410 Reference Model offers clear guidance for securing remote access, a critical capability.

As with other frameworks and reference models, the ICS410 Reference Model will require updates to accommodate the new devices and communication paths necessitated by increasing cloud connectivity and additional IIoT devices in ICS networks.

Review of ICS Cybersecurity Standards

If PERA laid the foundation for ICS cybersecurity with effective taxonomy and classification, then a series of other frameworks and publications have built upon that foundation with guidance specifically geared toward securing industrial control systems. Examples include:

• NIST Cybersecurity Framework (CSF)
• NIST 800-82 (Guide to Industrial Control Systems Security)
• ISA 99.02.01/IEC 62443: Security for Industrial Automation and Control Systems

Along with industry specific guidance in:

• North American Electric Reliability Corporation's Critical Infrastructure Protection (NERC CIP)
• Transport Security Administration (TSA) Pipeline Security Guidelines
• Cybersecurity & Infrastructure Security Agency (CISA) Critical Infrastructure Sectors Guidance

Published by the National Institute of Standards and Technology (NIST), the NIST CSF is central to much of the U.S. government’s guidance for critical infrastructure protection. This is evinced in the NIST CSF’s formal title: “Framework for Improving Critical Infrastructure Cybersecurity.” Similarly, the TSA provides guidance for pipeline operators using categories aligned to the CSF³.

The influence of the Purdue model on these guidelines and publications is evident in how they all promote effective segmentation and segregation of systems in the industrial network environment and require security controls at the boundaries between them. NIST 800-82, for example, articulates this concept as follows:

When designing a network architecture for an ICS deployment, it is usually recommended to separate the ICS network from the corporate network. The nature of network traffic on these two networks is different: Internet access, FTP, e-mail, and remote access will typically be permitted on the corporate network but should not be allowed on the ICS network. Rigorous change control procedures for network equipment, configuration, and software changes may not be in place on the corporate network. If ICS network traffic is carried on the corporate network, it could be intercepted or be subjected to a DoS attack. By having separate networks, security and performance problems on the corporate network should not be able to affect the ICS network⁴.

The standards cited here all share many core concepts including:

• Asset management and classification, including definition of critical assets and their roles in the framework.
• Building and maintaining a security program including risk assessment and management.
• Secure network and system architecture principles, emphasizing segregation.
• Incident response.
• Identity, access management, authentication, and authorization.
• Data and information protection.
• Secure configuration, vulnerability management, and patching.
• Security event monitoring.
• Practical application of controls.

In our final section, we will expand on some of these concepts and examine how to convert these guiding tenets into specific administrative tasks.

Applying the Principles: Best Practices for Modern ICS Cybersecurity Architectures

As we discussed in Part One of this series, it can be difficult to secure ICS networks for many reasons including the need for continuous and deterministic operations, interoperability in multi-vendor environments, the variety and age of devices, and their lack of intrinsic security capabilities. As a result of these constraints, the best opportunity to secure ICS environments is with strong architectural defenses which start at the network layer and feature prominently in the guidance provided by the standards and frameworks mentioned above.

A strong network architecture improves ICS security and provides a foundation on which additional security measures can be implemented over time. The Purdue Model, NIST SP800-82, IEC 62443, and the SANS ICS410 Reference Model all place a heavy emphasis on network segmentation and the control of communication between segments.

Just as perimeter firewalls are universally deployed to protect enterprise environments from internet-based attacks, ICS environments should have protection at their many enforcement boundaries. Although industrial processes are at lower levels in the Purdue Model, the most sensitive data and points of control are typically at Level 3, which is also where most attackers first access the ICS network from the business network.

Fundamentally, ICS systems should use dedicated infrastructure that is completely independent of the business network. With effective segmentation in place, a firewall between Levels 3 and 4 can control network communication into and out of the ICS network. This firewall should block all communication in and out of the ICS network and explicitly permit only the minimum required communication.

Attacks can also originate from remote sites, especially in widely distributed environments. For this reason, a secondary enforcement boundary should be configured between Levels 2 and 3 to protect management systems from attacks from the field, and to protect individual field sites from each other. These enforcement boundaries are often implemented using router access-lists to avoid having critical process communication pass through firewalls that could impede legitimate communication.

There are many different types of systems required for full functionality of an ICS network including operator workstations, HMIs, engineering workstations, management servers, database servers, historians, alarm servers, and many other specialized systems. Each system has a well-defined role and requires specific network access to other systems. Therefore, each level should be further segmented into multiple networks where systems with common roles can reside with an enforcement boundary controlling their communication with the rest of the network.

Multiple DMZs, each with a dedicated purpose, should be created to facilitate communication between the ICS network and the business network. Remote access, cloud access, and Internet access can also be mediated through dedicated DMZs. The implementation and configuration of DMZs will be explored in more detail in a future blog post.

Not only do enforcement boundaries control the communication between different classes of systems, but they also serve as natural network “choke points” where network traffic can be monitored and saved for later analysis. The logs generated by firewalls, combined with raw packets captured from the network, are a rich source of information. Since ICS networks are relatively static, a baseline of “normal” communication can be created and then used to detect anomalies and threats.

A detailed break-down of a complete network architecture is beyond the scope of this blog, however there are several important best practices to follow:

• The Internet should not be accessible below Level 4.
• Operations staff may have a separate, dedicated business computer for access to services such as email, Internet, and printing.
• Active Directory (AD) can be implemented to help manage control networks, but any such AD deployment should be completely independent of the business AD. Domain Controllers and other AD servers should be placed in Level 3.
• Enforcement boundaries should be employed as shown in the ICS410 Reference Model.
• Firewalls should block all communication by default, permitting only the communication that is required.
• All access to the ICS network should require additional layers of authentication, including multi-factor authentication.
• A secure mechanism should be provided to transfer files in and out of the ICS network while checking them for malware.
• ICS systems should have dedicated infrastructure such as anti-virus and patching systems that are not dependent on the business network.
• All communication in and out of the control network should be monitored and logged.

As more and more vendors leverage cloud-based management systems, practitioners need to evolve their ICS architectures. Devices that must communicate with the Cloud should be placed in separate, dedicated zones that restrict their network access to only their cloud-based controllers and the on-premises systems that they must communicate with.

The guidance offered here presents only a fraction of ICS cybersecurity best practices. There are several controls beyond architecture standards for security practitioners to consider as well, and with new functionality demands and new technologies continuously entering the equation, the field of ICS cybersecurity will keep evolving. Nevertheless, the venerable Purdue Model has stood the test of time, offering ideas about risk and a common vocabulary that inform many of the publications and models gaining traction today.

As our series on ICS cybersecurity continues, we’ll delve deeper into specific security measures including best practices for implementing and configuring demilitarized zones at enforcement boundaries.

Glossary of Terms

Sources

¹ Peterson, Dale. Unsolicited Response Podcast: Is the Purdue Model Dead (S4 2019 Main Stage Panel Discussion). https://dale-peterson.com/2019/02/11/is-the-purdue-model-dead/. February 11, 2019.

² Peterson, Dale. Unsolicited Response Podcast: Is the Purdue Model Dead (S4 2019 Main Stage Panel Discussion). https://dale-peterson.com/2019/02/11/is-the-purdue-model-dead/. February 11, 2019.

³ As a result of the ransomware incident suffered by Colonial Pipeline, the TSA issued Security Directive Pipeline-2021-01 requiring pipeline owner/operators to assess their current practices against the guidelines, identify gaps and remediation measures, and report these to the TSA.

⁴ Stouffer, Keith; Falco, Joe; Scarfone, Karen; Special Publication 800-82: Guide to Industrial Control Systems (ICS) Security, National Institute of Standards and Technology (NIST), U.S. Department of Commerce, June 2011.

Introduction to ICS Security Series:

Read Part 1 here.

Read Part 3 here.

About Stephen Mathezer & ICS410

Check out Stephen's bio, ICS contributions, and upcoming ICS410 course teaches here.

Learn more about SANS ICS410: ICS/SCADA Security Essentials course here