MQTT Enables IIoT Security Best Practices within the Purdue Model
As Industrial IoT has evolved over the past decade or two, the vision for secure data communications and the integration of enterprise and control systems has evolved at the same time. When the Purdue Model of Computer Integrated Manufacturing was published in 1990 as a reference for enterprise architecture and ISA 95 was developed a few years later for enterprise-control system integration, they did not originally prescribe security directly in the way we think of it today. They did not include a modern network or firewalls.
Since then both technology and use cases have changed drastically, with data demands growing exponentially and the types and quantity of enterprise systems demanding the data becoming more sophisticated. The Purdue Model and ISA 95 continue to frame industrial communication security requirements, leaving industrial companies trying to figure out how to satisfy modern use cases within the requirements.
This article will discuss MQTT security best practices and how MQTT and MQTT Sparkplug can meet the need to push data upstream to enable advanced and modern use cases while following the Purdue Model in a safe and secure way.
Security and the Purdue Model
The Purdue Model is a hierarchical model for manufacturing automation that defines what type of equipment goes where, what actions are supposed to happen at each level, and how machines and processes interact.
The Purdue Model is built as a stack and defines the following layers as shown in Figure 1. 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.
The Purdue Model ensures that OT systems are isolated from IT so they 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.
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.
Further reading: Industrial Robots Gone Rogue: Staying Ahead of Robot Cybersecurity Vulnerabilities
MQTT Security Features & Best Practices
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 MQTT Security practices will set the groundwork for implementing a secure MQTT infrastructure.
What an MQTT IIoT infrastructure includes
Before we discuss the details, let’s look at what an MQTT IIoT infrastructure typically includes as shown in Figure 2.
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.
What is Sparkplug?
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.
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.
As shown in Figure 3, 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.
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 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 the Purdue Model laws and requirements.
MQTT Principals to Mitigate IoT Cyberattack
In September 2016, the Mirai malware cyberattack shook the IoT world with a DDoS attack model that infected over 600,000 IoT devices. Such attacks on network-attached devices and IoT devices continue to increase exponentially. With the IDC predicting that there will be 41.6 billion connected IoT devices, generating 79.4 zettabytes (ZB) of data by 2025, the number of malware attacks we will need to protect against endure. That said, such IoT cyberattacks can be mitigated by adhering to key security principles – using secure technologies such as the MQTT protocol.
More about What’s best for IIoT: An integration hub or an MQTT broker?
IoT Cyberattack Vulnerabilities
At IoT conferences and events, discussions about IoT security are always a hot topic. These conversations confirm that the key factors behind IoT security vulnerabilities typically boil down to choosing the wrong technology or even simple oversight.
A 2018 IoT Security Foundation survey concluded that less than 10% of consumer IoT companies follow vulnerability disclosure guidelines. For a long time, companies in the IoT space have focused on reducing the time-to-market and overlooked implementing basic security principles. When users take advantage of all security features the protocol offers, the use of MQTT as the communication protocol is a secure technology. The key is to avoid falling prey to any of the commonplace oversights of security principles that we see all too often.
In the same way that public cloud users share the responsibility to secure the infrastructure from their end by adhering to specific security principles, MQTT users must adhere to key principles and best practices for securing their MQTT devices and communications.
Misconfigured and poorly configured MQTT clients are a primary cause of security and privacy issues in the IoT space. Without proper configuration and setup, the MQTT protocol allows anybody to subscribe to any topic. Theoretically, every MQTT client can subscribe to any MQTT server that is available on the Internet. It is us – the users – who share the responsibility to secure the communication channel with appropriate measures and comply with key security principles.
More about Preventing Malware Attacks with Network Security Monitoring Solutions
Read the full post from HiveMQ to learn about the key principles of MQTT security to reinforce IoT security.
The demand for data is only continuing to increase – most companies are now using several enterprise and cloud applications 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 opens security concerns.
About the Author
This article was written by Arlen Nipper. Arlen brings over 42 years of experience in the SCADA industry to Cirrus Link as President and CTO. He was one of the early architects of pervasive computing and the Internet of Things and co-invented MQTT, a publish-subscribe network protocol that has become the dominant messaging standard in IoT.