RE: one use for taxonomies

["Mark Curphey" <mark () curphey com>]

Isn't that called a pattern ? ;-) 

-----Original Message-----
From: Frank O'Dwyer [mailto:fod () littlecatZ com] 
Sent: Saturday, July 16, 2005 12:11 AM
To: Mark Curphey
Cc: 'Brenda'; 'Andrew van der Stock'; webappsec () securityfocus com
Subject: Re: one use for taxonomies

Just to clarify...by 'same old same old'...I don't mean 'same old crap'.

I mean that if you take 1,000 applications and separate them into those that
are 'good' in terms of security and those that are bad (which will be most
of them), the good ones will be remarkably similar in what they do.

The bad ones will have much more variety, but still be remarkably similar in
what they should have done :-)

When it comes to implementing good countermeasures every time - and the good
countermeasures do not vary on a weekly basis -  nothing insane about that -
you don't *want* different results.

Cheers,
Frank

Mark Curphey wrote:

> The main aim of the www.threatsandcountermeasures.com web site is to 
> build such a community knowledge base of threats and countermeasures 
> that is technology independent.
>
> As a side note the clinical definition of insanity is to do the same 
> thing repeatedlty and expect different results ;-)
>
> -----Original Message-----
> From: Frank O'Dwyer [mailto:fod () littlecatZ com]
> Sent: Friday, July 15, 2005 3:34 PM
> To: Brenda
> Cc: Andrew van der Stock; webappsec () securityfocus com
> Subject: Re: one use for taxonomies
>
> Brenda wrote:
>
>  
>
> > Andrew,
> >
> > 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.
> Cheers,
> Frank.
>
> [...much good stuff deleted ...]
>
>