Today we are announcing support for Azure IoT Edge, which is Microsoft's solution for edge computing suitable for IoT gateways. Project Iris now brings visibility and threat detection to the Azure IoT Edge platform and connected edge devices managed by it.
Azure IoT Edge Architecture
Azure IoT Edge extends Microsoft's cloud-based Azure IoT Hub architecture to the edge.
Azure IoT Hub provides a bidirectional communication channel between devices and the cloud, enabling users to perform tasks such as configuration, data collection, and command execution from the cloud. With just Azure IoT Hub in the picture (and prior to Azure IoT Edge), IoT devices would be required to implement the Azure IoT SDK to directly communicate with Azure IoT Hub in the cloud. The supported protocols between an IoT device and Azure IoT Hub are MQTT, AMQP, and HTTPS.
Azure IoT Edge opens up the picture, allowing IoT devices not using the Azure IoT SDK to be brought into the fold. These devices make up the vast number of existing IoT devices out there, and they use an alphabet soup of IoT protocols such as modbus, BACnet, and OPC-UA. Azure IoT Edge proxies communication between these devices and the cloud. This model is especially helpful from a security perspective.
Going into more depth, this post describes three different patterns for how Azure IoT Edge can used at the gateway:
- Transparent gateway: Device identities are managed by the Azure IoT Hub, and devices integrate with the Azure IoT SDK. Devices use Azure IoT Edge as a proxy to Azure IoT Hub in the cloud. No protocol translation is needed since devices are already using the Azure IoT SDK.
- Identity translation: Device identities are managed by the Azure IoT Hub, but devices don't integrate with the Azure SDK. Azure IoT Edge (or other software like EdgeX) performs protocol translation and communicates on behalf of these devices with the cloud.
- Protocol translation: Azure IoT Hub doesn't know anything about device identities (they are managed elsewhere). Azure IoT Edge performs protocol translation and exchanges device data with the cloud. Other software on the cloud side needs to make sense of the device data to do something meaningful with it.
In addition to protocol translation, Azure IoT Edge allows for general purpose computing at the edge. For instance, running analytics at the edge can save on overall IoT solution costs, compared to shipping all the data to the cloud for processing.
Project Iris and Azure IoT Edge
To use Project Iris to monitor Azure IoT Edge, deploy the Project Iris Docker container side by side with Azure IoT Edge running on the same IoT gateway host.
Azure IoT Edge uses modules to achieve a general purpose edge computing framework. Modules are simply Docker containers. There are two special modules provided by Microsoft, edgeAgent and edgeHub. The edgeAgent module uses the Docker service to manage other modules, and the edgeHub module handles communication between other modules and the cloud. Other modules, such as the Microsoft-provided modbus module, can perform protocol translation, edge analytics, or other activities.
The Project Iris container passively monitors all Azure IoT Edge modules and their communication with other edge devices, and passes up data to the Project Iris cloud service. Based on the data gathered, the Project Iris cloud service dynamically builds out profiles of expected behavior for Azure IoT Edge modules and edge devices tailored to your deployment. Alerts are triggered when significant deviations or anomalies from expected behavior are detected.
Project Iris Runtime Arguments
The Project Iris container should be deployed with the following environment variables as container arguments:
- AZURE_IOT_HUB_CONNECTION_STRING: This is used by the Iris container to gather metadata about Azure-managed edge devices and Azure IoT Edge deployments.
- AZURE_EVENT_HUB_CONNECTION_STRING: (optional) Azure IoT hub can be configured to stream diagnostics to an Azure Event Hub. Diagnostics can include useful security related events such as unauthorized device access. Set this environment variable to let Project Iris capture and surface these events.
Device identities can be managed in Azure or elsewhere. Project Iris is intelligent about surfacing these identities, depending on the type of architectural pattern under which Azure IoT Edge is deployed at the gateway (see above).
In the "Transparent gateway" pattern, device identities are fully managed in Azure, and Project Iris gets all device related metadata from Azure. This metadata includes arbitrary tags and configuration properties that can be set in the cloud.
In the "Identity translation" pattern, device identities are managed in Azure and in another piece of software such as EdgeX. Project Iris gathers identity data from both Azure and EdgeX and merges the data together, creating a unified view of identities across both sources.
In the "Protocol translation" pattern, identities are managed outside of Azure. However Project Iris can infer device identities by inspecting Azure IoT Edge module configuration. For instance, the modbus module contains configuration describing how that module can connect to downstream modbus slaves. Project Iris manufactures device identities based off this configuration.
In the future, as Project Iris continues to support more IoT gateway platforms, it will continue to merge device data together from disparate stores in a intelligent way to surface up a meaningful set of identities.
Project Iris raises alerts when Azure IoT Edge modules running on the gateway or connected edge devices exhibit behavior that deviates significantly from an established norm. The usage of containers by the Azure IoT Edge runtime permits the development of precise behaviorlal models for describing Azure IoT Edge modules. The types of alerts covered by Project Iris include initial infection, lateral movement, command and control, data exfiltration, and denial of service. These alerts are described in more detail in this blog post.
Below are some hypothetical alerts focused on the edgeHub module. This module has perhaps the most surface area for attack as it exposes several ports for access outside the gateway host.
This alert shows the edgeHub module making an unexpected outbound network connection, for instance in the case of an initial infection to download an exploit payload or reaching out to a command and control host.
Suppose malicious code injected into the edgeHub module attempts to move laterally by probing the network. Project Iris can pick this up - in the example below the edgeHub module is shown reaching out to a modbus device. This is unusual as the edgeHub module by design doesn't directly communicate with any IoT devices.
Now suppose the edgeHub module unexpectedly crashed or was unexpectedly killed:
If configured to integrate with Azure Event Hub, Project Iris can pull in diagnostic events raised by the Azure IoT Hub. Project Iris filters these events to raise interesting security-relevant events. For instance, below is an example of unauthorized access by a device reporting to be a thermostat.
All alerts includes applicable device details gathered from Azure IoT Hub. For instance, the sample below shows configuration details and tags for the aforementioned thermostat:
Whether you're using Azure IoT Edge or other technologies at the edge, we want to hear from you! If you want to learn more about Project Iris, visit the Project Iris web site and click Notify Me. Fill out the contact form and we'll be in touch!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.