Skip to main content

IOT security made easy with Azure IOT Suite

There has been quite a lot of talk about security concerns as it relates to IOT devices and security. Businesses want to make sure that they are not opening themselves up to a ton of risk as they expand their data streams and to increase productivity. Thankfully Azure IOT suite makes securely connecting your IOT devices to the cloud quick and easy.

Before we get too far, its important to explain exactly what IOT security means:

IOT Security

In its simplest form, IOT security is broken down into zones and trust boundaries. Typically the zones are defined as follows:

  • Devices – IOT devices that capture and send data
  • Field Gateway – Devices that can aggregate data to and from devices
  • Cloud Gateways – Endpoint that receives / sends data and commands to Field Gateways or directly do devices
  • Services – The services that “do work” on the data that is received from the IOT devices (via the gateways)
Trust boundaries are where data moves between zones. During this movement across boundaries the data can be subject to Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of privilege commonly called STRIDE. For more information about STRIDE, visit this link). Its important to make sure that your IOT devices and data are secure across all zones and trust boundaries.

IOT Security in Azure

The best way to make sure that your application is secure is by leveraging threat modeling during the design / implementation phase. This forces the design of the application to take security into consideration instead of adding it on at the very end. Just like all of its other products, Microsoft leveraged threat modeling for the Azure IOT components.

I want to go through how Azure handles security across the various trust boundaries.

Device to Field Gateway

IOT Devices and Field gateways are very similar and usually connect in much the same way. Typically the security risks from a device to Field gateway perspective are physical / hardware related. This means its important to keep your IOT devices secure physically from harm and intrusions. While harm can be done while transmitting data to / from them, typically its more physical than digital.

Device / Field Gateway to Cloud Gateway

In Azure IOT, the Cloud gateway is called the IOT Hub. The IOT hub uses time sensitive security tokens to authenticate devices and services to avoid sending keys over the wire. Although this sounds complex, the Azure IOT SK’s provide simple and easy ways of automatically generating tokens. Here is a great walkthrough on how that’s done.

Inside the hub itself you can set up Shared Access policies that allow devices that connect certain abilities inside of azure. if configured correctly, this greatly reduces risk to data tampering since devices do not have have direct access to data stores, etc..

Cloud Gateway to Services

This is by far the easiest thing to secure in an IOT implementation. Azure IOT suite allows users to easily configure connections between the IOT hub and other components like Stream Analytics, Azure Data Lake, SQL Azure, etc. All of these components are only available in your own Azure subscription and should reside inside the same data center to prevent data from potentially being tampered with while in transit (although that’s incredibly unlikely since they are all Microsoft data centers). Since only you can access and configure the components and the data is processed and analyzed in the same data center, security risk is very low.
The important thing to remember about security in the Services zone is that if you have any VPN’s to Azure, then that data is potentially venerable there and the normal VPN security should be taken in order to make sure that no one inside of your network can access the data.



As you can see, IOT security is important,  but it can be easy if you understand the threats it poses and know how to mitigate them. Leveraging Azure IOT suite makes an IOT implementation quick and easy. Please contact Flex Manage to learn more about IoT and how we can ensure your devices and data stay secure.

Comments

Popular posts from this blog

Executing .ps1 files in a DockerFile

This week I was trying to containerize an existing java application. Part of "installing" the application  on the container required executing an PowerShell script in the container during the Image build. Based on the documentation here  I thought i could add the following command to my dockerfile and it would work: RUN install.ps1 However, when I went to build the image, it just hung on that step. I tried several other variations of the run command including: RUN ["Powershell", ".\install.ps1"] which resulted in the following error: '["Powershell"' is not recognized as an internal or external command,operable program or batch file. RUN ["Powershell.exe", ".\install.ps1"] which returned the same error as above. I was about to give up and move the PowerShell commands from the .ps1 file directly into the dockerfile itself as described here , but I had an "A HA!" moment and decided to give a simpler a

Get NodeAuthorization working in Kubernetes with acs-engine

Node Authorization in k8s I'm starting to get into the container world and I'm loving it. Recently we helped a client build out and deploy a micro-services application in Kubernetes. We created the cluster in Azure using the open source project  acs-engine . After we got the cluster set up, our client asked for some updates to the cluster for security reasons. One of those updates was to enable Node Authorization . What is Node Authorization? Node Authorization locks down each Node in the cluster to only be able to do actions on itself. If this is not turned on, its possible for a malicious pod to take actions on any other node, including reading secrets, deleting pods, etc. There is an excellent post by Antoine Cotten that explains this very well ( as well as RBAC, which is a different subject altogether). How do I set it up? Based on the current documentation, it looks like setting up Node Authorization should be easy. Basically follow these steps Turn on TLS

Build/Deploy Windows service with TFS

Building and deploying a web service or website via TFS is pretty straight forward, but automatically deploying a windows service or console application takes a b it of setup. I’ve outlined the steps below to get your service deployed. Step 1: Set up Automated Build and MSDeploy on the Target server. If you are doing any sort of automated build/deploy I recommend using MSDeploy. You can follow steps 1-3 from a previous post here . Step 2: Edit the .csproj file The project file for the app you are trying to deploy needs to be edited so that TFS will create a directory for the output of the project. Otherwise the project will be built, but the assemblies will be placed in the code drop location with no organization to it. To edit the file, go to the open file dialog and locate the csproj file. Select it but don’t click “Open. Instead click on the dropdown arrow next to the Open button, select “Open with”, and choose the XML (Text) editor as shown: Once the file is open, add the fo