Automating IoT security threat/risk analysis and compliance

Risk management is a never-ending task. Security engineers must continuously evaluate threats, vulnerabilities and risks to meet compliance mandates and stay ahead of attackers. Analysts must be able to analyze near daily vulnerability reports and calculate their impact on systems. This can lead to overwork and fatigue as vulnerability reports never stop. Automation is critical to helping organizations make sense of threat intelligence data, dynamically update policies and achieve continuous compliance within systems. Machine-readability is required to enable automated threat and risk analysis processes.

This article examines some of the automated threat and vulnerability management options available today and discusses how these approaches can be adapted to the goal of securing the IoT and maintaining near real-time views of not only compliance but also risk status. A previous article more broadly discussed the need for tools that help developers more effectively build security into IoT products.

To enable automated risk management for IoT deployments, analytics systems ingest data from numerous disparate sources and automatically analyze that data to craft a clear picture of the latest risks. Sources of data ideally include IoT products themselves which should be designed to report on device software and hardware composition and third-party or open-source components. Firmware analysis tools run by the security operations team scan the latest deployed firmware and report back on weaknesses. Threat intelligence feeds provide context to threats including attacker profiles and capabilities. All of this data should be provided in machine-readable format so that it can be fed to machine-learning algorithms that are trained to calculate a risk profile for each device. Maintaining a continuously updated risk profile of each type of device provides a solid foundation for analyzing security trade-off decisions. Figure 1 shows a framework for automated and continuous threat and risk analysis.

click for larger image

Figure 1: Data collection informs automated risk profiling (Source: VDOO)

One of the first areas that can be automated is threat intelligence sharing. Threat intelligence provides ongoing data regarding the latest attacker profiles and context related to Indicators of Compromise (IoCs). Today, there are a number of automated threat intelligence sharing tools available. Structured Threat Information eXpression (STIX) is one example. Created by MITRE and OASIS, STIX allows sharing of threat information including motivators, capabilities, and suggested response. STIX also provides data related to the indicators of compromise and the appropriate response/course of action to take if compromised. STIX 2.0 is available from OASIS and is designed to work either as a standalone sharing standard or with the Trusted Automated eXchange of Intelligence Information (TAXII) specification.

TAXII is also defined by OASIS. TAXII is a REST-based API that operates over HTTPS. The specification defines how standardized threat intelligence information is shared. Channels can be configured using a basic publish/subscribe model allowing producers to share threat intelligence data with consumers. In an IoT model, the cloud security service supporting the device product would act as a consumer of threat intelligence data, enabling the service to autonomously evaluate the latest threat environment associated with the device. Three services are defined:

  1. A Discovery service allows peers/subscribers to learn about the services supported.

  2. A Collection Management service allows for subscription to data collections.

  3. An Inbox service allows nodes to receive content and a Polling service specifies how to request content.

There are three sharing models defined in TAXII: Hub and Spoke, Source/Subscriber, and Peer to Peer.

Both STIX and TAXII are machine-readable. Designing services such as this to be machine-readable is a pre-requisite for enabling automated analysis and response to the latest threats. These threat intelligence feeds provide useful information but must be analyzed in the context of the unique vulnerabilities associated with an IoT product – for this, additional data feeds are required. The latest security advisory data must be available for example. Machine-readable vulnerability feeds allow an IoT security service to analyze threats in context to come up with a true risk-based scoring model for their products. Cisco for example has defined the OpenVuln API to enable automation of their Cisco-specific security advisories. Security Content Automation Protocol (SCAP) provides a vendor-agnostic capability for machines to consume CVE data. SCAP has been around for more than a decade and provides a listing of known security flaws, software configuration issues and associated product names.

Product vulnerability information must extend down to the components used within the product. Open Source Software (OSS) and third-party libraries play a vital role in IoT products. Customer organizations must be able to identify these libraries within deployed IoT products to accurately calculate risk. To solve this, the National Telecommunications Industry Association (NTIA) is working on the Software Component Transparency initiative that will result in a machine-readable Software Bill of Materials (SBOM).

The SBOM will allow customer organizations to be able to query for the libraries and components used within the product and make use of the data in an automated analysis program. This supports easy identification of vulnerable components that must be patched and allows APIs to be developed that track the status of these components during the life of a product. It will take time however for IoT product vendors to begin incorporating this new capability.

In the interim, tools such as VDOO Vision™ can be used by security operations teams to scan IoT products attached to the network, report back on vulnerabilities and inventory all of the third-party libraries present in their IoT devices. This information is used to more accurately calculate risk and determine which specific library patches must be deployed quickly. Tools such as VDOO’s Embedded Runtime Agent (ERA™) can even be quickly compiled on IoT products to mitigate identified firmware risks far more quickly than it would take a developer to patch, presenting security operations teams with a balanced approach towards mitigation. ERA supports both Linux and Android and operates on MIPS, ARM and X86_64 architectures. It is designed to minimize impact on device requirements such as code-size, latency. For example, ERA introduces only 1MB of storage overhead and less than 1% of typical IoT CPU overhead. Security engineers are informed of the tailored ERA safeguards based on the results of the VDOO Vision scans.

Security Operations teams should begin designing automated risk management processes for their IoT deployments. In the Department of Defense (DoD) for example, cyber security leaders have begun to build upon the success of their continuous compliance programs to begin enabling a more comprehensive automated risk management program. Instead of simply calculating compliance scorecards that demonstrate a deployment’s adherence to a set of policies or regulations, security teams can automatically quantify risk by evaluating multiple data feeds that better inform on the context of a vulnerability. This requires a holistic view of the current vulnerabilities within a system and the impacts and likelihood of threats. By automating and integrating vulnerability data with threat intelligence data an organization can create a near real-time view of their risk management profile for their IoT products.

All of these automated data feeds can allow product security engineers to begin thinking about automated responses to the latest risks. We can look to the cloud firewall industry for examples of automated response to threat information. Cloud firewalls today integrate APIs that can automatically modify rules based on the latest threat intelligence – for example, known-malicious IP addresses or DNS records.

IoT products should begin to incorporate basic security automation features at the device and cloud service level that allow policies and rulesets to be updated as new threats are discovered or the likelihood or impact of a threat increases. Organizations such as NIST’s National Cybersecurity Center of Excellence (NCCOE) are also defining new approaches such as Manufacturer Usage Description MUD that allow device profiles to be generated and stored in the cloud. These profiles signal to the ecosystem the valid communication profile for the device. Using an approach such as this, IoT device profiles can provide an additional input into the automated risk analysis of an IoT deployment.

As industry continues to make progress in enabling technologies for automated risk management, IoT product vendors should adopt these features to support their customers’ ability to quickly assess risk and automatically deploy mitigation actions.

Brian Russell is a Security Advisor for VDOO and Chair of the Cloud Security Alliance (CSA) Internet of Things (IoT) Working Group. He is also a Chief Engineer for Cyber Security Solutions at Leidos – a Fortune 500 Government Contractor where he has led Research and Development (R&D) for secure cloud systems, autonomous vehicles, permissioned blockchain networks, and cryptographic key management systems. Brian is an adjunct professor with the University of San Diego (USD) in the graduate Cyber Security Operations and Leadership Program and co-author of the book Practical Internet of Things Security. He is also a SANS Analyst.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.