Home page logo

webappsec logo WebApp Sec mailing list archives

Re: one use for taxonomies
From: "Frank O'Dwyer" <fod () littlecatZ com>
Date: Fri, 15 Jul 2005 23:33:55 +0100

Brenda wrote:


I completely agree that the point of threat modeling is to analyze
business risks, and I also agree that as currently formulated, a threat
model with lots of technical details is difficult to use for business
risk analysis.

I'd like to suggest a different and possibly heretical view, which is
that maybe you don't need an (explicit) threat model at all. My reason
for saying that is for any of the formal analysis I've seen, it doesn't
lead to a different outcome, compared to much simpler and less formal
approaches (it depends on the approach, of course).

If you step back and look at the ultimate goal, it is to implement a
system [or a system dev lifecycle] with effective countermeasures
(technical and non-technical). The question is, which countermeasures
will those be? Most formal analysis tends to consider that question
along the following lines (hugely simplified):

1. Consider business impact
2. Consider attacks
3. Consider vulnerabilities
4. Consider likelihood
5. Build a threat model
6. Prune attack tree
7. Generate countermeasures to block remaining attacks
8. Implement the same old same old, the same stuff you would have
implemented if you hadn't done any of that.

Basically, you could just proceed direct to step 8 (I'm exaggerating,
but not all that much).

The thing is if the sort of question you will ultimately answer is
something like "gee, I wonder which transport security protocol we will
use THIS time. Will it be SSL/TLS, or, um...I'm sure there was another
one" - well, why not just cut to the chase?

Or what about authentication, which of the 2 and a half practical
options will you use there?  Are buffer overflows still a problem, or
has that changed since the last time we built a threat model? Hmm, might
we benefit from a firewall? Input validation? Audit trail? Encryption?
And so on. You are basically choosing between well known security design
patterns, or "security's greatest hits", and actually there aren't all
that many of those (certainly a great many less than there are detailed
attacks and vulnerabilities).

(I'm not saying threat models aren't ever useful, by the way, just not
necessarily for the problem they are put forward for. One area where I
think they could be useful is arriving at some formal justification of
which countermeasures are good (for example in the sense of reduction of
attack surface), although in many cases we already have a reasonable
hunch about the answer there too, still a formal justification would be
nice. I'm guessing you don't need an actual app to analyse there,
either. You could perhaps generate trees of attacks at random, and see
which countermeasures work best).

I guess what I am really saying here is that since you generally want
the sort of countermeasures that operate at a high level in the tree,
and therefore counter everything below, plus other things as yet unheard
of, you don't need to build a deep tree. Or at least that type of
chunked up , fuzzy model will get you most of the way there. The rest,
as you say, is an art.

Actually I can think of very few factors that DO lead a variation in
outcome. Off the top of my head, these are:

1. The overall worst case business impacts for confidentiality,
integrity, and availabilty (for those who wish to focus more expensive
and effective controls on potential high value losses)
2. The technology/architecture you use (affects how you implement the
same old countermeasures, also not using a technology means you can
discard threats - and hence countermeasures - that are only relevant for
that technology)
3. The environment your app will deploy in (this is another shorthand
for a very chunked up threat model - different environments have
different threats, so not being in a particular environment means not
having to care about a basket of threats peculiar to that enviroment,
and so the associated countermeasures aren't relevant either)
4. The infrastructure you use (infrastructure may implement
countermeasures so you don't need to)
5. A handful of well-aimed questions which may indicate you need less or
more countermeasures

One way to implement that whole process is to start with the complete
set of countermeasures you can ever imagine being useful, and
systematically delete those that be easily justified as not being
relevant to the case in hand, or which don't have the right
cost/benefit. And actually a lot of that can be automated too. I've got
some code that does a proof of concept of that, which I intend to
release (GPL) as soon as I get a minute to do so. It would be
interesting to see if your code and mine could be made to use the same
knowledge base of countermeasures. It is all XML based so maybe some
kind of mapping is possible.


 [...much good stuff deleted ...]

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]