
How we threat model - arkadiyt
https://github.blog/2020-09-02-how-we-threat-model/
======
baby
Thanks for the article! Some comments:

\- 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

~~~
Veserv
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.

------
mangamadaiyan
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.

------
segfaultbuserr
The automatic anti-clickbait algorithm screwed the title again. Please re-add
the word "How".

------
motohagiography
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.

~~~
baby
Still interested in the tool

~~~
motohagiography
Thanks! This is a bit ugly and it's been cleaned up since, but for public
consumption, it's described here:
[https://www.qtra.io/simpletm](https://www.qtra.io/simpletm) .

------
rbolla
tl:dr; Microsoft's Thread Modeling tool OWASP's Threat Dragon.

