55

I asked a question on what I need to do to make my application secure, when somebody told me:

That depends on your threat model.

What is a threat model? How do I make a threat model for my application?

  • 4
    Relevant and useful info when engaging in the process: security.stackexchange.com/questions/104137/threat-modeling – schroeder Jan 29 at 13:15
  • 8
    I use it whenever someone asks "Is this safe/secure?". Well, secure from what? If you don't tell me what you are worried about, I can't tell you if that's enough. – MechMK1 Jan 29 at 15:18
  • @MechMK1 you put the question in context of software development. Are you looking for answers within that scope alone? – schroeder Jan 29 at 15:24
  • @schroeder Not necessarily. I put it that way because this is where I see this situation the most. I'm very open to suggestions on how to make this question more general. – MechMK1 Jan 29 at 15:25
  • 2
    If you are looking for threat models to use, I have a threat modeling methodology on my GitHub which is based off of standards like STRIDE and VAST, and is tailored to be used in the agile cycle during software development. It has templates, instructions, and examples as well. If this doesn't suit your needs there are a handful of other methodologies out there which have been mentioned all over this page already and work just as well. – ExecutionByFork Jan 29 at 22:10
46

FilipedosSantos' answer does a great job of explaining a formal threat modelling exercise under, for example, the Microsoft STRIDE methodology.

Another great resource is the threat modeling course outline on executionByFork's github.


When I use the term "threat model" on this site, I usually mean something less formal. I generally use it as a response to new users asking "Is this secure?" as if "secure" is a yes/no property. It's usually part of a paragraph like this:

That depends on your threat model. "Secure" isn't a thing; secure against what? Your kid sister snooping on your iPhone? A foreign government soldering chips onto your datacentre equipment? Or something in between?

I really like the Electronic Frontier Foundation's threat modelling framework, which focuses on asking these three questions:

  1. What are you protecting?
  2. Who are you protecting it from?
  3. How many resources can you invest in protecting it?

I really like the way the EFF has written this because these simple and easy to answer questions can guide someone with zero background in security into figuring out "the right amount of security" for them.

  • 6
    @FilipedosSantos I agree that once you are comfortable with a framework, you can apply it to simpler situations; however if someone is asking what 2FA method they should use on their gmail account, then IMO teaching them the STRIDE model is overkill, instead I prefer to gently nudge them with the EFF questions. – Mike Ounsworth Jan 29 at 15:43
  • 2
    My classic example is to ask if they are building "an anonymous cutest-cat-picture-voting site" or "a web portal for launching a preemptive nuclear strike". Obviously the security concerns in these two cases are wildly different (and why in the world are you create a web portal for launching nuclear missles!!!!) – Conor Mancone Jan 29 at 17:25
  • 2
    @ConorMancone lol. If you're asking basic questions on StackExchange then maybe you're not qualified to build that web portal for launching nuclear missiles .... – Mike Ounsworth Jan 29 at 18:56
  • 9
    @MikeOunsworth :) Indeed. Although I've actually seen: "I'm building a payment portal for a fintech startup. How do I secure the payment portal, I'm new to this?". My answer: "hire someone else to do it." – Conor Mancone Jan 29 at 19:05
  • 5
    @ConorMancone I'd say "What resources"? Asking how many or how much sounds wrong to me because it's like asking how many tools you need to build a car. The number or amount is not really interesting. – JiK Jan 30 at 10:33
18

A great definition can be found in this excerpt from the OWASP page about Threat Modelling:

A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.

How you make the Threat Model will depend solely on the Threat Modelling methodology applied. One of the most common methodologies used in the industry is Microsoft's, that is based on the STRIDE model of threats.

Usually a Threat Modelling workshop/session is a round table with all developers, product owner, security experts and a moderator (it can be done alone if you are not working on a team). The ones involved will execute the steps proposed by their methodology in order, and the result will be the Thread Model document/artifact.

The Microsoft Threat Modelling Methodology defines 5 major steps:

  • Defining security requirements.
  • Creating an application diagram.
  • Identifying threats.
  • Mitigating threats.
  • Validating that threats have been mitigated.

The company that I work for uses a similar methodology and it's required for all products that are under development. One difference that I find quite interesting it that we can either make a Threat Model for the entire product, or we can make Threat Models for each product use case.

In the end a Threat Model is the result of many Threat Modelling sessions, where the development team, PO and security experts will brainstorm to find possible vulnerabilities, and then use the defined methodology create the Threat Model document.

7

A threat model answers the question - what are the reasonably expected threats for the concrete software (or "system"). Emphasis on concrete (== not academic/theoretic) and reasonably (== not overbearing, also known as paranoid)

A paranoid threat model can (quite literally) paralyze everything (not limited to software). An academic/theoretic threat model can increase the cost of defense/mitigation to infinity.

A threat model is about the life and death of what you want to protect and what you have to handle vs. what your customer or "larger system" is expected to handle. Who do you trust or not and why? That "why" part is very important and the answer can't be "because". You are defining the boundary of responsibility.

Defense and mitigation plans are not part of the threat model. Mitigation is if something is not reasonably defensible or perceived threat is by and large nonsense or a fad (have been a few in the past few years - makes good headlines - latest by NSA))

Examples:

#1 Say you are writing a server for a military contractor to do FEM analysis for engines (or whole devices/vehicles). What is a reasonably expected threat? Denial of service and confidentiality. What is not? Spoofing, tampering, repudiation, elevation of privilege.

Why?

Authentication and authorization and (much stronger) crypto are handled by systems external to your software (you reasonably expect that to be handled by client's "environment" and normally it is). Breaking "integrity" is pointless (submitting broken mesh to analysis), repudiation you don't care about (someone submitted a "broken mesh" or a "mesh that's not really 'their engine'" and then denying it - between irrelevant and none of your business).

Denial of service can really hurt you (server not doing the work == no money) and is plausible (from proverbial; "Russians" to the competition from across the street to "general net attack from China" - has happened, will happen. damage is real). Confidentiality - you can't trust the cloud - not even .gov Azure, even if you are US company (someone will sell your wireframes to Lockheed), not to mention if your client is Chinese or Russian or German or Brit ... - you've got the picture

#2 Say you are writing/porting an accounting or banking software to "as service". What is a reasonably expected threat? Spoofing, tampering, repudiation. What's not? Denial of service. What's maybe? Elevation of privilege (depends on the nature of your software). What's complicated? Confidentiality.

Why? You have to go to the cloud (which will handle DoS) and confidentiality is the legal category for that line of business, protected (or not) by the legal system (defending against a "mole" that's going to blow a whistle on his girlfriend's CEO is none of your business). Your responsibility gets complicated because you are answering to contradicting demands. You need a lawyer.

On the other hand, non-repudiation is more or less the bread and butter of your business and happens frequently. You might be contractually or even legally required to enable excessive auditing. Tampering is related (someone proves that tampering is possible - non-repudiation is dead) and very lethal and attractive for an attacker (money. money, money). One can do tampering without breaking (usual) crypto - your "tampering" has many legs - now what?

Spoofing is not "authentication" - it's a 3rd party being able to record interaction/transaction (moving money, sales records, everything) without anyone noticing." 2nd part of spoofing is actually tampering (ability to change data "on the fly" without anyone noticing). The actual "man in the middle" attack. The "without anyone noticing" is the defining aspect. One doesn't have to break authentication at all and it's better if he doesn't - the ultimate "not noticing").

Elevation of privilege may or may not be your problem, depending on what's your system providing as a service "over the wire" vs private/secured channels (which are always someone else's problem), who's your client and do you want/have to integrate into a larger system or write your own. You may have to do both but the important aspect is to know what and why.

See how things can get very different quite easily? When someone asks you "do you have a threat model" he's asking "do you know what you have to defend in your, very particular, case".

  • #1 - you don't care about auth&auth because the environment takes care of it but do care about DoS because the environment doesn't take care of it? – peterph Feb 2 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.