IoT messaging protocol is big security risk

Popular IoT messaging protocol lacks encryption and sufficient device authentication security.

wifi iot

The insecure implementation of the MQTT (Message Queue Telemetry Transport) protocol, an Oasis standard for IoT communication, by many IoT product vendors is contributing to the high risk of IoT devices on enterprise and home networks.  Although TLS is recommended by the Cloud Security Alliance for secure communication with MQTT, most vendors appear to ignore transport security, making all communication open and available.  Further, authentication is often ignored.

MQTT defined 

MQTT is a lightweight protocol that connects a device to a server or other management system when messaging is required.  This makes it a good choice for networks where bandwidth use is tightly controlled.  However, the MQTT standard does not include encryption.  Vendors or businesses must add encryption as part of their solution.  In addition, while servers can authenticate devices, no mechanism exists in the Oasis standard to allow devices to authenticate servers.

The risk

A authentication issue, however, is the failure to implement any available device authentication.  An example of the risk was reported by Lucas Lundgren last year. Lundgren claimed he discovered around 60,000 IoT message brokers that allowed access without authentication (McAuley, 2017).  With the fast growth of IoT, we can assume that this number has significantly increased.  Lundgren demonstrated that he can quickly compromise hospital, prison, and satellite control systems because of insecure configuration of MQTT.

Some vendors do provide encryption for their MQTT solutions.  Also, third-party vendors provide solutions to which any IoT device can securely attach, making IoT proliferation much safer.  The problem is that owners and managers of most businesses, especially small and home businesses, don’t ask the right questions or have the budget for third-party security.

Meeting the challenges

So who is responsible for IoT security.  Ultimately, it is we security professionals who have to perform the necessary risk assessments and make the necessary controls adjustments.  But this is not a long-term solution given the use of IoT across businesses, homes, and organizations of all sizes… including those with no security teams.  I agree with the Department of Homeland Security principles (below) in its Strategic Principles for Securing the Internet of Things that it is everyone’s responsibility to meet IoT challenges:

1.     IoT developers to factor in security when a device, sensor, service, or any component of the IoT is being designed and developed

2.     IoT manufacturers to improve security for both consumer devices and vendor managed devices

3.     Service providers, that implement services through IoT devices, to consider the security of the functions offered by those IoT devices, as well as the underlying security of the infrastructure enabling these services

4.     Industrial and business-level consumers (including the federal government and critical infrastructure owners and operators) to serve as leaders in engaging manufacturers and service providers on the security of IoT devices [in other words demand security]


It would be nice to see these principles voluntarily followed, but that is unlikely to happen unless consumers and businesses demand it.  Microsoft and Adobe, for example, were largely pushed to more secure practices by consumers and bad public relations related to breaches.  I hope it doesn’t take several highly destructive events to get IoT developers, manufacturers, service providers, and users on board with IoT security.  Even if it happens in the near future, security professionals must fill the gap with education and analysis whenever IoT is included in a project. 

Copyright © 2017 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline