Update: this is the classic solution of securing your Edge device. See also the new (agent-less or agent-based) version Azure Defender for IoT.
During the last Microsoft Build event this year, Microsoft announced support for IoT devices in their Azure Security Center.
This is a potentially interesting solution for checking all your IoT devices for security issues and a centralized way to react to these issues. There are both recommendations and imminent alerts to respond to:
It is advertised like this:
“Azure Security Center for IoT provides visibility into the security posture and state of your Azure IoT solution – from devices to applications”
This is a promising solution for the S of security in IoT (yes, there is no security in IoT 🙂 ).
Azure Security Center for IoT is currently in public preview but we can already try out its functionality.
ASC for IoT is presented in the Azure portal as being part of the IoT Hub. There’s a thirty days trial, I have not calculated the costs yet but you can try it out for yourself here.
There is a free tier but the standard tier is much more interesting. We will see that eg. the security event collection is very powerful:
In this blog, we check out How we can combine Azure Security Center for IoT with IoT Edge. This seems surprisingly easy.
For those who have no experience with Azure IoT Edge, please follow a tutorial like this one. IoT Edge is the ideal solution to connect local devices to the IoTHub. There are several reasons like protocol transformation or usage of local compute for making usage of IoT Edge.
But this means that your local Edge device is potentially vulnerable to security attacks. This is where Azure Security Center for IoT comes to the rescue.
Installation on the Edge
Once you have your IoT Edge running it’s easy to connect it to ACS.
On a Linux device:
1 your IoT edge runtime is configured and running
2 Install in Linux an extra Audit daemon:
sudo apt-get update sudo apt-get install auditd audispd-plugins
3 Verify in Linux this daemon is running ok:
sudo systemctl status auditd
This will show something like this:
The Linux Audit Daemon is a framework to allow auditing events on a Linux system.
4 Add this ‘mcr.microsoft.com/ascforiot/azureiotsecurity:0.0.3’ module named ‘azureiotsecurity’ (not clear why this name has to be set)
This module collects data from the ‘auditd’ daemon. And it puts the information in a certain JSON format on the IoT Edge route
5. check the create options and desired properties seen here
6 Add or update your routes so the messages from the ‘azureiotsecurity’ module are sent to the cloud (upstream)
{ "routes": "route": "FROM /messages/modules/azureiotsecurity/* INTO $upstream" } }
7 Replace the regular mcr.microsoft.com/azureiotedge-hub:1.0 with mcr.microsoft.com/ascforiot/edgehub:1.0.9-preview.
Note: This last step seems a bit odd. Why is the regular edgeHub module not good enough? I contacted Microsoft and they will merge the extra logic needed for this service in a future edgeHub. For now, we have to assume that the ‘ascforiot’ version supports the latest edgeHub version.
Note: There is an extra rule regarding the communication between IoT Edge device en cloud:
“Do not disable AMQP communication for the IoT Edge Hub. Azure Security Center for IoT module requires AMQP communication with the IoT Edge Hub.”
8 Optionally, you can test what happens locally. I can recommend this while testing ASC for IoT. So set the environment variable
logLevel=Debug
9 Also optionally, For my tests, I added my ‘echo’ module svelde/iot-edge-echo:1.0.0-amd64 to check the messages sent by the azureiotsecurity module:
{ "routes": "auditToEcho": "FROM /messages/modules/azureiotsecurity/* INTO BrokeredEndpoint(\"/modules/echo/inputs/input1\")", "route": "FROM /messages/modules/azureiotsecurity/* INTO $upstream" } }
Finally, the routing will look like this (flow diagram is generated here):
And once the IoT Edge device is updated, we see the modules running:
Although the cloud part of Azure Security Center for IoT is not touched yet, at this point, the edge part is already running. Messages are collected and sent to the cloud…
Messages collected by the module
If we look at the messages sent using the ‘echo’ module, we see that every two minutes a message is sent with a property ‘MessagePriority’-‘High’:
The message shows all sorts of settings on the device like firewall rules etc.
This is a large message, I measured it to be131Kb big. This is around forthy chunks every two minutes. With some 720 messages sent each day, this means in theory 28.800 chunks each day for one Edge device (out of 400.000 for one IoTHub unit).
Note: After a few days of testing, the IoTHub measured ~12.000 chuncks each day. This is half of what I calculated. It’s still a high number but security does not come for free…
Note: I calculate that I sent of 115MB of security messages each day so that makes 1 GB per week. If you are on 3G or 4G you have some extra costs there too. I hope the actual size is also split in half.
Now let’s look at what is happening in the Azure portal.
IoT Hub settings
At the IoT Hub something interesting is happening. The security messages are filtered out and do not appear to arrive at the hub. I tested this with an Azure Function and a separate heartbeat message.
Only the heartbeat message arrived at the Azure Function. The ASC messages were internally redirected to the Azure Security Center for IoT location.
What is this location?
Although Azure Security Center for IoT is hosted in the IoT Hub, A Log Analytics workspace must be available.
If you want to configure Azure Security Center for IoT, you need to create this workspace first. Workspaces do not come for free (I went for the GB per week version).
Note: At this moment, ASC for IoT is only available in three regions; Central US, Northern Europe, Southeast Asia:
So this is how you configure the security extension for IoT hub (this is step 10, the last step):
And then we wait. Some information can take hours before it is sent to the cloud.
This is the initial reporting part of the extension:
Not everything is filled in from the start. We really have to wait before we can drill down into the subreports with meaningful information.
If we are lucky we soon see something like this:
Yes, finally, we see some recommendations an even an alert.
We have a ‘most attacked’ device:
A brute force is not something we appreciate, so let’s take a closer look:
Yes, my Edge device is actually attacked due to my own stupidity 😉
To be clear, As an IoT edge device, I use a common VM in the Azure portal (you can find it in the Azure Market place). Microsoft provides a convenient Linux VM with the IoT Edge runtime preinstalled.
But I need an SSH connection to configure it afterward. So I deliberately opened an inbound port with a name/password security. This is not recommended in production or elsewhere. I was interested in what would happen.
Note: an inbound port is really not secure! Take a look at a more secure solution (in preview)!
Luckily, this potential security breach is now clear to everyone. Because after a few days, I see that I have fifteen alerts of brute force attacks:
Note: It seems that scanning port 22 is pretty popular amongst script kiddies…
I also create eight more devices which do not have an ASC agent defined. For some reason, this seems to be marked in red too.
And the list of recommendations also contains those which are not related to IoT. I also got recommendations regarding the usage of Azure Active directory in the Azure portal.
What now?
I can recommend to check out the various recommendations and alerts. See it as free education in security. You can even create alert rules to receive emails in case of an emergency.
Conclusion
So it pays off to dive into Azure Security Center for IoT. This is just one device which I have to harden against threats. Imagine the work to be done if you have hundreds of devices which are sometimes configured by hand.
The price to pay for this service is unclear. It’s hard to predict the costs upfront. But having security at scale protecting your devices is a powerful solution.
This is just an introduction and I am interested in what the future will bring once this service is not in preview anymore.
Sander van de Velde 