Automating the IoT incident response process




Today’s security analysts are overwhelmed. Their tools need to process a deluge of security events that often trigger massive amounts of false positive readings. At the same time, new vulnerable IoT products are being attached to networks every day, inviting compromise by automated malware. At this scale, the old ways of manually analyzing and responding to incidents cannot keep up.

Yet the process of managing a security incident requires deep expertise. Analysts must understand their adversaries’ typical attack patterns in order to quickly track and close them off from the rest of the network. They must be able to rapidly put together multiple pieces of the puzzle to determine whether there’s actually a security incident in progress. Analysts must also be able to think through the ramifications of any actions they take to contain an incident.

The Internet of Things (IoT) has introduced a host of new difficulties for incident response teams. IoT products are notorious for their lack of basic cyber hygiene, with many of them lacking robust logging features, which results in devices that are limited in their ability to protect against malware. Often, IoT products are limited even in their ability to report their state and status to asset management systems, complicating the ability to gather situational awareness of IoT device inventories. Quickly acting upon the realization that an IoT device has been compromised is also challenging because they are often installed without prior knowledge of the information security department.

This article discusses approaches to automating incident response in the context of the IoT. We discuss the category of cybersecurity known as Security Orchestration, Automation and Response (SOAR). We then describe potential approaches to integrating IoT and SOAR in order to enable efficient and effective response procedures for the IoT. We also describe approaches to informing the incident response (IR) process through the collection of real-time attack data and the integration of data feeds that provide up-to-date indicators of compromise.

Security Orchestration, Automation and Response (SOAR)

There are many SOAR products on the market today, incorporating a set of functional capabilities that support an efficient and timely incident response process. The orchestration part focuses on the effective integration of multiple capabilities and technologies within the process.

Gartner’s 2019 report Market Guide for Security Orchestration, Automation and Response Solutions identified a number of SOAR products including:

In the earlier days of the information security industry, a security analyst investigating a potential incident would need to manually gather information about relevant security events. This may have included manually logging into firewalls, routers, servers and applications to view logs, tracking source IP addresses using whois lookups, searching the Internet for known attack patterns and so forth. Today, orchestration tools make this process much easier, integrating Security Information Event Management (SIEM) feeds with threat intelligence feeds to automatically enrich data and enable more informed decision making. IR orchestration is documented in the IR team’s playbook which is where the manual and/or automated actions that need to be taken in the event of an incident are detailed.

Automation of IR actions typically invokes a lively debate. This is sometimes based on the perception that automated response entails an offensive strike against the perceived attacker. Automated offensive actions are typically discouraged given the difficulty associated with quickly attributing an attack to any particular geographic location, node or person, as well as the legal ramifications of launching an attack against a target.

Another layer of the incident response process that can benefit greatly from automation allows security analysts to define the actions that need to be conducted when there’s an incident. These could include moving infected nodes to a sandbox, notifying affected stakeholders, or triggering layered defenses or security configuration changes within the network in order to keep an attacker from moving laterally through the organization.

Playbook automation is being addressed by organizations such as IETF through the Collaborative Automated Course of Action Operations (CACAO) for Cyber Security. The dual goals of this work are to monitor the effectiveness of playbook operations and to share playbooks across organizations. CACAO allows senior security engineers to define typical approaches to handling security incidents, so that playbook automation can then be enabled using tools such as those discussed in this article.

Applying SOAR to the Internet of Things (IoT)

The IoT presents a great use case for the application of SOAR concepts, because the scale of IoT deployments requires efficient orchestration of IR activities and automated responses. These concepts have been previously explored and progress is now being made. In 2015, the Internet Engineering Task Force (IETF) held the Conducting Attack Response at Internet Scale (CARIS) workshop. A finding from this workshop was that automated response was perceived as most mature in terms of response to Distributed Denial of Service (DDoS) and botnet attacks. This bodes well for IoT devices since they are often victimized and added to botnets based on their relatively weak security posture.

In 2019, IETF held a second CARIS workshop, and the results are being used to support the Internet Research Task Force (IRTF) Stopping Malware and Researching Threats (SMART) group. The CARIS2 workgroup report identified several protocols as enablers for automated response, including Manufacturer Usage Description (MUD), Protocol for Automated Vulnerability Assessment (PAVA), and Protocol for Automatic Security Configuration (PASC), all of which are directly applicable to machine-to-machine coordination in support of the IoT.

MUD, which is defined in RFC 8520, supports the automated reporting of device specifications as well as intended device behaviors. It defines the concept of a MUD manager which could, for example, be implemented within a network management system. Based on the data received by a device, the MUD manager can make updates to the network infrastructure that supports it. PAVA provides an automated vulnerability assessment capability that feeds into PASC which provides automated configuration changes based on the identified vulnerabilities.

The ability to maintain positive situational awareness during an incident is a critical enabler of a successful response. Tools such as Mandiant’s Open Indicators of Compromise (Open IOC) provide an XML schema for sharing IoC information that can be useful to IR teams when determining whether a security event should be elevated to the level of an incident. Teams should also consider collecting real-time information from within their own network. Tools such as VDOO’s Quicksand can be used to establish honeypots within IoT networks that capture real-time attack data and provide beneficial information during an incident investigation.

Automation of command and control actions across IoT machines themselves is also a worthy goal given the speed at which malware can penetrate and spread through a network of IoT devices. The OpenC2 initiative is working towards creating this capability by defining a language that supports command and control of cyber defense technologies. This enables collaborative and automated machine-to-machine response actions to incidents that can counter the effects of automated attack processes. For example, OpenC2 may be used to implement automated playbook actions such as those defined using CACAO.

Although automated command and control is a great enabling capability, the optimal approach is to ensure that all devices connected to the network are hardened. This is not always easy in the case of the IoT. To support a secure inventory of devices attached to the network and to mitigate the typical vulnerabilities found in these products, VDOO has created a customizable device-specific protection layer known as the Embedded Runtime Agent (ERA). ERA is generated based on the unique threat profile of the device being protected and can be installed on the device with minimal overhead.

The network itself can also take part in automated defensive maneuvers. For example, IETF RFC 8329 introduces a Framework for Interface to Network Security Functions (I2NSF) which can be used to enable automated network infrastructure configurations during an ongoing incident. The IoT is specifically called out in this informational RFC with the concept that an IoT management system may send requests to the network to block communications that match a specific condition.

Sharing information associated with an incident is also critical to the success of the security industry as a whole. This can be done using multiple methods such as the OpenIoC framework discussed above or the tools defined in IETF RFC 8600. RFC 8600 defines a method, which is based on the Extensible Messaging and Presence Protocol (XMPP), for collecting and distributing security incident reports and other security information amongst devices within the network.

Figure 1 illustrates an automated incident response framework for the IoT that incorporates the protocols and tools discussed in this article.

click for larger image

Figure 1: Automated Incidence Response Ecosystem for the IoT (Source: VDOO)

New protocols will help secure the IoT

Although the technologies discussed in this article are not necessarily focused specifically on IoT, the movement towards machine-based data sharing and collaboration aligns directly with the abilities of IoT products. Forward looking manufacturers should align themselves with these new protocol standards and begin incorporating automation and information sharing capabilities directly into their IoT products. Cloud Service Providers (CSPs) and IoT platform providers should also begin planning to integrate these capabilities into their roadmaps and to pressure the device vendor community to do the same.

 

The post Automating the IoT incident response process appeared first on Embedded.com.





Original article: Automating the IoT incident response process
Author: Brian Russell