Software Defined Perimeter’s deny-all approach protects IoT devices

 In 2016, a massive distributed denial of service (DDoS) attack left much of the internet inaccessible on the U.S. east coast. The attack, which authorities initially feared was the work of a hostile nation-state, was in fact the work of the Mirai botnet.

Mirai took advantage of insecure IoT devices and amassed a botnet army that can still be used today to infect IoT devices (most of which are still unprotected) and launch DDoS attacks against their enemies, or selling that power to the highest bidder.

Most of the adopted protocols in the IoT were designed for wireless sensor networks (WSNs) but have suddenly become the core of IoT solutions. For example, the Message Queuing Telemetry Transport (MQTT) protocol is adapted to secure and blacken the application-specific purpose end devices in the IoT.

In fact, the MQTT  protocol lacks the interoperability and minimal authentication features as it was designed for isolated WSNs without the security of Internet connectivity in mind. Specifically, the protocol enables a two-way handshake that is susceptible to denial of service (DoS), man-in-the-middle (MITM) among others.

What is required to protect IoT devices is that both mutual authentication and encryption are required to prevent DDoS and other types of attacks. To demonstrate these controls, based upon Waverley Lab’s Open Source Software Defined Perimeter (SDP), a university team analyzed the performance of SDP in conjunction with the Message Queuing Telemetry Transport (MQTT) as a replacement to traditional login methods with a Single-Packet Authorization (SPA) process.

The team led by professors, Ahmed Refaey of Manhattan College and Abdallah Shami of Western University, detailed findings and conclusions in a new paper titled, “On IoT applications: a proposed SDP Framework for MQTT.” The experiment modeled the situation where a Denial of Service (DoS) attack was used by flooding the MQTT servers with TCP packets.

A typical IoT network is comprised of publishers of data and subscribers who consume the data as shown in the figure below.

Because the broker is responsible for managing the messages transmitted between subscribers and publishers, SDP modules were embedded into the MQTT network nodes to follow a strict authentication protocol. For the experiment, the message rate was set to 1 message per second per publisher at a payload of 30 bytes.

To evaluate the performance of SDP,  three metrics were used to measure the broker servers performance with and without it in the event of a DoS attack to determine Connection Setup Time, Network Throughput, and CPU usage.

Figure 3 (in the paper) below shows the results of the three minute (240 second) experiment. You’ll notice at the 60 second mark, the broker without the SDP-MQTT platform begins to spike up to 120% of CPU usage. The broker with the SDP-MQTT platform controls CPU usage to under 40% usage.

As business owners and IT leaders discuss issues related to MQTT security and privacy for IoT and machine-to-machine communications, it is imperative to provide integrated mutual authentication and encryption controls. Embedding SDP into the MQTT network nodes also renders IoT devices invisible while proving effective in slowing down DoS attacks and as a deterrent to others. To read the detailed findings in the paper, click here to download it.

The industry is starting to embrace innovative new tools for network security– specifically SDP technologies—that address all layers of network stacks in their security solution. Waverley Labs’ approach to modularize its SDP offering to implement ALL the deployment models in the enterprise is first of its kind. Using single packet authorization (SPA) techniques combined with a deny-all gateway to hide the infrastructure within the perimeter, providing a separate control and data channel to secure end-to-end connections and an internet-scale packet-filter to drop all unauthorized connections separates Waverley’s approach from existing SDP and zero-trust implementations. To learn more about engineering digital risk protection using SDP, check out this white paper.

###