Settling on standards to threat model IoT systems

August 23, 2015 OpenSystems Media

One of the foremost security experts in our field, Blackberry’s Chief Security Officer David Kleidermacher began his presentation at the IoT Evolution Developers Conference by pointing out that while there are a number of general guidelines, no real standards exist for IoT security. It’s easy to say that “device hardening” or “secure communications” are prerequisites for a secure system, but for developers looking to begin the process of threat modeling, what does this really mean? Beyond the theoretical, engineers need a real-world, methodical approach to the problem of security that helps them identify and evaluate threats and define the requirements of a solution.

Although they have been slower to take hold in the U.S., Kleidermacher suggests the Common Criteria (CC) standards, or ISO 15408, as a platform for guidance when building IoT security. Released in September of 2012, documents such as the “Common Methodology for Information Technology Security Evaluation” provide tools that can be used to evaluate the extent of threats to a particular system, such as the risk calculator shown in Figure 1 that considers factors such as the time required for an attacker to identify potential vulnerabilities; the expertise needed to exploit those vulnerabilities; attacker knowledge of the target device; an attacker’s window of opportunity; and the equipment required to exploit a vulnerability. Example checklists for various Evaluation Assurance Levels (EALs) that cover design aspects such as the security of the configuration management system (CMS), software delivery procedure(s), and premise and development environment are also provided.

These tools help get designers thinking about their device and whether it needs to be protected against local attacks, remote attacks, acts of God, or a combination thereof, and then build on that as the basis of their threat modeling (Figure 2). From there the threat model can become an artifact of the entire development lifecycle, and be used to help reduce attack surfaces, apply levels of assurance, and define methods for evaluating security as systems evolve. One good place to start when analyzing attack surfaces is the 20 Relative Attack Surface Quotient (RASQ) Attack Vectors, which defines some of the most common attack surfaces.

Still, as far as connected device security standards are concerned, there is a void. To address this Kleidermacher and his team are currently working on a new initiative called the Cybersecurity Assurance Program that both develops specifications and investigates security claims. Stay tuned for updates on this new consortium to get in on the ground floor.

Brandon Lewis, Technology Editor
Previous Article
Yup, these folks are all engineers

Slide show -- Every once in a while you come across lists like this one, dubbed as a "did you know?" For my...

Next Article
How IoT is transforming the automotive software development lifecycle
How IoT is transforming the automotive software development lifecycle

As you may know, QNX has been producing safety-critical software for real-time systems since the late 70s, ...


Follow our coverage of automotive-related design topics with the Automotive edition of our Embedded Daily newsletter.

Subscribed! Look for 1st copy soon.
Error - something went wrong!