Issue link: https://resources.mouser.com/i/1437738
An effective middle ground collects an evolving level of detail up to the necessary level to capture all interactions that cross trust boundaries between the separate, unique zones of a system (Figure 2). For example, an IoT application can comprise multiple zones linked with cloud resources, gateways, IoT terminal devices, and users. Transactions that operate across trust boundaries are particularly vulnerable to an exceptional array of attacks on transferred data, security credentials, or protocols. Even seemingly innocuous attempts to communicate across a trust boundary can create a pathway for a fingerprinting attack— where hackers use known indicators contained in the system's response to determine the system's underlying components in preparation for more directed attacks. Of course, an understanding of the interactions between the underlying components within each zone becomes especially important if some of those components come from third parties. For example, an IoT device that uses a third-party sensor driver could be vulnerable to threats at the driver's boundary (Figure 3). Although a suitably detailed description is essential for threat modeling, the identification of specific threats that connect to those details is the payoff. In the case of Arm's water-meter threat model, the modelers provide a plain-language list of threats associated with each asset, such as firmware, measurement data, and interactions with external entities (such as users, administrators, and attackers), that might touch the TOE. For firmware, the model describes specific threats, including the installation of compromised firmware, modifications of associated security certificates utilized to authenticate firmware updates, cloning, and more. Based on the list of assets and identified vulnerabilities, development teams can evolve a set of corresponding security objectives and mitigation methods. For example, Arm's water-meter model concludes with a list of security requirements, including those for firmware, such as the need for a secure boot, firmware authentication, a response to a failed authentication, and others. Available Resources In identifying potential threats, few (if any) development organizations can possibly remain current on every possible threat that might apply to the detailed assets and processes | 4 | | 25 | Figure 2: Threat models should provide sufficient details to identify possible transactions that cross trust boundaries between different zones of a system. (Source: Microsoft) Figure 3: Although this data-flow diagram was designed to illustrate transactions that cross the boundaries of desktop software drivers, the same principles apply to transactions involving third-party hardware or software components in any connected system, including IoT devices. (Source: Microsoft)