MQTT and the Purdue Model Work Together for IIoT Security

Although not written as a security model originally, the Purdue Model of Computer Integrated Manufacturing has provided guidance on how to protect OT systems since 1990. The Purdue Model was published as a reference for enterprise architecture that defines a hierarchy for what type of equipment goes where, what actions should happen at each level, and how machines and processes should interact.

Now, the demand for data from both OT teams and cloud and enterprise systems has grown exponentially, but the manufacturing industry is still tied closely to the Purdue Model. Let’s take a look at the security considerations required by the model and how MQTT can meet those needs to securely push data upstream and enable advanced IIoT use cases.

Security and the Purdue Model

The Purdue Model did not originally prescribe security directly in the way we think of it today – it did not include a modern network or firewalls – although the industry has certainly added those things into the model in practice. However, it separates manufacturing automation layers into a hierarchical stack (Figure 1) and keeps them isolated from each other to prevent any security breaches between Level 0 and Level 5 or anywhere in between. 

Level 0 is the physical process where the actual equipment resides – sensors, robots, etc.  Level 1 includes basic control such as PLCs and controllers. Level 2 is for area supervisory control such as HMIs or a SCADA system. Level 3 includes site operations, where centralized control and operator terminals reside and where OT systems report up to IT systems. Level 3 systems aggregate lower-level data that needs to be pushed up to higher-level business systems.

In between Layer 3 and 4 is the Industrial Demilitarized Zone, a buffer between the OT and IT zones that enforces security policies. Level 4 is for site business and logistics and includes all the IT systems that support the production process in a facility such as database servers, application servers, etc. At the very top is Level 5, which is the enterprise network of systems that sit at a corporate level, spans multiple facilities, and includes connection to the Internet.

Figure 1: The Purdue Model of Computer Integrated Manufacturing

The Purdue Model ensures that OT systems are isolated from IT so they cannot be accessed directly and do not receive non-production data that might cause issues or slow manufacturing processes. The model dictates the flow of data from the bottom-up. Data generated from the process on Level 0 can be collected, normalized, and pushed up through the layers, but layers above cannot talk to layers below.  The concept is a critical strategy for most OT operations today.

An Intermediate Layer between OT and IT

As technology has evolved, Levels 3 and 4 have naturally become the intermediate layers with both OT and IT components working together to aggregate OT data and push it up to IT systems. MQTT has emerged as the ideal and dominant IoT messaging protocol that fits within the Purdue Model and many manufacturers are choosing it as the path to push data upstream.  MQTT Sparkplug is an open specification that adds contextual information and a standard way to push data to clients securely within the model by allowing for read-only, ingest-only – without giving up control to the higher levels.

To understand how MQTT and related technologies fit into the Purdue Model, see Figure 2. Level 3 includes an IIoT gateway such as Ignition Edge. An MQTT server like Cirrus Link’s Chariot pushes the data upstream to Level 4 and again to Level 5.  Many systems can subscribe to an MQTT server to continuously fill the need for event-driven data for improved business decisions. As a result, MQTT has become a critical piece of the puzzle and security is essential to protect the OT from any attacks. 

Figure 2: A modern look at security within the Purdue Model with Ignition Edge on Level 3 and the Chariot MQTT server receiving data and pushing it upstream to Levels 4 and 5.

MQTT Security Features

MQTT is a publish/subscribe, extremely simple and lightweight messaging protocol.  MQTT is based squarely on top of TCP/IP so those standards are used for best-in-class security. Perhaps one of the most important overall security features of MQTT is it supports unlimited data consumers with only one port open. So MQTT can serve up the data with a remote-originated connection to any approved Level 4 or 5 system without opening itself up to security breaches. 

There are several specific security features that make MQTT the ideal method to move data through the layers of any IIoT implementation in respect to the Purdue Model and ISA 95. An IIoT application is only as secure as the weakest link in the infrastructure, but these best practices will set the groundwork for implementing a secure MQTT infrastructure.

Before we discuss the details, let’s look at what an MQTT IIoT infrastructure typically includes as shown in Figure 3.

MQTT Edge Clients: Remotely distributed devices and/or gateways in the plant or field connecting to the Level 0 process to gather data for control and/or ingest. 

MQTT Servers: Centralized servers that both the edge and enterprise client applications connect to, to send and receive process information.

MQTT Enterprise Clients: Centralized or remote applications that need to subscribe to the MQTT Servers to receive or send information in the IIoT infrastructure.

Figure 3: The MQTT IIoT infrastructure.

MQTT Sparkplug Security Features

As previously mentioned, the demand for data from enterprise, cloud and other applications has grown dramatically in recent years.  OT data traditionally consists of proprietary protocols and multiple data formats and is directly coupled to applications over isolated networks.  With the modern demands for data (big data, machine learning, etc.), this OT data needs to be served up to multiple subscribers securely without the consumer having any access to the layers below as defined by the Purdue Model. 

Sparkplug is an open-source software specification that facilitates serving OT data up to those applications via MQTT with contextualization so any subscriber can learn everything about the device and data immediately without compromising security.  Sparkplug defines a standard MQTT topic namespace, payload and session state management for the MQTT message, and decouples the data to enable a one-to-many approach for unlimited data consumers. Sparkplug makes tags 100% auto-discoverable and easy to consume and establishes a single source of truth at the edge.  Again, Sparkplug accomplishes all of these tasks without giving any other system access to the shop floor. So, multiple consumers can access the data without any security concerns.

As shown in Figure 4, Sparkplug pushes the contextualized data up from level 3 to what is commonly referred to as level 3.5, the DMZ zone, as a secure outbound connection. Then, layer 3.5 has self-awareness of what is happening at the edge, so if any changes or modifications are made at levels 2 and 3 – if tags change or new devices are added – the applications using the data are automatically subscribed to all of that information.

Figure 4: With MQTT Sparkplug, data can be pushed from level 3 to 3.5 to give applications a constant flow of the data they need

Once the data comes up to level 3.5, all or a subset of the data can be pushed up to the applications on level 4 or 5.  Now you have all of your business applications subscribing to the data from the levels below and it’s self-aware and all applications and environments are learning this data.  The data is pushed up without any of the layers above connecting to the layers below to meet all of the Purdue Model laws and requirements.

Secure MQTT Client Connectivity

Both the MQTT Edge and Enterprise Clients utilize the same security models. Each initiate an outbound connection over the TCP/IP network utilizing TLS with security certificate credentials from CA. TLS uses a set of public/private security certificates where the MQTT Clients must establish a connection to the MQTT Server which is authenticated by the CA.  This is the same level of security used in banking systems today and is considered a best practice.

To satisfy the unique network architectures in the industry and to satisfy the Purdue Model and ISA 95, MQTT Edge Clients have all inbound TCP Ports over the network disabled.  Disabling inbound ports provides a high level of security by preventing potential attackers on the internet or intranet from establishing a connection with edge devices or process equipment.

MQTT Servers Security

Data producers publish the data to an MQTT Server using Sparkplug B format, an open standard specification that provides the context data needed to define a tag value for use with OT, also providing data to IT, making it 100% self-discoverable and easy to consume.

The MQTT server enables those who have secure access to subscribe to the data. The OT application will subscribe to the data instead of polling for it in a bi-directional connection that is also used for control. If a new setpoint needs to be sent, the OT application will publish a command message to write the value to a PLC or device. 

The MQTT Servers provide the message delivery mechanism in the Enterprise Service Bus. The MQTT Servers must be 3.1.1 OASIS compliant such as the MQTT Distributor or Chariot MQTT Server supplied by Cirrus Link. For multiple MQTT Server redundancies and a higher number of connected clients, the Chariot MQTT Server is offered for on-premise or cloud-connected applications. 

MQTT Servers must be configured with the same TLS security as used by the MQTT Edge device. MQTT Servers utilize further security measures in the form of MQTT level username, password, and an Access Control List (ACL). The ACL limits which devices will be allowed to connect into the MQTT Server and only allows known devices to connect. The ACL also controls what topics a given username/password pair can publish and subscribe to, providing further security. 

The MQTT Servers should be set up in a DMZ and behind a firewall that only allows two inbound ports for connection: 8883 and 443. 

Conclusion

The demand for data is only getting bigger – most companies are now using several third-party applications and cloud solutions that require a constant stream of data.  They must set up the proper strategies to enable data flow for advanced use cases such as predictive maintenance and machine learning, and MQTT and Sparkplug provides the answer.

MQTT is an ideal fit because it pushes the data upstream while isolating systems and providing security at every step from client to server to data destination. Data is remote originated, outbound, and encrypted with TLS. Sparkplug adds the context information as the data moves upstream. Only approved clients can subscribe to specific data that can be read and ingest-only, and the data is self-discoverable if changes are pushed up as well. MQTT allows OT to share data with those applications without letting them come in and connect to their systems or do any remote management that exposes security concerns.

The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow

Featured Product

Handheld Printers and Industrial Printing Systems for Manufacturing Production Line

Print On Any Surface…Metals, Plastics/Composites and Glass. Handheld Printers and InLine Inkjet Printing Systems for Factory Automation, with PLC Control. Inkjet Coding and Marking Printers can be used for direct coding of parts or industrial products and compliance marking on Primary or Secondary Packaging. Small or Large Character Inkjet Coding & Marking with Barcodes and Logo Graphics printing. Integration with Handheld Barcode Readers (Scan and Print) for Track and Trace and Database connectivity printing of variables data. Motion Control Traverser Printing Automation. Top Brands: EBS HandJet 260, EBS250 HandJet, Sojet V1H Handheld Printer, Reiner JetStamp 790MP and RN Mark 7 Printing System.