Superconductor

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.

Going the way of Pluto?

In August 2006, astronomers at the meeting of the International Astronomical Union in Prague voted to adopt a new definition of the term "planet" that reduced the number of planets in the solar system to eight. Pluto was reclassified as a "dwarf planet," much to the dismay of many astronomers and much of the general public. The trend of "convergence," in which information security becomes integrated into corporate risk management organizations, may soon result in a similar type of reclassification of the discipline.

There are valid scientific reasons to support the new definition of a planet. Pluto is more similar to the icy bodies that form the Kuiper belt, the large disk-shaped region past Neptune that is home to many such objects, than to the other planets. Many people, however, find this distinction somewhat arbitrary, and have argued that Pluto should remain a planet. Some have even started a campaign to have its place as one of the nine planets restored. Only time will tell whether or not they are successful.

There have two main reasons advanced for reclassifying Pluto as a planet again: nostalgia and politics. The argument based on nostalgia is essentially that everyone knows that Pluto is a planet, so it should remain a planet. Six billion people cannot be wrong, can they?

The argument based on politics is essentially that it is easier for scientists to get funding for research on planets than on dwarf planets, trans-Neptunian objects or Plutonian objects, other terms for bodies that do not qualify as being planets in some way. It is no secret that there are lots of small, icy bodies in the Kuiper belt, making it hard to justify funding for research that tries to find more of them. Any why would NASA spend $675 million on the New Horizons spacecraft if it is just going to visit one of these many icy rocks? On the other hand, the goal of finding another planet sounds much more important and worth of funding.

The field of information security may be due for a similar reclassification soon, as the trend towards combining information security and other risk management operations moves information security away from its roots in information technology and into the business world. The reasons for justifying the merging of security organizations seems to make sense from the business point of view, but not everyone agrees that such a change is the right thing to do. The arguments against doing this are eerily similar to the arguments for keeping Pluto classified as a planet.

One obvious argument against merging security organizations can be summarized as nostalgia, or the fact that information security practitioners have grown accustomed to not having to justify investments in information security technologies like others might have to do in their business. This has even been institutionalized in using different metrics to justify investments.

The return on security investment (ROSI) concept seems to have been created to overcome the obstacles that information security practitioners face because it is often difficult to justify investments in information security by using the conventional ROI metric. Some industry analysts have even argued that information security should be exempt from traditional risk analysis and management methodologies because the traditional methodologies do not work well in information security. Such special treatment might disappear if information security merges with other risk management disciplines.

Another argument against merging information security into a business-wide risk management organization can be summarized as politics. Many information security organizations now have the attention of upper management due to the recent increased focus on regulatory compliance. If information security becomes part of a corporate-wide risk management organization, the political influence that comes with the attention of upper management maybe reduced. If such convergence happens, many information security investments will probably be questioned if they competing for funding with other risk management projects. Can you really justify the TCO of PKI-based encrypted e-mail if the same investment can be used to reduce slips, trips and falls?

The business forces that are pushing for the convergence of information security and other risk management functions seem to be fairly strong, which may lead to the eventual disappearance of information security as a separate discipline. For many information security professionals, it seems that understanding the business where they work has already become as important as understanding information security technology. As the trend of convergence continues, understanding the business aspects of their jobs will probably become even more important. And unlike the possibility that exists of reinstating Pluto as a planet, there seems to be little chance for this trend to be reversed. So information security professionals should note the trend of convergence and try to understand what it can mean for them in the future.

The Hand rule

The Hand rule is a principle that everyone working in the field of information security should know about. It's an example of a balancing test. In such tests, courts try to make outcomes depend on a reasonable balance between competing interests.

The Hand rule can be traced back to the 1947 ruling in the case United States v. Carroll Towing Co., in which judge Learned Hand ruled that determining liability depends on comparing the cost of preventing an accident to the expected loss from an accident. Here's what Hand actually said:

"Possibly it serves to bring this notion into relief to state it in algebraic terms: if the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B < PL."

This means that if it costs $2,000 to prevent an average loss of $1,000, you're not negligent if you don't spend the $2,000. Hand's ruling has been extensively studied by economists and game theorists, who seem to love finding pathological cases where the general principle can end up causing unexpected outcomes. An example of this can be found here.

The Hand rule is a good general principle to know and understand, but it can be difficult to apply to the decisions that information security managers need to make because the data that's needed often isn't available. In most cases, neither the probability of security incidents happening nor the damages that result from an incident are known very well.

Consider the simple case of a web server. Almost all software has some sort of security vulnerability. Some just haven't been discovered yet. In such a situation, what's the probability of your web server being hacked? And if it is hacked, how do you put a dollar value on the damage that's caused? Because it's hard to answer questions like these accurately, it's hard to apply the Hand rule in a meaningful way. So although the Hand rule is often used in other risk management disciplines, it's typically not very useful in information security.

The real insider threat

Despite what you may have heard, the insider threat is probably not the greatest threat to your organization. The most detailed study of the insider threat is probably the one performed at Carnegie Mellon University at the CERT Coordination Center. In 2002, the Insider Threat Study was started jointly by CERT and the U.S. Secret Service National Threat Assessment Center, the goal of which was a careful and systematic study of insider threats. One source of the data that this joint operation uses is the annual E-Crime Watch Survey.

Since 2004, the E-Crime Watch Survey has been jointly run by CERT, the U.S. Secret Service and CSO Magazine, and it provides a good summary of the state of information security threats. The results of this survey concerning the relative frequency of insider and outsider attacks are shown below in Figure 1. Note that in the years 2004 and 2005, survey participants were not given the choice to indicate that they did not know the source of attacks on their networks. It appears that the incidents that were later classified as coming from an unknown source may have actually been earlier classified as coming from outsiders, but there's no way to be sure.

Figure 1: Data from the E-Crime Watch Survey from 2004 through 2007.

Other studies have found similar results. The 2007 CSI Computer Crime and Security Survey is the latest in a series of 12 annual studies of the state of information security. In each of the years that this study has been conducted, it has never found the insider threat to be greater that the outsider threat, and the 2007 report even comments on this:

"A great deal is made of the insider threat, particularly by vendors selling solutions to stop insider security infractions. It's certainly true that some insiders are particularly well-placed to do enormous damage to an organization, but this survey's respondents seem to indicate that talk of the prevalence of insider criminals may be overblown."

It's unlikely that the mistaken belief that insider attacks are more numerous than those from outside will disappear any time soon. But it might make sense to not base your purchasing decisions on one of the legends of information security that refuses to die. There are certainly some cases where the risk from insider attacks is so serious that it justifies either technology or other controls to limit the exposure to damage from it. These cases are probably the exception rather than the rule. In most cases there are probably better uses for your security budget.

A smoking gun?

In a previous post we mentioned how risk-risk trade-offs can make it tricky to measure the overall cost of trying to manage a risk. In some cases, the measures taken to reduce a risk actually cause more damage than they eliminate, making them cause a net loss rather than a net gain. Requiring drivers to wear seat belts in cars is probably a good example of this. Studies have suggested that people feel safer while wearing a seat belt and compensate by driving less carefully than they would otherwise and that this riskier driving actually kills more people than the seat belts save. In the face of complications like this, it's extremely difficult to create an effective risk-management program.

Another problem can be caused by the fact that it can be hard to accurately measure the total costs in many situations because unexpected benefits can sometimes accompany the costs. The recent legal battles between the American states and tobacco companies provide an example of this.

The basis for the multi-billion-dollar settlement between the states and the tobacco companies was the notion that the tobacco companies are causing the states to experience higher costs, and that the tobacco companies should compensate the states for these costs. A closer look at this situation, however, shows that the tobacco companies really aren't causing any net additional costs for the states at all. They're actually decreasing the states' costs.

Studies estimate that states incur medical costs associated with smoking cigarettes of roughly $0.58 per pack. There are also other costs like about $0.43 per pack in foregone taxes because of smokers dying early, higher life insurance costs of about $0.14 per pack, the cost of additional sick leave taken by smokers of about $0.02 per pack fires and the cost of fires caused by cigarettes of about $0.01 per pack. These add up to about $1.18 per pack of cigarettes.

On the other hand, the fact that smokers tend to die before non-smokers mean that they also tend to not be around to cause some costs. In particular, the lower retirement pension costs amount to about $1.26 per pack and the lower cost of nursing home care to about $0.24 per pack. This means that there’s a benefit to the states of about $1.50 per pack that's caused by smokers dying earlier than non-smokers. This means that there's actually a net benefit of $0.32 per pack of cigarettes to the states. So although there are very good reasons to reduce smoking, the costs that the states incur from smokers probably isn't one of them.

Is information security exempt from this particular problem? It's hard to imagine a case where the damage caused by being hacked is outweighed by the benefits that the hacking might bring. On the other hand, there are certainly security technologies that probably aren't worth their cost.

NRS 597.970

We've have seen more than 39 states adopt data breach disclosure laws since California Senate Bill 1386, these laws help with cleaning up the mess left behind by a breach. Now, however we are starting to see the first laws trying to address the problem of preventing the breach from happening in the first place. The first state to do this is Nevada with Massachusetts, Washington and Michigan to follow shortly. These laws mandate the use of encryption to prevent sensitive customer information from being compromised when that information is transmitted out of the business.

Nevada Revised Statue (NRS) 597.970, which is effective October 1, 2008.

NRS 597.970 Restrictions on transfer of personal information through electronic transmission.

1. A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.

2. As used in this section:

(a) "Encryption" has the meaning ascribed to it in NRS 205.4742.

(b) "Personal information" has the meaning ascribed to it in NRS 603A.040.

This certainly looks like it requires encryption, but a closer look at the law also shows that there's no penalty for breaking it.

NRS 597.100 Criminal penalty. A person who willfully and intentionally violates any provision of NRS 597.010 to 597.090, inclusive, is guilty of a misdemeanor.

However, this law opens up businesses to law suits and in combination with the prevailing data breach disclosure law, having encryption will limit a businesses liability in the event of a data breach. So adding some low cost encryption software seems like a small price to pay for protecting your customer and employee data from being exposed after all.

Nevada businesses - take a look at www.voltage.com/nevada

UPDATE: From the WSJ - October 16th, 2008

"In Nevada, companies that suffer a security breach but comply with the new law would cap their damages at $1,000 per customer for each occurrence. Those that don't comply would be subject to unlimited civil penalties under the proposed enforcement plan, said James Earl, executive director of the state's task force for technological crimes."

Should you rotate keys?

Some standards require you to periodically rotate your keys, or to decrypt encrypted data with the old key and then reencrypt it with a new key. The current version of the PCI DSS, requires this, for example. At the IEEE Key Management Summit last week, there was some discussion of whether or not rotating keys even makes sense these days.

Those arguing that rotating keys is unnecessary claimed that the desire to rotate keys is essentially a holdover from the days when the only standardized encryption algorithm was DES. DES has a fairly weak key – only 56 bits of key are actually used in the DES encryption algorithm. This means that defeating DES is feasible for an attacker with a relatively modest budget. In 1999, for example, the EFF built the DES Cracker, a special-purpose computer that can recover any DES key in just a few days of computation, for only $250,000. Against adversaries able to do this, rotating keys frequently may make sense.

On the other hand, a 128-bit AES key is much more secure than a 56-bit DES key. It's probably infeasible for even the richest national governments to build a special-purpose computer that can recover a 128-bit AES key in anything less than millions of years. For all practical purposes, adversaries can't beat AES.

If you periodically rotate your AES keys, there is a chance of some sort of problem happening every time that you decrypt and reencrypt your data. Maybe the hardware module that you use to do the encryption will fail. Maybe some sort of catastrophic error will occur in your key management system and you'll end up cryptographically shredding your data instead of protecting it. The chances of this happening may be small, but they’re probably much greater than the chances of an adversary beating AES. This means that rotating AES keys may actually cause a greater exposure to risk than not rotating them does.

But just because an adversary can't beat AES doesn't mean that they can't beat the key management system that creates and manages AES keys. So it might be the case that a more reasonable comparison is between an adversary's ability to beat a key management system and the chances of the same key management system causing a severe problem due to an unexpected failure of some sort. In this case, it's not clear which alternative offers the lowest risk. Key management technology and the products that implement it are still relatively new, so it may take a while to get enough data to say much about which alternative is really better. Until then, it's probably still a good idea to rotate keys regularly.

The lack of reliable data

One problem with the field of information security is that there's little reliable data about security vulnerabilities. Without reliable data on exactly what's a risk and what's not, it's very difficult to make good decisions about what's worth doing and what's not. It's even worse because information security deals with the vulnerabilities in very rapidly changing technology. So even if you had accurate data on the vulnerabilities that exist today, the changing technology landscape will probably make that data totally useless a year from now. Probably much sooner than that.

People have overcome similar problems in the past, and seeing how this was done might provide some insight into what could be done to get a better and more useful understanding of security vulnerabilities. The International Classification of Diseases (ICD) is probably a good model for this.

All members of the World Health Organization (WHO) report the causes of deaths in their country to the WHO in a standard format that's defined by the ICD. The most recent version of this scheme is ICD-10. If you're curious to see how people are dying throughout the world, you can find the combined data from all WHO members here, where it's broken down into the categories that ICD-10 defines. If you die from an intestinal nematode infection, your death will show up in category W032. If you die from an iodine deficiency, it's category W055. If you die in a traffic accident, it's code W150. If die from a snake bite, it's X20.

Having all WHO members report the causes of death in a standard format makes it easy to track the progress of many health and safety programs. If you want to learn how well the medical community is doing in eliminating bubonic plague, you can get the data that tracks this from the WHO. If you want to see how well safety features of automobiles are reducing the number of fatalities, you can learn this from the WHO data also.

If we'd like a system much like ICD-10, but applied to information security, we would need a way to report and classify security vulnerabilities. We're not that far from that today. NIST maintains the National Vulnerability Database which tracks known vulnerabilities, but there's not yet a good system to classify the vulnerabilities past a high-level description like a buffer-overflow vulnerability or a SQL injection vulnerability. Maybe that's good enough, but I doubt it. A better system might be needed. With the current NVD it's still hard to find exactly how many products have a particular class of vulnerability. That could just be a question of the user interface, however.

It would also be useful to know how many users are affected by each of the known security vulnerabilities. Vendors of commercial software probably know how many users there are of their products, but that information might be harder to get for open-source software. On the other hand, it might not be too difficult to get open-source projects to report how many downloads of their code that they have had, from which you can probably get a reasonable estimate of how many users have it installed. Having this data reported to a single organization might make it much easier to understand security vulnerabilities. NIST is probably the best organization to collect this data. Or is there a better alternative?

Getting predictable outcomes

COSO, the Committee of Sponsoring Organizations of the Treadway Commission, was formed in 1985 by the leading US accounting organizations to help address the problems of fraudulent financial reporting. Since then, COSO has written a number of reports that give guidance on many aspects of dealing with accounting issues, which includes elements of risk management. One of the more recent reports was the Enterprise Risk Management - Integrated Framework. The full report costs $75, but you can get the executive summary for free.

There are lots of interesting ideas in the Enterprise Risk Management - Integrated Framework. One of them concerns the big picture - why businesses should be interested in risk management and incorporate it into their strategic planning at the highest levels. One such idea that one of the important goals of risk management is ensuring predictability of outcomes. From this point of view, revenue of $200 million that's predictable is better that revenue that will average $200 million but could be anywhere in the range of $150 million to $250 million. So predictable outcomes should be preferred, even if they may be less desirable that some unpredictable outcomes.

This is essentially what insurance does. You pay slightly more for insurance than the average losses that you'd expect to incur without the insurance. The slight difference covers the operating costs of the insurance company. But by doing this, you gain predictability. Your loss will be no more that the cost of your insurance premiums plus whatever deductible you might have to pay.

Information security also provides a desirable level of predictability. Consider the case of laptop computers. About 1 in 10 laptops gets lost or stolen each year. Most of the lost laptops don't cause any problems. After all, most people really don't want the data on someone else's laptop.

Suppose that Alice is the VP of Marketing for an airline manufacturer and Bob is a sales manager for a plastic tubing company. Alice's laptop might contain marketing plans for her company, a few romantic comedies to watch on long flights and some classical music that she likes to listen to. Bob's laptop might contain the plans for his company's new line of narrow-threaded pipes that they plan to launch next quarter, a few action movies to watch on long flights and some rap music that he likes to listen to. Both Alice and Bob think that the information on their laptops is very valuable, but it's actually of no value at all to the other one. Alice doesn't care about what new types of pipe Bob will be selling next quarter, and has absolutely no interest in the movies and music on his laptop. Bob has a similar level of disinterest in everything on Alice's laptop.

This situation is probably typical, so that is a laptop is lost, the chances are that the person who ends up with it doesn't really want the data on the laptop, even if its original owner thought that it was worth millions of dollars. The serious trouble is caused by those rare cases where a lost laptop ends up in the hands of someone who does have an interest in the data on it. It doesn't happen often, but when it does, it can cause a major headache.

Encrypting the hard drive of laptops is good protection against these rare events. When they happen, the damage that they cause is greatly reduced. If you lose an encrypted laptop, the loss is limited to the value of the laptop and you're not gambling on who will end up with the data on the laptop. You'll have spent a little more, the cost of buying and supporting the encryption software, but you'll have gained a very predictable outcome by doing this. According to the COSO report, that's a goal that all businesses should have.

Government Regulation in Security: Good or Bad

You want to protect yourself in cyberspace from the thieves and other criminals. So you probably take precautions, such as using anti-virus software and a Spam filter, and keeping your sensitive data secure on your computers.

The problem is that other entities have your sensitive information on their machines and in their databases. You have no control over what measures they take to protect your identity. No matter how much effort you expend to protect yourself, your safety is dependent on other people. Furthermore, some of these other people have very little incentive to protect your info. If they spend money on security, they reduce their profits. But if they don't spend money on security and something bad happens, the damage doesn't affect them, it affects other people.  The operator of some internet concern can take the attitude, "I wouldn't like it if someone stole our customers' identities, but it's not my identity. I'm not the one who suffers."

It's kind of like valet parking. The valet company might take the attitude, "I don't like it when people steal cars, but it's not my car. It doesn't really affect me."

That's not exactly a valid comparison, after all, a valet company can be held liable for losses if their security was too lax, or if they are negligent. That's government regulation. If you like using valet parking, you're probably glad that the government steps in and has created some laws to give the valet companies significant incentive to take precautions with your car.

In cyberspace, various governments have stepped in to create laws giving companies incentives to employ security if they possess people's personal information. As with valet parking it might be liability. The government does not mandate that the company take precautions, or if they do take precautions exactly what they should do, but if something goes wrong, the company can be forced to pay customers remuneration, or pay fines to the government. Other regulations describe the steps companies must take, or prohibit various activities.

A more libertarian approach would be "buyer beware". Do some research before doing business with a company. Or join a private organization that does the research for you. You pay a fee and get access to the reports. Or buy insurance. If something goes wrong, the insurance company reimburses you for your losses. The insurance companies would then have an incentive to do the research and advise you on which companies to avoid. Maybe they would even have lists of the bad companies, and declare they will not reimburse if you incur a loss with them. If a company is lax with security, customers will stay away. The company that spends money on security will have smaller profits, but that's better than going bankrupt.

Which is better? Government intervention or market forces? In some ways, government is similar to the mythical private company researcher (which is not that mythical when you look at Consumer Reports, Morningstar, and other such organizations). The difference is in whether payment is voluntary or not. Also, with most of the government solutions, if you incur a loss, you don't get any money back. The company loses, but so do you. On the other hand, the free market approach still requires a government that enforces private contracts. And with the market solutions, who keeps an eye on the organizations who claim to do research or the insurance companies? Other private watchdogs ("it's turtles all the way down").

Would somebody who favors the market approach be willing to say there is no liability? That there is very little right to collect from negligent or even fraudulent people? Only insurance companies? And let the insurance companies do research? The government then regulates only the insurance companies.

Would someone who favors government solutions be willing to live with the "lag" the time between discovering something new and government's response to it?

Convergence may be a bad idea

"Convergence" is again a hot topic. In the past, it meant the trend of IP networks and telephone networks to move towards common technology. Now it refers to the trend of integrating information security groups and other corporate risk management organizations. There are good reasons for doing this, but a closer look at some aspects of information security may indicate that this may not be such a good idea.

Three of the major security professional organizations, ASIS International (ASIS), Information Systems Audit and Control Association (ISACA) and Information Systems Security Association (ISSA), recently sponsored a study on the convergence of information security and risk management. The result was the 2005 report Convergence of Enterprise Security Organizations by Booz Allen Hamilton, which discussed the trend of convergence and the reasons for it.

The desire for a single organization that's responsible for all aspects of regulatory compliance is one driver for convergence. Another is the migration of more corporate assets to information technology. This has caused a change in what the most valuable assets of businesses are and a corresponding change in the focus of risk management. These reasons seem fairly compelling, and seem to allow for more cost-effective risk management strategies. On the other hand, a closer look at information security casts some doubt on whether this strategy will be effective in the long run.

The fundamental problem is that the factors that are used to quantify a risk – the probability of an event happening and the loss that accompanies the event – are almost always never known in information security. In information security, it's often difficult to make estimates that are even close to being accurate. What is the probability of one of your e-mails being intercepted and read while it's on the Internet? If this happens, how much loss does it actually cause?

This means that the usual techniques of risk management don’t work very well on the problems that information security deals with. On the other hand, applying information security methodologies, where decisions are often made without any reliable data at all, to other risk management functions will also probably result in poorly-managed risks.

The best solution is probably to understand the differences between the types of risk that exist and to manage them differently. If you're doing that, does it make sense to merge the two functions into a single organization? Unifying information security and other corporate risk-management organizations may not necessarily be a good idea.

All your Bayes are belong to us

Risk management deals with the losses that accompany uncertain events. To find the risk associated with a particular event, you multiply the probability of the event happening by the loss that the event would cause. So an event that causes $1 million is loss but happens with only a 0.1 percent chance represents $1,000 in risk.

In some cases, parts of a population can have a much greater chance of experiencing a particular event than others. This can lead to misleading ideas about risks. In some cases, conditional probabilities give a better understanding of risks.

It's commonly believed, for example, that it's safer to fly on a commercial airline than to drive your car to an airport. You can get this result by using the average number of fatalities per mile for travel by car and travel by airplane to estimate the chances of being killed on each trip. A closer look at the data, however, shows that a significant number of deaths in cars are caused by young, drunk men who are driving late at night. Because young, drunk men tend to not be on the road when people driving to airports are on the roads, it's actually much safer for them. People driving to airports are also typically not young, drunk men. So the more relevant probability in this case is the probability of being killed in a automobile accident given that you're the kind of person who would actually be traveling to an airport. Based on this conditional probability, it turns out that air travel is actually more dangerous than driving.

Gregory Baer's book Life: the Odds gives some interesting examples of conditional probabilities, although he doesn't call them that. For example, there are roughly 250 New York Times best-sellers each year and there are roughly 6.7 billion people in world today. If you look at the chances of writing an New York Times best-seller as being about 250 in 6.7 billion, the chances seem fairly small.

On the other hand, suppose that your book has been published. In this case your chances of having written an New York Times best-seller are roughly 1 in 220. That's better by a huge margin. If you relax the requirements for being a best-seller to include books on other lists, like those from USA Today and Publishers Weekly, the chances of writing a best-seller get even better. Using the broader definition, the probability of having written a best-seller, given that your book has actually been published, is more like 1 in 54.

Baer's book is very entertaining, but it definitely isn't too serious. It also estimates the chances of Satanic possession to be roughly 1 in 7,000 each year. That's roughly the same as the chances of dying in an vehicle accident in the US, which is about 1 in 6,535 per year. If Baer is right, there's a significant chance, roughly 1 in 100, that a typical person will be possessed at some point in their life. Maybe there's a bias towards young, drunk men in this estimate also.

Mostly a good idea

NIST has just released another draft of Special Publication 800-37, Guide for Security Administration of Federal Information Systems. It’s an interesting document, but parts of it probably really aren't suitable for use by the government. This is because this document tries an approach that works well in the commercial world, but one that probably won’t work well for many government agencies.

All organizations, both government and commercial, face many kinds of risks, and a good first step towards dealing with these risks is to understand an organization’s tolerance to risk. Some organizations are willing to accept greater risks because of the greater gains that can accompany the greater risks. Others are happy to limit themselves to smaller risks and the smaller gains that tend to accompany them. Knowing exactly how much risk your organization is willing to accept is one of the first things that you should do when creating a strategic risk management plan.

The problem with SP 800-37 is that it’s aimed at government agencies. Government organizations have extremely low tolerances for risk, and this is somewhat understandable. An unfortunate aspect of a market economy is the fact that businesses can and will fail, and this sometimes happens because of risks they take. The problems that accompany businesses failing, however, are more than compensated for by the gains that other businesses make from accepting risks. Thus having some failures but lots of successes seems to provide the basis for a system that works fairly well.

That’s probably how it should be. Voltage is doing quite well making and selling encryption products, but if Voltage somehow decides to risk their future by focusing on IBE-enabled lava lamps, for example, we deserve to fail miserably.

Governments, on the other hand, need to do their best to avoid some types of failure, which means that they need to avoid some types of risk. While it may be acceptable for some businesses to fail, when a government fails, the results can be catastrophic. This means that governments sometimes need to accept lower risks than for-profit businesses would be willing to accept because they need to keep this chance of catastrophic failure to a very low level.

It’s also the case that the way that government agencies are run doesn’t create an environment in which there’s any incentive to take risks. In the business world, people accept that risky ventures sometimes fail. In governments, however, this does not seem to be the case. In the public sector, failure is often rewarded quite differently. There’s always some partisan group that will act outraged that taxpayers’ funds were wasted when a government project fails, even if the failure is just the result of a risky venture that just experienced bad luck. This outrage often translates into public humiliation for the unlucky government officials responsible for the failed project. They’re often vilified by the media and forced to publicly explain to politicians exactly how and why their project failed. In this environment, there’s little incentive to take risks.

So government agencies aren’t better or worse than businesses - they’re just different because they work within an entirely different set of constraints. These differences can dramatically affect how they manage risks. Because of this, the strategies for managing risk that work well in the private sector may not work very well for government agencies. So although the ideas in the new version of SP 800-37 are good ones, some of them probably won't work well for that publication’s intended readers.

Risk-risk tradeoffs

As mentioned earlier, there are four general types of risk-risk trade-offs that health and safety regulations may introduce, and each can be seen in the field of information security. Here’s a discussion of each of these cases. The bottom line is that managing risks of any kind is a complicated problem for which there's often no easy and simple solution, and the risks that information security deals with are not exempt from this.

One risk-risk trade-off comes from people taking additional risks because they feel safer because of better technology or stricter regulations. This can make the overall result of the new technology or regulations a net loss rather than a net gain if more people are injured by the riskier behavior than are saved by the improved safety. This has been shown to be true in the case of seat belts, air bags, or anti-lock brakes. People using these technologies seem to feel safer and thus compensate by taking risks that they wouldn’t have taken otherwise.

Similarly, it’s probably the case that computer users who are protected by anti-virus software feel safer and tend to be less careful with dangerous attachments to e-mail than they would in the absence of anti-virus software. Add an anti-phishing product to your e-mail system and you might find people being less suspicious of potentially-dangerous e-mail.

A regulation may also reduce one risk while increasing a different risk. Banning saccharine, for example, may have reduced some health risks due to the exposure to the saccharine, but may also have increased health risks to others due to obesity caused by substituting sugar for saccharine in some diets.

Similarly, using a particular information security product may introduce new vulnerabilities even as others are reduced. Requiring that all information security products be Common Criteria certified and operating in an evaluated configuration may decrease some security risks while increasing others, for example. This happens because the inflexibility of the Common Criteria does not allow users of certified products to install patches or software updates and stay in an evaluated configuration. This leaves deployed systems exploitable by any new vulnerabilities that are discovered since the completion of the Common Criteria certification. Add a security product to your network that has an exploitable buffer overflow vulnerability and you've also done this.

Implementing ways to reduce risk may also result in activities that increase risks more than the original risk is reduced. Regulations that require new construction are an example of this, because the activity of construction may be more dangerous than the risk that is reduced by the results of the construction. So if reducing the levels of a toxic chemical in the water supply requires the construction of a waste water treatment plant, it may be the case that the risks to the construction workers who build the treatment facility outweigh the benefits that the facility may provide.

Deploying or supporting information security technologies can also introduce new vulnerabilities in a similar way. Giving consultants or other contractors access to your network carries the risk that they will use their access to carry out malicious activity or to otherwise subvert your network, for example.

Finally, spending limited budgets to reduce risk in one area means that the same funds are not spent on reducing risk in other areas, even ones that provide a greater benefit.

Suppose that you can spend $50,000 in one of two projects, one that reduces risk by $100,000 and another that reduces risk by $200,000. If you choose in the project with the lower return, you will have kept our exposure to risk unnecessarily high and added an unnecessary $100,000 in risk to your organization. Because it's very difficult to get accurate estimates of the chances of security vulnerabilities being exploited and the damage caused when these vulnerabilities get exploited, it's very difficult to avoid this particular risk-risk trade-off. This means that you may be doing it and not even knowing it.

Data-centric security

There’s lots of talk these days about the potential for data-centric security and how it will revolutionize the field of information security. While it’s true that data-centric security is a good solution to some problems, it doesn’t solve all problems, and it’s almost certain to coexist with existing security technologies instead of replacing them. It does this in a way that makes it particularly useful in dealing with data breaches, so it should provide a good tool to help fight the massive losses of sensitive data that we're seeing today.

Data-centric security focuses on protecting data rather than protecting the network where the data lives. Traditional security technologies like firewalls establish a security perimeter that's designed to keep hackers out. Everything inside the security perimeter is considered to be more-or-less safe while everything outside the perimeter is considered suspect. Perhaps not exactly Evil, but certainly Bad.

Trends like mobile computing and tighter integration of business partners are making it more and more difficult to define exactly where a security perimeter is. This makes enforcing the traditional model more and more difficult. It's almost impossible to enforce a strong perimeter, after all, if you can't really say exactly where the perimeter is. Because of this, data-centric security is often proposed as an alternative.

With data-centric security, you protect the data instead of the network where the data lives. This is typically done with encryption. In the ideal data-centric model, sensitive date is encrypted and only authorized users can get the cryptographic key needed to decrypt it. To unauthorized users, data looks like a bunch of random bits, and because they can’t get the key needed to turn these random bits into useful information, the data isn’t useful to them.

If a hacker manages to penetrate a network that’s protected by data-centric security, any data that he manages to get will be useless to him. Doing key management correctly is needed to make this a reality, but let’s make a huge leap of faith and assume that that’s possible. This means that a hacker can’t get the decryption keys that he needs to make sense of the encrypted data.

This certainly sounds good, but it probably doesn’t describe a scenario that’s likely to happen, and probably doesn’t describe one that people will pay for. Although they’re far from perfect, existing technologies can create fairly strong security perimeters, after all. So why should we be interested in data-centric security at all?

The real reason that data-centric security will probably become popular is because it provides a way to extend the security perimeter to where it needs to be. Sensitive data is extremely difficult to keep control of. It’s carried outside the security perimeter on a routine basis by people who need to use it. Laptops are routinely lost or stolen. CDs containing sensitive data are lost in the mail. USB drives are also. So keeping sensitive data inside a protected perimeter is virtually impossible. It’s also probably not worth trying to do. People need access to sensitive data to do their jobs, and not letting it leave a protected network probably isn’t practical.

On the other hand, if sensitive data is encrypted, then losing control of it won’t cause any problems because data-centric security extends the security perimeter to wherever the data is. That’s assuming that key management is done correctly, but we’ve assumed that to be the case. The most important use of data-centric security probably won’t be as an additional layer of protection against hackers that manage to penetrate a protected network. Instead, it will probably be used to protect data that leaves the network for legitimate purposes.

The big problem with protecting sensitive data isn’t that hackers get in, it’s that data gets out, and data-centric security has the potential to eliminate the problems that data getting out can cause.

How do you measure it?

In Lord Dunsany's story “Jorkens' Revenge,” the Munchausen-like Jorkens manages to win an unusual wager with his nemesis, Terbut: Jorkens bets him £5 that it is further from Westminster Bridge to Blackfriars Bridge than it is from Blackfriars Bridge to Westminster Bridge.

The perplexed Terbut then finds that the taxi ride one way is indeed longer than the ride the other way and grudgingly pays Jorkens £5 without fully understanding why he lost the bet. The secret to Jorkens' victory, of course, is that the road between the two bridges is shaped like an arc of a circle, and driving an arc of a smaller radius gives you a shorter distance than driving an arc with a larger radius.

This example demonstrates fairly clearly that exactly how we measure things can be very important.

Measuring the effectiveness of information security technologies is not as easy as taking a taxi ride and noting odometer readings, but it is a critical part of making the right decision about whether or not to make investments in your corporate IT infrastructure.

One of the most detailed attempts at doing this was done by Kevin Soo-Hoo in his doctoral dissertation at Stanford. Curiously, his models seem to show that the benefits of encryption outweigh its costs, but encryption still hasn’t become very popular. On the other hand, his models also seem to show that the benefits of a firewall aren’t justified by its cost, but I doubt that many people could be convinced to not use a firewall based on such a cost-benefit analysis. It makes you wonder exactly how people make decisions about whether or not to use particular security technologies. If they don’t use a careful cost-benefit analysis, how do they make such decisions?

Is security too hard?

Much like the genre of science fiction, we can divide information security into "hard" and "soft" varieties. But while it may be acceptable for fans of science fiction to prefer one type over the other, doing so in information security is undesirable. The human dimensions of security are as important the technical components, and a shortcoming in either area can create weaknesses that adversaries can exploit.

The first book that's generally accepted as being a work of science fiction is Mary Shelly's Frankenstein. Not long after the publication of this book in 1818, the genre evolved into two separate subtypes that have more or less remained to the present day. These are often described as "hard" and "soft" science fiction, and the genre seems to have flourished despite this division.

The works of Jules Verne are good examples of early hard science fiction. In this, scientific inventions are featured prominently and often described in great detail. If you read Twenty Thousand Leagues under the Sea, you'll find discussions of how much air a man in Captain Nemo's Nautilus consumes per day (176 pints). You will also find details of the screw that propels the submarine (a diameter of 19 feet and a thread of 23 feet, turning at 120 revolutions per second), the system of ballast that's used to control the buoyancy (150 tons of reservoirs that bring the total weight of the vessel to 1,507 tons when fully filled), as well as many others. Verne seems to revel in providing this level of detail, and his fans seem to enjoy reading it.

The works of H.G. Wells are good examples of early soft science fiction. In this, the technology is often not described in great detail, and the stories focus more on the ways in which people experience the technology. If you read The War of the Worlds, you won't find detailed specifications of the tripods that the Martians ride in as they rampage through the English countryside, or details of the operation of the heat rays and deadly black smoke that the Martians use to destroy their human opponents. Instead, you'll see the effects of the Martian invasion on the characters in the story, and follow the narrator through being separated from his wife and finally managing to find her again after several close brushes with death at the hands of the invading Martians. The horror that the narrator feels when he learns that the Martians are using humans as a food source is much more important to the story than any of the alien technology that happens to be present.

We can see a division in information security that roughly parallels the division of science fiction into the hard and soft subtypes. Part of information security focuses on the details of technology. Cryptography provides a particularly good example of this. Understanding exactly how many bits of key are needed to attain a particular level of security and how to securely manage cryptographic keys involves an understanding of more details than Jules Verne would have felt comfortable providing in one of his stories.

On the other hand, it's equally important to understand the ways in which people can or cannot use security technologies and to ensure that they're used appropriately. Cryptography also provides a good example of a case where this is particularly important. An adversary might require billions of years on a supercomputer to crack a cryptographic key, but he may be able to avoid having to do this. If encryption isn't used at all because it's too difficult for people to actually use then an adversary won't have to worry about the encryption at all. Or if encryption is used in a careless way then it also provides very little protection. So it's equally important to address usability issues of cryptography as it is to deal with the more technical issues associated with it. If you fall short in either area, you may be open to compromise, and a sensitive message that is read due to careless use of cryptography is just as compromised as if it were compromised by a hacker who has the computing power to crack the key. So although it might be acceptable for fans of science fiction to accept the division of the genre into hard and soft varieties, a similar division in information security should definitely be avoided.

In many organizations, however, the human dimension of a comprehensive information security program is often almost totally overlooked. Many organizations are relatively willing to commit resources to technology purchases, but seem to be much less willing to dedicate any resources at all to the less technical aspects of information security that are needed to ensure that the technology can provide the benefits that it's designed to provide. This often results in security programs that have excellent technical components, but have significant gaps due to the way in which the technology is used. This creates risks as great as those when the technical components are not present.

Part of the reason for this may be because of the difficulty of estimating the return on investment (ROI) for anything related to information security. It's notoriously difficult to calculate a meaningful ROI for security technology purchases, but it's even more difficult to get accurate estimates for the ROI for investments in human capital. Because of this, less than half of organizations provide their employees with ongoing training in security awareness and the controls needed to use IT systems securely. This often results in information security programs with very weak human components.

Hackers don't just attack security technologies: they attack the combination of the technologies and the way in which they are used, and a weakness in the use of the technology is just as exploitable as the technology itself. So by not providing the basis for ensuring that your security technology is used correctly, you're providing an opportunity for a hacker that's just as good as the opportunity provided by not using the technology at all. So although it may be acceptable for fans of science fiction to favor either the hard or soft varieties of the genre, favoring security technology over the human elements of using the technologies should probably be avoided. It may be challenging to get funding for projects that improve the human elements, but if they're ignored, the result can be an incomplete security program that leaves plenty of opportunities for hackers. Try not to overlook the critical human element of information security.

Unintended consequences

In the field of risk management, risk-risk tradeoffs can be important. If you try to decrease one risk, you may get unintended consequences that increase other risks, perhaps ending up making things worse instead of better. Studies have shown, for example, that drivers of cars equipped with safety features like seat belts, anti-lock brakes or air bags actually drive more carelessly that drivers in less safe cars. In some cases, this increased recklessness can more than compensate for the benefits from the safety features, creating an actual net loss from the safer cars.

Unintended consequences can often occur in unexpected ways. An example of this is the way in which treating some parasitic infections can cause an increase in allergies. This connection was noticed by Eric Ottesen, when he visited the tropical island of Mauke in 1972. On this visit, he treated the inhabitants for infections by parasitic worms. Being a specialist in both parasites and allergies, Ottesen noticed that the Mauke islanders had both a high rate of parasitic infection as well as a very low rate of allergies. His follow-up study found that while the infections by parasites had been dramatically reduced by 1992, the rate of allergies had become very high. This made him suspect a connection between the seemingly unrelated phenomena.

Subsequent research verified that there is indeed a connection between infections by certain parasitic worms and allergic reactions, leading some researchers to believe that allergies are an unfortunate and unintended consequence of the way in which our bodies deal with the parasites. The theory is that when parasites are rare, our bodies' defenses tend to overreact to lesser threats, like pollen or dust mites, because they are not being used to fight off parasites, and that we experience the effects of this overreaction as allergies.

Some researchers have even suggested using an intentional infection by safe types of parasitic worms as a treatment for serious allergies, a technique which has shown to be effective in mice. In many cases, people may find infection by parasitic worms to be less appealing that suffering the effects of allergies, but it will certainly depend on how severe the allergies are. People with life-threatening allergies may not mind a few worms living in their bodies if the worms make it safe for them to live more normal lives, for example.

Information security products can come with their own set of unintended consequences. These unintended consequences are probably not as unintuitive as the connection between parasites and allergies, but some of them do require some careful analysis to understand. In the next few days, I’ll talk about the different risk-risk tradeoffs that can make creating a good information security strategy more difficult than it first looks.