Supplier eBooks

In fact, the sheer complexity of today's designs increases the chance of open attack surfaces, particularly with multilayered, connected systems such as IoT applications. When large numbers of programmable devices of different types connect to the cloud, end-to-end security becomes more of a statistical probability than an absolute certainty. Each element in such an interconnected system of systems contributes not only its specific functionality but also its own set of vulnerabilities to the security equation. By fully understanding how each vulnerability can become a threat to the overall application, an enterprise can decide whether the associated risk of a successful exploit of that vulnerability will rise above the threshold of acceptance and ultimately require mitigation. The ability to gain this level of visibility into the nature of a risk provides strategic value that cannot be overstated. At the same time, by intersecting security vulnerabilities with risk assessments, a development team can devise a tactical roadmap for developing a practical response to the nearly endless stream of threats to any connected system. Indeed, without a more rigorous level of understanding gained through threat and risk assessments, even the most experienced development team is gambling on the security of their systems and applications. Gaining this knowledge, however, starts with a clear understanding of the potential threats against a system, which is achievable through a well-documented threat model. Threat models capture the specific security vulnerabilities associated with a system's design. Creating a threat model seems simple conceptually: For example, developers analyze their designs to identify security vulnerabilities that relate to each underlying component. However, in practice, threat modeling can involve much more work, research, and strategy than this simple idea suggests—and can yield far more than a list of technical security concerns. More broadly applied, threat modeling can also identify vulnerabilities in the associated life cycle processes and overarching security policies that correlate with an IoT application. Ultimately, what constitutes acceptable threat models can vary as widely as the IoT applications and organizations they serve. Even so, different threat models share certain characteristics, and any threat modeling methodology will follow a few common steps. Threat Modeling Threat modeling begins with an accurate description of the system, the so-called Target of Evaluation (TOE), associated with a specific use case, such as the operation of a utility water meter. If a threat model paints a picture of system vulnerabilities, the TOE description is the canvas. By widening or tightening the scope of the TOE, a threat modeling team can expand or contract the focus in a threat identification process. For example, Arm's recently released smart water-meter threat model sharply restricts its TOE, focusing only on the system's core (Figure 1). Of course, a TOE confined within a single subset of a larger, more complex system or application translates to a more limited ability to identify threats, assess risks, and build an effective mitigation plan. For a complex system of systems such as an IoT application, experienced threat modelers might create a series of threat models, going from a fairly abstract description of the complete system to increasingly detailed descriptions of subsystems of particular importance or concern to the organization. Whatever the approach, there is no absolute requirement for the level of detail required in the TOE description. Modeling approaches that intend to provide the exhaustive details of each component can simply exhaust the participants in the process. On the other hand, models that are too abstract are likely to hide subtle vulnerabilities or prevent the identification of vulnerabilities buried deeply in a chain of dependencies or third-party software libraries. | 4 | | 24 | Headline Learn More 4 • Evaluate the features of the RA6M3 32-Bit Microcontroller • 32MB external QSPI flash • User LEDs and buttons EK-RA6M3 Evaluation Kit for RA6M3 MCU Group Figure 1: Arm's water-meter threat model limits its TOE to the system's core rather than including the full complement of subsystems typically included in these systems, resulting in a more manageable scope of analysis. (Source: Arm)

• Cover