5 Questions to Ask When Threat Modeling Software Applications

Posted by David Brown on January 17, 2017 at 8:47 AM

Hackers continue to use new techniques to wreak havoc on software applications and get access to sensitive data. The most effective way to reduce broad-scale application security risk is to conduct threat modeling regularly and have a formalized policy or process for grouping data together based on data sensitivity. This can be used as a starting point when prioritizing how much scrutiny different systems should receive from a security team that has a lot on their plate but limited resources.

If you don't know how sensitive a given piece of data is, you can't accurately assess the risk of losing it. Without the ability to accurately assess risk, making reasonable decisions about how and where to spend a security group's time becomes much harder.

It's also a good idea at some point during threat modeling to ensure you know how various components within a system are related to each other, with the goal of understanding how sensitive data is moved around. This provides the information necessary to determine what protections should be in place while the data is in transit. One approach is to use existing architecture diagrams provided by the development team as a starting point and layer security requirements directly on top. For example, take a look at the following data flow diagram. In the image, note that the example system is represented by discrete components, trust boundaries, and the flow of data between them.

As you threat model and focus on what hackers likely want (your sensitive data), be sure to ask yourself the following questions:

  • How is the sensitivity of data determined?
  • What sensitive data is handled by the application?
  • Where does sensitive data enter and leave the application?
  • How is it secured while in transit and at rest?
  • What type of encryption is used and how are encryption keys secured?
Software Threat Classification

Topics: application security, application risk & compliance, threat modeling

David Brown

Written by David Brown