Machine learning helps devices identify their own anomalous behavior.
One major challenge to cyber-security in Internet of Things (IoT) devices is the constantly evolving nature of threats. New vulnerabilities are continually being found and exploited and new methods of attack are evolving, turning IoT security into an ongoing battle for developers. Now, however, an emerging approach to IoT security using artificial intelligence (AI) promises to provide protection against both known and new, unknown threats.
The traditional approach to cyber security is to implement protections against known threats by monitoring system activity to identify attacks as they happen. As attacks evolve, the protective software must be continually updated in order to maintain protection. For IoT devices, however, this approach has several drawbacks. One is that providing regular updates to installed devices is both costly and burdensome for the device vendor. Further, it requires that devices be designed to receive and process updates, which in itself introduces vulnerabilities that can be exploited.
A second drawback is that updates typically can take place only after a new threat has emerged and been analyzed. This means that the IoT device remains vulnerable for what may be a significant period of time. This time of vulnerability can pose significant risk for both the vendor and user.
Software company Exein has developed an approach to providing IoT security that promises to provide protections against cyber attack that can handle both known and unknown threats. This approach does not require external updates to threat lists or any other outside information. It is entirely built into the device’s own firmware. In addition, the software framework is maintained as an open-source repository, giving developers easy access to the core and helping ensure continual improvement through the community development process.
The core of Exein’s approach is AI based on convolutional neural network technology. A machine learning engine (MLE) running on the device in the user space continually monitors software processes to look for anomalous behavior. When it detects that the device is behaving in an unusual manner, it can send alerts to the operating system or even suspend the execution of suspicious software. It does not need to recognize a specific attack profile; it simply recognizes that things are not going as expected.
There are two other parts to the software, which run under the Linux OS. A Linux security module (LSM) tracks hook calls to the kernel to collect information on all software processes that the developer has tagged with a unique label. The information collected will depend on the type of hook being executed, but might include file descriptors, memory usage details, and access permissions. That information passes to the MLE through the Linux kernel module (LKM), which serves as the interface between the kernel and user spaces. If the MLE detects an anomaly, it signals the LSM back through the LKM.
This process does add a measure of overhead to the system’s software, so it is impractical for developers to tag every software process for monitoring. Further, the overhead associated with training the MLE to recognize normal system behavior may make it impractical for deployment. The software can operate in different modes, however, depending on the compute resources available. On high-end devices and when training the MLE, the software will operate in “live” mode. On low-end devices the software can operate in “snapshot” mode by using a pre-trained version created during device development and testing, thus avoiding the need for training’s computational burden in the deployed device.
The company recommends that developers use the MLE to concentrate on watching external communications processes. Most cyber-attacks come through a device’s network connection to the outside world, so watching only these processes can provide significant protection at a minimal performance cost. Exein also points out that this protection is only active after a device has booted up, so it provides no protection against physical access or attacks that interfere with the boot process. These limitations together with the need for operation under the Linux operating system mean that the approach is not suitable for every IoT device. But for those systems that have the right resources, the approach holds great promise for future-proofing your IoT device security.
This article was originally published on EDN.
Rich Quinnell is a retired engineer and writer, and former Editor-in-Chief at EDN.
New products & solutions, whitepaper downloads, reference designs, videos
Register, join the conference, and visit the booths for a chance to win great prizes.