Lessons learned and systematic approaches

IoT systems can be highly complex implementations that encompass many technology layers. Each layer has the potential to introduce new vulnerabilities into the overall IoT system. Our discussions related to potential airline attacks as well as real-world automobile attacks provide glimpses into understanding how overcoming the vulnerabilities of each component within a system is critical in combating highly motivated attackers from reaching their goals. This becomes even more concerning as the IoT intersects safety and security engineering in the physical and electronic worlds. Described earlier, collaboration between the security engineering discipline and other engineering disciplines is needed now to allow system designers to build security into the foundations of their products and guard against attacks that focus specifically on removing, dismantling, or reducing the effectiveness of safety controls in IoT CPS.

An interesting point related to the IoT is the need to be critical of third-party components or interfaces that may be added at a later time to an IoT deployment. Examples of this persist in the automotive industry, such as after-market devices that plug into vehicle ODB-II ports. Research has shown that at least one of these devices can be used to take control of the vehicle under certain circumstances. Security architects must understand that the security of the system as a whole is only as strong as the weakest link in the chain, and understand when the potential is there for a user to introduce new components that make the attack surface much larger than originally intended.

The security community has also collectively learned that many developers are fundamentally not familiar with engineering security into systems. This is primarily true because of the general lack of security training and awareness in the software engineering world. There are also cultural barriers between software developers, security, and other types of engineers. Whether discussing Supervisory Control and Data Acquisition (SCADA) systems, connected vehicles, or smart refrigerators, product engineers have historically not had to worry about bad actors gaining remote access to the target. This is no longer true.

In addition to a general lack of security awareness, another issue of concern is the frequent opaqueness and complexity in the proceedings of Standards Organizations (SOs). Not all SOs integrate the right types of security practitioners into their committees or allow specialized external peer review, especially early in the development of protocols. This lesson learned (in this case, addressing the IEEE) was cited by one researcher as a significant factor in allowing the 802.11 WPA2 key reinstallation attack to become feasible (see https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/).

The key takeaway from this discussion is the need to systematically evaluate the security posture of an IoT implementation from its origins in standards, through its engineering and development process, and ultimately its deployment. This means it is equally important for OEM/ODM vendors developing specific IoT devices as it is for the enterprise architect integrating an IoT system on the fly.

Threat modeling provides us with a methodical approach to performing a security evaluation of a system or system design. We will next demonstrate the tailored development and use of a threat model. Threat modeling helps develop a thorough understanding of the actors, entry points, and assets within a system. It also provides a detailed view of the threats to which the system is exposed. Note that threat modeling and attack/fault tree modeling go hand in hand. The latter should be performed in the context of an overarching threat modeling approach.