Zero Trust: The Rules Are Different for Manufacturing
Zero trust is a well-known term in cybersecurity. With its origins in information technology the primary focus and guidance was constructed on a set of principles that not long ago would have been difficult, if not impossible, to implement in an operational technology (OT) environment. But today cybersecurity leaders in the OT realm are adapting zero trust for the unique requirements for their environments, as well.
The history of zero trust goes back to the mid 1970s, to the principle of least privilege (POLP), which simply states that only the authority required to perform the specific function should be granted. In other words, every entity must be able to access only the information and resources that are necessary for its legitimate purpose. While this principle is implemented in the privilege rings of the application stack, the general principle of limiting access to authorized and validated resources directly applies to zero trust.
There are really only two primary goals of zero trust. First is to prevent unauthorized access to data, services and resources. Second is to make access as granular as possible by shrinking or eliminating explicit trust zones.
I can’t even count the number of articles on zero trust I’ve read, and it seems there is a differing opinion in each. I would love to give you the easy, five-step method to implementing zero trust in your environment, but methodologies are as numerous as the opinions of each author. Instead, I will explore some of the zero trust basics and how we might practically apply them to OT.
Considering the First Step
The question I get most often is where to start in securing your OT environment. The migration to a zero trust architecture needs to be thought of as a journey rather than wholesale replacement of infrastructure, which is neither cost-effective nor even plausible in most cases. The effort needs to be prioritized based on criticality and possible risk or exposure, prioritizing safety and efficiencies while implementing a proposed architecture. Focus on the individual workflows in the environments—for instance, you may find your initiative needs to be implemented one business process at a time.
The important thing is to start. Bad actors will pick the easiest targets to maximize their time as any rational business would do. If they run into resistance during recon, they may just pack it in and head for an easier target.
Adapting for OT
Let’s start with a look at the general tenets of IT Zero Trust where we find some basic guidance, at least in theory, for application in OT.
1. All data sources and compute services are resources.
2. No resource is trusted.
3. Any remote/external connection is hostile.
4. Assume the environment has already been compromised.
5. Network location is not an entitlement of trust. Our internal networks are not implicit trust zones.
6. Exchange of data is granted per individual session.
7. Access is assessed by a dynamic policy that continually evaluates the security posture of the asset.
8. Authentication and authorization are enforced before access is allowed.
9. Data collection requires gathering as much telemetry from the environment as possible.
How do we translate this to OT? We need to modify the solution into a hybrid approach. Some of the tenets listed don’t map or may not be possible in your environment.
Taking Stock
If we are going to define process architecture and apply security practices to achieve trust, the number one priority is to understand what’s out there. You will need a clear picture of all assets, resources, people and non-person entities (NPEs). This visibility will enable you to identify, categorize and assess your target environments or processes. You’ll need a systems or solution set to do active discovery and enumeration of assets across the target infrastructure.
Asset information will assist in not only identifying risk and vulnerabilities but also in providing a starting point to map the individual business process. You may choose to identify and rank processes across the organization for a global roadmap to zero trust. Consider tackling a low-impact process to create your workflows and implementation plans, then move through your priority list as determined by management objectives. Ideally, you want a solution continuously discovering, analyzing, monitoring and documenting all OT assets within the operational environment, then correlating any discovered risks to prioritize them based on their impact on operational and business continuity.
Applying Controls
Now that we have all this juicy data, let’s apply some controls based on our analysis and prioritization. Assuming you have perimeter hardening and detection, let’s focus on the internal OT network. Your primary consideration is to never let anything into the environment that has not been inspected. You will want to scan all inbound devices brought on site by personnel to stop insider threats, as well as to scan assets before onboarding to prevent supply-chain attacks.
Referring back to our primary tenet No. 2—no resource is trusted—we will want to enforce protection at several points within our network.Lock down assets and network communication through deploying trusts lists. Trust lists secure endpoints and networks alike by specifying what actions that assets, applications or users are trusted to do and blocking everything else. At the endpoint level, they can stop unauthorized applications from executing and ensure that only trust-listed users can make changes to configurations or data.
Network-Level Considerations
At the network level, trust lists can be deployed as your Policy Decision Point (PDP), enforcing asset communication privileges that are strictly limited to those necessary to carry out the asset’s function. They can also be based on common OT protocols, ensuring only approved commands can be sent at a network level. This prevents both malicious tampering and mis-operation. The same network devices should also enforce network segmentation groups, assigning vulnerable assets into operations-friendly safe zones. This can help prevent both attackers from moving laterally and malware from spreading across a flat network.
Another network consideration is shielding assets to secure vulnerabilities in legacy and other unpatched assets without interrupting their work. OT-native intrusion prevention systems (IPS’s) and firewalls that make this kind of asset-centric cyber defense possible have rule sets specifically designed to repel attacks without forcing endpoints to conduct an update, resulting in no system reboots and no production downtime.
It's a long road to protect your critical OT infrastructure, but a journey that must be taken to secure enterprise environments.
Jim Montgomery is Principal Solutions Architect with TXOne Networks, a global leader of OT zero-trust cybersecurity that works with manufacturers and critical infrastructure operators to develop practical, operations-friendly approaches to cyber defense.
