March 7, 2024

Securing your devices & data protection

How to keep your IoT solution secure

With billions of connected devices, IoT is really starting to scale and become a part of not just our everyday lives, but also our businesses. But as we enjoy the benefits of the connected world, it’s important to consider the consequences of potential security breaches.  

Different use cases have different requirements and budgets, which means some IoT deployments may not be using the most capable hardware – and the device you use can have real implications on your deployment in terms of security. So, let’s go through some of the things you should think about when designing your deployment in order to ensure it is secure. 

Typical security threats to deployed IoT devices

Many IoT deployments involve the distribution of large volumes of inexpensive devices due to budgetary constraints, which typically means devices with immature or insufficient security and hardening, which in turn brings associated attack surfaces.  

Here are some examples of threats you might face with these types of devices: 

  • A flaw in security of a deployed device that could be used by an attacker to gain access to the device, to the network of devices, or even to the application server. This access could then be leveraged to insert faulty data, to extract data, or to inject malware into the system
  • A device that is physically insecure could be stolen by an attacker and brought to a location more suitable to engineering further attacks
  • By using connectivity from a compromised device an attacker could emulate a legitimate device to gain access to the network of devices or to the application server
  • A misconfigured device or subscription that could be used by an attacker to gain access to services that should not be available in the designed applicatio

Not all use cases have the budget to support IoT devices with hardened security, or devices that have been thoroughly tested and validated by reliable organizations.  And many deployments successfully rely on simple hardware. But it is important to understand the consequences a lack of strong security could have on the rest of your solution during its lifetime.  

For example, an inexpensive and simple device may not have firmware update capabilities, and even if the device has the capability to update firmware you should ask yourself if you can afford to spend the battery power required to perform the actions associated. If a critical flaw is found in a few years’ time, how will the effects be managed and mitigated? There are solutions, but the design to handle such issues may have to be implemented from the start.  

Addditionally, it is important to keep track of the devices deployed, such as their location and status. With potentially thousands of devices deployed, it’s difficult to manually keep track of the disappearance or reappearance of a single device – and you may find yourself looking for answers to the following questions:

  • What caused a device to drop off the network?
  • Did it reconnect in a different location?
  • Did anything else change while it was gone?

All of these are signs of tampering which could be the start of an attempt to breach the network and there are ways to mitigate these types of threats.

Our recommendation is to use some kind of function to authenticate the device, be that device certificates or functionality built into your Connectivity Management Platform (CMP) using authentication capabilities already existing on the SIM-card, preferably combined with device location tracking and device change triggers (IMEI change notification.) 

An attacker who has physical access to a device may gain access to the SIM. By using the connectivity that SIM provides in a different device the attacker may have more possibilities to breach the network. The attacker may also gain access to services that were not intended to be used but were left activated on the subscription.

For example, when deploying multiple different use cases, voice and data services are provisioned on all subscriptions, but in reality voice would only be used by a few devices in a specific use case. An attacker gaining access to any SIM in such a deployment could potentially generate high-cost voice calls or otherwise cause financial harm.

The main mitigation we propose to these threats is the device change triggers and associated automation rules in Cisco IoT Control Center (IMEI change notification), which can automatically lock the subscription and SIM if it is inserted into a different device. Other mitigation capabilities include provisioning of the correct service set over API once a device is deployed, and continuous service utilization monitoring. 

Other threats to your IoT service

Outside of device threats one of the more disturbing threats to an IoT service are denial-of-service attacks. If key pieces of the infrastructure are identified by an attacker an overloading attack can be launched, which could take your entire IoT solution completely offline. This becomes possible when a solution is relying on the internet for transport of data. Even if the data is tunneled and encrypted, the gateways have interfaces towards the internet and as such are exposed to attacks should they be identified.  

The mitigation to these kinds of risks is to take the transmission path off the internet, and into a private domain. By using a private interconnect, a private cloud interconnect, or even a virtual private interconnect a separated path is provided all the way from the device to the customer’s data center, where it never transits a shared medium, which in turn makes it increasingly difficult for an attacker to find attack surfaces for denial-of-service attacks.  

There is also the topic of data and network segmentation. Using a private interconnect allows you to include the IoT devices in the field into their own intranet, providing the same security principles to be implemented as the customer’s other IT services, although this may not always be the preferred setup.

Perhaps there are subsets of devices that are preferably kept outside, which is where segmentation comes into play. Using private APNs, the customer can segment its devices into network categories or even separate data into data classification categories, each with separate addressing and server side end points. When setting up a new customer our service managers typically go through the design in detail, choosing a setup that is well suited to the customer’s use case needs and requirements.  

Systems interacting

Tele2 IoT uses Cisco IoT Control Center as its connectivity management platform. IoT Control Center is very capable in terms of subscription control, monitoring, and automation and comes with an extensive set of APIs for external control from the customers’ side. A customer should require that other systems it procures also support APIs to enable control systems to interact with each other.  

One example where these kinds of system interactions come into play could be that a device (Device A) is installed and activated in the field with the installer selecting use case B as the designated activity. The device management platform would then call the CMP over an API requesting the service profile associated with use case B to be provisioned to Device A. The CMP could then inform the customer’s application that it can expect data associated with use case B to arrive from Subscription C that it has associated with Device A over the link associated with APN D. 

In case the SIM is moved to a different device the relation between Device A and Subscription C would break and the CMP could take action, informing both device management and the customer’s application. Both could contain logic to request the CMP take action, or if configured locally in the CMP it would act first and then inform the external systems to prevent further security implications. 

Correctly planned, designed, and configured, an IoT deployment is very secure, even when use case constraints, such as budget, force design choices where security is not on a level it should be according to policy. 

Best practices

  • Keep your devices in check:
  • Where are they, when were they placed there, will they be stationary or move around, and how are they supposed to communicate
  • Think through the device lifecycle, including firmware maintenance
  • Physical access, passwords, and service availability
  • Automated service usage monitoring, change of device location and change of device, identity notifications.
  • Segmentation of networks and data, private connections for reduced exposure
  • Enable API integration between components for increased capabilities to enforce security policy and act on breaches.

 If you would like to learn more about security and data privacy and how to best protect your IoT solution, please get in touch.

Jonas Hallman
IoT Architect
Tele2 IoT

 

Get in touch