Leveraging ML for IoT Security
The Internet of Things (IoT) is globally expanding. Unfortunately, the IoT is also accompanied by a large number of information security vulnerabilities and exploits. If we take into account the inherent computational limitations of IoT devices in addition to their typical vulnerabilities, the ease by which hackers can locate them, and their expected proliferation worldwide, then both the risks and the projected global impact of connecting IoT devices to the network in any modern environment become clearly evident.
Self-deployed IoT devices may support a variety of enterprise applications. For instance, smart cameras and smoke detectors enhance security; smart thermostats, smart light bulbs and sockets facilitate power savings; and so forth. Given this, care should be taken to make sure that such Web-enabled devices do not contribute to an expansion of the cyber attack surface within the organization. The smart TVs typically installed in conference rooms are a good example. Skype app can be used by a widget in order to obtain elevated privileges. It is then able to perform rooting, make images of the complete flash memory, and leak them outside to a remote FTP server. In situations of industrial IOT, these kind of attacks are not just an issue of losing information but often a question of physical safety.
Regarding the implications of employee behavior on organizational IoT security, the rapidly emerging concept of employees bringing their own IoT devices (BYOIoT) to the workplace also increases the number of IoT devices connected to enterprise networks.
The resulting risks include cross-contamination which can arise when a BYOIoT device(possibly infected earlier with malware from a domestic network) connects to the organizational network. Scenarios of this kind which are likely to occur frequently, could serve to unintentionally inject malware into enterprise networks, or add entry points for hackers. Once obtaining access, attackers can preserve persistency in the network, and hide their presence inside the organization for long periods of time. Full-fledged attacks can then be launched from the compromised IoT device. Additional negative consequences can incur in cases in which there is inadequate separation between production and guest networks, or in cases in which the app of the BYOIoT device is installed on organizational PCs (possibly asking for too many permissions).
Two major attack types can be described as follows:
- Untargeted: The connected IoT device has been previously infected by a malware of indiscriminate nature, virally spreading among as many devices as possible. Cross-contamination provides a mechanism for this kind of attack.
- Specifically targeted: The malware was intentionally implanted on the IoT device by an attacker, based on the assumption that the device would likely be connected to a specific organizational network in the future. Various attacks are possible in this situation, including a supply chain attack, in which the IoT device is contaminated before it reaches the end consumer, e.g., while in manufacturing, distributing, or handling. Another more focused and precise attack is one in which the attacker gains control of a specific IoT device belonging to the noncompliant user, while this user is at home, and uses the IoT device to infiltrate the organizational network.
The attacks discussed above are enabled only when the compromised IoT devices are connected to the organizational network. For mitigation of associated risks, one option is to intentionally control what connects to the network (i.e., refrain from connecting device types that are known to have unacceptable vulnerabilities). In small offices, composing a list of authorized IoT device types as an organizational policy is a feasible option. Enforcement of IoT device type white listing is then achievable by means of employee training, backed by regular physical surveying. In contrast to this small-scale environment, large corporate enterprises are much harder to monitor for unauthorized connected devices. This is mainly due to the large number of employees and guests, as well as the size of the physical premises. Thus, non-technical policy-based solutions will not suffice in large organizations, and advanced automated means are required. Once deployed, an automated IoT device type whitelisting system can feed a SIEM (security information and event management) system. Subsequently, (near) real-time network segmentation and access control can be implemented. Constant network monitoring with sufficient resolution may also prove effective in enabling the investigation of security policy violations, and help to identify the specific time and place from which an unauthorized IoT device tries to gain network access.
In order to enforce organizational security policies regarding the types of IoT devices authorized to connect to the network, continuous traffic monitoring should be performed. For each stream of traffic data originating from a connected device (i.e., an IP stream), the challenge is to accurately identify the IoT device type. Then, upon determining whether the IoT device type is authorized (i.e., appears on the white list) or not, actions may be taken (e.g., disconnect from the network).
Given a set of authorized device types (i.e., the white list) and a structured set of traffic data, we can treat the task of IoT device type identification as a multi-class classification problem. That is, wecan map each IP stream to the type of IoT device that is most likely to have produced it. We can make the assumption that every device type on the white list is sufficiently represented in the(labeled) dataset. This way, a classifier can be induced by means of supervised ML, which captures the behavior of every authorized device type. In turn, this classifier can be continuously applied to new streams of (unlabeled) traffic data for device type identification and white listing.
In Part 2 of the blog, we will online a detailed approach on how to implement this.