"Risk management" is just a fancy term for the cost-benefit tradeoff associated with any security decision. It's what we do when we react to fear, or try to make ourselves feel secure. It's the fight-or-flight reflex that evolved in primitive fish and remains in all vertebrates. It's instinctual, intuitive and fundamental to life, and one of the brain's primary functions.

Some have hypothesized that humans have a "risk thermostat" that tries to maintain some optimal risk level. It explains why we drive our motorcycles faster when we wear a helmet, or are more likely to take up smoking during wartime. It's our natural risk management in action.

The problem is our brains are intuitively suited to the sorts of risk management decisions endemic to living in small family groups in the East African highlands in 100,000 BC, and not to living in the New York City of 2008. We make

systematic risk management mistakes -- miscalculating the probability of rare events, reacting more to stories than data, responding to the feeling of security rather than reality, and making decisions based on irrelevant context. And that risk cockpit of ours? It's not nearly as finely tuned as we might like it to be.

Like a rabbit that responds to an oncoming car with its default predator avoidance behavior -- dart left, dart right, dart left, and at the last moment jump -- instead of just getting out of the way, our Stone Age intuition doesn't serve us well in a modern technological society. So when we in the security industry use the term "risk management," we don't want you to do it by trusting your gut. We want you to do risk management consciously and intelligently, to analyze the tradeoff and make the best decision.

This means balancing the costs and benefits of any security decision -- buying and installing a new technology, implementing a new procedure or forgoing a common precaution. It means allocating a security budget to mitigate different risks by different amounts. It means buying insurance to transfer some risks to others. It's what businesses do, all the time, about everything. IT security has its own risk management decisions, based on the threats and the technologies.

There's never just one risk, of course, and bad risk management decisions often carry an underlying tradeoff. Terrorism policy in the U.S. is based more on politics than actual security risk, but the politicians who make these decisions are concerned about the risks of not being re-elected.

Many corporate security decisions are made to mitigate the risk of lawsuits rather than address the risk of any actual security breach. And individuals make risk management decisions that consider not only the risks to the corporation, but the risks to their departments' budgets, and to their careers.

You can't completely remove emotion from risk management decisions, but the best way to keep risk management focused on the data is to formalize the methodology. That's what companies that manage risk for a living -- insurance companies, financial trading firms and arbitrageurs -- try to do. They try to replace intuition with models, and hunches with mathematics.

The problem in the security world is we often lack the data to do risk management well. Technological risks are complicated and subtle. We don't know how well our network security will keep the bad guys out, and we don't know the cost to the company if we don't keep them out. And the risks change all the time, making the calculations even harder. But this doesn't mean we shouldn't try.

You can't avoid risk management; it's fundamental to business just as to life. The question is whether you're going to try to use data or whether you're going to just react based on emotions, hunches and anecdotes.

This essay appeared as the first half of a point-counterpoint with Marcus Ranum in Information Security magazine.

Among other dissection highlights, Hochberg pulled out plastic-like pieces, which comprised what could be best described as a backbone, as well as a translucent brownish-yellow piece of the beak, which is made of fingernail-like material. The giant squid's anatomy features a mouth at the top of the head, which means the esophagus travels through the brain. "So you have to get very small chunks of food," said Hochberg, "or you'll blow your brains out." The sharp beaks, then, are used to chomp food into tiny pieces before sending it down the esophagus, through the brain, and into the gut.

1. The Sun-Sentinel newspaper in Fort Lauderdale accidentally republishes a six-year-old news story about the bankruptcy of UAL. It wasn't on the home page, but instead buried somewhere inside the web site.
2. Google's news crawler (an automated thing, remember) finds the story and incorporates it as part of its news feed.
3. Investors see the story, and immediately react. When UAL's stock plunged 76% to a low of $3, Nasdaq shut down trading. Eventually trading resumed, and the stock closed at just under $11, losing about 11%.
4. United blamed Tribune Company (the owner of the Sun-Sentinel) for "irresponsibly" changing the date on the story and demanded a retraction.
5. Tribune Company blamed Google, claiming they've had issues with Google's crawler "for months."

Who will blame be shifted to next?

Look -- if people haven't realized by now that the Internet pretty much lacks a delete function, then (IMNSHO) it becomes the requirement of each and every one of us to pay close attention to what we're reading, to use our own big brains and fine-tuned bullshit detectors to suss out whether something makes sense.

Since this is my blog, I'm going to parcel out blame the way I see it:

• United: 0%. If the concept of "negative blame" made any sense, then I'd actually write −∞ (that's a negative infinity, in case your character set is different than mine).
• Google: 5%. How can an automated crawler know that a newly-dated story isn't really new? Well, those folks over there at Google are smart. Certainly it shouldn't be that difficult to compare a "new" article against existing ones. Content hashes won't work as a comparison tool, because the date would be included in the hash computation, thus making the hashes different anyway. Full-text comparisons? Sure, it would take a lot of horsepower. Perhaps not every "new" story needs comparison, but at least the crawler could submit to the comparator any stories that ought to be verified (say those with the word "bankruptcy" in them).
• Tribune Company: 30%. Hey guys, you changed the date on the article. Don't go blaming someone else for your screw-up.
• Investors: 65%. If you're using an automated news aggregator (remember, an aggregator is not a source of news) to make major financial decisions -- decisions that affect the livelihoods of thousands (maybe millions) of people -- well, you're a moron. You should know that incorrect information can be just as instantly available as correct information. Verify potentially damaging claims before engaging in reckless behavior.

What's this got to do with security? I don't know, maybe nothing directly related. But it certainly raises the question -- what if someone intentionally wanted to cause nearly permanent damage to a person or a corporation? Malicious content, disguised as "news," certainly seems to have become a potentially successful attack vector this week.

Worried about a social engineering attack on a massive scale? I suspect that what happened Monday (8 September) was the largest social engineering attack in history -- although I wouldn't classify it as intentionally malicious. Just you wait until the idea spreads.

This post is intended to member of the Black Hat Bloggers Network and others who blog on security.  When we announced our affiliation with the Black Hat folks, we said that between now and the show in August we would pick topics of interest tied to presentations at Black Hat for us to "shine a light on".  With over 150 blogs in the network, if even a small percentage of us write on one particular topic that should be quite a concentration.  I am looking forward to see the many different tangents our members will take these topics. 

Our first topic comes to us from an SBN member who will be presenting at Black Hat. It is one of our resident big brains, Chris Hoff talking about virtualization and security. I asked Chris to give me a quick write up on what he is presenting and here it is:

This talk will clearly demonstrate that unless we radically rethink our approach, the virtualization security apocalypse is nigh!

• Some security things you do today are perfectly reasonable and work well in virtualized environments, others simply don???t work at all
• Virtualized Security can seriously impact performance, resiliency and scalability
• Replicating many highly-available security applications and network topologies in virtual switches don???t work
• Monolithic security vendor virtual appliances are the virtualization version of the UTM argument
• Virtualizing security will not save you money, it will cost you more

You can read more on this at Chris's blog here. So bloggers here is the deal.  You have what Hoff thinks, what do you think.  Wrap your heads around virtualization and security and lets hear what you have to say.  We will all be reading!  ON YOUR MARK, GET SET, BLOG!

This post is intended to member of the Black Hat Bloggers Network and others who blog on security.  When we announced our affiliation with the Black Hat folks, we said that between now and the show in August we would pick topics of interest tied to presentations at Black Hat for us to "shine a light on".  With over 150 blogs in the network, if even a small percentage of us write on one particular topic that should be quite a concentration.  I am looking forward to see the many different tangents our members will take these topics. 

Our first topic comes to us from an SBN member who will be presenting at Black Hat. It is one of our resident big brains, Chris Hoff talking about virtualization and security. I asked Chris to give me a quick write up on what he is presenting and here it is:

This talk will clearly demonstrate that unless we radically rethink our approach, the virtualization security apocalypse is nigh!

• Some security things you do today are perfectly reasonable and work well in virtualized environments, others simply don’t work at all
• Virtualized Security can seriously impact performance, resiliency and scalability
• Replicating many highly-available security applications and network topologies in virtual switches don’t work
• Monolithic security vendor virtual appliances are the virtualization version of the UTM argument
• Virtualizing security will not save you money, it will cost you more

You can read more on this at Chris's blog here. So bloggers here is the deal.  You have what Hoff thinks, what do you think.  Wrap your heads around virtualization and security and lets hear what you have to say.  We will all be reading!  ON YOUR MARK, GET SET, BLOG!

This post is intended to member of the Black Hat Bloggers Network and others who blog on security.  When we announced our affiliation with the Black Hat folks, we said that between now and the show in August we would pick topics of interest tied to presentations at Black Hat for us to "shine a light on".  With over 150 blogs in the network, if even a small percentage of us write on one particular topic that should be quite a concentration.  I am looking forward to see the many different tangents our members will take these topics. 

Our first topic comes to us from an SBN member who will be presenting at Black Hat. It is one of our resident big brains, Chris Hoff talking about virtualization and security. I asked Chris to give me a quick write up on what he is presenting and here it is:

This talk will clearly demonstrate that unless we radically rethink our approach, the virtualization security apocalypse is nigh!

• Some security things you do today are perfectly reasonable and work well in virtualized environments, others simply don’t work at all
• Virtualized Security can seriously impact performance, resiliency and scalability
• Replicating many highly-available security applications and network topologies in virtual switches don’t work
• Monolithic security vendor virtual appliances are the virtualization version of the UTM argument
• Virtualizing security will not save you money, it will cost you more

You can read more on this at Chris's blog here. So bloggers here is the deal.  You have what Hoff thinks, what do you think.  Wrap your heads around virtualization and security and lets hear what you have to say.  We will all be reading!  ON YOUR MARK, GET SET, BLOG!

Somebody asked me: "That's great that you have such a clear  vision of a future log management technology - but tell me first what future business problems will such 'ideal tool of the future' solve?"

First, I laughed and said: "Dude, look around, will ya? :-) There are plenty of log-related problems today which we are not even close to solving. We need to solve the problems of today first, before we can get to solving the future problems..."

So, what I consider to be the biggest log-related problems of today?

1. Not knowing what to log - whether  for compliance, tracking attackers or troubleshooting system problems. Remember all the comedy about "Tell me EXACTLY what to log for PCI?" If not, reread it!
2. Log volume  - there is too darn many log messages (seriously, 100,000 each second is a lot of log - but there is more at large companies!), and, which is worse, a lot of them are of unknown value to the users (might be useful, might not - but you never know in advance); thus, log clutter networks, systems and brains of security/system analysts.
3. Log diversity - logs all look different (at least while standards are being developed) and no single person have the skill set to understand  more than a few types. PIX admin groking SAP logs? No way!
4. In light of the above, just pure bad logs are also a major challenge - logs that miss a key piece of info (like the infamous "login failed" without the username...) or are useless in some other way are sadly common.
5. How about getting the logs from all the nooks and crannies where they are stuck  (think application logs here) - it is a problem if you want to achieve  (expand, rather) your operational awareness of applications.
6. Finally (not really, the list can go on and on), making sense of logs in  an automated fashion is still a #1 challenge  (IMHO) - we are getting better creating tools for humans to go thru logs (via reports and search), but log->conclusion process still requires a human, and a darn smart one.

Now, when you read the above think "end user", not "log management  vendor" challenges (I plan to post about these later). My idea of an ideal tool will seek to solve these and others.

Along the same line, this picture from 4th SANS Log Management Survey shows how people perceive the logging challenges:

as well as my logging challenges poll (analysis here):

Now, let's think of logging problems of the near future, say in 2 years.

But you'd have to wait for the next post for this :-)

The answer to this is usually “yes and no”. I know, helpful, right?

The first thing we have to understand before answering is- is this a completely light AP solution, or is it ‘semi-light’. These are my terms and each manufacturer has their own verbiage they’ll use, but the concepts are the same.

In a completely light AP product, the controller has the brains, and the APs are dumb. For all practical purposes here, the APs are just radio antennas. They know nothing, and every packet is sent back through the controller for processing. Generally a fully light AP will not even have an IP address.

With a semi-light AP product, the controller does most of the work (usually anything routed or not local) and the APs have enough sense to process local traffic.

Scenario. Imagine a controller at a central office, connected to a light AP at another location (across the WAN). If it’s a completely light AP, it will send every bit of traffic over the WAN, to the controller. Not a great idea if you have medium-heavy wireless usage and a small WAN pipe. You’ll find you can quickly eat your bandwidth with your wireless traffic. If it’s a semi-light solution, the AP can process local traffic, for example a wireless user that wants to send a print job locally.

Processing local requests at the AP cuts down on the amount of traffic that has to traverse the WAN and is generally the way to go if you want a single central controller and remote APs.

If you decide you just have to run a completely light AP solution across the WAN, be sure your pipe is big enough and your usage low enough to support that configuration. Note that ‘big enough’ and ‘low enough’ are always relative and you’ll need to do a little experimenting to get the right threshold for your environment.

# # #