- this methodology lacks what I think is a good threat model: a list of attacks your system wants to defend against, attacks that are not in scope, and the attacker model (attacker has access to the network at all time, can tamper with traffic, etc.)
- likelihood of each attack vector helps prioritization of work
- STRIDE sucks in my opinion, but it’s a good start for people who have no clue about threat modeling. Are there any other models like that to follow?
- frequency: this overlooks how hard it is to get devs to go through that work, taking into accounts that people are always busy. How do you streamline this process and how do you argue for the value of repeating this exercise frequently?
- different types of threat models: what about deployment? What about updates? What about ci/cd? All of these have threat models as well.
- different layers of threat models: I like the idea of a global threat model managed by the security team with sub threat models managed by teams owning different components, as these can help guide design decisions For new features and refactors
You are being far too kind. The things you mention are the essence of a threat model. The fact that the article mentions none of those things and instead proposes something that can not, by any reasonable definition, be considered threat modeling and the fact that they think what they propose is threat modeling demonstrates gross systemic incompetence in their security organization.
In no universe can this: "A threat model is a collaborative security exercise where we evaluate and validate the design and task planning for a new or existing service." be considered the definition of a threat model. It mentions nothing of "threats" or modeling them and at no point in the article do they describe actual threat modeling, so this is not a disconnect between definition and action. They also mention: "Then, holistically evaluate the entire surface area and develop the most likely points of compromise. This is the key deliverable." which again completely misses the point of threat modeling as that is identifying where they are weak, not where they will be attacked (though they are likely to be related). This is conflating "know your self" and "know your enemy" which is ridiculous. What they appear to actually be describing in the article is the most rudimentary security process of actually evaluating their own systems which is a prerequisite for a functional security process since you can not shore up weaknesses without understanding where they are. So, my best possible interpretation is that their security organization seems to think "threat modeling" is a catch-all term for any security process which is a baffling degree of institutional incompetence.
The way I threat model is I use a tool I developed and a conversation with PMs and devs/architects to determine each thing we're protecting, the current state of what we plan to use to protect it, who we're actually protecting it from, and the tech stack it depends on.
It creates a bunch of visualizations that everyone up and down the chain can understand quickly, which update dynamically as we add new security features, and which reflect complete tracability of the technical reality from an engineering perspective, along with a gap analysis that product, security, engineering, compliance, and security can reason about. The side effect is a visual security architecture, and an objective attack surface for your post-controls like VAs and pen-tests.
Then the tool automatically generates epics and stories that import into Jira so we can build security controls as features and manage them in iteration planning and standups.
Just this week I put a 50 page architecture doc through it in about an hour and provided an agency director with a concrete security posture that demonstrated how it had lots of controls for prevention, but none to detect or respond to the threats we actually cared about, and that this should be the substance of their conversation with the vendor.
If you want to know why you should threat model, I'm also using it to support the sales org at a new security product company by modelling the security of target customers' products and showing how their authN product fills gaps it illustrates in the customer's products, and I use it personally for fast modelling attack surfaces on gigs. One client called it the "Deloitte killer," because it does in a couple hours what big-5 consultancies take weeks and $50k to do. That's generous, as people hire those companies for compliance and not to build better products. My tool is not a product because it alienates other security and compliance people, and product/project people mostly care about having them onside. My personality probably doesn't help either. :)
IMO, STRIDE is bike shedding. Real threats are counter-cases to your product's business model.
Off-topic: I found it hard to parse "How we threat model"; the sentence is grammatically incorrect. It should either be "How we model threats" or "How we threat-model".
"Model" by itself can be used in the verb sense, but I'm having a hard time accepting the model in "threat model" as a (qualified?) verb.
9 comments
[ 42.1 ms ] story [ 780 ms ] thread- this methodology lacks what I think is a good threat model: a list of attacks your system wants to defend against, attacks that are not in scope, and the attacker model (attacker has access to the network at all time, can tamper with traffic, etc.)
- likelihood of each attack vector helps prioritization of work
- STRIDE sucks in my opinion, but it’s a good start for people who have no clue about threat modeling. Are there any other models like that to follow?
- frequency: this overlooks how hard it is to get devs to go through that work, taking into accounts that people are always busy. How do you streamline this process and how do you argue for the value of repeating this exercise frequently?
- different types of threat models: what about deployment? What about updates? What about ci/cd? All of these have threat models as well.
- different layers of threat models: I like the idea of a global threat model managed by the security team with sub threat models managed by teams owning different components, as these can help guide design decisions For new features and refactors
In no universe can this: "A threat model is a collaborative security exercise where we evaluate and validate the design and task planning for a new or existing service." be considered the definition of a threat model. It mentions nothing of "threats" or modeling them and at no point in the article do they describe actual threat modeling, so this is not a disconnect between definition and action. They also mention: "Then, holistically evaluate the entire surface area and develop the most likely points of compromise. This is the key deliverable." which again completely misses the point of threat modeling as that is identifying where they are weak, not where they will be attacked (though they are likely to be related). This is conflating "know your self" and "know your enemy" which is ridiculous. What they appear to actually be describing in the article is the most rudimentary security process of actually evaluating their own systems which is a prerequisite for a functional security process since you can not shore up weaknesses without understanding where they are. So, my best possible interpretation is that their security organization seems to think "threat modeling" is a catch-all term for any security process which is a baffling degree of institutional incompetence.
It creates a bunch of visualizations that everyone up and down the chain can understand quickly, which update dynamically as we add new security features, and which reflect complete tracability of the technical reality from an engineering perspective, along with a gap analysis that product, security, engineering, compliance, and security can reason about. The side effect is a visual security architecture, and an objective attack surface for your post-controls like VAs and pen-tests.
Then the tool automatically generates epics and stories that import into Jira so we can build security controls as features and manage them in iteration planning and standups.
Just this week I put a 50 page architecture doc through it in about an hour and provided an agency director with a concrete security posture that demonstrated how it had lots of controls for prevention, but none to detect or respond to the threats we actually cared about, and that this should be the substance of their conversation with the vendor.
If you want to know why you should threat model, I'm also using it to support the sales org at a new security product company by modelling the security of target customers' products and showing how their authN product fills gaps it illustrates in the customer's products, and I use it personally for fast modelling attack surfaces on gigs. One client called it the "Deloitte killer," because it does in a couple hours what big-5 consultancies take weeks and $50k to do. That's generous, as people hire those companies for compliance and not to build better products. My tool is not a product because it alienates other security and compliance people, and product/project people mostly care about having them onside. My personality probably doesn't help either. :)
IMO, STRIDE is bike shedding. Real threats are counter-cases to your product's business model.
"Model" by itself can be used in the verb sense, but I'm having a hard time accepting the model in "threat model" as a (qualified?) verb.