mailing list archives
RE: Threat Modelling
From: "Brewis, Mark" <mark.brewis () eds com>
Date: Mon, 24 May 2004 01:00:43 +0100
Mark Curphey wrote:
Sent: 23 May 2004 14:22
In general IMHO this conversation started discussing apples (threat modeling to build better technical
solutions) and is now trying to compare oranges to apples (info sec management of systems).
Agreed; the discussion has moved from the modelling necessary for the secure coding of an app. or the pentesting of
that app. into assessing the wider holistic security environment. That's great, if that is what I want to do. If a
wanted to define a test strategy, or identify generic class vulnerabilities in an app. under development, that doesn't
meet my needs. I wanted a screwdriver, and you've passed me a monkey wrench. They are both tools, and both supply
rotational force, but they don't do each others job. As a community (writ large), we don't seem to be able to define
what we mean particularly clearly. We've been having the penetration test/vulnerability scan/security audit debate for
years, and this is just another variation. I've used "threat modelling", both in the way Mark and others define it and
as a part of a traditional risk assessment, defining it in context each time I've used it. It is a useful phrase,
probably too useful to be monopolised either way.
I actually think you probably hit the nail on the head when
you talk about
"applications of this class". The detail you elude to I have
never seen in
any RA tools. If it were it would be able to support the
process of the type defined in writing secure code etc I
think that would be
Perhaps we need to look at Webapp testing tools in a new light. At the risk of making gross generalisations, a trend
in tools is that they start off doing something niche, then grow and change. If you design a tool which catalogues web
vulns, the logical development path is to make them look for those vulns. You turn a database into a scanner, because
that is less niche, and potentially more marketable (whatever your market is - it isn't just a commercial thing.) Now,
I don't know whether any webapp. testing tools started as someone's list of vulnerabilities in products, or
technologies, but they certainly contain some of that level of detail. The trick will be to turn them around so that
developers know what to avoid, rather than pentesters knowing what to look for.
I'm in danger of sounding monotonous, but I'm going to mention the L3 tool again, because it is a good example. It was
an interesting, flexible database that allowed you to define your risks/threats (some predefined, others user
generated), and then allocate those classes to a host. You turned the handle, it did weighted calculations and gave
you a risk value and countermeasures to your threats, if there were any countermeasures defined. It did lots of other
things, network mapping etc, none of them as well as competitors, but which were seen as important, flavour of the
month developments, where technical risk assessment wasn't. In the end there was too much functionality, not enough
core identity, not enough market share, and it went.
It may be that there wasn't a marketplace for a technical threat modelling tool then. It may be there isn't a
marketplace quite yet. It may be that OWASP has to kick start the development.
But for modeling technical security of software designs, I
have to say I
still don't believe high level risk assessment tools have a
strong place to
I'm not sure they have any - you spend too long trying to get them to fit, trying to do something useful. Spanners and
monkey wrenches again.