"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.

Around the same time that Professor Luckham and his team was working on CEP applications in network management and security management, I was leading efforts to build network and security management control centers for the United States Air Force.  In the beginning, dating back to 1994, my Internet-related work was for Air Combat Command (ACC), working out of ACC headquarters at Langley Air Force Base.

In 1997, I lead a technical team that developed countermeasures against an actual distributed Internet-based attack on the Langley AFB SMTP email infrastructure.  This attack was documented in a technical paper, E-Mail Bombs and Countermeasures: Cyber Attacks on Availability and Brand Integrity, IEEE Network Magazine, Vol. 12, No. 2, pp. 10-17, March/April 1998.  In addition, this attackand countermeasures I designed was featured in Popular Science Magazine in an 1998 article, War.Com and other news channels.  I also published a number of related papers on this topic.

Our team used a rule-based approach for countermeasures against massive email bombs attacks on the Langley Air Force Base email infrastructure.   We called this rule-based system, BombShelter. and it was written in PERL.  I developed both the original software architecture and the original working prototype for BombShelter (in two days) and then we turned the software over to our team who used the rule-based approach for daily attack countermeasures.

I watched for days, and then weeks, as my team designed rules, and the attackers wrote new attacks that circumvented the rules.  Some folks in the Pentagon used to say that I “lead the effort to fight the first war in cyberspace”.   It might have have been the first cyberwar, I am not sure, but it was certainly the first publicly documented cyberwar.  There is no doubt about this.

Without getting into all the historical footnotes and significance of this cyberwar that was fought with experts and rule-based systems, I would like to jump to an important conclusion.

Rule-based systems are useful, but have limited functionality and scaleability in most complex event processing applications.

Rule-based systems are human resource intensive because rule-based systems cannot learn and adapt on their own, humans learn and then write new rules.  This is how rule-based systems work.

This is the motivation behind why I spend a lot of time to search for new, more efficient and adaptive methods as alternatives to rule-based systems.   After extensive research, I published a series of papers on the future of intrusion detection in the Internet.  Intrusion Detection Systems & Multisensor Data Fusion - Creating Cyberspace Situational Awareness [1], helped lead an evolution in Internet security, particularly in the area of network-based intrusion detection systems (IDS).

In my published research work, motivated by limitations with rule-based approaches, I used the same mature functional model that is used to process missile attacks, control global air traffic, and other complex event processing applications in physical space; but I applied these concepts to cyberspace.

Around the same time, Professor Luckham and others were working on similar problems, all related to real-time detection and response to threats in cyberspace.  They were also funded by the US government.

Sidebar: Stream processing of transaction- based systems (databases), another area of interest, was focused on a totally different problem, which was the low latency processing of straight-thru processing in databased-oriented systems.   These stream processing systems were, and remain however,  rule-based systems.  The problems we were trying to solve in cyberspace, however, cannot be efficiently and pragmatically solved by rule-based systems alone.  Only relatively simple scenarios can be efficiently detected by rule-based stream processing systems.

The vast majority of complex event processing classes of problems require rules plus advanced algorithms that can learn and adapt in real-time.    I know this, not from reading papers or taking university classes on rule-bases systems, but from working on some very challenging operational problems in real-time.    This is why I remain interested in complex event processing and why I continue to elaborate on why rule-based systems have limitations.

Note that if I want to opt out of further communications, I have to do two separate things -- which actually becomes three things.

• First I have to click the last link to opt out of future TechTarget spam. (Yes, I deleted the actual links. But certainly none of my trustworthy readers would attempt to re-subscribe me, right...? <g>
• But that isn't enough -- I also have to separately opt out of future Avaya spam! (Why does the no-more-from-Avaya link live on a techtargetmail.com server? Whatever.) Clicking on that link eventually does land me on an avaya.com page, where I have to confirm my email address and indicate they don't have my permission to send me spam. Hmm, too difficult to embed my email in that link, when the other techtargetmail.com link did embed my email?
• Then after submitting it, another page pops up telling me that I'll soon receive an email with additional instructions! In this email there's a link -- to avaya.com with my email address embedded -- that I must click, I guess to double plus confirm that yes, I really really really do wish never to hear from you again. Clicking that link takes me to a page that promises my "permissions have successfully been set. Thank you."

A pox on both your houses, TechTarget and Avaya. I never asked for your stuff. Go away.

Spam, my friends, is only going to get worse. It was so easy to ban junk faxes in 1991. But even those regulations were weakened in 2005. So do you really think we'll see anything even remotely logical for outlawing spam? I doubt it, unless we the citizens foment a revolt. Let's get cracking!

Received: from SVC-EXGWY-E801.partners.extranet.microsoft.com (10.251.24.242)
by tk5-exhub-c102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft
SMTP Server (TLS) id 8.1.291.1; Tue, 16 Sep 2008 11:27:56 -0700
Received: from mail139-wa4-R.bigfish.com (216.32.181.113) by
mail04.microsoft.com (10.253.160.184) with Microsoft SMTP Server (TLS) id
8.1.291.1; Tue, 16 Sep 2008 11:27:55 -0700
Received: from mail139-wa4 (localhost.localdomain [127.0.0.1])    by
mail139-wa4-R.bigfish.com (Postfix) with ESMTP id 018C11184C2    for
<steriley@microsoft.com>; Tue, 16 Sep 2008 18:27:50 +0000 (UTC)
X-BigFish: ps16(zz18c1K1936K2b7wcak69jzzzz2af1jz2fh6bh5eh65h)
X-Spam-TCS-SCL: 4:0
Received: by mail139-wa4 (MessageSwitch) id 1221589667478982_28100; Tue, 16
Sep 2008 18:27:47 +0000 (UCT)
Received: from pp.techtargetmail.com (pp.techtargetmail.com [65.211.80.227])
    by mail139-wa4.bigfish.com (Postfix) with SMTP id 46566978071    for
<steriley@microsoft.com>; Tue, 16 Sep 2008 18:27:47 +0000 (UTC)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pp.techtargetmail.com; b=iOmibOrM91/1Ugy2gj3QbWo74T2m3GuhmwxZCXJQpFT+nwRES8QKg+4vjt48SNp7WWJExG61Ge+DtnKD3KVI3KwqTKzkPRVrEBF0DCHhYot6VAG/EyEr5vb5RhBz+91yvNhbIqITzGnuQ+uBDJzyc6gU0FHfBl0Fa3S/phcPELM=;
Message-ID: <a818b044.724694.236c8ee748f7dd97.1.n.4.2971370188@pp.techtargetmail.com>
Date: Tue, 16 Sep 2008 14:27:47 -0400
thread-index: a818b044.724694.236c8ee748f7dd97.1.n.4
Reply-To: Avaya <a818b044.724694.236c8ee748f7dd97.1.n.4@pp.techtargetmail.com>
From: Avaya <Avaya@pp.techtargetmail.com>
To: Steve Riley <steriley@microsoft.com>
Subject: 7 Tips to Ensure Readiness for UC Deployment
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133
Return-Path: a818b044.724694.236c8ee748f7dd97.1.n.4@pp.techtargetmail.com
X-MS-Exchange-Organization-PRD: pp.techtargetmail.com
Received-SPF: Pass (SVC-EXGWY-E801.partners.extranet.microsoft.com: domain
of Avaya@pp.techtargetmail.com designates 65.211.80.227 as permitted sender)
receiver=SVC-EXGWY-E801.partners.extranet.microsoft.com;
client-ip=65.211.80.227; helo=mail139-wa4-R.bigfish.com;
X-MS-Exchange-Organization-PCL: 2
X-MS-Exchange-Organization-Antispam-Report: DV:3.3.6916.600;SV:3.3.6916.813;SID:SenderIDStatus Pass;OrigIP:65.211.80.227
X-MS-Exchange-Organization-SCL: 2
X-MS-Exchange-Organization-SenderIdResult: PASS

The following message was sent to you as a subscriber to third party offers from a TechTarget property, including our network of Search sites, Bitpipe.com, CIO Decisions Magazine, Information Security Magazine, Storage Magazine, KnowledgeStorm, TheServerSide.com and/or TheServerSide.NET. To unsubscribe, see below.
____________________________________________________________

How should you evaluate the move to unified communications (UC)? Who within which parts of an organization will benefit? Will UC reduce the time to market? Read this E-Guide for answers to these questions and a better look at how the value of UC will, at first, be less of a financial issue and more of a productivity improvement issue that translates into financial benefits. Download this white paper now: http://pp.techtargetmail.com/c.asp?724694&236c8ee748f7dd97&1

When implementing unified communications, there are a number of important issues to think about and questions to ask. This E-Guide analyzes seven phases to ensure you reap the full benefits of UC in each. If you're ready to take the plunge but you're not sure your business or your infrastructure is - download this E-Guide now.

Click here to learn more: http://pp.techtargetmail.com/c.asp?724694&236c8ee748f7dd97&1

"If you do not wish to receive future promotions directly from Avaya please forward this e-mail to {link removed} ; please note that there is a separate opt-out procedure below to be removed from the list from which this email originated."
____________________________________________________________

Please do not reply to this email.  To unsubscribe from all future third party offers from all TechTarget properties, simply click here: {link removed}

TechTarget | 117 Kendrick Street, Suite 800 | Needham, MA 02494

The New York Times rounds up using cell phones as hotspots: Though the reporter, Bob Tedeschi, mentions the issue of having to have an unlimited data plan to avoid unpleasant charges, and worries about bad drains and malicious users, he doesn't note that many carriers don't allow this kind of sharing or routing without a separate "tethering" plan, that can run $20 or more per month. Also, U.S. carriers have now all imposed a 5 GB per month reasonable use cap; some will cut you off, some charge you more, some cancel your service based on exceeding this use.

Gigabit Wi-Fi? Someday: TechWorld considers the IEEE's Very High Throughput (VHT) study group, which wants to start work on 1 Gbps or faster Wi-Fi standard for completion in 2012. With 802.11n offering raw symbol rates up to 600 Mbps--even though no devices have shipped with the radios and antennas to offer that optional high speed yet--there's interest in other frequencies that would allow faster encodings, as well as aggregating multiple links to achieve high speed rates. My experience in testing and using 2.4 GHz with Draft N would show that wide or aggregated channels doesn't work very well. The article's writer, Peter Judge, notes that ultrawideband had potential (over short distances) to approach the gigabit mark, but that UWB hasn't really reached the market in any substantive way years after it was promised to be a big technology.

Flight attendants express concerns about in-flight broadband porn: When I've spoken to airlines, industry experts, and service providers, I find that they all have stories about how porn is viewed on computers, through DVD players, and in convenient magazine form on planes today. Adding the Internet may provide new salacious imagery, but the problem predates Internet access, and filtering Internet service is never as good a solution as a social one. Someone idiotic enough to view porn on a plane over the Internet is also stupid enough to bring along inappropriate DVDs they watch while seated next to children. Flight attendants already have the power vested in them to take care of this. The flight attendants for American might be expressing this concern as part of a bargaining issue, where their responsibilities but not commensurate pay have increased.

Spokane ends free Wi-Fi: Remember Vivato? Boy, I sure do. A company with a reach far exceeding its grasp, Vivato initially powered Spokane's downtown network. The network has continued to run on some basis--I'm not sure using what equipment--and now will move from free to fee. OneEighty Networks will charge about $10 per month to cover the costs of the network, for which local businesses at one point chipped in.

Brazilian TAM airline signs up for in-flight calling, messaging: OnAir has signed up the Brazilian carrier TAM, which will deploy the service on its Airbus A320 craft. Brazil hasn't yet provided regulatory approval, so no launch date is noted. TAM is the largest domestic and international carrier for Brazil.

It's become a big deal in IT security, too. Many corporate customers are demanding ROI models to demonstrate that a particular security investment pays off. And in response, vendors are providing ROI models that demonstrate how their particular security solution provides the best return on investment.

It's a good idea in theory, but it's mostly bunk in practice.

Before I get into the details, there's one point I have to make. "ROI" as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It's an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn't make sense in this context.

But as anyone who has lived through a company's vicious end-of-year budget-slashing exercises knows, when you're trying to make your numbers, cutting costs is the same as increasing revenues. So while security can't produce ROI, loss prevention most certainly affects a company's bottom line.

And a company should implement only security countermeasures that affect its bottom line positively. It shouldn't spend more on a security problem than the problem is worth. Conversely, it shouldn't ignore problems that are costing it money when there are cheaper mitigation alternatives. A smart company needs to approach security as it would any other business decision: costs versus benefits.

The classic methodology is called annualized loss expectancy (ALE), and it's straightforward. Calculate the cost of a security incident in both tangibles like time and money, and intangibles like reputation and competitive advantage. Multiply that by the chance the incident will occur in a year. That tells you how much you should spend to mitigate the risk. So, for example, if your store has a 10 percent chance of getting robbed and the cost of being robbed is $10,000, then you should spend $1,000 a year on security. Spend more than that, and you're wasting money. Spend less than that, and you're also wasting money.

Of course, that $1,000 has to reduce the chance of being robbed to zero in order to be cost-effective. If a security measure cuts the chance of robbery by 40 percent -- to 6 percent a year -- then you should spend no more than $400 on it. If another security measure reduces it by 80 percent, it's worth $800. And if two security measures both reduce the chance of being robbed by 50 percent and one costs $300 and the other $700, the first one is worth it and the second isn't.

The Data Imperative

The key to making this work is good data; the term of art is "actuarial tail." If you're doing an ALE analysis of a security camera at a convenience store, you need to know the crime rate in the store's neighborhood and maybe have some idea of how much cameras improve the odds of convincing criminals to rob another store instead. You need to know how much a robbery costs: in merchandise, in time and annoyance, in lost sales due to spooked patrons, in employee morale. You need to know how much not having the cameras costs in terms of employee morale; maybe you're having trouble hiring salespeople to work the night shift. With all that data, you can figure out if the cost of the camera is cheaper than the loss of revenue if you close the store at night -- assuming that the closed store won't get robbed as well. And then you can decide whether to install one.

Cybersecurity is considerably harder, because there just isn't enough good data. There aren't good crime rates for cyberspace, and we have a lot less data about how individual security countermeasures -- or specific configurations of countermeasures -- mitigate those risks. We don't even have data on incident costs.

One problem is that the threat moves too quickly. The characteristics of the things we're trying to prevent change so quickly that we can't accumulate data fast enough. By the time we get some data, there's a new threat model for which we don't have enough data. So we can't create ALE models.

But there's another problem, and it's that the math quickly falls apart when it comes to rare and expensive events. Imagine you calculate the cost -- reputational costs, loss of customers, etc. -- of having your company's name in the newspaper after an embarrassing cybersecurity event to be $20 million. Also assume that the odds are 1 in 10,000 of that happening in any one year. ALE says you should spend no more than $2,000 mitigating that risk.

So far, so good. But maybe your CFO thinks an incident would cost only $10 million. You can't argue, since we're just estimating. But he just cut your security budget in half. A vendor trying to sell you a product finds a Web analysis claiming that the odds of this happening are actually 1 in 1,000. Accept this new number, and suddenly a product costing 10 times as much is still a good investment.

It gets worse when you deal with even more rare and expensive events. Imagine you're in charge of terrorism mitigation at a chlorine plant. What's the cost to your company, in money and reputation, of a large and very deadly explosion? $100 million? $1 billion? $10 billion? And the odds: 1 in a hundred thousand, 1 in a million, 1 in 10 million? Depending on how you answer those two questions -- and any answer is really just a guess -- you can justify spending anywhere from $10 to $100,000 annually to mitigate that risk.

Or take another example: airport security. Assume that all the new airport security measures increase the waiting time at airports by -- and I'm making this up -- 30 minutes per passenger. There were 760 million passenger boardings in the United States in 2007. This means that the extra waiting time at airports has cost us a collective 43,000 years of extra waiting time. Assume a 70-year life expectancy, and the increased waiting time has "killed" 620 people per year -- 930 if you calculate the numbers based on 16 hours of awake time per day. So the question is: If we did away with increased airport security, would the result be more people dead from terrorism or fewer?

Caveat Emptor

This kind of thing is why most ROI models you get from security vendors are nonsense. Of course their model demonstrates that their product or service makes financial sense: They've jiggered the numbers so that they do.

This doesn't mean that ALE is useless, but it does mean you should 1) mistrust any analyses that come from people with an agenda and 2) use any results as a general guideline only. So when you get an ROI model from your vendor, take its framework and plug in your own numbers. Don't even show the vendor your improvements; it won't consider any changes that make its product or service less cost-effective to be an "improvement." And use those results as a general guide, along with risk management and compliance analyses, when you're deciding what security products and services to buy.

This essay previously appeared in CSO Magazine.

On the 29th episode of The Silver Bullet Security Podcast, Gary talks with Dennis Fisher, executive editor of The Security Media Group at TechTarget. Dennis helps run SearchSecurity.com and Information Security Magazine. Gary and Dennis discuss the current “BS factor” in security journalism, shopping at TJ Maxx right after the TJX privacy breach, the state of software security, and which is harder: being a fry cook at Hardees or working as a PR flack.

• Dennis’ blog
• TJX
• Joe Walsh plays dirty laundry
• Software Security Grows
• Dennis’ un-named podcast
• Series of Tubes
• Hardees
• Nike/iPod