Home page logo
/

webappsec logo WebApp Sec mailing list archives

Re: Threat Modeling
From: "Frank O'Dwyer" <fod () littlecatZ com>
Date: Fri, 21 May 2004 09:44:19 +0100

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





  By Date           By Thread  

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