July 2022, Vol. 249, No. 7
Features
Securing Pipeline Flow Measurement and Metering
Tim Manning, Product Manager, Flow And Remote Monitoring, Bedrock
Maintaining safe, reliable and profitable pipeline operations requires a high degree of trust. This is especially true for remote users who must have faith that the conditions are safe and that the person or device requesting the operation has authorization to do so.
Traditionally, the pipeline industry has relied on standard engineering practices such as safety assessments, design reviews and field tests to maintain safe and reliable remote operations.
As such, the industry has become adept at validating flow measurement through an intricate process of audited reviews, but several converging factors are pointing to the need for a new approach.
Increasing demands for data collection and analysis and the growing need for remote operations management are driving the need for greater digitalization of automation and measurement systems; however, existing systems tend to rely on private or pseudo-private communication infrastructures, which are expensive to maintain and increasingly harder to secure.
Plus, as operational requirements call for adding more and more devices to the infrastructure, legacy systems are not designed to scale the orders of magnitude higher throughput volumes that those new devices will generate. The result is increasing vulnerability, data bottlenecks and stymied innovation.
Tradition of Trust
Remote automation and measurement telemetry has relied mostly on private or pseudo-private networks. From direct current (DC) loops and pulse duration meters to the advent of modems on leased or private telephone networks, to user-owned and operated radio networks, the network has been mostly private and assumed trustworthy.
If you let only good guys on the network, everyone reasoned, nothing bad could happen. And if someone did get on the network, everyone just assumed that they must be trustworthy and that the signals they sent were exactly what they had intended to send.
Additionally, most control systems communicated using proprietary protocols, or they used obscure industry-specific protocols that were deemed safe based on their relative invisibility. And, because the device could communicate using the same protocol as everything else on the network, everyone trusted it.
Finally, the controllers supported only serial or proprietary communication buses, which limited device connections to supervisory control and data acquisition (SCADA) connections or local connections only. Because of restricted physical access to the sites, people trusted local connections implicitly.
When industrial control system (ICS) manufacturers started adding Ethernet connections to the controllers, the controllers could connect to a local area network (LAN) or wide area network (WAN), but the connections were still implemented as private networks, for example, using private radio networks or public infrastructures that extended the local network security approach via the use of virtual private networks (VPNs) or other means. The networks were becoming more vulnerable, but the industry continued to operate using a trusted network mindset.
Erosion of Trust
As networks continued to expand, ICS vendors continued to expect that the industrial controller would be deployed on a trusted network and relied on the end-user to implement the external firewalls, intrusion detection and other bolt-on devices to protect the control system from cyber-threats.
Figure 1 shows a traditional measurement architecture. Flow computers receive pressure and temperature data from field sensors and share it with RTUs (remote terminal units) and PLCs (programmable logic controllers) over a private or pseudo-private network.
Field devices communicate with the SCADA system over legacy protocols, which provide little, if any, security, and connections between the flow computers, PLCs, and radios are also unsecured, often leaving one or both ends open to unauthorized access.
Likewise, connections to local human machine interfaces (HMIs) or operator tools typically use very weak security, at best a username and password, and users seldomly update them.
This amounts to virtually no security at all, which becomes an emerging problem because pipeline and oilfield operators implement industrial internet of things (IIoT) strategies to reduce costs and improve productivity, or they just want to incorporate the internet as part of their traditional SCADA infrastructure.
Trust No One
The trust-everything-on-the-network-strategy is out of date. Rather than the control system implicitly trusting all connections, the best approach for today’s open networks is a never-trust-anything/verify-everything mindset. This is what the National Institute for Standards and Technology (NIST), among others, calls a Zero Trust architecture. NIST identifies the following characteristics of a Zero Trust architecture.
- The entire enterprise private network is not considered an implicit trust zone. Assets should always act as if an attacker is present on the enterprise network, and communication should be done in the most secure manner available.
- Devices on the network may not be owned or configurable by the enterprise. Visitors and/or contracted services may include non-enterprise-owned assets that need network access to perform their role.
- No resource is inherently trusted. Every asset must have its security posture evaluated via a positive expiratory pressure (PEP) before a request is granted to an enterprise-owned resource.
- Not all enterprise resources are on enterprise-owned infrastructure. Resources include remote enterprise subjects as well as cloud services.
- Remote enterprise subjects and assets cannot fully trust their local network connection. Remote subjects should assume that the local (i.e., non-enterprise-owned) network is hostile.
- Assets and workflows moving between enterprise and non-enterprise infrastructure should have a consistent security policy and posture. Assets and workloads should retain their security posture when moving to or from enterprise-owned infrastructure.
Incorporating Zero Trust cybersecurity into pipeline measurement operations requires a streamlined architecture and military-grade authentication and encryption, which are easier and less expensive to deploy than it might sound.
Simplifying the Architecture
Traditional control and measurement architectures are just too complicated and costly to implement in a Zero Trust paradigm. Running everything on an integrated internet/cloud-based architecture promises the most cost-effective solution for simplifying the architecture, given the almost infinite bandwidth, pervasiveness of the internet and availability of inexpensive and scalable cloud service providers.
But many may question the wisdom of putting a strategic industrial controller on the internet, saying things like, “After all, isn’t the internet where bad things happen – where viruses and hackers live? Wouldn’t it be better to put your controls on a nice, clean, isolated network?”
IIoT and cloud-based architecture, however, are securable thanks to advances in interoperability software and cybersecurity access control. Figure 2 shows a streamlined IIoT-ready architecture that can provide a foundation for a Zero Trust cybersecurity strategy. In such an architecture, designers replace private or pseudo-private communications with open communications protocols such as message queuing telemetry transport (MQTT) and OPC Unified Architecture (UA).
Through these approaches, devices that want to communicate with PLCs, flow computers, measurement applications, SCADA stations or other elements send a message to an MQTT server, which, in turn, routes it to the appropriate devices and applications such as flow measurement applications via an encrypted channel. The MQTT server can reside on premises, the internet or the cloud.
Rather than having to secure the multiple channels (Figure 1), we get the brokered, secure, point-to-point exchange (Figure 2).
To help secure both ends of the encrypted channel, open protocols such as MQTT and OPC UA support mutual authentication, using public key infrastructure (PKI) and certificates, which can be created by the user or, ideally, a trusted third-party certificate authority.
The certificate authority maintains a key management system that automatically generates the digital keys that any person or device seeking to communicate across encrypted channels must present and coordinates pairing of devices and keys. The PKI authorizes users and trusted participants in the network for defined roles and privileges. PKI mechanisms enable all members of the trust web to recognize other members and exclude imposters automatically.
To the Core
While PKIs controlling access to encrypted channels provide more security than traditional networks, the best way to implement Zero Trust is to use controllers that have the PKI participation algorithms embedded into their electronics at birth.
When automation controllers are responsible for their own security, the system is no longer solely dependent on an external network of firewalls, intrusion detection devices or other bolted-on devices to determine which incoming signals to allow in. While elite hackers can bypass firewalls, breaking intrinsic PKI-protected cryptography is not a practical possibility.
It presents the hacker with a whole new set of barriers along multiple signal paths. The controller essentially has an immune system.
The architecture in Figure 3 is based on a controller that has had unique digital keys embedded at the factory where it was built. Any user or device that wants to access that controller must present the secret key that the certificate authority has generated previously, via the PKI key management software.
This enables the controller to know, for example, that the actor is an engineer who is authorized to change the user program or an operator who has permission to change a set point. If the actor has the proper PKI credentials, the controller allows the action; otherwise, the controller automatically blocks it.
Reliable Measurement
When combined with higher bandwidth made possible by modern industrial control systems, implementing inherently secure controls opens an entirely new realm of possibility for trusted flow measurement.
Now, instead of running flow calculations on a flow computer that is independent of the controller and thus presenting another path that must be secured, today’s powerful hardware makes it possible to embed all that software functionality at the factory, under protection of the PKI.
Conclusion
Designing and deploying systems designed for a Zero Trust network is a good first step, even if there are no immediate plans to start moving systems from a private network.
It is possible to use intrinsically secure controllers as proxies to transition unsecure legacy measurement systems to integrated, cybersecure systems without significant downtime. Because the security is built in, there are no requirements to install external equipment to secure those controllers, which makes for a scalable solution with lower costs.
Whether the goal is to implement an IIoT strategy or just to add depth to their cyber-defenses, users should understand the concepts of a Zero Trust architecture and select equipment that deploy easily in these networks.
Comments