Securing Emerging Technologies: Strategies for More Effective IoT and Cloud Threat Modeling
Threat modeling is a crucial tool for organizations seeking to proactively understand, enumerate, and protect against adversarial threats to business information assets. Threat modeling can significantly improve information security outcomes by identifying and cataloging potential threats early on, enabling an organization to reduce risk to the right levels. But the rapid adoption of emerging technologies such as Internet of Things (IoT) and cloud computing – and the consequent need for these technologies to securely store, process and transmit sensitive data – demands new approaches to threat modeling that account for novel abuse cases and ensure integration of end-to-end, iterative security processes.
This is the first in a series of articles setting forth our views on how enterprises can more effectively protect information in the cloud. The following best practices and insights are informed by our experiences protecting Fortune 100 enterprises from data breach and should be top of mind as companies seek to enhance their information security posture in the cloud:
A long-predicted wave of business use of IoT and cloud technologies is here, and recent research forecasts that investments in IoT are projected to grow at 13.6 percent per year through 2022. Over the same time horizon, the growth of spend on public cloud services is forecast to be 22.5 percent annually. These changes bring tremendous opportunity, but business technology leaders must balance the commercial and cost-savings opportunities presented by IoT and cloud adoption with the unique risks that accompany them.
IoT might enable introduction of a novel consumer-facing product line or avoidance of an incremental asset investment through improved utilization or maintenance, but an implicit assumption driving adoption is that these new technologies do not introduce unacceptable business risks. For that to be true, the security risks associated with data stored on IoT devices or in multi-tenant cloud environments must be effectively managed. Threat modeling for IoT and cloud deployments becomes critical to ensuring that these novel technologies are a source of business value – rather than an exposure – for the enterprise.
When Performing IoT Threat Modeling, Focus on Data Stored on the Device and Assessment of Data-in-Use and In-Transit
Among the most critical factors for effective IoT threat modeling is appropriate consideration of data stored on the device, factoring in data-at-rest, data-in-use and data-in-transit. Many organizations struggle to effectively identify threats to sensitive information stored on the device during the design phase. Identification and mitigation of such threats is a critical success factor for IoT threat modeling because, without the appropriate controls, an adversary could, for example, obtain access to information on the device, potentially exposing Wi-Fi credentials, health information, payment information, or enabling access to the device’s backend.
To account for threats to data stored on an IoT device and data-in-use, take the below threats and mitigations into account during threat modeling.
- • A common pitfall we have observed impacting data stored on IoT devices is failure to enforce access control that ensures only authorized users have access to resources on the device. Ensure that proper access control polices such as attribute-based access control (ABAC), discretionary access control (DAC), mandatory access control (MAC), or role-based access control (RBAC) are enforced.
- • An adversary who has access to the device could attempt to dump its data to perform further reconnaissance of the application or capture intellectual property. This is a primary reason why companies must ensure the presence of controls such as file-based or full disk encryption.
- • Threats to the secure boot process must be mitigated by ensuring that secure boot is properly enforced, preventing an adversary from tampering with the boot process and obtaining access to firmware or the operating system.
- • Threats to sensitive data such as payment information must be mitigated by ensuring implementation of a solution such as trusted execution environment (TEE) or Secure Element (SE), focusing on assurance that there is a secure pairing between the device and the SE or TEE chip.
Technologists and security practitioners also need to be mindful of threats to data-in-transit. For example, data that is not effectively secured in transit could be intercepted by an adversary. We generally recommend enforcing mutual TLS (mTLS) and ensuring that the identification of the device is validated using both hardware and software attributes. This along with mTLS provides certainty that proper validation of the device ID is enforced before information is transmitted to it.
Evaluate the Security of Protocols Leveraged for Device-to-Device IoT Communications
A focus on the protocols that enable device-to-device IoT communications can also help companies more effectively identify information security risks. Complete evaluation of such protocols (which may include near-field communication (NFC), Bluetooth Low Energy (BLE), and Secure (MQ Telemetry Transport) MQTTS) is of the utmost importance.
These protocols are not as transparent as HTTPS from a testing perspective. In addition to this, security attestation is further complicated by the relative dearth of tooling and information. In consequence, companies may to turn to a security firm with IoT expertise, as well as knowledge of threat modeling and security testing processes.
When comprehensive threat modeling and security assurance has not taken place, we have seen attacks that capture and replay Application Protocol Data Unit (APDU) payloads to affect an unauthorized transaction. It is therefore critical that protocol-related threats are enumerated and mitigated as early as possible. In payments, for example, mitigations may include integration of an Authorization Request Cryptogram (ARQC) to ensure payments are handled once.
Another often overlooked aspect of IoT threat modeling is the risk introduced when handling BLE communications. An IoT device may expose Bluetooth GATT (Generic Attribute Profile), which is used exclusively after a connection has been established between the two devices. The Bluetooth SIG (Special Interest Group) defines quite a few standard profiles, services, and characteristics. In the past, we have discovered services which allow a device to communicate with another IoT device using Write, Read or Notify properties. From an adversary’s perspective, it is possible to bond with BLE and write HEX bytes that could be returned or written to an IoT device. The big risk then becomes that the IoT device executes malicious instructions without the proper authentication. It is consequently very crucial that once the device is paired it should not pair or bond with any other device, especially in a no keyboard or no display-type setting.
Ensure IoT Threat Modeling Addresses Hardware Tamper Resistance
As technologists and security practitioners engage in threat modeling, another key factor is hardware tamper resistance. This is key because hardware tampering can lead to an adversary dumping firmware. Organizations need to ensure controls are in place to detect malicious activity and take secure actions in response in an offline mode.
From a hardware perspective, controls to mitigate hardware tampering threats may include ensuring that eFuses (if available) are burned properly so that if tampering on the hardware is detected, the device is wiped or becomes effectively useless to an adversary. An additional important step is ensuring that the Joint Test Action Group (JTAG) standard, Universal Asynchronous Receiver/Transmitter (UART), Serial Peripheral Interface (SPI), and Inter-integrated Circuit (I2C) protocol are disabled from the production build. We also recommend ensuring hardware tampering mesh is implemented across the System on Chip (SoC) and any other integrated circuits (IC) so that attacks such as chip-off or tapping are protected against.
For Containers and Novel Components of the Technology Stack Ensure Coverage of Data Access, Application Security and Other Security Controls
Increasing container innovation in production environments must be paired with a security approach that ensures threats and risks are appropriately managed. Containers – which offer a logical packaging mechanism that enable applications to be abstracted from the environment in which they actually run – must have appropriate security controls that ensure coverage of scattered data stored on various containers, application security and other controls to prevent data leakage, exfiltration or threaten overall confidentiality and integrity of the information stored. With many companies we have seen a lack of security attestation for the control plane resulting from inadequate controls, even where the control plane is responsible for critical functions such as identity and access management or security assurance for the data plane.
Additionally, a dedicated service must be leveraged that manages, deploys, and updates the lifecycle of fragmented data sources among several pods. It also becomes important to ensure that this service maintains the state of each pod configuration; manages the storage environment configuration; mandates stringent identity and access management; and performs security attestation of each pod before its deployment.
Additionally, threats such as data exfiltration by an internal user with elevated privileges need to be addressed through stringent segregation of duties and granular logging of accesses.
Ensure Effective Secret Management Solutions for Containers
A key risk with containerized workloads is leakage of control plane secrets. One may be tempted to either hard code the secrets within the source code or within environment variables. As security practitioners, we know storing secrets in source code is dangerous. However, for environment variables, anyone who can exec into that container, run docker inspect remotely or a user with root access can access /prop folder about the environment and gain access to secrets. To address such risks, threat modeling should account for the need to store all control plane secrets within a vault solution. Along with a few known vendors such as Aqua and Nomad, Docker Swarm and Kubernetes have some built-in capabilities for secrets management as well. They provide capabilities to rotate keys, and in many cases after successful bootstrapping, ensure that checks for the control plane-managed instances have the appropriate configuration.
For Containerized Workloads, Address Vulnerabilities Associated with Image Creation and the Underlying Platform
A frequent misstep when it comes to image creation is failing to consider the security aspects of it. Often, users will install an application while keeping the default configuration without implementing any security safeguards or controls. The use of third-party resources — for example, creating an image using a GitHub repository — is often an unavoidable aspect of container development. However, this exposes the container to potential attacks, such as backdoors, for example. Integrating security workflows while attesting third-party resources and internal designs is an important consideration the threat modeler must integrate within the security processes.
In addition, the underlying container solution such as Kubernetes or Docker Swarm may expose threats to containers. These threats may range from logging and monitoring-based exploits to Application Programming Interface (API) abuse that may put the entire host system at risk. For example, with CVE-2017-1002101 containers that use subPath volume mounts, allow an adversary access to files or directories even to the host’s file system. CVE-2017-1002102 allows containers using secret, configMap or downwardAPI volume to trigger deletion of arbitrary files and directories on the nodes where they are running.
Adopt an Integrated, Iterative Approach to Emerging Technologies Threat Modeling
Regardless of the technology under development, the whole threat modeling process must be highly iterative and move at a fast pace. We often see companies struggle to ensure effective integration of threat modeling outputs into follow-on application security processes such as secure code review and penetration testing. To achieve this, there must be a resolution to tensions between agile development approaches with traditional threat modeling, which has been seen by some as document intensive and slow.
We have seen companies find greater success when threat modeling is performed in an iterative manner rather than in a traditional point-in-time fashion. We recommend that there be touch points for threat modeling at the development phase, application specification phase and at the implementation phase. These touch points help security practitioners obtain a firmer grasp of changes within the design and calibrate for any additional attack vector that may be exposed. This also allows secure code reviewers and penetration testers to perform their work in a more context-driven manner, as threat modeling artifacts will ideally be the starting point for testing.
Increasingly, businesses are realizing the potential of emerging technologies to transform business models and product lines. But business executives, technologists and security practitioners must tackle the risks associated with these new technologies in a head-on, proactive way, to ensure the bold bets they have placed on IoT and cloud technologies are realized – and not undermined by security threats. Effective threat modeling, then, provides an important starting point for businesses to innovate in a way that does not compromise security.