IoT security – A barrier to deployment?

One issue undermining user confidence is the lack of information regarding the security arrangements already in place for networks underpinning IoT, both the licensed and unlicensed variants. Low Power WAN (LPWAN) technology platforms such as LoRaWAN and Sigfox use unlicensed spectrum to deploy IoT sensors at scale and it’s been heavily reported that such network types lack the traditional security mechanisms of cellular networks, with carriers talking about a cellular based IoT network being ‘more secure’ as traffic on these network types is within the control of the respective carrier. To tackle the argument, it is important to make the distinction between the types of sensor traffic that is passed over these networks, and how security can be applied at various points in the network. For example, all the traffic that runs through a LoRaWAN network of sensors is non-IP protocol based, has business grade 128-bit encryption, and requires decryption via an application server that sits in a private cloud environment. This contrasts favourably with Wi-Fi based sensor networks that may be interfacing to public internet connections, that require very stringent security requirements locally at site. Ideally, public networks, their providers and the device manufacturers need to look at every element of their design and deployment to ensure maximum security at every level, and to promote these arrangements to users. Despite these security concerns, it’s important to note that not all IoT networks are as prone to security breaches as others, from a security perspective, the recent networks that are being deployed on LoRaWAN have inherent built in security from the design, which is paramount.

So, who’s ultimately responsible for keeping IoT secure? Should network providers be supplying a super secure network? Does some of the responsibility lie with the user to secure their local area network? Is it up to the IoT device manufacturers to integrate security directly into the device from the off? The answer is yes to all three scenarios. In order to make IoT secure from development to deployment, down to using the connected IoT device, a co-ordinated joint effort will need to be made by all parties involved. Dependant on the choice of network access technology, there may be inherent security features built-in already, such as those in Cellular LPWAN,but there’s no reason you can’t have similar arrangements for unlicensed spectrum IoT networks , through the creation of a private network type that has layered security end-to-end.

The Milton Keynes smart city project deployed a LoRaWAN network towards the end of last year, to provide coverage across city central areas for a variety of use cases including energy, parking and environmental, amongst others. Data collected from the several thousand LoRa-based IoT sensors is collected securely over the low power wide area network (LPWAN) and deposited in a purpose-built IoT data hub, which allows analytics to be conducted by a variety of stakeholders in a secure monitored way, that is compliant with data protection legal frameworks. These types of projects undoubtedly hold security as a top priority due to the volume of the deployment and the population numbers that will use the network and the devices connected to it.

Consumers need to have confidence that the security arrangements put in place are robust, not just for the software, but also the physical environment. There are already initiatives to provide much deeper security through blockchain and other platforms, to make even public network traffic more secure. Perhaps the most critical part is the site where the devices are actually deployed and making sure they can’t be hacked into locally. If someone is able to access and interfere with the device locally, it won’t matter what’s happening on the rest of the path of the sensor data because it’s already been compromised. Tamper-proofing is therefore a key feature when monitoring the health of an IoT sensor deployment, from a simple accelerometer through to temperature changes, the analytics can show or project potential tampering and minimise device interference.

The uncertainty for enterprises around security appears to be a barrier for deployment, but it needn’t be. There are a number of potential areas to secure within an IoT deployment, especially for legacy infrastructure and older networks, but by applying security at each point; device, edge, WAN and cloud, there is a much better chance of mitigating against potential incursion. Manufacturers have the ability to incorporate certain security features into their devices from the off and that’s something that the semiconductor industry is looking at already. But again, it’s the general lack of standards that stands in the way. There are already a number of security standards in place for the software, but what about the hardware in terms of chips and other parts of the semiconductor package, within the IoT device? Fragmentation is still an issue as manufacturers are in a way, doing their own thing, but it’s cross coordination between them that will make the most difference. There’s a strong case that deployment and security should not be a concern, provided you’re picking the right system of partners. There are substantial developments and enhancements to security in all types of IoT coming, to give customers comfort that they can deploy with intensity and scale.