Ian,

To clarify, I just said that security people by large are familiar with concepts of probabilities (the point that Paul Ohm in "the Myth of the Superuser", referred in the previous post, seemed to deny).

If you ask me, security is about risk, economics, psychology and usability together (as well as politics), hence solving the problems by concentrating on any single of those things would unlikely to be successful.

old, long winded post about the thread between risk management and information security http://www.garlic.com/~lynn/aepay3.htm#riskm

for little side track ... risk management is more than security issues ... "insurance" traditionally is part of a risk management toolkit and used for things far from traditional security issues. for other issues see BIS and BASEL
http://www.bis.org/publ/bcbsca.htm

in the past, i've hypothesized that there have been instances where a risk adverse organization has avoided addressing a problem (say ISP with regard to incoming/ingress from their customers ... filtering long before it got to the destination end) since they might then be held accountable if the measures weren't perfect (and then got sued). They sidestepped liability by doing nothing (at least until some sort of gov. authority steps in and mandates something)

some of these scenarios is that not doing something might put their customers at risk ... but wouldn't directly affect the institutions. doing something that turned out to be not one hundred percent perfect created more risk and liability to the institution than doing nothing.

this old post is about security (aka countermeasures) proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

where the value to the attacker is several times larger than the value to the defender ... and is somewhat related to the whole "naked transaction" discussion
http://www.garlic.com/~lynn/subintegrity.html#payments

from a slightly different perspective
http://www.garlic.com/~lynn/2007k.html#12

i also had these discussions/arguments in the early & mid 90s about ISPs being able to just about eliminate IP-address spoofing and DOS attacks with ingress filtering (this was before botnets and DDOS attacks).

when we were working on the financial industry privacy standard (including some of the discloser issues), we made the comment that it was going to require some culture change for institutional risk and security professionals. traditionally, institutional risk & security professionals were looking at protection of the institution. various gov. mandates were forcing institutional risk & security professionals to start thinking about protecting the institution's customers (in some of the scenarios even protecting the customers from the institution).

"Are there limits to the risk management approach, beyond the fact that it seems to be beyond the capabilities of the industry?"

The past two days I've had the pleasure of sitting with the best and the brightest in the state of Ohio in an all Infragard/ISSA/ISACA event. About 300 people. Now I don't know all of them, but those I do know encompass Ohio's largest retailers, F.I.'s and other Fortune 500's.

I can count on one hand the number of companies who:

1.) Have a risk management approach

2.) "Get it"

I think it's too early to say that there *even exists* a risk management approach (not analysis or assessment, or remediation of vulnerabilities with some probability dust sprinkled on the VM lifecycle, but *risk management*). Not as I know risk, certainly not.

When I started studying compsci in 1985, my professors told me that C was a bad programming language because it wasn't type-safe, and that there were "security implications." Nevertheless, when I graduated, I and everyone else doing significant programming work among my fellow students was using C.

With the runtime architecture of C and C++, any programming mistake has the potential of allowing an attacker to inject arbitrary code by overwriting a return address or a function pointer. In March, an exploit was published for OpenBSD, which overwrote a function pointer in the heap of the kernel and gave an attacker full control of the machine. The bug had been present for years. Is there anyone who doubts that in 50 years, all operating systems now in use will be considered ludicrously unsafe?

As long as we are sticking with a runtime architecture that allows an attacker to potentially let any program function as anyprogram, risk management is an euphemism for crisis management.

re:
http://www.garlic.com/~lynn/aadsm27.htm#11 Is this Risk Management's Waterloo?

i.e. insurance, alarms, bumpers, guard rails, etc are all types risk mitigation.

possibility is that with regard to information systems, very few people have any fundamental understanding of related threats, vulnerabilities, etc. ... i.e. w/o any fundamental understanding how information systems operate ... any treat and vulnerability analysis will miss enormous number of issues.

for slightly related topic drift
http://www.garlic.com/~lynn/aadsm27.htm#12 Owned .gov machines (was Re: Russian cyberwar against Estonia?)

the above is specific with regard to implementations that evolved from a non-hostile and disconnected environment with few or little countermeasures.

now some of the more systems that are considered quite a bit more secure 1) have been implemented in languages other than "C" and are remarkably free of the buffer overrun/overflow types of exploits and 2) originally assumed a potentially hostile environment and so risk mitigation permeates all aspects of design and implementation.

for other drift ... my work on merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

I've drawn on numerous sources for merged security taxonomy and glossary
http://www.garlic.com/~lynn/secure.htm

click on "risk management" in the glossary "fastpath" and there are broad range of definitions ... some specific to information systems and others more general.

from GAO 06-91:

A continuous process of managing through a series of mitigating actions that permeate an entity's activities, the likelihood of an adverse event and its negative impact. Risk management addresses risk before mitigating action, as well as the risk that remains after countermeasures have been taken.

... snip ...