Organizations continue to embrace IoT solutions to enhance productivity and efficiency. With the rapid creation of new data — up to 2.5 quintillion bytes a day — safeguarding data exchanged between devices is critical.
Common security vulnerabilities such as inadequate authentication and authorization of IoT devices, insufficient encryption, etc., have highlighted the need to instill fundamental security principles in IoT deployments. In this blog, we will explore how to enhance the security of IoT deployments while using MQTT, the de facto protocol for IoT, and HiveMQ’s Enterprise Security Extension (ESE).
Data Security FAQs for IoT Deployments Using MQTT
Imagine a wearable technology company offering remote healthcare monitoring services leveraging IoT technology. Such an organization constantly requires a solution to monitor patients' vital signs and securely send data to healthcare professionals. Even a small breach in security, such as an unauthorized device gaining access to the IoT deployment because of insufficient authorization controls, could result in malicious actors obtaining sensitive customer health and activity data.
Following essential security practices and also using secure solutions and infrastructure is critical for IoT deployments. Security is a shared responsibility amongst the MQTT ecosystem. In a blog titled "Mitigate IoT Attacks with Key MQTT Security Principles," we emphasized the importance of MQTT users following specific security principles and using solutions to secure their MQTT devices and IoT communications. Similar to how public cloud users share responsibility in securing the infrastructure, MQTT users must take necessary steps to ensure their devices are secure and protected from potential attacks.
There are numerous data security challenges in IoT deployments, and our customers and prospects commonly pose the following questions related to the challenges that follow:
Do my MQTT-based IoT deployments have proper authentication and authorization controls to secure the deployment sufficiently? Inadequate authentication and authorization of IoT devices
How can I safeguard my complete IoT setup from unauthorized access by malicious actors while using different protocols like MQTT, Modbus, Kafka, etc.? No fine-grained access control
When using an MQTT broker, how can I guarantee sufficient encryption for the data transmitted between IoT devices and backend systems? Insufficient encryption
How can I effectively handle and ensure the security of access credentials for each IoT device? No device identity management
How can I actively observe and identify inadequate logging and monitoring in real time? Inadequate logging and monitoring
You can uncover the best practices to combat these challenges in our latest white paper, Enhancing Data Security in IoT Deployments.
The HiveMQ Enterprise Security Extension (ESE) for Data Security in IoT Deployments
In mission-critical IoT and M2M scenarios, ensuring secure end-to-end encrypted communication and implementing advanced authentication and authorization features is crucial. HiveMQ leverages and builds upon the security of MQTT with the following security architecture.
The HiveMQ Enterprise Security Extension (ESE) takes security up another notch, allowing organizations to authenticate and authorize MQTT clients using various data sources. Taking the example of the wearable technology company mentioned earlier, ESE enables the definition of domains to partition the server into protected areas. How does it do this? The HiveMQ ESE helps to process incoming client connections in highly configurable pipelines — offering customizable stages to handle the authentication and authorization of all IoT devices (a.k.a MQTT clients).
With the HiveMQ 4.16 platform release, the HiveMQ ESE offers several features that help address data security issues in IoT deployments. The following features can enable better authentication and authorization of IoT devices.
Hyper-Advanced Authentication and Authorization
The HiveMQ ESE supports advanced file-based authentication for MQTT clients and HiveMQ Control Center users. Combined with the already existing file-based authorization, this allows the possibility to configure full standalone pipelines without the burden of external dependencies like an SQL Database or an OAuth provider. In addition, the ESE also offers file-based authentication and authorization for the REST API.
Authentication and Authorization Preprocessors
The ESE provides authentication and authorization preprocessors that help you customize authentication and authorization via data pipelines. For those unaware, preprocessors are lightweight pipeline steps that work with the current state of the ESE variables and have no external dependencies. Creating and setting custom values makes fulfilling a wide range of use cases easier. Examples of preprocessors include actions like “Set,” “Copy,” “Regex,” and more.
Preprocessors help solve challenges like enabling external authentication and authorization by facilitating integration with external authentication and authorization systems. They also facilitate deploying custom security policies by allowing administrators to configure security parameters based on their specific requirements. Finally, preprocessors enable granular access control by allowing administrators to define particular domains and partition the MQTT server into protected areas with controlled access.
Support for OpenID Connect
The HiveMQ Enterprise Security Extension supports OpenID Connect authentication. OpenID Connect (OIDC) is an open authentication protocol and supports enterprise-wide single sign-on (SSO) capabilities with your preferred OIDC provider, such as Auth0.
Certificate Revocation Check
The Enterprise Security Extension allows you to configure OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) client certificate revocation checking during the TLS handshake for secure TCP listeners and secure WebSocket listeners.
Now, you can configure one or more revocation checks of your choice in the ESE configuration and reference TLS listener configurations in the broker. When a client/device connects to the HiveMQ broker, certificates are checked against a list of revoked certificates. If the client certificate has been revoked, the connection is refused.
IoT deployments that use certificates to secure client-to-broker communication sometimes must revoke an existing client certificate before its natural expiration date. Revocation can be achieved with a certificate revocation list (CRL) or the online certificate status protocol (OCSP).
In both cases, the client/device certificates are checked against a provided list of revoked certificates. The connection attempt is denied if the client/device certificate has been revoked.
This process can increase the security for use cases such as connected car applications where being able to centrally manage access control for vehicles can be a safety and compliance concern.
Extracting More Fields from X.509 Certificates
If your MQTT deployment relies on X.509 certificates, the latest feature in HiveMQ Enterprise Security Extension (ESE) introduces a powerful capability to extract and utilize specific fields from these certificates. This enhancement opens the door to implementing more sophisticated security use cases, particularly in the realm of user authentication and authorization.
The X.509 preprocessor in HiveMQ ESE is designed to facilitate the authentication and authorization of MQTT clients based on information retrieved from their X.509 certificates. This means you can harness the X.509 preprocessor to extract values from designated fields within the client's X.509 certificate and transfer these values to an ESE variable.
Example Scenario: Wearable Technology Device Authentication
To illustrate this feature, consider a scenario involving a wearable technology company deploying MQTT for its network-connected devices. Imagine a new wearable device seeking to establish a connection to the network, employing X.509 certificates for security.
In this scenario, HiveMQ ESE becomes instrumental.
The wearable technology company can use the X.509 preprocessor to selectively extract crucial values from specific fields in the X.509 certificate of the wearable device. These values can then be copied to ESE variables.
Significance in Authentication
When the wearable device attempts to connect to the network, the extracted values from its X.509 certificate are utilized for authentication purposes. The wearable technology company can define authentication rules based on these values, enabling a secure and controlled onboarding process. For instance, the wearable device can be authenticated and granted network access only if certain conditions derived from its X.509 certificate are met.
This feature streamlines the authentication process and provides enhanced control over authorizing or disallowing network connections. By leveraging specific fields from X.509 certificates, organizations can enforce fine-grained security policies tailored to the unique requirements of their IoT deployments.
Proxy Protocol with TLS
MQTT version 3.0 does not provide any headers for metadata that would allow carrying the original client’s IP address to the MQTT broker if the original TCP connection is proxied by a load balancer. Using the PROXY protocol can be beneficial in deployments where MQTT clients connect to a load balancer or proxy instead of directly to the broker. The PROXY protocol is a TCP-based protocol that allows transporting client details, such as the source IP address and port, over multiple proxies.
This feature helps address the problem of insufficient encryption because using Proxy protocol with TLS helps establish end-to-end encryption between load balancers and the MQTT broker with complete visibility of client IPs.
In the growing world of IoT, it's crucial to stay vigilant about security to prevent cyber-attacks. Following basic security principles helps strengthen MQTT deployments layer by layer, reducing the risk of IoT threats. As we move forward with innovations for connected devices, prioritizing security ensures a safer and more resilient IoT environment.
Developing a deeper understanding of common data security challenges in IoT deployments is essential now. Our white paper, Enhancing Data Security in IoT Deployments, discusses IoT data security challenges and methods you can adopt to enhance IoT deployment security posture.
The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.