Posted on Leave a comment

Create an Azure IoT Security module Twin

What are these things and why do we need them?

The twinning concept is one of the cooler things to come about lately. Not only can you digitally twin IoT or IoT Edge devices, but you can also twin environments, and I’m sure eventually we’ll be twinning all sorts of things like industrial equipment, trains, planes, automobiles. Basically, anything that fog computing devices need to work with can be twinned, including the actual fog computing device.

To understand what a module twin is, we need to also understand what a device twin is and what purpose it serves in Azure’s IoT Hub.

Device Twins are basically json documents that represent a device. They store metadata, configuration information, conditions, and basically represent the state of that device.

One thing to note, this is only available in the Standard tier of IoT Hub (and Free), but not in Basic. That’s because Basic doesn’t provide for two way communication. Basic only allows IoT Hub to receive telemetry data. One way communication. Standard however will allow IoT Hub and the device to maintain two way communication. If you plan to practice building out more sophisticated IoT devices, especially the AIoT or Edge devices, you will need to use Standard tier.

A device twin has this structure:

  1. Tags
  2. Desired properties
  3. Reported properties

And you’ll use the device twins to do the following operations:

  1. Synchronize workflows between devices and the backend systems
  2. Store device specific meta-data in the cloud
  3. Report on state
  4. Query the device for metadata, state, or configuration

There’s recommendations on how that communication should transpire, but I won’t go into that in this post.

It’s just import to remember that device twins store device information that allows the device and the backend to synchronize configuration and conditions and that the solution back end can query long running operations.

Device Twins also have a lifecycle. This is linked to the device identity. Twins are created and deleted when a device identity is created or deleted in the IoT Hub.

The json document includes the following elements; tags, desired properties, reported properties, and device identity properties.

I won’t go into detail on these, but they can be used to manage various aspects of the device. There are also a number of back end operations like; retrieve device by twin id, partially update device twin, replace desired property, replace tags, and get notifications from the device – this is managed with a twinChangeEvent.

Operations that can be performed on a device are

  1. Retrieve device twin
  2. Partially update reported properties
  3. Observe desired properties

Devices preserve their desired properties when connecting to IoT hub if their device twin version is the same. However, if the version has incremented it will retrieve the full json document to get the desired properties.

How does this relate to module twins in the IoT Hub? What is a module twin?

When you create a device identity and IoT Hub creates a device twin, under that device twin you can create up to 50 module identities.

These represent a sub-section of the device. For instance, if I have a Raspberry Pi with a moisture detector, a light detector, and a temperature detector, I can make these all modules under the device identity I’ve assigned the Raspberry Pi.

Module twins are nearly identical in form and function as their parent device twin. I can also assign different security profiles to a module twin and grant access to it to different groups. This means that certain members of my team can see the moisture information, others can see the temperature, and yet another group could see the light information (probably no real reason to do this in the real world with this particular device, but the capability is there).

How do we create a azureiotsecurity module twin?

  1. You can actually create a module batch script that will automatically create module twins any time a new device twin is created.
  2. You can also manually create them.

To manually create a new azureiotsecurity module twin for a device use the following instructions:

  1. In your IoT Hub, locate and select the device you wish to create a security module twin for.
  2. Click on your device, and then on Add module identity.
  3. In the Module Identity Name field, enter azureiotsecurity.
  4. Click Save.

Boom! That’s all you need to do. When you review your existing modules for the device, you should find on there titled, azureiotsecurity.

Posted on 4 Comments

Azure IoT Custom Security Alerts

I love that IoT Hub makes it easy to add custom alerts. You can also manage these alerts for groups of devices, instead of attempting to create them one at a time. These alerts allow you to build specific rules for these groups of devices that best fit the use case of the device.

The following the recommended method for setting these up in the portal. I’m still searching for a way to do this with Azure CLI, but when I find it I’ll post an update.

Because you as the developer will know your devices best and understand what sort of alerts you need to create for your device parameters, Azure Security Center provides a way for you to develop device behavior policies and alerts.

What are security groups?

Security groups are a logical way to maintain devices by tags. You choose how those devices are categorized. It could be by hardware type, region, or whatever best fits your particular domain needs.

This is tagged in the device twin settings under the tags property of “SecurityGroup,” and comes with a value of “Default”

After creating a group, you can assign custom alerts.

How do you customize an alert?

  1. On your IoT Hub Security section, open the Settings
  2. Click custom alerts
  3. If you haven’t, create a device security group
  4. Click on the new security group
  5. Click Create custom alert rule
  6. Select a rule from the list

You can find a list of customizable security alerts here:

Customizable security alerts – Azure Security Center for IoT

Set your parameters for the rule.

For example, I selected the custom alert for “Login by a local user that isn’t allowed,” and added an email for paul@raspberrypitestdevice.com.

Save the new rule. Continue this process for each group and each rule.