As information technology (IT) migrates to hybrid environments, which include both on-premises and cloud services, traditional perimeter-based security is becoming outdated. Zero trust (ZT) principles are part of an organization’s toolbox for mitigating some of the new risks to its IT environment.

In operational technology (OT) environments, implementing ZT architecture is especially hard. The often-unique nature of OT assets, coupled with their specific requirements for operational safety and reliability, don’t easily mesh with ZT principles for security. Many critical infrastructure organizations depend on OT assets to monitor and control industrial processes. Though most industrial control systems (ICS) are on premises, more and more of the IT systems they interact with are not.

In this blog post, we introduce a few fundamental ZT and ICS concepts, discuss barriers to implementing ZT principles in ICS environments, and propose potential methods to leverage ZT concepts within this domain.

A ZT Refresher

The spread of mobile devices and remote work has greatly increased consumer and organizational use of cloud-based storage and software-as-a-service (SaaS). Businesses are adopting SaaS solutions, such as customer relations management and collaboration tools, to improve business operations and reduce management costs. Other cloud solutions, such as infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS), are enabling organizations to more efficiently build and deploy infrastructure that supports business goals at a global scale. While these services facilitate critical business processes, they also introduce new potential risks, which a ZT architecture is intended to mitigate.

A 2021 blog post by our colleague Geoff Sanders describes the origin of ZT at Forrester and delves into the National Institute of Standards and Technology’s (NIST) Zero Trust Architecture. There has been a lot written about ZT, with more coming every day. Although we’ve included a sampling of related U.S. government mandates and guidance published just in the last year or so at the end of this post, here is a summary of ZT’s most basic concepts:

• Assume the bad actors are already in. You can’t afford to assume everyone and everything inside the perimeter is trustworthy.
• Data is the new perimeter.
• Don’t inherently trust; verify.

ZT represents a shift from perimeter-based defenses to a security architecture that does not implicitly trust all subjects. This shift may seem daunting, but many aspects of ZT are already being incorporated into current defenses and security measures.

Industrial Control Systems

Critical infrastructure operators are responsible for providing vital services, such as electricity generation, water treatment, and manufacturing. These services rely on a mix of IT and OT assets. For example, an electric utility may have a supervisory control and data acquisition (SCADA) system that uses supervisory computers to communicate with field assets and control electricity distribution.

While ICS organizations might transition some business functions to cloud-based services, industrial processes, such as water treatment or electricity generation, are unlikely to follow this path. Advances in hardware virtualization give organizations increased flexibility in how they deploy the assets that manage and control industrial processes, but some core components cannot be virtualized.

Operational Technology Versus Information Technology Assets

OT assets include specialized equipment, such as programmable logic controllers (PLCs). PLCs receive input from physical sensors and transmit output signals to devices, such as valves, that adjust industrial processes. PLCs often communicate with higher level supervisory systems through unique communication protocols.

Critical infrastructure organizations often prioritize availability and safety over other requirements, such as confidentiality. Many OT devices and components therefore have a low tolerance for communication interruptions. Organizations commonly segregate OT assets on a separate network to ensure that communication among them is not affected by other enterprise network traffic. This architecture led to ICS communication protocols that often lack common IT security measures, such as authentication and encryption. Current communication protocols used in industrial environments, such as the Inter-Control Center Communications Protocol (ICCP), enable OT assets to communicate via TCP/IP and potentially communicate with traditional IT assets.

Not only are IT environments frequently needed to configure and manage OT devices, but they are also where key data must be collected, normalized, processed, and reported on so the organization can effectively manage their OT assets. This ability to bridge enterprise and industrial networks fulfills a business need. As more IT assets migrate to cloud-based environments, however, OT assets are now exposed to cybersecurity challenges that previously did not exist.

Zero Trust Challenges in OT

ZT principles are important, and ICS is really important. What are some of the challenges of putting them together? Below are some thoughts on how to begin addressing the three principles of zero trust.

Assume the Bad Actors Are Already In

Once an organization accepts this premise, it needs to prioritize next steps on how to address it. Decisions should be based on risk. For example, has the likelihood and the impact of successful malicious activities on our ICS networks been objectively considered, and have the appropriate steps been taken to protect and sustain the operation of the assets that compose those ICS networks? Taking those steps may be made much harder in ICS environments that require continuous, 24x7 operation or rely upon dated, but purpose-built equipment. Issues can include

• an inability to easily upgrade
• uncommon technical platforms that stymie the implementation of robust cybersecurity measures
• a loss of organizational knowledge about longstanding, but easily ignored or forgotten equipment

Data Is the New Perimeter

One way of thinking about this concept is to say that every device that stores or processes data should ideally be a policy enforcement point (PEP). Even if other cybersecurity measures are compromised, the device itself challenges each transaction. Stated another way, the device does not trust the transaction simply because it’s happening inside a network perimeter.

Of course, not all devices are capable of being a PEP, which is of particular concern in ICS environments where OT assets with specific functionality may not be able to support this capability. Many don’t have the processing overhead or the technical capability. They simply wait for or provide an instruction and trust all traffic as safe. The data being transmitted may be simple instructions to control an industrial process, as opposed to a document or email message that would be transmitted on the IT network. This type of data is very different from data typically transmitted on IT networks, where fine-grained access controls may limit access to a document based on user attributes (e.g., geographic location of the user, data classification, user role).

Another valuable defense is encryption of data, both at rest and in transit. Data exfiltrated from a compromised device would be useless without the appropriate key. OT devices were not historically designed with security in mind, however, so the concept of data at rest might have been considered design overhead. Data-in-transit encryption protects data on the wire versus on storage devices. Organizations facing encryption challenges might consider layering a third-party encryption solution into the existing environment, though this practice could disrupt availability and performance due to its processing overhead. A reduction in availability and performance would likely be unacceptable in many industrial environments because it could negatively affect the safety of an industrial process.

Don’t Inherently Trust: Verify

Many OT devices have been around for a long time and were designed for single-user operation. Allowing multiple users might require shared account authentication, which precludes the important cybersecurity concepts of nonrepudiation and least privilege. Shared accounts are in some ways the antithesis of zero trust.

Extending Zero Trust Principles into ICS

ICS organizations often have strong business justifications, as well as safety and reliability requirements, for operating older equipment and implementing devices from a wide variety of vendors. The same can be true in IT environments, but the stakes are different. Upgrading an OT asset could have a negative cascading effect if a group of OT assets uses a unique communication protocol. These requirements present a significant challenge in architecting a solution that meets ZT tenets around securing communications between devices and enforcing fine-grained access control.

How to Get Started

While technical barriers may limit the feasibility of implementing some controls from the ZT toolbox, creative thinking can help organizations extend ZT principles even into sensitive industrial environments.

• Depending on the current architecture of the ICS network, it may be necessary to accept that the industrial network is one large implicit trust zone. Where feasible, network segmentation can reduce this trust zone into more manageable pieces.
• Take a hard look at the industrial network and ensure that all interconnections are identified and managed. For example, did a vendor install a cellular modem for maintenance that is providing an unknown back door?
• Restrict interconnections to a limited number of assets that can initiate a remote session from the enterprise network and are mediated by a jump host that itself has robust monitoring.
• Implement logical access restrictions to enforce least privilege by limiting the users that can establish remote connections to only those necessary to meet operational requirements. For example, the organization may grant remote access privileges to engineers who perform maintenance tasks using a remote desktop client.
• Implement stronger authentication, such as multifactor authentication or a privileged access-management system, to provide additional assurance for the assets that are permitted to establish remote access sessions.
• Implement unidirectional gateways for information leaving the industrial network, such as process data being replicated to a database.
• Consider physical access controls that may provide a satisfactory, risk-informed, compensating level of control and monitoring for those who have physical access to OT devices.

Though these controls might not constitute a fully mature ZT implementation, as described by guidance like the CISA Zero Trust Maturity Model, they would increase the trust in communications between the two networks. This approach would limit the communications that are permitted to cross the ICS environment’s trust boundary to assets that have strong authentication and can be accessed only by individuals with an operational need. Organizations should also keep core security principles in mind when defining access requirements, such as separation of duties and least privilege.

Building a Comprehensive View

Another core tenet for supporting a ZT architecture is the implementation of comprehensive monitoring. Aggregating logs from as many assets as possible using a security information and event management (SIEM) solution will help organizations build a more complete view of the network and host activity.

Though SIEM solutions are used in both the IT and OT worlds, the cultural and organizational divides between them may present some challenges to monitoring and analysis activities. If an organization has two SIEMs being monitoring by two separate teams, important insights and early warnings may be lost. Ideally, the aggregated logs cover both enterprise and industrial assets. Just as importantly, there is a collaborative approach to reviewing and responding to SIEM alerts. This approach could present a great opportunity for experts from both domains to learn from each other and support the organization.

Not Just a Technology Issue

A recent Ponemon Institute study found that most surveyed organizations lack a unified strategy and sufficient collaboration between IT and OT teams. Though the skill sets of these teams have some overlap, they specialize in unique technologies, and their activities focus on different requirements.

As stated previously, most ICS environments were not originally based on traditional IT systems. They commonly include custom, vendor-specific hardware, software, and communication protocols and, unlike IT, prioritize availability over confidentiality and integrity. Finally, ICS environments are often managed through an organization’s operations chain, whereas IT is traditionally a back-office function. Likewise, ICS environments are often managed by a vice president of engineering or operations, with IT managed by the CIO. This cultural divide increases risk because the underlying platforms for these environments are converging and the need for bidirectional communications between them is growing.

A ZT architecture implemented by the CIO may not comprehensively cover the organization. A true enterprise-wide implementation of ZT would require the unique perspective and input of OT professionals to understand barriers to adopting ZT in an ICS environment.

Here are some questions an organization’s IT and OT management can ask as they consider a ZT implementation:

• To what extent is the operations function permitting bidirectional connectivity from ICS networks, and how is that access configured?
• Can IT management articulate the business justification for direct and continuous access into ICS environments in lieu of a DMZ?
• To what extent is the organization moving toward a model where a single program is accountable for the overall cybersecurity of both IT and OT assets to promote more holistic cybersecurity oversight?

Starting Down Your ZT Path

Technology implementation alone does not solve the problem. Organizations must put in the hard “people” work (policies, processes, roles and responsibilities, etc.) for a ZT implementation to achieve its goals. Before doing so, however, organizations should gain a thorough understanding of ZT and consider how these principles may apply to their operations. Just as importantly, they should have a clear understanding of their critical services and the assets that underlie them. This insight greatly helps in prioritizing ZT implementation. The following are issues to consider when starting down your ZT path:

1. Familiarize yourself with ZT concepts and definitions and how they apply in your current cybersecurity context.
2. Understand how much ZT you may already have in place via existing controls and other measures.
3. Understand what you must do (i.e., executive orders if a federal civilian agency) and what you should do (over and above laws and regulations, based on your organization’s risk appetite).
4. Establish a plan for what you need to do to close the gap between items 2 and 3 above.

While industrial operations present challenges to implementing ZT, remaining flexible and building a relationship between different operational units will help organizations build creative and effective solutions.