Superconductor

Weird risk stories from 2011

There's an interesting article at the allbusiness.com web site that talks about some unusual risks that appeared in 2011. Here's one of the incidents that this article describes:

Newspaper Burned by Exploding Donuts

Apparently crazy court decisions are not solely an American invention. A Chilean newspaper, La Tercera, was recently ordered to pay $163,000 US to 13 people who suffered burns after the churros they were cooking exploded. The court agreed that the temperature listed in the paper’s recipe was too hot, which caused the dough to explode.

The plaintiffs won’t be rolling in dough, but this is a very unique legal theory. I wonder if U.S. newspapers will discontinue printing recipes to mitigate their risk.

Understanding risks and probabilities

I was just talking to a former co-worker who had just returned from Las Vegas. Although I've been to Las Vegas a few times, I've never gambled while I was there. The expected value of gambling is negative, after all, and I really don't think that I'd find gambling entertaining enough to justify calling any gambling losses an "entertainment expense." My former co-worker, on the other hand, always gambles when he's in Las Vegas.

When I explained my justification for not gambling – the fact that's the best you can do is to lose money in the long run – my former co-worker said, "But that's only if you play the best odds."

"And if you don't do that," I said, "you'll lose even more, won't you?"

Perhaps it's a good thing that this particular former co-worker doesn't work in information security or risk management any more.

Smeed's law and information security

 

Will Smeed's law apply to the dangers from hackers? Probably not. Here's why.

Smeed's law is based on a 1949 observation by Reuben Smeed that the number of deaths per vehicle from automobile accidents tends to decrease over time. So even if the numbers of cars driven increases dramatically, the number of deaths caused by cars will decrease even faster than the number of cars increases, resulting in fewer deaths per car.

Smead claimed that this was due to a sort of group psychology that understands and adapts to risks over time. Some data suggests (PDF), for example, that when cars with modern safety features are used in developing countries the fatality rates per car are as much higher than you'd expect for the same car driven in a more developed country, which is exactly what we'd expect from Smeed's law.

Let's suppose that that people's behavior actually causes Smeed's law. If that's true, we might expect them to adapt to the dangerous world of the Internet, learning to avoid phishing, etc., over time. But this doesn't seem to be happening. That's probably because the threat environment changes too quickly. What's a very serious information security threat today may not be serious at all a year from now, and a year may be too short of a time for the group psychology in Internet users to understand and adapt their behavior to the changing threat.

And unless the adaptation is close to perfect, it may not be enough to significantly affect the threat landscape. If people adapted to spam by never clicking on it, for example, then spamming would become unprofitable and the flood of spam would stop. But because it takes very few people falling for spam-based schemes for the schemes to be profitable, it's unlikely that it will ever be possible for enough people to adapt to spam enough to make it disappear. So even if the group psychology effect of Smeed's law is real, it seems unlikely that it's effects will ever be significant for the risks that information security manages.

Could Be Used by Criminals

Back in the 1970's and 1980's, the US government (and other governments throughout the world) placed restrictions on crypto because it could be used by criminals. The rationale was the following: Even though law-abiding citizens have a legitimate use of crypto, criminals and terrorists can use it to hide evidence or distribute information securely, and otherwise make it more difficult to prevent and prosecute crimes and acts of terrorism.

At first, there were some attempts to make use of crypto illegal, but that was not possible. So the US government did some other things. For example, they standardized on DES, which was a weaker algorithm (key size was limited to 64 bits), then they weakened DES (artificially reduced the key size to 56 bits). They placed export restrictions on crypto, and introduced Clipper in the hopes that the only crypto available would be a version with a government back door built in. In the end, crypto became too widely available and any attempts to restrict it became futile.

Because of my experience in the crypto industry, this idea -- because something can aid criminals it must be outlawed or severly restricted -- has always interested me.

A story in the San Jose Mercury News talks about another case. Bob Wallace of Saratoga, CA, sells a water purifying product. The product contains iodine crystals, which can be used in the production of methamphetamine. So the government, through the Drug Enforcement Agency (DEA), has demanded that Wallace pay a special regulatory fee, report suspicious customers, prove his security is sufficient, and other things. Eventually, because Wallace was not able to secure a permit to trade in iodine, his supplier stopped sending the raw materials (after the DEA threatened that company with legal action if they continued doing business with Wallace). So Wallace is out of business.

This is similar to the restrictions placed on cold medicines containing pseudoephedrine. You can't get them over the counter, and when you do buy them the pharmacy sends your your name to a registry that tracks purchases.

One thing I found interesting in the article is a quote from Barbara Carreno, a DEA spokesperson. "Methamphetamine is an insidious drug that causes enormous collateral damage. If Mr. Wallace is no longer in business he has perhaps become part of that collateral damage, for it was not a result of DEA regulations, but rather the selfish actions of criminal opportunists. Individuals that readily sacrifice human lives for money."

There is a logical flaw in there. In part one, she mentions collateral damage caused by the drug. She further claims that Mr. Wallace lost his business because of that collateral damage. However, Wallace did not lose his business because of the drug's collateral damage, rather he lost it because of the enforcement policy's collateral damage. She said "it was not a result of DEA regulations," but that's exactly why he lost his business.

There seems to be a threshold for criminal usage. For example, criminals use ski masks to hide their faces and gloves to prevent leaving fingerprints, but we don't make it hard to buy ski masks or gloves. Or accountants use bookkeeping software or books to hide embezzling. Or spray paint is used for graffiti. Or kitchen knives, baseball bats, lighter fluid, laptops, cell phones, fertilizer, apricot pits, hair dye, screwdrivers, wire cutters, cameras, and on and on are used or can be used as tools to commit crimes.

Why does the government heavily regulate some tools and not others? I think there are two reasons. The first is when drugs are involved, the government is very zealous. The second is, they can. I suspect if law enforcement agencies could place heavy handed regulations on more items that are dual use (honest and dishonest), they would.

If they can, they will. If for some reason they can't, they'll just have to figure out how to get along without the regulations. With cold medicine and iodine crystals, they can. With crypto they can't. The legitimate users of crypto have a lot of lobbying power (banks and other financial institutions especially) to make sure the government relents. There's not enough money in cold medicine and iodine crystals to afford the lobbying muscle needed to get the government to back off.

#voltagelive Voltage Customer Summit Video

Data-centric security for a data-centric world - #voltagelive 2011 in NYC

New innovation and emerging technology brings with it opportunities for streamlining costs, eliminating hurdles for end users and reducing risks to the business. However, implementing game changing solutions can be unique to your environment, policies and processes.

That's why I invite you to join Voltage Security at its first customer summit in New York City on November 9, 2011. The summit will focus on data-centric security and will feature top Voltage customers such as Amex, Wells Fargo, State Street and others, who will discuss how they implemented encryption projects for mail, data and payments. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently developing new analyses of how companies use encryption. The summit features customers talking to customers—at last count this includesAmerican Express, BJ's Wholesale Club, Citigroup, Deutsche Bank, Fidelity Investments, JPMorgan Chase, UBS, State Street Bank andWells Fargo. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices. If you're interested in attending, please visit www.voltage.com/live.

The theme is 'Data-centric Security for a Data-centric World,' it's an area of huge attention. Data is the lifeblood of industry, commerce and leisure, every business and every transaction. That's why protecting it is such a serious and difficult responsibility. 

Here's a quick scan of the Hot Topics we have on tap at Voltage Security Live 2011:

Cloud Data Security Data-centric Encryption Ecommerce Security

Email Encryption Mobile Data Security Payment Security

There's no question that every company continues to face a long serious of challenges related to these topics. The conference is designed to tackle specific issues and help formulate achievable solutions. The areas to be covered include:

• How to fund and integrate a data-centric strategy into your overall security program
• Best practices for data-centric encryption based on real-world implementation at a Fortune 50 Bank
• How to roll out encryption projects successfully across the organization and end-user community
• Successful phases for fast and non-disruptive implementation—what you need to do before during and after an implementation
• Elements of key management architecture and design
• The role of cloud and mobile data-centric security

Voltage Security Live 2011 will bring together the brightest minds in our field, all with considerable experience. There will be representatives from teams responsible for implementation, as well as enterprise and security architects looking for, and developing, best practices for data-centric encryption. 

The sessions will cover customer project case studies addressing issues such as how to maximize end-user adoption for your B2C implementations and implementing data-centric encryption projects, while the Customer Track focuses on panel discussions and presentations on topics such as protecting outsourced data, eDiscovery and Archiving and securing application emails. There's also an Architecture Track, featuring panel discussions and presentations on topics such as key management architecture, security policy, enterprise applications and the web services API and scalable design considerations. And there's the Security Panel, with a discussion and general Q&A featuring leaders from the security community—Gartner Security Analyst, Encryption Architects, QSAs. 

There's going to be a broad cross-section of security specialists attending, but some executives will find it particularly enlightening: CXOs and security leaders responsible for security strategy and programs; VPs/Directors responsible for security implementation; and architects responsible for security and application and enterprise architecture. If you have one of these roles, we think this conference is exactly right for you. 

We know there are constant demands on your time - we hope to see you there.

Register at www.voltage.com/live

The CDC's plans for zombie outbreaks

Back in May, someone at the CDC did a blog post about how to prepare for an outbreak of zombies. Here's how the CDC would respond to such an unprecenented event:

If zombies did start roaming the streets, CDC would conduct an investigation much like any other disease outbreak. CDC would provide technical assistance to cities, states, or international partners dealing with a zombie infestation. This assistance might include consultation, lab testing and analysis, patient management and care, tracking of contacts, and infection control (including isolation and quarantine). It’s likely that an investigation of this scenario would seek to accomplish several goals: determine the cause of the illness, the source of the infection/virus/toxin, learn how it is transmitted and how readily it is spread, how to break the cycle of transmission and thus prevent further cases, and how patients can best be treated. Not only would scientists be working to identify the cause and cure of the zombie outbreak, but CDC and other federal agencies would send medical teams and first responders to help those in affected areas (I will be volunteering the young nameless disease detectives for the field work).

Now I really doubt that the CDC actually has plans for how to handle a zombie outbreak, but when I read this I wondered what other events some government agency has actually planned for. Do they have plans for deflecting killer asteroids from Earth like shown in the movie Armageddon? Do they actually have plans for how to handle an invasion by aliens like shown in the movie War of the Worlds? (H. G. Wells' book did indeed come first, but I'd guess that any plans are based on the movie version, not the book version.)

What about more realistic, yet very unlikely, threats? What happens if a clever hacker finds a way to break the ubiquitous RSA encryption algorithm? What happens if a hacker manages to get into the air traffic control network? I wouldn't be too surprised if things like these are planned for, but I'd also guess that the plans are classified, so we'll probably never quite know what our governments have planned for us.

Voltage Customer Summit #VoltageLive - Only 23 Spaces left

 *** Only 23 spaces left ***

Voltage Security invites you to "Voltage Security Live 2011" at Bridgewaters in New York City on November 9, 2011. This customer summit will focus on data-centric security and will feature several leading Voltage customers, such as American Express, Wells Fargo, State Street and others, who will discuss how they have implemented encryption projects for email encryption, data-centric encryption and end-to-end payment encryption. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently working on a new analysis of how companies use encryption. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices.

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now at www.voltage.com/live

Join Voltage customers including: ADP, American Express, Bank of America, AT&T, Citigroup, Deloitte, Deutsche Bank, Elavon, Fidelity Investments, Heartland, JPMorgan Chase, McGraw-Hill, UBS and Wells Fargo. 
.
Highlights of the agenda include:

• CxOs Panel – Business dynamics for data-centric encryption security – How to get your security project funded
• Key Note – Eric Ouellet, Vice President Research, Gartner Group                      
• How to maximize customer adoption – Kim Mroczkowski, Wells Fargo
• 4. How to structure a data-centric encryption project – Emily Mossberg, Deloitte
• 5. “Birds of a Feather” Networking lunch
• 6. Tracks: Customer and Best Practices – American Express, State Street, Thales, PwC, Coalfire 
• 7. Security Leadership Panel – Gartner Group, State Street, American Express, Wells Fargo

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now atwww.voltage.com/live 

 

The biggest risks, according to E&Y

According to Ernst & Young's Business Risk Report 2010, here are the top 10 risks that businesses are facing today:

1. Regulation and compliance
2. Access to credit
3. Slow recovery or double-dip recession
4. Managing talent
5. Emerging markets
6. Cost cutting 
7. Non-traditional entrants
8. Radical greening
9. Social acceptance risk and corporate social responsibility
10. Executing alliances and transactions

Regulation and compliance is at the very top of the list this year. That's up from position 2 last year. It was also number 1 in 2008.

But there's a lot more to regulatory compliance that just the things that information security deals with. Here's how E&Y described the risks that businesses face from regulation and compliance:

Regulation and compliance has remained one of the most prominent risks since 2008 when these reports began. In 2008, regulation and compliance risk topped the global list. In 2009, this risk was only exceeded by worries about the credit crunch. For 2010, regulation and compliance has resumed its place as the Number 1 threat, not only for financial services, but also across a spectrum of sectors, from oil and gas to real estate, and from life sciences and technology to telecoms. Compliance risks are also notable in the automotive sector and the power and utilities sector.

For the financial services sector, the risk of encroaching regulation is still growing with severe worries regarding a poorly designed regulatory response to the credit crisis. Coordination among governments worldwide has the potential to fall by the wayside, increasing the risk of uncoordinated and conflicting new regulation. Banking executives and academic analysts expressed concern that this could result in an over-regulated sector and greater protectionism, preventing global firms from effectively operating across borders.

Our interviewees worried that, in the wider financial sector, regulatory reform proposals have the potential to destroy customer and shareholder value. "New taxes and higher capital requirements will impair the industry’s ability to absorb risk, impose a competitive disadvantage when it comes to attracting capital relative to other financial market players, and more broadly constrain the industry’s ability to meet its social and economic function as ultimate holder of risk," wrote Daniel Hofmann, Group Chief Economist at Zurich Financial Services. Firms need to rebuild trust, and act in concert to convince governments, regulators and the public at large that their activities do not create systemic risks.

Uncertainty over regulation was another problem raised by many panelists this year. Uncertainty both damages investment and the ability of companies to act. "Governments need to move fast to remove uncertainty, particularly regarding regulation of the financial sector," wrote one panelist. Similar concerns were raised beyond the financial services sector in telecoms, power and utilities, and oil and gas.

Companies can take a number of steps to respond to this risk. First among these is planning ahead and preparing for expected changes in regulation now, rather than waiting for regulations to be imposed. Trying to respond to new regulatory standards in a short space of time can be difficult, especially in a climate where forbearance may be scarce. Avinash Persaud, an independent consultant on finance and policy, commented that forthcoming regulations were likely to favor banks with larger deposits. To respond proactively to such fundamental changes may require companies to take a long view on possible regulations and consider alternate scenarios.

So information security is part of the biggest risk that businesses are facing today, but there are also lots of other issues related to regulations and compliance that are making life difficult for people in the business world. So don't be surprised if the divisions tasked with ensuring regulatory compliance grow significantly over the next few years. And also don't be surprised if most of that growth is in areas other than information security.

Engineering Security

 

Peter Gutmann's book Engineering Security (PDF) is one of the best single books that I've found on the topic of information security. It collects all sorts of information that's both useful and interesting, and it seems to be the only place where this type of information is collected. If you read a chapter of this book, you're able to amaze and astound people with the fascinating information security knowledge that you have.

My memory's not as good as it used to be, so for me, this effect wears off after a couple of weeks. But for those couple of weeks, I look much smarter than I really am.

I don't know if this book has found a publisher yet, but it's definitely the sort of book that deserves to be printed.

Statistical Analysis of Texas Hold'em

I just came across an interesting paper ("Statistical Analysis of Texas Hold'em" (PDF)) by application security consultants Cigital that tries to determine whether poker is a mainly game of skill or chance. Their conclusion is that it's mainly a game of skill. Here's how the executive summary of this paper describes what they found:

The effect of luck (i.e., the dealing of the cards) in Texas Hold’Em is a subject of much debate in the legal community. This study seeks to establish clear numbers derived from a significant sample of actual play. This study does not quantify the effect that luck has on Texas Hold’Em, but it provides compelling statistics about the way that the outcomes of games are largely determined by players’ decisions rather than chance.

Cigital examined 103 million hands of Texas Hold’Em poker played at PokerStars. In the majority of cases, 75.7% of the time, the game’s outcome is determined with no player seeing more than his/her own cards and some or all of the community cards. In these games all players fold to a single remaining player who wins the pot. In the 24.3% of cases that see a showdown (where cards are revealed to determine a winner), only 50.3% of showdowns are won by the player who could make the best 5-card hand. The other roughly half of the showdowns are won by someone with an inferior 5-card hand because the player with the best 5-card hand folded prior to showdown.

Much like poker, information security also deals with making decisions in the face of uncertainty, so a reasonable question to ask is: Is luck or skill more important in information security? Is it possible to make 75.7% of hackers not even try to attack your systems because they think that it's a waste of time because your security would be too tough for them to crack? And if that's possible, exactly how would you do it?

JPMorgan Chase awards Voltage Security for Data-centric Encryption Innovation

At the J.P. Morgan Technology Innovation Symposium, yesterday afternoon, JPMorgan Chase inducted Voltage Security into its Innovation Hall of Fame in front of hundreds of Silicon Valley executives. 

Only two vendors were selected in this year's awards which recognize top emerging technology vendors for business impact, measured in terms of driving value for the firm, disruptiveness of technology and the overall quality of the partnership. Voltage was selected by top IT executives at JPMorgan Chase for its innovative data-centric encryption approach for protecting structured and unstructured data across datacenters, the cloud and mobile devices.

 

"In an environment of ever-increasing threats, secure communications are critical to our business and our clients." 

- Guy Chiarello, Global CIO of JPMorgan Chase.
 

"Voltage's stateless key management technology is enabling JPMorgan Chase to roll out secure communications on a global scale with an excellent time-to-market." 

-Anish Bhimani, Chief Information Risk Officer of JPMorgan Chase. 

   

http://www.voltage.com/pressreleases/PR111005-Voltage-JPMC-Innovation-Award.htm 

 

How many zombies do you know?

I just came across an interesting paper about indirect survey methods. This was "'How many zombies do you know?' Using indirect survey methods to measure alien attacks and outbreaks of the undead," by Andrew Gelman of Columbia University. A quick summary of this paper is that because it's too dangerous to actually go out and do field research on attacks by aliens or zombie outbreaks, it's better to learn about them indirectly. So instead of witnessing the events directly, talk to people who were actually at them instead.

Because a survey of about 1,500 people can give you indirect information about 1 million people, it's possible to get much more coverage using indirect methods than by more direct methods. Gelman mentions social networking web sites as a potential way of doing this. (My LinkedIn network connects me to over 5,252,783 professionals. Hoody hoo! And I don't really go out of my way to add LinkedIn connections.)

Gelman's approach is eerily similar to one that I've seen using for years to estimate the chances of information security incidents happening. I usually do this at the RSA Conference with a group of information security professionals, usually after a free beer or two that some vendor's party has conveniently provided. I ask people things like, "Have you or anyone that you know ever been hacked through a buffer overflow in their Lisp interpreter?" This is an obviously-fake example, of course, but it's one that's using an indirect survey to estimate the chances of a certain attack happening.

I also ask how many people know of someone who's died in a certain way. Things like, "Do you know anyone who has died in a car accident?"  I assume that people tend to remember deaths more than other events. And because the chances of dying in various ways are fairly well known, this provides a handy way to calibrate the answers about security incidents.

This probably gives me a good idea of what types of incidents happen fairly often and which ones don't. And it might be accurate to within a factor of 10 or so for estimating probabilities. So I can probably distinguish between security incidents that have a 1 in 10,000 chance of happening per year and incidents that have a 1 in 100,000 chance of happening per year.    

I used to think that this isn't a careful and scientific approach, but since an well-known statistician wrote a paper about it, it might be better than I had first thought.  

What information security can learn from food safety

I just came across the program (PDF) for the Fera/JIFSAN 12th Annual Joint Symposium, a joint meeting of the UK's Food and Environment Research Agency and the American Joint Institute for Food Safety and Applied Nutrition that was held in College Park, Maryland, on June 15-17, 2011. Here's a list of the four sessions that comprised this meeting:

Session 1: Sources of Uncertainty in Food Safety Risk Assessment – Current Practice

Session 2: Improving Data Collection to Quantify and/or Reduce Uncertainty

Session 3: Tools Used for Characterizing Uncertainty

Session 4: Informed Decision Making

When I saw that, my first thought was roughly, "Holy cow! Those are the very same issues that a workshop discussing the big issues in information security might talk about!" You'd have to change "Food Safety" to "IT Systems" in Session 1, of course, but that's all you'd need to do to have the basis for a great information security workshop.

So maybe the lesson to be learned here is that everyone who deals with risks is really dealing with the same underlying hard issues. If that's the case, I'll have to make an effort to read more papers from workshops like the Fera/JIFSAN 12th Annual Joint Symposium in the future.

An unexpected way to manage risk better

Information security concerns managing uncertain outcomes, so it's based on an understanding of those uncertain outcomes. Some people do this better than others. Like the subjects in the research by psychologists Baba Shiv, George Loewenstein, Antoine Bechara, Hanna Damasio and Antonio Damasio that's described in "Investment Behavior and the Negative Side of Emotion."

Can dysfunction in neural systems subserving emotion lead, under certain circumstances, to more advantageous decisions? To answer this question, we investigated how normal participants, patients with stable focal lesions in brain regions related to emotion (target patients), and patients with stable focal lesions in brain regions unrelated to emotion (control patients) made 20 rounds of investment decisions. Target patients made more advantageous decisions and ultimately earned more money from their investments than the normal participants and control patients. When normal participants and control patients either won or lost money on an investment round, they adopted a conservative strategy and became more reluctant to invest on the subsequent round; these results suggest that they were more affected than target patients by the outcomes of decisions made in the previous rounds.

In other words, the test subjects with brain damage actually did a better job of managing risk than the test subjects without brain damage. I'm not sure that I want to think about the implications of that in the field of information security for too long.

Looking back at the size of data breaches

Verizon's recent 2011 Data Breach Investigations Report (PDF) seems to show that very few records were exposed by data breaches in 2010. The report says that all of the breaches that Verizon investigated in 2010 only added up to about 3.9 million records that were exposed.

That doesn't mean that only 3.9 million records were exposed in 2010. 

The Open Security Foundation's data breach database lists breaches in that year that exposed over 28 million records. So although the amount of data that was exposed through data breaches was lower in 2010 than it was in the previous few years, there was still a significant amount of data exposed. Much more that the 3.9 million that Verizon's investigators looked at.

A breach that exposes 5 million records doesn't really look that big when it's compared to other recent breaches. Here's a graph that I created with IBM's Many Eyes data visualization tool. It shows the relative size of recent data breaches (from the Open Security Foundation's data breach database), with a single breach of 5 million records highlighted. 

 

This seems to tell us that a breach that exposes 5 million records really isn't very notable.

If a breach that exposes 5 million records really isn't that notable, that's a sure sign that we're losing way too much data.

Data breaches that expose 1 million or more records aren't really that rare. There have been over 50 of these since 2006, or almost one per month. And if you look at how much data has been exposed by data breaches, 1 million records doesn't really look like that many. Here's a graph that shows this. The single highlighted breach exposed 1 million records.

 

Excerpted from recent posts about data breaches by Luther Martin

Another example of how people don't estimate small probabilities well

People don't estimate small probabilities very well. To get an idea of how bad we are at this, I periodically ask several people what they think the current mortgage foreclosure rate is in the US. According to realtytrac.com, 1 in every 597 homes in the US received a foreclosure filing in April 2011. That's 0.17 percent per month, or about 2 percent per year.

A few weeks ago, when I asked several people what they thought this was, the lowest estimate was 5 percent, the high was 20 percent, with most of the estimates being close to 10 percent.

When I did this over a year ago, the foreclosure rate was about 4 percent, and most of the estimates were close to 20 percent, with some being as high as 40 percent.  

That's not a careful and rigorous study. Not even close, really. But I found it a bit surprising that the average estimate was off by roughly the same factor in both cases. I'll have to start being more careful about how I ask this question and how I record the answers in the future.

Now that's risk aversion

Information security isn't the only field that concerns managing risks. Local governments in the UK also do this. An example of this is their warning to the parents of a 7-year-old girl telling them that they would be reported for "child protection issues" for letting her walk the 65 feet from her house to her school bus stop alone.

When I was 7, almost everyone walked to school. Today it's considered too dangerous.

Have we really become that risk averse?

Fortunately, the local government saw the error of their ways and the girl was eventually allowed to walk to her bus stop on her own, but I doubt that this will be the last time that such incidents happen.

5 Things to do now as a result of the Epsilon Data Breach

As you will have read or watched in every media outlet today, Epsilon, a company that provides some of the top brand name companies with email marketing services had a data breach that uncovered the names and email addresses of millions of customers. These customers as reported in the New York Times and other blogs such as Byron Acohido's "The Last Watchdog", will now probably suffer from further attempts on their private information - Here's some resources that will help you make sense of the data breach and ensure that your company is not the next Epsilon:

 

		What do you need to know about the Epsilon Data Breach?
		By now, everyone has read about a company named Epsilon. In fact, many people most likely have direct involvement, having received one or more emails from companies they do business with warning them to be very careful after a recent incident. These notifications stem from Epsilon Interactive, a third-party service provider of managed email, getting compromised and having some of their 2,500 clients customer emails stolen. Epsilon provides email and customer loyalty services to more than 2,500 corporations, including seven of the top 10 Fortune 100 companies. The company sends more than 40 billion emails annually on behalf of these clients. So even if you haven't heard of it before, chances are high that your bank or your favorite retailer or hotel chain is using Epsilon for email and other services. The company touts itself as the world's largest permission-based email marketing provider and is believed to store more than 250 million email addresses. A list of companies whose customer data has been breached can be found at http://datalossdb.org/incidents/3540 and http://krebsonsecurity.com/2011/04/epsilon-breach-raises-specter-of-spear-phishing/ – these lists are being updated as companies send out their data breach notifications.
		What to tell your customers and employees to do now?
		If you yourself have received data breach notifications from companies that you do business with then chances are your own email was amongst those breached – here's some basic guidelines on how to avoid follow-up fraud from the perpetrators of this data breach: Don't open emails from people you don't know Don't respond to emails asking to verify your password or other personal details Hang up on phone calls from the bank or others who call asking to verify personal info Don't open email attachments - even 'Data Breach Notification' letters - if do you make sure anti-phishing countermeasures are active Do change your passwords - go direct to company website - don't click on a link in an email
		How to protect your data?
		Like most companies Epsilon had extensive security measures in place – however, sophisticated criminals found a way to breach those defenses. Once inside they were able to make off with millions of emails, because this type of data was lying around in the clear – no one thought the data was at risk. The best defense is to protect the data itself. That way, even if hackers force their way into your systems, the data itself is useless. The solutions to accomplish this – typically encryption or tokenization are widely available and are used extensively by payment processors, retailers, financial institutions and healthcare organizations to protect sensitive data – wherever it goes. In fact, the best approach is to encrypt information as quickly as possible and keep it encrypted for as long as possible until it is actually needed – this is often referred to as End-to-End Encryption. Voltage has provided some of the largest brand name companies in the world with solutions to protect emails, information stored in databases and used by applications – inside and outside the cloud. To learn more click on one of the following links: In addition: Consumers need to know what data is being captured, what it is used for, and how it is being protected as a matter of corporate policy Corporations must demand that their business partners and IT secure personal data so it cannot be exploited in this all to easy manner as illustrated by the Epsilon attack Protect non-regulated personal data – Email may not be a regulated field in regulations like PCI, but if it's being captured, it can be exploited Access to personal data within a corporation needs to be locked down – on a need-to-know basis – reducing access to e.g. the last 4 fields of an SSN instead of a whole one, or using encryption and tokenization to reduce the exposure of real data to employees, partners and customers. Communication with consumers and business partners needs to be secured and trusted – use a secure email solution but make sure it has anti-phishing countermeasures activated. Avoid using live data in test systems by de-identification and masking to reduce exposure outside production controls Learn how a top financial services firm protects sensitive data
		Making sure your 3rd party service providers protect your data
		The other big lesson to learn from the Epsilon data breach is that while you may implement safeguards to protect sensitive data within your datacenters, your third-party service providers must also do the same – it is critical that your sensitive information is protected via encryption or tokenizaton by the third party. In fact many in the industry are calling for contractual clauses that insist on data encryption by 3rd parties. Learn how a top insurance company made sure its service providers protected its data
		Consumer Data Protection Manifesto
		In order to safeguard sensitive customer information many customer advocates are calling for new rules that force companies to certify that they have adequate data protection in place to protect data even in the event of a breach – similar to Sarbanes-Oxley, this would bring board level visibility to a critical issue in the minds of consumers. Secondly to protect data that is being used by 3rd party service providers, companies should insist on a data protection clause in their contract that mandates the use of encryption of all consumer data. Data transferred to a service provider should be encrypted in line with making sure that consumer information is encrypted at the earliest opportunity and remains encrypted until needed. See Voltage co-founder, Matt Pauker's, Op Ed in Forbes on the subject.

 

Were they really talking about ALE?

CAT: I've got it. We laser our way through.

KRYTEN: An excellent plan, with just two drawbacks: One, we don't have a power source for lasers; and Two, we don't have any lasers.

Red Dwarf, “White Hole”

In the "White Hole" episode of the old TV show Red Dwarf, there's a scene where Cat and Kryten are trying to get into the bridge of the Red Dwarf but are being thwarted by a locked door. Cat suggests that they blast their way through the doors, and then Kryten explains to Cat that his plan won't work because they're missing some key pieces of equipment that they'd need to carry it out.

I was reminded of this scene recently when I was talking to someone about the Annual Loss Expectancy methodology that's often used in risk management. In the case of ALE you calculate the risk associated with a particular event by multiplying the probability of the event happening by the loss that will accompany the event if it happens. This is often written as R = P x L.

But when you try to apply this framework to the problems that information security tries to address, you find that you're missing two key pieces, much like Cat was in Red Dwarf. Cat was missing both the power source for a laser as well as the laser itself. In the case of ALE, we find that we don't really know either the probably of events happening or how to quantify the damage that will occur of the events happen. But aside from that, as Kryten might point out, using it is probably an excellent plan.

More interesting fraud data from the Kansas City Fed

As I mentioned before, "The Changing Nature of U.S. Card Payment Fraud: Industry and Public Policy Options" by Richard J. Sullivan, has some interesting data about the nature of fraud. Here's what's in Table 2 in this document.

Card issuers	billions	Share of total loss
PIN debit	$0.028
Signature debit	$0.337
Credit cards	$1.240
ATM withdrawals	$0.397
Total issuer losses	$2.002	59%
Merchants
POS	$0.828
Internet, mail order, and telephone	$0.568
Total merchant losses	$1.396	41%
Total losses	$3.718

I noticed a few interesting things is this data:

• Banks actually suffer more from card payments fraud than merchants do - roughly 50 percent more
• For banks, ATM fraud is a almost one-third of credit card fraud
• Merchants actually have more POS losses than CNP losses

I wouldn't have expected any of those to be true.

More wisdom from the CIA

There's another bit of information in the CIA's book Psychology of Intelligence Analysis that seems particularly relevant to information security. This concerns how much information people need to make good decisions. Here's what Chapter 5, "Do You Really Need More Information?" says about this:

Key findings from this research are:

• Once an experienced analyst has the minimum information necessary to make an informed judgment, obtaining additional information generally does not improve the accuracy of his or her estimates. Additional information does, however, lead the analyst to become more confident in the judgment, to the point of overconfidence.
• Experienced analysts have an imperfect understanding of what information they actually use in making judgments. They are unaware of the extent to which their judgments are determined by a few dominant factors, rather than by the systematic integration of all available information. Analysts actually use much less of the available information than they think they do.

So maybe it's the case that information security professionals don't need as much information as we might think they do to make informed decisions and that too much information can actually be harmful instead of beneficial when it comes to this. And if security professionals are really using only some of the available information to help them make these decisions, I'd be very interested to learn exactly what information they do use. Hundreds of marketing people probably would also.

Biases in estimating probabilities

Understanding how often security breaches happen is important to understanding how many resources to allocate to preventing them. This can be tricky because there's not much reliable data about how often security breaches happen. People also don't estimate probabilities very well, so in the absence of good data we're likely to make mistakes that can lead to either too much or too little being spent. This problem isn't limited to just information security, of course. It also complicates things any time we don't have good estimates of probabilities.

I recently came across an interesting discussion of this in a book by the CIA: Psychology of Intelligence Analysis. Here's the book's summary of its Chapter 12, "Biases in Estimating Probabilities," and these comments seem to apply to information security just as well as it applies to intelligence analysis:

In making rough probability judgments, people commonly depend upon one of several simplified rules of thumb that greatly ease the burden of decision. Using the "availability" rule, people judge the probability of an event by the ease with which they can imagine relevant instances of similar events or the number of such events that they can easily remember. With the "anchoring" strategy, people pick some natural starting point for a first approximation and then adjust this figure based on the results of additional information or analysis. Typically, they do not adjust the initial judgment enough.

Expressions of probability, such as possible and probable, are a common source of ambiguity that make it easier for a reader to interpret a report as consistent with the reader's own preconceptions. The probability of a scenario is often miscalculated. Data on "prior probabilities" are commonly ignored unless they illuminate causal relationships.

So if you're interested in how people mis-estimate probabilities and ways to deal with this, this CIA book actually seems to have a fairly good discussion of it. And the price (free) is certainly right.

Risk Assessment Methodologies: A Comparison

I came across another interesting report from the Burton Group. This one was "Risk Assessment Methodologies: A Comparison." Here's how they describe their findings:

Bottom Line: The operating phrase for using a risk assessment methodology is a “good starting point.” Enterprises will find value in the U.S. National Institute of Standards and Technology (NIST), Information Systems Audit and Control Association (ISACA), Information Security Forum (ISF), or Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) risk assessment frameworks, but each will need care and feeding for apt use. If system-level assessments are the goal, NIST and ISF are good bets. If enterprise-wide IT or information risk needs consideration, then ISACA's Risk IT should receive attention. OCTAVE's flexibility makes it good for a wide variety of uses, but it comes with some steep homework. Enterprises should choose a framework that correctly targets their assessment scope, complements their chosen control framework, and helps to socialize the risk assessment effort across the organization.

I've always been curious about how the various risk assessment methodologies would compare, and it really shouldn't be too surprising that each has its own particular strengths and weaknesses. After all, if one methodology was clearly better, it would probably end up being the only one used while people would lose interest in the others. So the fact that several methodologies exist is essentially proof that each has some area in which it excels, and this report seems to be a good summary of exactly what those areas are.

The Dark Side of Cloud Computing

I recently came across an interesting report by the Burton Group - "The Dark Side of Cloud Computing." This report talks about the usual issues that people always talk about around cloud computing (security, vendor lock-in, etc.), but it also had an interesting list of the unintended consequences of cloud computing:

• Data loss
• Predictability of volume
• Core vs. commodity business strategy
• Organization dis-integration
• Inadequate knowledge of internal costs and business capabilities
• Unexpected expenditures
• Inadequate budget forecasting
• Unnecessary risk
• Unintended changes to operational procedures

This report is probably worth tracking down just for the discussion of those unintended consequences.

Is information security like preventive health care?

It's hard to find a good model for the cost-effectiveness of information security. Traditional risk management methodologies fail miserably because the unknowns that information security addresses typically can't be quantified like the unknowns that risk management methodologies are designed to handle. This means that the model of information security as an insurance policy really doesn't work very well.

What other models might work better? What about preventive health care? Preventive care is similar to information security in some ways. In both cases we spend money to prevent bad things from happening, and we hope that this will reduce the need to spend money after the bad things have happened.

According to the survey of medical literature done by Joshua Cohen, Peter Neumann and Milton Weinstein that was recently published in the prestigious New England Journal of Medicine, it turns out that most types of preventive care really aren't worth doing. Their analysis shows that, on average, it's really no better to spend money on preventive care than to treat existing conditions. This doesn't mean that all types of preventive care aren't worth doing. There are many cases where preventive care pays. Counseling adults to quit smoking is apparently an example of this, as is providing flu vaccines.

Cohen, Neumann and Weinstein also list cases where preventive care is beneficial but very expensive, things like "newborn screening for medium-chain acyl-coenzyme, a dehydrogenase deficiency." (Yes, I'll admit that I have absolutely no idea of what that means.)

In some cases, preventive care actually increases costs and worsens health. Treatments like "antibiotic prophylaxis (amoxicillin) for children with moderate cardiac lesions who are undergoing urinary catheterization" is apparently an example of this.

So if information security is like preventive health care, how well would popular information security technologies fare in a similar analysis? It's probably not too hard to come up with examples of technologies where it's no better to use a security technology than to just absorb the cost of not using the technology at all. Are there any obvious examples of technologies where you'll probably end up both spending more and getting worse security if you use them?

Another risk-risk tradeoff (almost)

Like I've mentioned before, one thing that makes risk management hard is the fact that things are always more complicated that you first think. When you try to reduce one risk, you may inadvertently increase another one, and in some cases, this can actually leave you off worse than you were to begin with. It's not exactly risk management, but it seems that the government's Cars Allowance Rebate System, more commonly known as the "Cash for Clunkers" program, may have created a similar situation.

According to the analysis done by the people at Political Calculations, the net affect of this program will actually be to increase the amount of gas consumed by American cars. You can read their analysis that leads them to this conclusion here.

Their argument is essentially that newer cars are driven more miles per year, and this more than compensates for the better gas mileage that the newer cars get. Their analysis tells us that the Cash for Clunkers program will actually result in an additional 289 gallons of gasoline being burned each year for each older car that it takes off the road when you account for this. That's probably not what the government meant to do, and it's probably an example of an unintended consequence.

The two-envelope problem in risk management

Does it make sense to never change your information security strategy? That's a possible consequence of the so-called two-envelope paradox. This is a problem in probability theory that has confused students of probability theory for over 50 years. It goes like this.

Suppose that you're given two envelopes and you're told that one envelope contains twice as much money as the other. You then open one of the envelopes and see how much money it contains. Based on this information, you decide to either keep the contents of the first envelope or to switch its contents for the contents of the second, unopened envelope.

It might seem that it always pays to switch.

Suppose you find $2 in the first envelope. You know that the other envelope either contains $1, which happens with probability 0.5, or it contains $4, which also happens with probability 0.5. So you can calculate the expected value of the second envelope as $1 x 0.5 + $4 x 0.5 = $2.5. Because this is greater than $2, it always pays to switch.

There's a problem with this argument, of course, but it's fairly subtle. Even specialists in probability theory don't agree what the problem actually is, although they all agree that there's a problem with the argument.

Now let's suppose that we can't find a flaw in the above argument and we apply it to our information security strategy. Let's suppose that we have some initial set of technology, policies and procedures that end up giving us some exposure to risk that we'll denote R, and if we change to a different set of technology, policies and procedures, we might either increase the risk to 2R or decrease it to R/2. If we apply the same reasoning that we applied above, we find that it never pays to change, because the alternative always has a greater than the risk than what we have now. This clearly doesn't make sense, but it's what you might get if you do a risk analysis that isn't as careful as it could be.

The bottom line is probably that probability is a complicated and subtle concept, which means that risk management, which relies on it, also is.

More unintended consequences

Risk management is harder than it looks, in part because of the unintended consequences of approaches to mitigate risks. Some studies have suggested that wearing seat belts actually increases fatalities, for example, because some people drive more recklessly when they wear seat belts. I just came across another example of this, and this has to do with the labeling of alcoholic drinks in Australia.

In Australia, there are apparently laws that require alcoholic drinks to be labelled so that you can tell exactly how much alcohol you're getting when you drink one. The intent is to help people drink responsibly and safely, but it seems that younger drinkers have found another use for this labelling, and that's to help them optimize how much alcohol they get so that they can get drunk in the shortest possible time. This is discussed in "The impact of more visible standard drink labelling on youth alcohol consumption: Helping young people drink (ir)responsibly?," by Sandra Jones and Parri Gregory, which was published in the January 2009 issue of Drug and Alcohol Review.

That's the sort of risk-risk tradeoff that makes risk management harder than it looks.

 

Security-adjusted ROI

At the recent National Cyber Leap Year Summit, one of the ideas that was considered was research into developing a new metric called "security-adjusted ROI." I thought that this wasn't a good idea, and here's why.

ROI is the most popular metric used to justify security purchases, edging out NPV and IRR, the next most popular metrics by a comfortable margin. If you look at your favorite accounting text, you'll find careful definitions for both NPV and IRR. You won't find a careful definition for ROI, because there isn't one. If you're really curious to read more about this, you might want to track down a copy of "The Use of ROI in Information Security," an article that I wrote for the November 2008 issue of the ISSA Journal. This article describes this in a fair amount of detail.

It turns out that ROI is really just whatever argument will convince the decision-maker that you need to influence. Many ROI calculations start with NPV and tweak it to add things that are only relevant for security investments, but you don't have to do that. Any other calculation is just as valid. That's why there's really no need to define metrics like Return on Security Investment (ROSI) or security-adjusted ROI: because you can do those calculations and still call the result ROI.

The intent of ROI is to quantify the economic benefit of an investment, and if that means including measures of attacks or other losses that security technologies might reduce, that's fine. You can include elements like that in a calculation and still call the result ROI.

There are other good reasons to call a metric ROI instead of something else. In particular, other risk-management projects in an enterprise are typically justified by an ROI calculation, and if you're willing to allow a different metric for information security investments, it's only reasonable to expect other metrics to be used to justify other risk-management projects. That's probably a fight that's not worth having, so it's probably better to just keep the name ROI, even though it's really a metric that takes into consideration things that are particular to information security.

Doing that doesn't violate any accounting principle, because there's no careful definition of ROI that we really have to use. It's also in line with the intent of an ROI calculation, which is to measure the economic benefit of an investment. That's why I think that there's no need to develop a new metric called "security-adjusted ROI:" what you'll get is just ROI, but with a different name. You already have the freedom to include security benefits in ROI calculations. Why not just take advantage of this?

The security crisis

An import part of understanding a risk is understanding exactly how often a particular loss-causing event happens. It's hard to get an accurate picture of some of these chances due to the way that some things are covered by the media. It's fairly clear that the foreclosure rate for houses is now much higher that it was in the past few years, but exactly how high is it? If you watch TV news, you'll see lots of pictures of Stockton, California, the city where the most foreclosures per capita are currently happening. And because of the media coverage, many people's understanding of the housing market isn't quite as accurate as it could be.

A few months ago, I did an informal poll of people, asking them what they thought the rate of foreclosures was in the US. The answers clustered around 20 percent, with a significant number of estimates being closer to 40 percent. On the other hand, the actual rate is more like 2 percent. It seems fairly clear to me that the way that foreclosures were reported in the media is responsible for the gap between perception and reality in this case.

And just like it's useful to know whether the foreclosure rate is closer to 20 percent or to 2 percent if you're making public policy decisions, it's useful to know how serious some of the risks are that information security addresses if you're trying to figure out how to best spend your security budget. It's hard to get an accurate estimate of foreclosure rates from what you see on TV, and it's probably just as hard to get an accurate estimate of the severity of information security risks from the media.

There's certainly not as much accurate information as we'd like about security threats, but you don't need to make your IT investment decisions based on wildly inaccurate information. Basing decisions to elect politicians based on what the media shows us is bad enough. Don't make the same mistake with your information security purchases.

Neurosecurity?

Neuroeconomics is a new area of economics that might be interesting to information security practitioners. It tries to understand how our brains affect how we make decisions. Economists have apparently realized that our brains are very complicated and don't make decisions in a way that's easily modeled, and neuroeconomnics tries to take these complexities into account. It essentially realizes that we're not rational and tries to understand the implications of that fact.

Psychologist Daniel Kahneman shared the 2002 Nobel Prize in Economics "for having integrated insights from psychological research into economic science, especially concerning human judgment and decision-making under uncertainty," which may indicate that neuroeconomics may have interesting and useful implications. It might even give us some insights that we can apply to the field of information security.

Microeconomics tries to explain why people make the decisions that they do. It typically tries to understand decisions as a tradeoff between two or more choices, and assumes that people will pick the choice that they like the most. Measuring exactly how much people like various alternatives can be tricky because it almost always comes down to more than just the dollar value of what you get from a particular outcome. To model other factors, economists talk about "utility," which is just a way to quantify things that have value but aren't easily measured in dollars. People who live in Silicon Valley, for example, might like being to make a day trip to Yosemite National Park, but they'd be hard pressed to quantify exactly how much this is worth to them.

Having Yosemite nearby has utility even if it doesn't actually give us any money that we can spend on other things. And just like utility is a better way to measure how much we like things, it also might be a better way to measure how much information is worth. The utility of information might be more than its value. If that's the case, we might want to protect it more than we might think is necessary. Or it might be less that its value. In that case, we might want to protect it less than we ought to. In any case, it probably pays to understand the difference between the information's utility and its value.

It's hard to put an accurate value on information, but an equally hard part of information security is understanding how often the bad things happen. In particular, our brains systematically overestimate very low probabilities and systematically underestimate very high probabilities. We might estimate that a probability that's really 0.0001 to be 0.1, for example. Or we might estimate a probability that's really 0.9999 to be 0.9. If these probabilities represent the chances of bad things happening, then the bias that we have can make a big difference.

We should expect people to spend more to address a risk of $10 million than a risk of $10,000, but if the way our brains works tends to make us want to deal with a $10 million risk as if it's really a $10,000 risk, we might be heading for trouble because we probably won't be trying hard enough to mitigate the risk in some way. Similarly, if we deal with a $10,000 risk as if it's really a $10 million risk, we'll probably spend too much on mitigating it, and that's money that could be put to a better use somewhere else.

So the bottom line is that our brains don't do a good job handling the type of data that we need to make good decisions about information security. Maybe neuroeconomics will one day be able to give us some useful insights into how to do this better. We know that we're not rational; we just haven't found the patterns in our irrationality yet.

Wired to the data breach

 

It all started with an article in WIRED - Group Spots Giant Hacks by Combing Small Newspapers by Kim Zetter, about how intrepid researchers had found patterns in the customer breach notifications coming from regional banks around the US which led them to suspect a wide-ranging data breach. The researchers are all part of a nonprofit volunteer organization - the Open Security Foundation, that posts the result of its research on the DataLossDB.org website. We decided we wanted to see patterns too, especially if it could help focus our customers on new and upcoming security risks. We contacted the foundation and set about visualizing data breach incidents. The result is the map you see above, which you can play with at www.voltage.com/data-breach. Just click on any of the red areas of the world map - clearly not every country reports data breaches, but whatever information is available publicly will eventually find its way into the foundation's database. We marked the incidents with rectangles, the size of which is determined by the number of records breached - just like earthquake maps. A lot of recorded incidents, up to 30%, do not specify the number of records lost however.

In building out the map, we decided to conduct our own statistical analysis of the data - with surprising results.

The analysis, which you can read about in more detail in our blog posts and in this paper, shows that while there is a constant low-level stream of incidents, there are epidemic like qualities to the breaches i.e. you can model the incident data to the point where it's possible to predict the magnitude and frequency of future breaches (just click on the map and press the "Future"" button to see the predictions). It will be interesting to do this analysis again in a year to see if the companies have implemented sufficient safeguards to lower future breach incidents.

We also wanted to find a way to assess the impact of breaches on ordinary consumers - this is difficult to do. The location of a breach though interesting doesn't necessarily represent the sphere of impact. So we settled on a very simple gauge that looks at the number of breaches in the last 90 days to determine the severity level. We're hoping that that the severity level drops to elevated soon.

There are more patterns in the incident data and we'll be covering those in future posts.

We are most grateful to the team at the Open Security Foundation for helping us with this project to shine a little light on data breaches - and we congratulate them on winning SC Magazine's Editor's Choice Award 2009.

How useful are digital signatures?

There's one article that anyone interested in the business use of PKI should read. This is "Legislating Market Winners: Digital Signature Laws and the Electronic Commerce Marketplace" by Bradford Biddle. Biddle is a lawyer, and this article was first published in the San Diego Law Review in 1997. It's also available from Biddle's web site here.

The abstract of the article nicely sums up the legal arguments about using PKI. Here's what it says:

Abstract: "Legislating Market Winners" argues that certain enacted digital signature laws are premised upon false assumptions, and inappropriately enshrine a business model which would not evolve naturally in the marketplace. In attempting to solve an unsolvable liability allocation problem, such legislation harms consumers and the future evolution of electronic commerce. The article points out that alternative business models can solve the liability allocation problem. Despite obvious flaws, legislation of this type continues to be proposed, partly because the infrastructure created by these laws coincides with the needs of key escrow proponents. Ultimately the article argues that digital signature laws, which impose a particular view of electronic commerce, should be abandoned, in favor of laws which remove specific, well-defined barriers to electronic commerce and which allow the electronic commerce marketplace to evolve unfettered.

This article goes on to essentially argue that the type of PKI envisioned by digital signature laws simply isn't viable, and that the only viable PKI is one in which the CA is essentially totally absolved of any liability. Similarly, a problem with individuals using PKI is that digital signature laws try to give an end user much more liability that any other legal framework in existence. Because of these problems, digital signatures that try to be anything more that a cryptographic checksum are almost certainly doomed to fail.

Anyone who is thinking about using PKI in one of their business processes would do well to read this article and think about what it says. Some things are feasible with digital signatures. Some things aren't. Confusing the two can be a source of all sorts of problems.

Information security insurance isn't practical

There are at least four ways with dealing with risks. One way is to accept a risk. This may be a good idea if the potential loss from an uncertain event isn’t very big or the uncertain event happens very rarely. For more significant risks, you might want to invest in either technology or additional processes to reduce the expected loss from an uncertain event to an acceptable level. Another way of dealing with a risk is to avoid it. If you think that the risk associated with using email can’t be addressed any other way, you can always stop using email, for example. The final alternative is to transfer a risk to a third party. Insurance policies are a common way to do this, and they essentially transfer the risk from the policy holder to the insurance company who offers the policy. In the case of information security it’s probably the case that options are more limited, and that using insurance to transfer risk may be impractical due to the nature of information security vulnerabilities.

The definition of "risk" as understood by risk managers is defined to be the loss that you expect to incur from events that have an unknown outcome. To quantify the risk associated with such an event, you multiply the probability of an event by the loss associated with the event. For example, if you have an event that will cause $1 million in loss if it occurs, but this event only happens with a 1 percent chance, then this event represents $10,000 in risk, or 1 percent of $1 million. Actuaries that estimate a risk to be $10,000 typically set the price of an insurance policy that covers the risk to be $10,000, plus whatever additional costs needed to cover the operating expenses of the insurance company.

In the case of the unknowns that information security deals with, we usually don't know either of the two values that are used to quantify a risk. It's very hard to accurately estimate the chances of security incidents happening, and it's equally hard to estimate to put a price on the damage caused by any incidents that do happen. This makes it difficult, if not impossible, for insurance companies to cover information security risks.

Suppose that you could go back in time to January 24, 2003. At that time, there was a known buffer overflow vulnerability that might have affected your implementation of Microsoft SQL Server 2000. This vulnerability had been known for at least six months, at least since July 24, 2002, but had not been exploited. Because of this, you might have estimated the chances of it being exploited as being fairly low. The very next day, however, the SQL Slammer Worm was released that took advantage of this vulnerability in a spectacular way. At that point, your assessment of the vulnerability would probably have changed dramatically.

This situation is probably very typical of security vulnerabilities. All software has bugs, and some of these bugs cause serious security vulnerabilities. Many of these vulnerabilities haven’t been found by security researchers yet. In the face of this unknown risk, how do you price an insurance policy? Perhaps a better question to ask is whether insurance is even practical for information security vulnerabilities. It’s probably not.

That’s why I wouldn’t be surprised if a significant market for information security insurance never comes into being. It’s probably not practical.

What FM 100-14 tells us

Risk management guru John Adams gave a talk back a few years ago entitled “Does the Royal Navy have enough accidents?” In this talk, he noted how the Royal Navy tends to be fairly risk averse in time of peace, but understands that risks are necessary in time of war. He then asked if the training that’s suitable for peacetime operations is really suitable for an organization whose ultimate purpose includes winning wars. Is the risk management mindset that’s needed in a peacetime navy even useful in time of war?

I haven’t seen any data from the Royal Navy, but the data that I’ve seen from the US Army leads me to believe that the difference between the ways that military organizations need to manage risks in peace or war isn't really that great. Here’s the data from The US Army’s Field Manual (FM) 100-14, Risk Management, that led me to this conclusion. This compares the number of accidental losses to the losses due to enemy action that the US Army has had in the past few wars that they’re fought. Historically, there are more losses due to accidents than due to enemy action.

	World War II 1942-1945	Korean War 1950-1952	Vietnam War 1965-1972	Gulf War 1990-1991
Accidents	56%	44%	54%	75%
Friendly Fire	1%	1%	1%	5%
Enemy Action	43%	55%	45%	20%

US Army battle and non-battle casualties according to FM 100-14.

Based on the US Army’s experience, it looks it may be more important to deal with reducing losses due to accidents than it is to worry about fighting the enemy. After all, if you’re careful, you can probably reduce your losses due to accidents, but you much less influence over what your enemy will do or try to do.

How can we apply this to the field of information security?

Information security is not that different from fighting a war. Instead of battling enemy forces for the control of terrain, information security organizations battle with hackers over control of sensitive information. There’s no distinction between peace and war in this conflict, but there is roughly the same difference between losses due to accidents and due to enemy action. With sensitive data, you can either lose it due to human error or you can lose it when you’re hacked. Losing it due to human error corresponds roughly to the Army’s losses due to accidents or friendly fire, and losing it when you’re hacked corresponds roughly to the Army’s losses due to enemy action. Which causes the loss of more data – human error or being hacked?

The 2008 edition of CompTIA’s Trends in Information Security report, estimated that 30 percent of serious data breaches are caused by human errors, another 30 percent are caused by a hacker taking advantage of a human error, and only 40 percent are caused by a hacker actively overcoming flaws in technology. These numbers are quite a bit different than they were five years ago. The 2003 edition of the same report estimated that only 8 percent of serious data breaches didn’t involve some sort of human error. People are getting better at protecting sensitive data, but they still not very good at it. It’s still the case that most serious data breaches are caused by a failure of people instead of a failure of technology.

So just like it’s important for an army to worry as much about accidents as it does about enemy forces, it’s just as important for information security organizations to worry about human errors as it is for them to worry about being hacked. And just like an army can definitely reduce its losses due to accidents but has less influence over losses due to the actions of their enemies, information security organizations can reduce losses due to human error but have less influence over losses due to hackers. The threat from hackers is bad enough by itself. Don’t make their job any easier by making human errors more common than they have to be. Training is cheaper and easier than buying and supporting security technologies. Don’t overlook it.

2009 business risks

The 2009 Ernst & Young business and risk report is now available. The predictions that E&Y has made in previous editions of this report have been fairly accurate, so I always look forward to seeing the next edition of it. Like the reports from previous years, this year's report has a few interesting things in it.

The first thing that I noticed was an obvious non sequitur by Edmond Escabasse. He's the CEO of Asialis and a member of the board of directors of ParisTech Telecom. He's also the person who wrote the section of this year's report that talked about how regulation, convergence and the evolution of economic models are important to businesses. Here's what he said.

In the complex world of telecoms, care needs to be taken to avoid confusing industry drivers with sector risks. Instability is driven by a number of factors, such as the capital intensive demands of infrastructure, constant technological disruptions and the rapid rate of service development. Taken together, they make for an industry that is as unstable as it is innovative.

He then follows with this totally unrelated statement.

In this light, regulation is key to ensure that all players get fair remuneration for their work, avoid economically unjustifiable network migration and are allowed to cooperatively evolve with other segments of the industry.

It's not at all clear to me why regulation is needed to ensure that companies make a fair profit, don't make bad investments and negotiate mutually-beneficial deals with other companies. Shouldn't successful companies do these things on their own? If they can't, they probably shouldn't be in business. Perhaps Mr. Escabasse's view of the world has been affected by the telecom bubble of 1997-2003. But even if this is the case, it's not clear why regulation will keep managers from making bad decisions, which was really what caused the telecom bubble.

One thing that's interesting in this year's report is the fact that there a new threat to businesses listed. This year "business model redundancy" is the 9^th biggest threat, and appears on the list of the biggest threats for the very first time. This is a threat because "technological change and industry transitions are making long-established business models obsolete, forcing industry-leading firms to reinvent their corporate strategies and structures."

This reminds me of the hearings before the Subcommittee on Economic Goals and Intergovernmental Policy of the Joint Economic Committee, back in June of 1982 when the Post Office tried to get their monopoly extended to cover email. The Post Office's pitch, "The future of mail delivery in the United States," is hard to track down these days, but it shows how they tried to justify this. Luckily, the Postal Rate Commission and the Federal Communications Commission didn't let them do it, and the use of email became widespread. And you didn't need to deal with the Post Office to get it. That's a bit of email history that's probably not widely known.

Types of indicators

There's a new report that's available from NIST that has some interesting ideas in it. This report is the draft of National Institute of Standards and Technology Interagency Report (NISTIR) 7564, Directions in Security Metrics Research.

The part of this report that I found particularly interesting is this:

Analogous to economic indicators, security metrics may be potentially leading, coincident, or lagging indicators of the actual security state of the system. The distinction is significant. A coincident indicator reflects security conditions happening concurrently, while leading and lagging indicators reflect security conditions that exist respectively before or after a shift in security. If a lagging indicator is treated as a leading or coincident indicator, the consequences due to misinterpretation and reaction can be serious. The longer the latency period is for a lagging indicator, the greater the likelihood for problems. That is, a lagging security metric with a short latency period or lag time is preferred over one with a long latency period, since any needed response to an observed change can take place earlier. It is important to recognize lagging indicators and, if they are used, to be prepared to handle the intrinsic delay and associated limitations.

That's obvious when you hear it, but I hadn't thought of that before.

Leading indicators are ones that tell you what's going to happen in the future. Coincident indicators tell you what's happening right then. Lagging indicators tell you what happened in the past. What you'd like to find is a leading indicator of the security that your systems have. If that indicator starts to drop, you have a chance to address the source of the lower level of security before it becomes a problem. If you have a lagging indicator, by the time that you find out that you once had a lower level of security, you may already have been compromised.

The problem is that it's not clear what a good leading indicator of information security is. If you can find one, you can probably have the basis for a good service or product.

Experimental security

 

Which keeps you drier – walking or running in the rain? It turns out that doing a careful analysis of this problem isn't that hard. There's a paper by mathematician David Bell that walks through a complete solution. Like most things, if you think carefully about the problem, it turns out to be more complicated than you first think. In the case of keeping dry in the rain, it turns out that the optimal solution depends on the direction that the wind is blowing. If the wind is coming from in front of you, you keep driest by running. If it's coming from behind you, you keep driest by keeping pace with the wind. With most problems, however, a definitive solution isn't as easy to find. Information security is particularly tricky in this respect.

When you take a careful look at the risks that come from using computer systems, it's very difficult to find all of the risks. Even if you find them, understanding how serious they are can be hard. Understanding the best way to address them is even harder.

Because most people probably aren't aware of Bell's solution to the walk-or-run-in-the-rain problem and don't seem to be inclined to derive the optimal solution themselves, they often try other approaches. If what you see on the Internet is true, many people have resorted to comparing how wet they get when they walk in the rain to how wet they get when they run in the rain to estimate which approach is best. Most of these seem to arrive at the right answer – that it's better to run.

In information security, we have a similar problem. Even if we want to do a careful model to help find the optimal way to get the security that we want, we can't do it because we don't have enough accurate data about security risks. In the absence of reliable risk information, a similar approach to information security may be the best that we can do – just try different things and see which works the best. You might call this approach "experimental security." There may be no better approach.

Questioning risk models

A critical look at the safety estimates for the Large Hadron Collider (LHC) may give us some useful insights into estimating the risks that information security tries to address. Here’s why.

The LHC is the world's largest particle accelerator. By smashing beams of protons or heavy ions together at extremely high energies, physicists doing experiments with the LHC are able to test predictions of high-energy physics and perhaps even give us additional insight into the structure of the universe a short time after its creation in the Big Bang almost 14 billion years ago. But because it works at such high energies, some people believe that it might be able to create microscopic black holes that could destroy the Earth. There has even been a law suit filed to stop the operation of the LHC based on these concerns. The legal challenge to the operation of the LHC was eventually dismissed, but a new paper questions the methodology of the study that estimated that the chances of a black hole being formed by the LHC are too low to worry about.

"Probing the Improbable," by Toby Ord, Rafaela Hillerbrand and Anders Sandberg questions the accuracy of the estimates that the chances of the LCH destroying the Earth are too small to worry about. They don't claim that the LHC is dangerous. They just question the methodology of the safety study.

The basis for questioning the methodology of the safety study is that the probabilities of the dangerous events that the study estimates are so low that they are dwarfed by other errors. The LHC safety report estimates that there's roughly a 1 in 1 billion chance per year of the LHC destroying the world. On the other hand, the chances of the model used to produce the estimate being in error or of an error happening in scientific calculations are much higher. This means that the 1 in 1 billion number isn't really an estimate of the safety of the LHC. Instead, it's really a conditional probability: the probability of the LHC being safe given that the model is accurate and there's no error in the calculations. According to "Probing the Improbable," roughly 1 in 1,000 is a reasonable estimate for both the chances of a peer-reviewed scientific papers turning out to be inaccurate as well as the chances of an error in calculations happening. Accounting for these possible sources of error can increase the overall estimate of the danger posed by the LHC by a significant margin, perhaps by a factor of 100 or so.

Information security deals with a similar situation. In quantifying the risks from using computer systems, we also deal with relatively rare events, but ones that can have severe or catastrophic consequences. This suggests that you could probably make a similar criticism of many risk models. In many cases, the probability that there's an error in the threat model or in a calculation may be greater than the actual probability of an event. After all, most risk models don't really get the same level of scrutiny that peer-reviewed scientific publications do. But just like the paper by Ord, Hillerbrand and Sandberg doesn't say that the LHC is dangerous, this doesn't mean that inaccurate risk models tell you that systems are not secure. It just means that you might want to question exactly what a risk model can actually tell you.

Financial risk tradeoffs

Risk homeostasis is the theory that people like a certain level of risk in their lives and will tend to change their behavior, possibly increasing risks in one area if the risks that they experience in another area are reduced. Experiments seem to show that there's some basis for believing that this actually happens in some cases, although it's not clear exactly how much behavior is changed and how important the effects of the changed behavior are.

If one risk is reduced, people may change their behavior to include other risky activities, and the new situation may actually either be better or worse than the original situation. If the new behavior causes more loss than the original behavior, then reducing the original risk will actually result in a net loss. If the new behavior causes less loss than the original behavior, then the reducing the original risk will result in a net gain. Two examples from the financial services industry may illustrate this.

At the heart of the recent financial crisis, for example, is the rate at which American home-buyers are defaulting on their mortgages. A careful look at the available historical data from the FDIC shows that the default rate for mortgages has actually been steadily increasing since 1972, and that the current situation was probably inevitable in light of this trend. The FDIC report that gives this historical data also shows that the trend  towards consumers accepting more and more financial risk is the most important cause of the increasing default rate on mortgages. So if the increased default rate on mortgages is caused by consumers' willingness to accept more financial risk, why have people been willing to accept more and more financial risk?

One possible explanation for this trend is that the increased acceptance of financial risk was caused by the safer environment caused by the stricter health and safety standards that were adopted over roughly the same period. Perhaps people that live and work in a safer environment found assuming additional financial risk as a new way to keep their lives exciting. If this is the case, the trillions of dollars in losses that we're now seeing in the financial services industry may actually outweigh the benefits from the safer environment.

Another example of substituting one risk for another may be seen in the ways in which credit unions make their money. One difference between credit unions and commercial banks is that more customers of credit unions have overdraft protection on their checking accounts than customers of commercial banks do. Having this service in place makes writing a bad check less risky than it would be otherwise, and credit union members probably make up for this decreased risk by being less careful about the checks that they write. The fact that over 60 percent of the revenue of credit unions comes from charges from overdrafts indicates that this may indeed be the case. For commercial banks, less that 18 percent of their revenue comes from overdraft charges.

So it seems that credit unions may essentially be possible because of the increased risks that they get their customers to accept and the fees that they can charge to support this risky behavior. Credit unions seem to serve very useful purposes, so it might be the case that the services that are subsidized by their customers carelessly writing checks may more than make up for the costs that the careless customers incur.

Is risk homeostasis real?

Is risk homeostasis real? There are studies that both confirm and deny its existence. Many of these studies are biased, but research that tries to eliminate the bias seems to indicate that risk homeostasis is real.

Risk homeostasis is the theory that people like a certain level of risk in their lives, and that if you eliminate one form of risk, people will tend to compensate by taking additional risks. If this really happens, it has significant public policy implications. Wearing seatbelts, for example, might make people feel safer so that they compensate by taking other risks. If the dangers from these additional risks exceeds the danger from not wearing a seatbelt, then we may actually be better off by not requiring people to wear seatbelts than by requiring people to wear them.

In the case of seatbelts, it can be difficult to get an unbiased answer as to what’s best. Some researchers, particularly those with Libertarian leanings, seem to want to prove that making people wear seatbelts doesn’t make sense. You can see an example of this here. Other researchers, like those working for insurance companies or government health and safety organizations, seem to want to prove that making people wear seatbelts is a good idea. You can see an example of this here.

Supporters of either side in this debate may selectively cite statistics that support their position while ignoring those that don’t. Because of this, there are studies that have shown that requiring drivers to wear seatbelts is both a good idea and not a good idea, which makes it difficult for policy-makers to make an intelligent and informed decision about what’s best to do.

There are also areas of information security in which we might expect to see the effects of risk homeostasis if the effect is actually real. We might expect people running anti-virus software, or example, to be less careful when opening emails or attachments to emails if they believe that their anti-virus software is protecting them.

Jeremy Jackson, while a student at Simon Frasier University, decided to test whether or not risk homeostasis is real. To do this he carefully created an experiment that tried to eliminate all of the sources of potential bias that earlier experiments might have had. His experiment tried to test the accuracy of the original study that claimed that drivers compensate for the additional safety that wearing seatbelts provides by driving more recklessly. You can get his full findings here.

The bottom line is that the effects of risk homeostasis seem real, so that we can expect to see people compensate for decreased risks in one area by taking additional risks in another area. It’s still not clear, however, whether or not this compensating for decreased risks in one area leads to an overall gain or loss.

It might be the case, for example, that if you eliminate a risk that's causing $10 million in loss that you get people taking compensating risks that only cause $5 million in loss. If that's the case, then trying to eliminate the first risk makes sense. If the compansating risks cause $15 million in loss, however, then you're better off not trying to eliminate the first risk. Because it's impossible to tell which of these will happen for any particular risk, the best way to manage any given risk needs to be looked at on a case-by-case basis.

A Different Philosophy on Preventing Drunk Drivers

Suppose someone gets caught drinking and driving. They often avoid jail time, but in some cases the courts mandate a breathalyzer be installed in the car, it won't start unless the driver passes the sobriety test. In other cases, the offender's driver's license is revoked. The message is, "If you drink, don't drive."

I think that's wrong. I think if people are caught drinking and driving, they should not lose their license to drive, they should lose their license to drink.

In my opinion, here's how the system should work. Your drivers license, by default, has a red stripe through it, meaning you aren't allowed to buy liquor. If you want the red stripe to go away, prove to the DMV you are of legal age (which should be 18, not 21, in my opinion) and you have no drunk driving convictions.

If you have no drivers license, but would like to buy liquor, get a license to drink (an ID card like the drivers license).

We now punish liquor stores and bars if they sell and/or serve alcohol to underage people, we would simply update that to punish them for serving to people who have no license to drink. Laws now say that citizens can be held liable if they serve alcohol to underage people (even if they don't sell it), we would update that as well.

Of course, this would not prevent people who lost their license to drink from obtaining alcohol, but I think it would make it harder for them to get it, and harder to get it away from their homes. That is, if someone gets a few beers from the fridge or a few shots from the liquor cabinet at home, we can't stop them. But they are less likely to drive after that. People who drink and drive are often going home after drinking.

Certainly this would not prevent all drinking and driving, but the current system doesn't either. We have an imperfect system, now, so if we replace it with another imperfect system that does a better job of reducing the problem, then we're still coming out ahead.

Another advantage of this system is that bars, restaurants, nightclubs, liquor stores, and beer, wine, and liquor producers will all have a monetary interest in reducing drinking and driving. They would spend some money and effort themselves to reduce the problem. That means some of the costs of fixing the problem will be borne by those who help create it.

One disadvantage is that it might make everyone a law enforcer. If you have a party at your house and serve alcohol, do you have to check everyone's ID? We would have to address this issue. Maybe we do say people who host parties are responsible for keeping alcohol oout of the hands of non-licensed drinkers. Or maybe there is a less draconian solution.

Another reason I like this idea is that it does not restrict someone's ability to make a living. Driving to and from work can sometimes be a necessity to hold a job (no public transportation available, cabs would be too expensive, carpooling not possible), so taking away a drivers license can make it too difficult to hold a job. We don't want drunk drivers to not work, we want them to quit drinking and driving.

If we want to prevent the drinking and driving combination, take away one of those elements. Why not take away the drinking rather than the driving?

Perception and reality

Where I live in San Jose, there's a shortage of parking. Every house has a two-car garage, but most of the garages are used for storage instead of parking. Add a few families with three or four cars, and you have a situation where the demand for parking spaces exceeds their supply. One of my neighbors actually blames the Bush administration for our parking problems. I'm not sure of what line of reasoning led him to that conclusion. I was fortunate enough to have my wife listen to those particular details.

This is probably a case where there's a difference between perception and reality. I seriously doubt that politicians in Washington did anything that created The Great San Jose Parking Crisis, but there's at least one person out there who believes otherwise and I doubt that any amount of facts will change his opinion. His perception and reality will probably never agree.

Information security has its own set of mismatches between perception and reality. For example, there's the perception that e-mail is in danger of being intercepted and read while it's on the Internet, but that it's safe inside the firewall. On the other hand, the reality is that e-mail is definitely in danger of being intercepted and read inside the firewall. It's fairly easy for anyone on your network to watch the traffic on it, and it's also easy for mail administrators to read people's e-mail. I know of many more cases of an administrator intercepting and reading e-mail that I do of e-mail being intercepted and read on the Internet. Most security people you talk to will probably have the same story. Despite this, the perception is that e-mail is safe in the very place that it's at the most risk.

This may or may not be a serious problem. If all of your employees can see all of your data, then you have nothing to worry about, but this is probably not the case. There's almost certainly lots of sensitive information contained in some of the e-mails that are sent within any business. Your HR people probably send documents back and forth that contain all sort of sensitive information in them including salaries, social security numbers and more. Executives preparing for their quarterly board meetings probably send documents back and forth that contain all sorts of sensitive information about the financial situation of their company and its future plans. Sales managers probably send messages to other sales managers and to the sales engineers who support them that discuss the details of the deals that they're working on. All of this sensitive information may never leave your network, but you also may not want it to get into the wrong hands, and that doesn't necessarily mean that a hacker gets his hands on it. So if you're considering encryption as a way to protect sensitive information, don't forget to protect information when it's the most vulnerable, and that's when it's still in your network.

Virtual risks

There's often a big difference between perceived risks and actual risks. Understanding the difference may be important to people in the information security industry because people probably buy security products to mitigate perceived risks instead of actual risks. Even more tricky to deal with are "virtual risks," in which there's no easy way to determine what the real risk is or when experts can't agree on the nature of the risk.

One area in which it's not clear what type of risk really exists is in deciding whether or not cell phones pose a health threat. The Interphone study, a six-year study that cost $30 million and involved scientists from 13 different countries, tried to assess whether or not such a threat exists and come up with very mixed conclusions. Some researchers are claiming that the study showed that cell phone use seems to prevent certain types of cancer. Others are claiming that the study showed there's no connection between cell phone use and cancer. There's apparently no consensus on what the data collected by the study really means. In the absence of a meaningful scientific consensus, people will probably decide what to do based on what they think the risk is, so the issue of cell phone safety may soon enter into the realm of virtual risk if it isn't there already.

An even stranger situation seems to have happened in Sweden, where some people apparently have "electrosensitivity," or the unfortunate situation that electric fields cause them pain. The Swedish government has recognized this as a legitimate disability and will pay to have the houses of sufferers shielded. The catch is that electrosensitivity is totally psychosomatic. The discomfort felt by sufferers of electrosensitivity is real, but it's also not actually connected to the presence of an electric field! So this may actually qualify of a real risk, although it's certainly different than the risks that we usually worry about.

Applying risk homeostasis

Information security is the application of risk management principles to information technology, so we should expect that results for the broader field of risk management should give useful results when specialized to information security. The concept of "risk homeostasis," as defined by Gerald J. S. Wilde in his book Target Risk, may be such a principle. Risk homeostasis theory tells us that we need to modify the behavior of employees to have an effective information security program, something which is often overlooked in the design and implementation of such programs.

The principle of risk homeostasis tells us that people feel comfortable with a certain level of risk in their lives. So if one type of risk is somehow reduced, people will tend to adjust their behavior to compensate, perhaps accepting additional risks as they do so. Wilde's research indicates that this happens in many cases.

If risk homeostasis is indeed an inescapable part of human behavior, as Wilde suggests, then we can expect it to apply to the use of information technology as well. Traditional techniques of minimizing risk usually involve the "triple-E" of engineering, education and enforcement. On the other hand, risk homeostasis theory tells us that the motivation of users is the most important factor to consider, yet traditional approaches do little or nothing to address this, and may just reallocate risk instead of reducing it.

Risk homeostasis theory provides a way for using motivations to affect behavior, and Wilde's research has found a number of characteristics of successful risk reduction programs that are common to many such programs. Incentives play an important role in such programs, and are particularly effective at changing behavior. The common characteristics of successful risk reduction programs include the following:

1. Managerial vigor. Managerial commitment to a program should be obvious and reinforced often. This applies to any program, and information security is no exception.
2. Rewarding the bottom line. Effective incentive program should reward the outcome instead the intent. So it is better to measure the number of computer viruses that an organization is infected with rather than the percentage of computers equipped with anti-virus software.
3. Rewards must be attractive. Incentives to employees that successfully reduce the number of security incidents could include cash, shares of stock, extra privileges or extra holidays. Rewards do not have to be large to be effective.
4. Progressive incentives. It is more than four times as difficult to remain free of security incidents for one year than it is to remain free of security incidents for one quarter. So a reward for a complete year with no security incidents should be more than four times as great as the reward for no security incidents for a single quarter.
5. Simple rules. A successful information security program should be kept simple and easily understandable to all employees who it affects.
6. Perceived equity. The rewards of an incentive program should be perceived as equitable by those employees that it affects. Employees who are not eligible for an incentive for some reason should not resent the incentives received by those who are eligible.
7. Perceived attainability. Goals for which incentives are offered should be attainable. If goals are unattainable, some people will not make an active attempt to meet the goals. A goal of no security incidents at all is probably unattainable, so a more realistic goal should be used instead.
8. Short incubation period. The time period for which an employee needs to remain free of security incidents in order to be eligible for an incentive should be relatively short. Delayed incentives are not valued as much as ones which are immediate.
9. Reward both group and individual performance. Incentive programs should be designed so that they strengthen peer pressure towards a goal of effective information security. Incentives to entire groups as well as to individuals are also useful to this end.
10. User participation in program design. Any incentive system should be developed in cooperation with those who will be affected by it. People are more likely to achieve goals that they have helped define.
11. Prevention of incident under-reporting. An effective incentive program should counter any tendencies to not report security incidents. If a computer is infected by a virus, for example, not reporting the incident should be penalized more than just getting a virus.
12. Reward all levels of an organization. Workers, supervisors and middle-management should all be eligible for incentives for meeting their information security goals. This creates a more cohesive and pervasive orientation towards being security-aware.
13. Appropriate information security training. Although training for security is different from motivating towards security, some studies suggest that it helpful for employees to be told what specific behaviors will help avoid security incidents.
14. Maximize net savings or benefit/cost. In the planning an incentive program, there will not be enough resources to reward all behavior, so some thought should be given to the question of exactly what behaviors are rewarded. Be sure that the behavior that is encouraged is that which provides the greatest return for the organization.
15. Effective research. Like any health and safety program, an incentive plan for information security should not be casually introduced. Understand what factors an incentive program can affect, the benefits from the possible changes, as well as the costs of doing so, before implementing any incentive program.

By using an incentive program with the characteristics that Wilde’s research indicates are the most effective, you may maximize the chances of changing employees' behavior so that information security risks are minimized. You might want to give such elements serious consideration when reviewing the status and future direction of existing information security programs.

Do we have enough data breaches?

Do we have enough data breaches?

That may be a question that you've never heard before. Instead, attention usually focuses on the massive amount of sensitive personal information that's lost through data breaches and the ways to address the problem. It's certainly possible to reduce the amount of sensitive data that's lost. You can encrypt storage devices like laptop hard drives and backup tapes, for example, so that if the storage is lost then the sensitive data that it stores isn't available to whoever ends up with the device.

The question that's rarely considered is whether or not this is actually worth doing. After all, many forms of encryption are expensive and hard to use, so it might be the case that the cost of encrypting your storage is greater than the damage that losing the stored data will cause. There's also the question of availability to address. If you can't decrypt data that you've encrypted, your encryption hasn't just protected the sensitive data from hackers – it's also cryptographically shredded it and made it unavailable to you also.

This is much like the situation that auditors face when trying to eliminate fraud. With no controls in place, you'll probably have lots of losses due to fraud. At the other extreme, you can have extremely strict controls in place, but you'll find that you’re spending more on the controls than the fraud that you’re eliminating. So there's an optimal amount of fraud, and auditors don’t expect you to have controls that reduce fraud past this optimal level.

In the case of protecting sensitive data, we have a very similar situation. With no controls at all in place, it's likely that all of your sensitive data will find its way into the hands of hackers. At the other extreme, you can have extremely strict information security measures in place. But in this situation you'll find that the costs imposed by the higher level of security is extremely high, and you're better off without such draconian measures. So you also need to find the point where the cost of the security measures isn't too high, but the amount of sensitive data lost also isn't too high. And just like auditors don't try to reduce fraud past the optimal level, you shouldn't try to reduce data breaches past the optimal level either.

This means that it's certainly possible that you're not having enough data breaches, and that it would make sense to reduce the level of security in your organization until you find the right balance between data loss and the cost of your security measures. This is almost certainly not the case. Most organizations still don't encrypt much information, and this is probably because some forms of encryption are indeed hard and expensive to use. If you've only looked at those technologies, then you might have come away with the impression that it was better to not use the technology and to take the risk of losing data.

Fortunately, encryption technology has gotten much better in the past few years. It's now simple enough to use that the costs of supporting it make it reasonable to use in more cases than before. Key management technology has also gotten better, so you can be sure that you'll be protecting your data with encryption instead of shredding it. So if you once looked at encryption as a way of protecting sensitive data and decided not to use it, it might be worth looking at the newer technologies. They're much better than they once were, which means that it’s now cost-effective to use them in ways that it wasn't in the past.

The dangers of a risk assessment

Performing a risk assessment is often listed as one of the first steps in information security life-cycle methodologies. Performing such a risk assessment is actually hard to do. There's little valid data that tells how often security vulnerabilities are exploited, and it's very hard to quantify the damage that’s done if a hacker actually exploits a vulnerability.

This means that estimating risks, which are defined to be the probability of an event multiplied by the loss associated with the event, often isn't practical in information security. It turns out that there may actually be another reason to do such a risk assessment, even if was feasible, and this reason relates to the potential legal complications that may arise if you do a careful risk assessment. This was first noted by W. Kip Viscusi in an internal discussion paper that he wrote while at Harvard Law School that was subsequently published in the Journal of Legal Studies as "Jurors, Judges, and the Mistreatment of Risk by the Courts."

As we previously mentioned, the Hand Rule tells us that you’'e not required to spend more than the value of a risk to mitigate it. So if it will cost you $2 million to mitigate a $1 million risk and you decide not to spend the $2 million, the Hand Rule tells that you can't be found negligent.

Viscusi’s research showed that jurors don't properly apply negligence rules like the Hand Rule, particularly in cases where the probabilities of events are small and losses are large. Jurors seem to be offended by trade-offs between costs and risks. In Viscusi's research, the only factor that showed a meaningful correlation with the size of damages awarded by synthetic juries (those composed of test subjects that were asked to decide damages under a number of different scenarios) was with whether or not a risk assessment was performed.

The personal characteristics of jurors didn't matter. The cost per life saved didn't matter. Even a high absolute level of risk didn't matter. The only factor that was significant was whether or not a risk assessment was performed.

Here has been no research similar to Viscusi's that asks about damages from data breaches or other security incidents, but the fact that jurors might be offended by a careful risk assessment should be chilling to people in information security organizations. Without a risk assessment, you may not spend your budget in a reasonable way, but with one, you may be leaving yourself open to other complications.

Dealing with risk

The uncertainly of events has two components: the likelihood of an event and the impact of an event. Likelihood is usually defined as a probability of an event occurring, while impact of an event is usually defined by the financial loss that accompanies an event. Multiplying the probability of an event by the loss that accompanies an event gives us a way to quantify the risk associated with an event. Risk is the amount that we expect to lose by a certain activity.

In a hypothetical example, suppose that the data on each of our laptop computers is worth $10,000 and the laptops themselves are worth $1,000, and that there is a 10 percent chance of a laptop being stolen in a one-year period, resulting in a loss of the data on the laptop as well as the laptop itself. This means that the risk from using laptops represents $1,100 of risk per laptop per year.

Once we understand the level of risk involved in using a particular technology, we need to decide how to manage this risk. We have four general ways to manage risks: avoidance, reduction, transfer, and acceptance.

If we decide to avoid a risk, we might simply refuse to use a technology that causes a risk. In our example of laptop computers, one way to deal with our hypothetical $1,100 of risk is to ban the use of all laptops in our organization and accept the implications of such a decision. In some cases, this may actually be the best way to deal with certain risks. In our hypothetical example, if we cannot demonstrate at least $1,100 of benefit from each laptop, this decision may be reasonable. In other cases it may not be feasible to avoid the risks associated with some technologies and we need to consider alternatives to avoidance.

If we decide to reduce a risk, we take an action to reduce either the likelihood or the impact of an event. In our example of laptop computers, we might be able to reduce the rate of laptop theft by investing in locks to make theft of the laptops more difficult. Or we could reduce the impact of having a laptop stolen, perhaps by deploying a full-disk encryption product, so that when we lose laptops to theft, the data on the laptops is not compromised. Because there is also loss associated with the physical loss of a stolen laptop, encryption does not eliminate the risks associated with using laptops, but only reduces it. Most investments in security technologies behave similarly, leaving some residual risk after they are implemented, and understanding the level of residual risk can be as important as understanding the original risk.

If we decide to transfer a risk, we get someone else to accept the risk, usually at a cost to us. Purchasing insurance is one way to do this, as is outsourcing the operation of a particular technology. Transferring risk often reduces the uncertainty of outcomes, but probably requires a cost roughly equal to the risk that we are transferring. So if we can purchase an insurance policy for $1,000 per year, this premium reflects the average loss that the insurance company expects its customers to experience. Losses above the average amount are reduced at the expense of increasing losses which would have been below the average amount, but we gain a level of predictability by doing this. In the terminology of statistics, we have slightly increased the mean of our loss but greatly decreased the variance of our loss.

The final way to address risks is by doing nothing, or by accepting a risk. In our example of the risk associated with the loss of laptops, if the cost of full-disk encryption products were much higher than they currently are, say $1,500 per laptop per year, then it would not be worth deploying the technology because the cost of reducing the impact of the risk would exceed the risk itself. In this case it would be reasonable to not encrypt the data on the laptops, and to just accept the risk associated with losing the laptops that we expect to lose. Many organizations are dealing with many risks in this way without fully understanding the implications of their actions; doing nothing is certainly the default way to manage risks, but it may not always be the best way.

Learning from the Marines

Information security concerns managing the risks that come with using IT systems. Actually, it's probably even vaguer than that. There is so little known about some security vulnerabilities, that information security is probably closer to managing uncertainty than managing risk. Because of this, we may be able to find useful insights that are relevant to information security in research that has been done on how people make decisions under uncertainty. In particular, a study by the United States Marine Corps may give some insight into how we can expect some decisions to be made by security managers. One USMC publication describes the uncertainty that Marines face in the following way:

"While we try to reduce these unknowns by gathering information, we must realize that we cannot eliminate them. The very nature of war makes absolute certainty impossible; all actions in war will be based on incomplete, inaccurate, or even contradictory information."

If you replace "war" with "business," this statement is still accurate, so it seems general enough to be applied to more than just the USMC. But while all businesses face uncertainties, those faced by information security managers are probably greater that those faced by many other managers, and some of the research that the USMC has done about decision-making under uncertainty may be particularly useful for providing insights that information security managers can use.

One interesting report is Tactical Decision-Making Under Uncertainty: Experiments I and II, which describes the results of experiments that looked as the ability of leaders to make decisions in a Combat Operations Center under varying levels of uncertainty. One interesting result was that although both inexperienced leaders and experienced leaders made decisions just as quickly, the less experienced leaders chose the "wait and see" option more often than their more experienced counterparts did. Choosing to wait for the situation to develop can lead to problems, so it’s probably reasonable to summarize this finding as experienced leaders make better decisions than inexperienced ones.

The unusual finding in this USMC study is that experience that helped leaders make better decisions was not general experience, but rather experience doing a particular job. So while years of service or rank didn't help reduce the tendency to wait and see, experience in a COC did. The performance of leaders with more COC experience was also not affected as the uncertainty that they were exposed to increased.

If we try to generalize the conclusions of this USMC study, it seems that there may be no substitute for relevant experience, not just experience. So we might expect information security managers with more experience in information security organizations to make better decisions that their less-experienced counterparts, even those with more experience managing other types of organizations. This study also seems to question the assumption that a competent manager can manage any organization. It may be the case that direct experience instead of general experience is actually more important. Even though the fact that managers are fairly generic seems to be widely believed, I don’t recall seeing any evidence that supports this claim.