If you’ve ever had a security review meeting with your company’s security team—or even wandered by their team area—you’ve likely heard them use the term “threat modeling.” However, you may not know what a threat model is.

According to the Open Web Application Security Project (OWASP), “A threat model is essentially a structured representation of all the information that affects the security of an application.” More simply, it’s a careful look at everything that could impact your app’s security. A threat model can contain all kinds of things, including architecture diagrams, data definitions, technology dictionaries, a list of threats and mitigations to the system under review, and open vulnerabilities that haven’t yet been addressed.

Threat models can be a powerful tool for the creation of secure and robust software, but threat models are also useful outside the application development space. Anyone can use the principles of threat modeling in their everyday lives to assess the risk of a particular activity, formalize ways to mitigate that risk, or explore options to eliminate the risk altogether.

Before we discuss how that might work, let’s take a look at how New Relic uses threat modeling in software development.

Threat models at New Relic

At New Relic, the security team creates and maintains a threat model for all major services and larger feature additions. We use threat models to help identify potential vulnerabilities in new features and services during the design phase, ideally before any code is written, but certainly before the feature or service is shipped to production. Building a threat model of a new feature or service early on helps us to make more informed decisions about application architecture, technology choices, and hosting options—all when it’s still relatively easy to modify those decisions if necessary.

For example, imagine that a development team chose language framework XYZ to implement a new service, which involves encrypting customer data. However, XYZ has poor support for encryption, outdated encryption algorithm options, and a framework that is not updated regularly. When building the threat model, the security team might recommend using an alternative framework, ABC, since its encryption options use up-to-date algorithms with robust support.

After we create the threat model, we review it with the development team to try to make certain we fully understand what is being built, and that we haven’t missed any components or data flows. This review also helps ensure that the developers understand the security concerns and any suggested mitigations. In addition to helping stave off potential security problems, threat models can act as a testing guide for security consultants or members of an internal security team when performing application penetration tests.

Threat models beyond software development

Many people already use some of the principles of threat modeling to moderate risk for their online activities, often without realizing it. For example, when reading about social media accounts being hijacked leads you to create a stronger password and enable multi-factor authentication, you’ve identified a risk to your online identity and implemented a mitigation. From online banking to popular social media sites such as Twitter or Facebook, threat modeling can help you stay safe and keep your information protected.

What do you want to protect?

For example, consider your date of birth. Many social media websites ask when you were born, partly because they’re legally required to verify your age, but also so they can let your network know when it’s your birthday so your friends can send you funny cat pictures. However, date of birth is also a common authentication question asked by many financial institutions and healthcare services.

Where is your sensitive information stored?

The second step in building your personal threat model is knowing where the information you want to protect resides, and who is handling it. While it can be difficult to know exactly how your information is being stored and handled, or who has access to it, you do know whom you’ve given your information to and what steps you have taken to protect it.

Before sharing information with any entity, it’s a good idea to review its privacy policy, any documentation on the site regarding storage and handling of data, and the security controls it may offer, such as two-factor authentication support. This can help you define your level of trust in the entity with which you’re considering sharing information.

What risks are you taking?

The third step in building your personal threat model is learning to understand the risks you’re assuming by performing a particular action or activity. Risks come in a wide variety of types, and from an equally wide variety of sources. Of course, while everyone takes risks every day, the goal of the threat model is to reduce those risks to an acceptable level.

Discovering threats, weighing risks, and cataloging personal information is a lot to consider. So here’s an example of a personal threat model to help tie it all together.

Example: Managing bank accounts at Acme Banking from a local coffee house

Imagine that you are a remote worker, and that you frequent a local coffee house to work from while enjoying artisanal pour-over coffee. One reason you like working there is the shop’s fast wireless internet, and that you don’t need to bother the barista to ask for the wi-fi password.

patrons using laptop in cafe

Because you are there so often, you routinely do your online banking—paying bills and transferring funds—while connected to their free wi-fi, Then, one day, a friend mentions that there are risks in performing sensitive actions on an open wi-fi network, so you decide to figure out the risks and determine if there’s anything you can do to reduce or eliminate those threats while still enjoying the shop’s awesome coffee.

Let’s take a look at the possible risks and mitigation tactics:

  1. Someone could observe which bank you use, and attempt to guess your credentials. To mitigate this risk, you could use a long, complex password to make credential guessing more difficult. You could also set up multi-factor authentication to make unauthorized access to your account much harder.
  2. Someone could observe you inputting your password to your banking site, and use that information to impersonate you. To protect against this, you could use a password manager to store your password. This would let you avoid typing your banking password in a public space where someone could record your keystrokes.
  3. Your bank does not serve its entire site over HTTPS. Your friend warned you this could enable a man-in-the-middle attack on public wireless networks. To prevent someone tampering with your banking session, you could subscribe to a VPN service to use for sensitive operations. This helps ensure that no one in the coffee house can sniff or tamper with your traffic.
  4. Someone could observe information on your screen that could help them steal your identity or conduct other unauthorized online activities. To avoid this, you could use a privacy screen that obscures the information on the screen from anyone who isn’t directly in front of the computer.

Common sense, and beyond

There are likely other threats that you may be exposed to if you decide to do internet banking from your laptop on a cafe’s free and open wi-fi, but these are of some of the more obvious ones. In this example, we used simple sentences to express the threats we care about and what we’re going to do to make sure we’re not exposing ourselves to unnecessary risk.

While many threat situations can be mitigated with common sense, systematically thinking about threats you might face can give you insight into how to handle a variety of obvious and less obvious situations.

 

Matthew Lapworth is a senior security engineer who joined New Relic’s Product Security team in 2014 after having spent a lot of time with his head in the cloud, thinking about security. He believes security shouldn’t be hard and that it’s possible to balance security and business needs to ship secure products that meet the needs of customers. When not working on security software, Matthew can be found rock climbing, cycling, or running in the park.

View posts by .

Interested in writing for New Relic Blog? Send us a pitch!