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_at_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_at_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_at_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
>
>
>
>
>
Received on May 21 2004
Intro
