The question more IoT stakeholders need to be asking is whether they trust the data coming from their devices. Given that companies invest in IoT because they believe additional real-time data will lead to greater efficiency or increased profits, any business decisions taken using flawed data may result in losses rather than gains. Security is a risky topic to neglect or to hope for the best.
The problem is most significant, and hardest to detect, when devices report plausible but inaccurate data. Imagine we have twenty smoke detectors installed throughout a building complex and all but one is working correctly. Now, this rogue unit will always send a “no smoke” status regardless of the actual situation. Its potentially disastrous flaw isn’t apparent to the monitoring station, because the data it sends is reasonable, almost expected.
Another example is a remote device that detects when a rubbish bin is full. If this device has been quiet for some time, does that mean the bin still has space, or has the battery has run out?
We can group the root causes of these trust issues into human error and malicious activities. Human error captures all the mistakes that are resulting from developing and deploying IoT devices, ranging from firmware bugs to misconfiguration. Malicious activities are deliberate actions that disrupt normal device behavior, such as the installation of malware or a denial-of-service attack.
At Arm, we are looking to this tackle problem with Device Sentry, a new feature in our Pelion Device Management service that automatically monitors and reports device behavior. For now, let’s explore methods for increasing the trustworthiness of IoT data and show how Device Sentry can automate this process for device manufacturers and operators.
How to Improve Trust in Data
Unfortunately, it’s impossible to trust data entirely, but you can increase the confidence levels by taking measures to improve prevention and detection. Prevention involves taking steps that make human errors and malicious activities less likely; best-practice examples that Pelion implements include:
- Performing rigorous and automated testing as part of a secure software development life cycle. This sort of process discipline can help prevent firmware bugs from going undetected.
- Enforcing safeguards to ensure that malware cannot be installed or executed. Device design should mandate that only secure, signed firmware images and a trusted boot process are allowed, and device management policies this
Detection is about spotting the problems that occur as swiftly as possible, so bad or compromised data has a limited impact on the business. Accelerating this awareness was Arm’s driver for developing Device Sentry. Establishing baselines of standard and accepted behaviors, and actively monitoring these can reveal a lot about a device’s operational state. Delivering this situational awareness was Arm’s driver for developing Device Sentry.
Monitoring Device Metrics
CPU state, memory usage, and network traffic can all indicate whether a device is working correctly. By tracking these metrics over time, anomalies can be observed.
For example, comparing the time spent in different CPU states (awake, idle, sleep, etc.) can help spot configuration errors. If a battery-powered device is designed to sleep for twenty-three hours a day, yet has been awake for four hours already today, something is wrong. Spotting this early can make the difference between a remote configuration change and a costly device battery replacement.
Another example could be detecting extra CPU threads running on the device, which might indicate a debug process running in production or that the device is executing malware.
Memory use monitoring can help spot firmware bugs. A good example is a memory leak, which occurs when a device application keeps allocating more memory without releasing the old memory. Over time this exhausts the device’s finite resources, and a crash is inevitable. This sort of condition can be difficult to spot without careful observation because it will likely restart and continue operation. Yet, the crash will have resulted in data loss, at some cost to the IoT solution and the business.
Network traffic is another good indication of device health. Sending unusual volumes of data could indicate something is amiss. Exchanging data with unexpected third-parties could indicate a security flaw or a misconfiguration.
Automating With Device Sentry
Using the Pelion Device Management service allows customers to accelerate their IoT projects and get to market sooner. Pelion automates many lifecycle management tasks, such as device registration, firmware updates, and fleet management, allowing organizations to focus on what they do best – their unique business model.
Device Sentry delivers similar automation for device health monitoring. The Pelion Device Management Client automatically collects device metrics, meaning that no programming effort is required to elevate the trustworthiness of device data and your overall security posture. The metrics are then transmitted to the Pelion Device Management platform and compared to expected behavior (see Figure 1 – Device Sentry). If a deviation occurs, system operators will be alerted, and the anomalies investigated.
Device Sentry also allows device manufacturers to monitor any time-series data that is important for their health. An example might be following the battery charge on a solar-powered device.
Best of all, Device Sentry is a no-charge option, available to all users of our Pelion Device Management service.
Given their life expectancy – five, ten, or even twenty years – IoT devices are not fire-and-forget products. Regular monitoring ensures devices are operating normally, and their data can be trusted. Basing business decisions on bad data undermines the entire value proposition that the IoT solution was purchased to give.
With the release of our new Device Sentry capability, Pelion Device Management makes increasing trust levels simpler and more straightforward. It’s a free feature that automates the collection of device metrics and the identification of unexpected and potentially fatal behavior.
For more information or to see a demo: