Hi everyone,

This is a continuation in my series on developing secure mobile devices. Earlier, I talked about determining what you need to protect. In this post, we’ll talk about identifying threats.

Just as a data-flow diagram illustrates how information travels through a system, threat trees illustrate how security can be breached. An individual threat tree highlights a security issue, tracing a path from the general concern to the actual breach. You should create separate threat trees for each security issue.

At the base of the threat tree – which is usually at the top of the diagram – is the general threat, such as “hacker accesses sales database.” While some security experts say it is okay to do otherwise, in my experience, I have found that the base should always be written from a business perspective. You should never list a specific technical problem as the base threat.

See Figure 2 which illustrates a sample threat tree for a Smartphone.  (This threat tree is based on the example shown on page 116 of the book, Threat Modeling, by Frank Swiderski and Window Snyder published by Microsoft Press in 2004.)

Tying the threat to a business issue makes it much easier to communicate. If top managers don’t understand the threat, it will be much harder for you to win funding and other resources you need to address it. Also, writing the threat from a business perspective helps make sure it gets appropriate attention. If the description at the base of your threat tree is complicated and/or vague, it can be tough to determine how much attention that issue really needs. Anybody, regardless of technical background, should be able to understand the root threat.

From the root threat, add attack paths. These branches and leaves visually represent how security can be compromised. For example, continuing with the sales database example, you may want to add branches for accessing the database remotely or through the device. For the latter of those two points, you may want to add leaves for “guessing the password” and “finding the data in the cache.”

It’s important to document all threats – even those that may pose only minimal risk now. Needs change over time. While very little data may be exposed through a particular security threat today, very sensitive data could be at risk in the future. Additionally, these threat trees may be used as the starting point for a security analysis for a future device or upgrade.

Threat trees, like the data-flow diagrams, are best created by the developer, who has the most insight into how the system’s vulnerabilities. The developer’s threat trees, however, should be reviewed by the entire development team, including quality assurance specialists. Get the team to brainstorm threats and ways that hackers could exploit vulnerabilities. It’s impossible for one person to think of everything. This team approach will give you much better coverage than if the developer worked alone.

In my next blog, I’ll share with you best practices for documenting and categorizing threats.

. . . . . . . . . . . . . . . . . . . . . . .
Steven Yee, CISSP
Engineering Manager
Professional Engineering Services
BSQUARE Corporation | Contact Me!