RE: Threat Modelling

["Brewis, Mark" <mark.brewis () eds com>]

> > 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 
> > threat modeling
> > process of the type defined in writing secure code etc I 
> > think that would be
> > great. 

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

Cheers,

Mark