Search This Blog

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.

Get link

Facebook

Twitter

Pinterest

Google+

Email

Other Apps

Labels

Comments

Post a Comment

Popular posts from this blog

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 fileThe 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 following “Pr…

When I first started deploying code from TFS I took the simple approach and created a batch file and deployed the websites via RoboCopy. I’m a very “Keep it simple” kind of guy, so this worked for us for a long time and so nothing was changed. With my most recent project however, we were deploying code over a slow VPN tunnel from our servers in Chicago to servers located in Europe. Due to this, the RoboCopy was taking over 4.5 hours to complete. I needed a better/faster way so I started looking into Web Deploy (MSDeploy). I was able to get it working fairly easily and I was pleasantly surprised how easy it was to get it working, and how much time its saved me! I can now deploy the code in less than 20 minutes!I’ve outlined the process in detail below, but in general you only need to do this:Add MSBuild parameters to your automated buildCustomize the deployment parameters for the websiteCreate a batch file to an auto-generated MSDeploy scriptExecute the batch file from the automated bu…

We recently migrated a production environment for a client to new Servers. I had previously been using MSDeploy to deploy the websites/services to the servers so I figured all I had to do was install MSDeploy, point Update my deploy scripts to point to the new servers, and deploy! I was using MSDeploy 2 on the previous servers so I figured it would work on the new ones. Unfortunately it didn’t turn out to be that easy.
When I ran the updated scripts I got the following error:Fatal: Request to remote agent URL 'http://myserver/MSDEPLOYAGENTSERVICE' failed. Fatal: The remote server returned an error: (401) Unauthorized. Fatal count: 1
I was using an admin account and I could hit that URL above in a browser so I knew it wasn’t an authorization issue.
Here are the things I tried that DIDN’T work:Uninstall/Reinstall MSDeploy 2Install MSDeploy 3Create the fake user group on the server per these instructions:http://www.iis.net/learn/publish/troubleshooting-web-deploy/web-deploy-er…