Re: Threat Modeling

["Frank O'Dwyer" <fod () littlecatZ com>]

We've developed our own Risk Assessment Methodology (LCZ-RAM). Although 
we've built commercial tools around it, the process itself and the 
security content for it are open. We also intend to give away a free 
version of the supporting software - look for an announcement from us on 
this in the coming weeks.

We are still evolving our approach and welcome feedback on it, but we 
believe it already has a number of advantages over more academically 
inclined methods such as CRAMM or penetration graphs. In our experience 
such approaches tend to fail in the real world because they are too 
complex and long-winded and/or because they pretend to be able to model 
and quantify things which are inherently vague, controversial or 
unknown. These methods also typically do not take into account the 
political realities of getting security countermeasures accepted, paid 
for and implemented. Another reality which is not usually acknowledged 
is that in terms of countermeasures, when you get down to it you are 
usually choosing from a very limited set of options. If you only have 2 
methods of authentication available to you, then it doesn't take a great 
deal of analysis to make that decision.

We do not model threats and likelihoods explicitly, because for one 
thing this information is usually not known, or not reliable, and 
secondly because in practice this kind of exercise makes (or should 
make) no real difference to the countermeasures that you wind up 
choosing in the end, and last but not least because that's a really bad 
and dangerous way to design security. In the real world you don't weigh 
up the likelihood of various types of car crash on a particular stretch 
of road, the value of each of your limbs, the availability of blood 
donors for your blood type, etc., before fastening your seat belt or 
fitting an air bag, you either do it routinely "just in case" or you 
don't. Similarly when designing a web app you don't need to go through a 
huge penetration graph exercise to find out what level of authentication 
to use today, or whether a certain type of web attack can be ignored 
here or not. Nobody needs to go through lengthy analysis to see if it 
might be safe to leave out some OS patch on an "unimportant" system 
because the associated attack is not "likely". It's obvious at a glance 
that kind of optimisation would be stupid and dangerous - much cheaper 
and simpler to just do it by default, just in case, and to deal with 
exceptional cases as they arise. Most security countermeasures are like 
this.

Similarly we don't attempt to make a list of assets and value them, 
because this really makes no observable difference to the outcome in 
terms of countermeasures, compared to much simpler approaches. All of a 
business's assets have some importance or the business wouldn't have 
them. The business process that a system automates and the assets 
involved are either extra important or they are of normal importance, 
otherwise you wouldn't need the system. The system either has super 
confidential information or it doesn't, it has unusual availability 
requirements or it doesn't, and so on - 20 minutes of looking at the 
overall business impact if security controls fail is usually enough to 
establish this. Moreover this is only relevant in the first place if 
some of your available countermeasures are especially costly - if not 
then you should just do them all routinely anyway, irrespective of the 
system's importance.

In general available countermeasures can be broken down into three basic 
types: those which you always do (baseline countermeasures), those which 
(for whatever reason, but usually cost) you do only for especially 
important systems (above baseline countermeasures), and those which are 
contingent on the circumstances of the particular system being protected 
(its environment, technologies used, etc). Our approach reflects this - 
we look for an indication of the business importance of the system, the 
environments it will run in, the technologies used, any security 
infrastructure used, and ask any supplemental questions we can to 
eliminate irrelevant countermeasures. From this we then generate a 
checklist or action plan of relevant countermeasures..

Cheers,
Frank

-
Frank O'Dwyer <fod () littlecatZ com>
Little cat Z http://www.littlecatZ.com/

Upcoming events: One day Information Risk Management Seminar - Lord's 
Cricket Ground London - May 26th 2004 - 
http://www.littlecatz.com/seminar.html

aporia () tiscali co uk wrote:

> I've been looking for a free set of threat models, too - no luck, though
> - would be interested to know if you are successful.
>
> _However_ I can recommend a software product called CRAMM.  I don't know
> if you've used it, but basically it's a tool developed by HMG in Cheltenham.
> The great thing about it, and the reason it costs 4,000 GBP is that it
> contains a database of over 3000 threats, vulnerabilities and countermeasures.
>
> It also follows a specific methodology (Crown Copyright), and is aligned
> to BS7799.
>
> Unfortunately, the cost is a significant barrier to using it.  What about
> just buying the BS7799 (about 150 GBP) and ISO TR 13335: Guidelines for
> Management of IT Security (GMIT)? A reasonable starter pack.  This isn't
> fee either, unfortunately.  But it is American.
>
> ---------------
> Ian Ristic [ivanr () webkreator com]
>
>  
>
> > Any links to any free threat modeling tools out there ?
> >    
>
>   Does anyone know what happened to the threat modeling tool
>   Microsoft announced in late 2003?
>
> --
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]
>
> __________________________________________________
> Broadband from an unbeatable £15.99!
>
> http://www.tiscali.co.uk/products/broadband/home.html?code=SM-NL-11AM
>
>
>
>