Dan GriffinWelcome to the 23rd edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what’s on our radar, specifically with respect to enterprise network security, but also regarding IT and business more generally.

The Informer is intended to be useful content and good for a quick read. So if it’s just clutter in your inbox, we’ve failed, and I hope you’ll let us know.

Software Development Lifecycle: Usability and Threat Modeling

The hardest part of software development is balancing security and usability. The proper balance can’t be achieved without analysis and a systematic approach, although the process need not be heavyweight. The two most important ingredients: use cases (or user stories) and threat modeling. Indeed, the two go hand in hand.

To many people, threat modeling sounds like an intimidating – and perhaps too academic – task. Likewise, too many software architects yield the responsibility of user interface design to others. But in both cases, getting your hands dirty is the best way to prevent defects early in the software development process, thereby reducing their impact and cost. This is true even for software that has already been released, since the threat modeling and user experience modeling processes frequently reveal changes that can be made relatively cheaply in the next planned release.

Effective threat modeling is difficult without understanding how the customer will be using the product, end to end, in a specific context or scenario. Likewise for usability: without experimenting with real-world user interaction with the system, latent problems won’t surface.

Step 1: Create a Data Flow Diagram

Usability and threat modeling are both built on a foundation of analysis that is inherently visual. In the case of usability, it is the responsibility of the designer to model the interaction of the end user with the software as early as possible during software development.

Similarly, the foundation of the threat model is the data flow diagram, or DFD. The DFD is a pictorial representation of the assets, data flows, and trust boundaries in the system being modeled.


The cartoon above draws an analogy between data flows in software and the traffic flows of a new road that must traverse a river. Much as sensitive line of business data must transit high-risk links such as the public internet, civil engineers must design bridges in such a way that accounts for the stresses that will be placed upon the spans.


The preceding figure is a DFD representing a typical cloud-based, three-tier line of business application. There are three trust zones in this DFD and the boundaries between them are represented as dashed red lines. In this example, each trust zone has a single entity with bilateral communications links to the next.

Just like a DFD, effective user experience modeling starts with a drawing consisting of no more than simple boxes and labels.

Step 2: Enumerate the Threats

The importance of the DFD becomes crystal clear once you begin the second step of the threat modeling process: Enumerating Threats.


Much like the bridge-over-water analogy depicted in the cartoon above, the data flows and trust boundaries in the DFD show you exactly where to look for threats, and how to prioritize them. Do you have internet-based assets that can read sensitive data from a document repository? If so, consider threats such as unauthorized access. What about servers hosted in a third-party-managed data center? If so, consider threats such a trusted insiders.

Much like the iterative user interface design process, a picture makes threat enumeration systematic. But without a picture, both jobs are nearly impossible.

Step 3: Review the Design with the Architects

The designers, developers, and testers of a software component are the subject matter experts and it is those individuals that need to be involved in the analysis of the threats.


Similarly, usability can best be achieved by those that understand the customer’s use of the full system, including its interaction with external components.

Step 4: Enumerate and Apply Mitigations

Typically, a technical program manager takes ownership of the threat model and schedules the analysis session. The architect, developer, and tester should be present and each threat should be discussed in turn. Some threats will be determined to have little impact on the security of the data, while others will be mitigated by changes to be implemented by the development team.


Usability also presents challenges both small and large, especially when it comes to tradeoffs with security and time to market. It’s important to take a systematic approach.

Step 5: Review with Management

Any residual risks should be escalated for management review to determine if an unmitigated threat is acceptable to the project as a whole.


The entire development team benefits by engaging in the threat modeling and usability processes. This involvement leads to heightened awareness of the ramifications of design and implementation decisions. Additional benefits, often overlooked, include higher overall code quality as well as greater management visibility into the benefits of instituting processes that can otherwise be difficult to quantify.

Security and usability go hand in hand, and yet pose a mutual tradeoff. The savvy software architect models both security and usability before principal development begins and revisit the models as major implementation decisions are made. Even a cursory analysis, though based on a systematic approach, results in fewer defects, quicker time to market, and higher profit.

JW Secure specializes in threat analysis and remediation of software systems and IT infrastructure. Our methodology combines our Four Pillars of Endpoint Security model with the STRIDE by Element approach. To learn more, please contact us.