I’m assuming the author wants us to read the title as “Things to Look Out For in Performing Risk Analysis” and not “Risk Management is Folly - Stop, Stop, Stop!” The former is fine, the latter isn’t supported by the evidence presented by the subjects of the article.
The subjects of the article are a good study from Wade Baker & Co. at Verizon, and a report from RSA’s Security for Business Innovation Council. Let’s take a look at each of these and examine why what they’re saying might contribute to poor risk management, shall we?

1.)  THE VERIZON REPORT

The Verizon report is an analysis of some 530 forensic investigations their company performed.  It is well worth your time as it’s chock full of interesting information.  As it relates to the Dark Reading piece, a coarse summary would be that “likelihood” is “different” for different people and so you can’t use the same “likelihood” across different industries.

Distilled through the lens of FAIR:

“different threat communities may be applicable based on Probability of Action factors which include: Value, Level of Effort and Risk (of Getting Caught).”

Or, even further distilled and in the words of my six year old son,

“Duh-uh”.

With regards to what I assume is the purpose of the article (What Doesn’t Work in Risk Analysis) this concept  seems just to rehash the old GIGO argument regarding risk analysis.  Great.  Can’t argue with that, nor it’s corollary QIQO (quality in, quality out).

But let me ask you -  is this really a problem common in your analysis?  Did reading this article make you go “Crap, we’ve been using data normalized across multiple industries in our analysis! They’re all wrong!”  Or have you already been accounting for the unique value proposition your company has to the specific threat community you’re worried about?  See, maybe I’m just not your average analyst, but even in my NIST/OCTAVE days, this has *never* been an issue for me.

Let me be specific, this is not a problem with Verizon’s very cool report.  It’s just that I don’t see what the big deal is.  This article is starting to feel like someone is running through the motions, trying to play the ” a crazy title gets people to read a boring article” game.

Speaking of cool reports - You know what would be cool?  I think it would be interesting to see is the quality of these companies’ “risk management process” established using good criteria,  and then correlated to the frequency and magnitude of real-world losses across the aggregate sample.  In other words, can we establish evidence that strong risk management practices not just reduce “risk” but also reduce actual incidents.

2.)  THE RSA COUNCIL “EXPLORES WHY LEGACY METHODS OF EVALUATING INFORMATION SECURITY RISK DON’T WORK IN TODAY’S CONNECTED WORLD, IN WHICH ANY NEW BUSINESS INNOVATION INHERENTLY CARRIES SOME LEVEL OF RISK TO INFORMATION.”

This report from the RSA council puts forth a seemingly obvious proposition, that risk must be balanced by reward.  Why is this news?  Now as I read the article it’s not clear if:

• The RSA Council is claiming that the CISO’s office should be the ones determining reward.  Absurd.

or

• Businesses aren’t doing a good job at determining risk and reward.

Let’s go with the latter.  So I’m pretty sure (good) businesses do a good job at estimating reward.  Businesses I’ve been a part of?  We LOVE(D) estimating reward.  We don’t tend to start projects all willy-nilly. No we tend to be careful to identify the size of the market and what it will cost to address the market.  So what could the problem be that this RSA council is trying to address?  Maybe it has to do with something like the following:

Yesterday, I got a demo of an IT-GRC application that shall remain nameless.  It seemed to be very good at the “C” bits - lots of information on regulations and expectations and even what sorts of controls would answer the regulations (which is goofy, but we’ll have to talk about that later).  It also gave you the ability to build workflow quite nicely.  But it measured NOTHING.  There really was no observable “G” and “R” was really Medium X Low X Low = High sorts of stuff.  So let’s use this relatively expensive tool as evidence of what your average CISO is armed with going into a Risk/Reward sort of meeting.  I imagine a nice board room with wood-grain paneling and glass bowls filled with little chocolate covered mints designed to give everyone involved in the meeting (CEO, CFO, CIO, CSO, VP S&M, etc…) a little sugar rush when needed and fresh breath.  The conversation goes a little something like this (apologies to Rich):

Business Guy Who Wants to Make Money Because That’s What Businesses Do: Based on market studies, we believe that initial gross revenues from the new product and technology rollout will be eleventy gazillion dollars based on a 37% market penetration in Scandinavia, alone.

CSO: Well now, we have a likelihood of “High” and a “C” impact of Medium, and an “I” impact of Low, and an “A” impact of “High” and because we are a (bank/hospital/retailer/basically any business that breathes anymore) we weight “C” by a factor of 2 - we multiplied those all together and got a “High”.

So can you guys delay the product rollout by 9 months and give me a bunch more money that’s not in the budget so that I can get this thing down to a “Medium”, please?

Again, I just don’t see the problem with Information Risk Management being that our businesses have no idea what the rewards of business might be.  Now maybe we need get a seat in that boardroom just to be able to talk about our “Mediums”, sure.  And maybe we’re infantile in our ability to describe our problem space.  But I cannot fathom that “Risk Management Doesn’t Work” because businesses haven’t been considering “reward”.

WHY RISK MANAGEMENT MAY  NOT BE WORKIN’ FOR YOU

Two meta-categories of causation:

• No skills

and/or

• No resources

Any ancillary “cause” can be mapped to one of these categories.  You could have significant resources but crappy models, and have conversations like our imaginary CSO, above.  You could have really good models and people trained and motivated to use them, but scarce time & money, so no conversation happens.

Now my question for you is - which does it make sense to acquire *first* to solve the “Why Risk Management Doesn’t Work” problems, skills or resources?

One of the more interesting session I went to yesterday was a talk by Chris Hoff called "The Four Horsemen of the Virtualization Apocalypse."  (If you've never read Hoff's blog, you should check it out at http://rationalsecurity.typepad.com/.)

I thought I was keeping a close eye on security and virtualization issues, but this talk illustrated how wide and varied the topic really is.  This was not about Blue Pill and it wasn't about having security monitors in the hypervisor - instead he focused on how virtualizing physical devices (e.g. switches, systems) will cause lots of problems for security architects and administrators.

Briefly, here are the four horsemen:

• Conquest - Translating your physical capacity planning implementation to virtual devices probably won't work.
• Death - Virtualized networks lack several physical attributes assumed by security applications and high-availability devices today - you'll probably have to re-architect it all to get the same functionality, which might not even be possible in your new virtual world
• War - Adding security VAs takes away precious resources that could have been used to dynamically add VMs.  It is a war of resources.
• Famine - With all of the redesigning and accommodation happening, security costs are going to eat into any savings you make on server consolidation.

Now, if you want to read the much more thorough version, see Hoff's original post here.

Okay, how does this all relate to the title of my post?  Not much.  However, much later on day one, things really started rolling.

After being crowded out of the Shadow Bar, a bunch of us ended up over at Casa Fuente (A cigar bar in Caesars forum).  Five minutes after arriving, someone spilled a drink in my lap, big fun!  It turns out that it was Stepto's birthday, and Hoff makes sure everyone has a drink and we all sing happy birthday to Stepto.  Check out part of it, courtesy of Jack Daniel:

Immediately after the toast, Jennifer Jabbusch knocks over a table, falls to the floor and begins having a seizure. Stepto rushes over, trying to help, and just about that time, she flips over and starts laughing - total fakeout! Everybody bursts out laughing.

Shortly after that, they closed for the night and kicked us out and we all headed over to Cleopatra's Barge. There weren't enough seats or tables for us, but I noticed that the "reserved" barge seating was empty. Drawing upon a clever technique (i.e. sometimes called "asking") I social engineered a waitress into letting us have the reserved area. Within mere minutes, several security geeks are on the dance floor, doing us proud.

This leads me to the Four Horsemen of Cleopatra's Barge.  (Though I was out there too, I am excluding myself since simply because I can.)

• JJ, for leadership
• Hoff, who owned the dance floor.
• Ryan Naraine, for getting low, low, low
• David, for letting his hair down.

Though our collective dancing does not signal the end of the world, it certainly capped an excellent day

The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

This essay previously appeared on Wired.com.

The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

To solve a complex problem in the blackboard-style, the intelligent agents cooperate as functional specialists, observing updates to the blackboard and self-actualizing in an event driven process) when there is new information to process.  Agents continually update the blackboard with partial solutions when the agents capabilities for processing match the state of the blackboard. 

The blackboard architecture is a distributed computing model for a metaphor describing how people work together to collaboratively solve a problem around a blackboard (whiteboard in todays lingo).   For example, one person is standing at the whiteboard working on a solution while three other people are sitting (or standing) around watching.   One of the observers sees new information on the whiteboard, thinks of how he (or she) can contribute, and then jumps up, takes the whiteboard marker from the person working, and adds to the solution.  This process is repeated in various scenarios.  

The blackboard architecture can be very effective in solving complex distributed computing problems, including event processing problems; however, scheduling the self-actuating agents can be a key challenge.   Another core challenge is how to model and manage the blackboard itself, especially in distributed blackboard architectures.  

John McManus, former CTO of NASA, wrote an excellent PhD dissertation in 1992,  Design and Analysis Techniques for Concurrent Blackboard Systems, at the College of William and Mary, addressing challenges in BB systems.

The table below lists two books that focus on blackboard architecture:

One of the thought leaders in blackboard architecture is Daniel D. Corkill a professor at the University of Massachusetts Amherst. 

Blackboard architecture is relevant to the field of event processing, and in particular complex event processing.   I will go into more details in future blog posts on this topic, including how blackboard architectures relate to grid computing, distributed object caching (of the blackboard), and CEP.

Future presidents can learn a lot from all this -- do exactly what the Bush Administration did! If the law holds you back, don't first go to Congress and try to work something out. Secretly violate that law, and then when you get caught, staunchly demand that Congress change the law to your liking and then immunize any company that might have illegally cooperated with you. That's the lesson. You spit in Congress's face, and they'll give you what you want. The past eight years have witnessed a dramatic expansion of Executive Branch power, with a rather anemic push-back from the Legislative and Judicial Branches. We have extensive surveillance on a mass scale by agencies with hardly any public scrutiny, operating mostly in secret, with very limited judicial oversight, and also with very minimal legislative oversight. Most citizens know little about what is going on, and it will be difficult for them to find out, since everything is kept so secret. Secrecy and accountability rarely go well together. The telecomm lawsuits were at least one way that citizens could demand some information and accountability, but now that avenue appears to be shut down significantly with the retroactive immunity grant. There appear to be fewer ways for the individual citizen or citizen advocacy groups to ensure accountability of the government in the context of national security. That's the direction we're heading in -- more surveillance, more systemic government monitoring and data mining, and minimal oversight and accountability -- with most of the oversight being very general, not particularly rigorous, and nearly always secret -- and with the public being almost completely shut out of the process. But don't worry, you shouldn't get too upset about all this. You probably won't know much about it. They'll keep the dirty details from you, because what you don't know can't hurt you.

• VU#484649 - Microsoft Windows DNS Server vulnerable to cache poisoning
• VU#252735 - ISC BIND generates cryptographically weak DNS query IDs
• VU#927905 - BIND version 8 generates cryptographically weak DNS query identifiers