Mobile and IoT Security Strategies in the Cloud
Security measures and principles in Azure, Google Cloud, and AWS
Join the DZone community and get the full member experience.Join For Free
Editor's Note: The following is an article written for and published in DZone's 2021 Application Security Trend Report.
As the Internet of Things (IoT) space continues to expand, “smart” products are becoming more popular. Now you can easily buy and connect devices like vacuum cleaner robots, doorbell cameras, and smart locks. Moreover, you can combine all these devices in a smart home set. However, some product teams don’t take security risks into account. And they postpone the introduction of security features into the product until a security attack or data leak occurs.
This article is separated into the following parts:
- Four examples of the most prominent IoT attacks
- Key principles of and best practices for securing IoT applications and devices
- Examples of IoT components and security solutions for Azure, Amazon Web Services (AWS), and Google Cloud (GC)
Most Popular Attacks on Your IoT Environment
- Trendnet webcam security breach – The company released its web cameras without security protection, and anyone could easily access the camera just by knowing the device’s IP address. Also, the company stored user login credentials in clear, readable text.
- Jeep hack — Imagine driving your car when suddenly, you lose control and see that someone is driving your car remotely. A few engineers tried to connect to a Jeep through its cellular network and execute an exploit that updated the car’s firmware. The result was total control of the car: Hackers managed to slow down and move the car out of the road.
- Smart TVs – Many smart TV sets don’t have any authentication options. For example, I started casting YouTube to my neighbor’s device by wrongly clicking another TV that appeared in the list of devices on my smartphone. Another example is when hackers can use a TV’s microphone and camera to watch what the device owner is doing.
- Smartphones – Hackers can steal sensitive data by running exploits on a mobile phone. In one such case, a user typed something on their smartphone, which created soundwaves that malware recorded, converted to symbols, and sent over the internet.
IoT Security Principles and Best Practices
Now that we understand several ubiquitous security problems in IoT, let’s dive into four key security principles and solutions.
Watch Your IoT Devices
You should constantly monitor your IoT devices and infrastructure. Device monitoring can be an issue, especially for enterprise companies or industrial factories. For example, if employees bring USB drives that are compromised with malware, you can mitigate it using the following security measures:
- Configure network with firewalls and other security compliance.
- Use central security monitoring that covers all IoT devices in the organization.
- Add specific workstations for user-provided external devices.
- Monitor legacy devices — for example, an old conference smart TV device connected to the central network can be an unsecured backdoor to the whole organization.
Use JSON Web Token Authentication
Use JSON Web Tokens (JWTs) and the latest signature-based standards — for example, JWT ES256 and JWT RS256. JWTs provide one of the safest ways of authentication based on OAuth and OpenID protocol. Here is how JWTs work for IoT:
- The device should provide authentication data (user, password, SSL certificate, unique device ID) for an authentication service that validates this data and generates the JWT.
- The device uses this JWT to access the cloud services and API. The cloud identity services check the token every time before the device tries to access the cloud API or services.
Integrated Security Approach
Companies that produce IoT devices should focus on integrating security into device controllers during the production phase because integrating security features in IoT device firmware post-production can be extremely challenging, or nearly impossible in some cases. Securing a completed device may also lead to additional expenses. Often, you need to set up additional security infrastructure, or you must send all devices back to update the firmware — this always means additional time and money. So customers choose devices with security software that is already onboarded.
Use TLS or LWC Everywhere
IoT device producers should consider hardening their devices to use Transport Layer Security (TLS) or Lightweight Cryptography (LWC). IoT devices should check certificates on the server-side and revoke it if it is compromised. Next, I will focus on using these principles in cases where an organization has IoT infrastructure in the cloud or wants to migrate it to the cloud.
This is an excerpt from DZone's 2021 Application Security Trend Report.
Read the Report
Building Secure IoT Architectures in Azure
In this section, I describe the most prominent Azure resources to build secure IoT architecture, accompanied by an IoT architecture example.
Azure IoT Hub
Azure IoT Hub is a resource service that allows your solution to communicate with the IoT device — it is a service bus with IoT features that sit like middleware between the device and back-end service of your application. Azure IoT Hub has the following features:
- Registers and stores device data
- Enables device telemetry, data insights, and monitoring
- Supports device-to-cloud communication, request-reply, and file upload from service communication options
- Secures connections based on X.509 certificates and SAS tokens
Azure IoT Edge is a platform based on edge computing principles. IoT Edge allows IoT devices to run in offline mode, integrates with Azure IoT Hub, and has modules that run in the IoT device. Each module is a Docker container, and it can be custom code or Azure services-based code. For example, code gathers logs and telemetry or manages the connection between devices and the Azure cloud (Azure IoT Hub). IoT Edge contains the runtime that is also installed on a device and orchestrates the modules.
Azure IoT Edge security functionality includes:
- Support for confidential computing – The application or module is encrypted in transit and at rest.
- TLS-based encrypted certificates – IoT Edge devices use these between modules, runtime, and the cloud.
- An additional security layer – This layer, Security Manager, secures not only modules and runtime software but also the device’s hardware layer.
Azure Defender for IoT
Azure Defender for IoT is a security option that allows you to identify security vulnerabilities and threats in your IoT devices and IoT back-end infrastructure. One of its significant advantages is that it supports agentless setup, which is suitable for legacy devices that don’t support agent setup. Let’s review an example of how your IoT architecture may look using all these components.
Architecture Example Using Azure IoT Solutions
The architecture solution illustrated in Figure 1 below is an intelligent climate control system for warehouses. Climate control should maintain different temperatures, humidity, and air quality according to the season — this architecture is based on a real customer use case.
The IoT device infrastructure for the warehouse climate control system in this example contains: air temperature, humidity, and air quality sensors; climate control devices; and legacy devices that don’t support agent setup. Hackers can use legacy devices as a backdoor to the whole system. So we send all data from these devices to Azure Defender for IoT to check for potential vulnerabilities. Also, Azure Defender allows you to reinforce the device infrastructure security by involving tools like Splunk. Splunk integration is part of the Azure Defender for IoT service. Other devices operate via the Azure IoT Edge Runtime directly in the device and in the cloud.
Additional processes that occur:
- Azure IoT Hub stores the device data, and the application back-end services operate with data and manage the climate control system according to the sensor telemetry.
- Back-end services are deployed to Azure Kubernetes Services and App Services.
- Azure Log Analytics builds a monitoring and alerting subsystem that the operator can react to when some security incident happens. Therefore, when a device has security issues or doesn’t respond, log analytics display such occurrences in the dashboard and send alert notifications such as email, SMS, and webhook.
Let’s see how we can build the same secure architecture in Google Cloud.
Building Secure IoT Architectures in Google Cloud
To build IoT architectures, Google Cloud (GC) provides us with IoT Core, which is a fully managed IoT service that offers the following features:
- Device registration
- Device telemetry aggregation and analysis
- Integrated Pub/Sub
- Device connection management
- Streamlined integration with other data monitoring and processing services for more granular data analysis
IoT Core also provides robust security features:
- JSON public and private web tokens with a limited expiration time
- TLS 1.2 certificates
- RSA encryption
- Support for GC Identity and Access Management (IAM) to manage API access
Let’s see how the same architecture looks in Google Cloud.
Architecture Example Using GC IoT Core
I will keep the same use case — intelligent climate control systems for the warehouses — for this example.
The security workflow in Figure 2 contains an authentication step. The initial authentication process covers the generation of public and private keys. It is the main requirement to register the device in the IoT Core service. Two components are involved in that process: the provisioner and device manager.
With IAM, a user who is assigned a role of provisioner with
cloudiot.provisioner has permission to manage the devices but cannot modify or delete the registry. The device manager is a component of IoT Core that allows you to register devices and verify device identity. The device manager stores the public key, while the device itself stores the private key. The second phase of authentication is JWT generation. The device generates and signs the token and with a private key, then sends the token to the MQTT bridge, which is a component of IoT Core that verifies the JWT and establishes the connection.
The solution also contains monitoring that uses Prometheus log provider and Grafana dashboards. But if the device can use certificates and JWT tokens, the IoT core can accept it.
Building Secure IoT Architectures in AWS
AWS IoT Core is almost the same as the service in Google Cloud that I described above. It includes the following security functionality:
- TLS-encrypted connection (same in the GC IoT Core)
- Fine-grained device permissions based on Thing policy variables
In addition to all security options provided by IoT Core, you can use AWS IoT Device Defender — a service that analyzes device logs and data to find potential security issues. This is similar to the Azure Defender for IoT, covered in the Azure section.
Architecture Example Using AWS IoT Core
Below, you can see an example of AWS Architecture that is similar to the GC Architecture mentioned above. Everything looks the same except the IoT policy. IoT policy filters data by different topics. Since it can be a category or device ID, your back-end services can listen to a specific topic to collect data. AWS IoT defender is optional here and used as an additional security reinforcement.
In this article, I provided cases of secure IoT solutions, general principles of secure IoT architecture, and example workflows of secure IoT architectures based on Azure services, Google Cloud, and AWS.
|Boris Zaikin, Software and Cloud Architect at Nordcloud GmbH
@borisza on DZone | @boris-zaikin on LinkedIn | @boriszn on GitHub
I'm a Certified Software and Cloud Architect who has solid experience designing and developing complex solutions based on the Azure, Google, and AWS clouds. I have expertise in building distributed systems and frameworks based on Kubernetes and Azure Service Fabric. My areas of interest include enterprise cloud solutions, edge computing, high load applications, multitenant distributed systems, IoT solutions.
Opinions expressed by DZone contributors are their own.