Superconductor

Identity theft and the Fair Credit Reporting Act

The biggest reason that data breaches are a problem is that the sensitive data that they expose can be used for identity theft. According to the analysis by legal scholar Lynn LoPucki in “Human Identification Theory and the Identity Theft Problem,” the reason that identity theft causes so much trouble can be traced back to the Fair Credit Reporting Act. Here’s why he claims this:

The impersonated victims in these scenarios are not liable for the obligations incurred in their names. Thus, the resulting credit reports are false. Nevertheless, those victims have no legal remedy for the false reporting if the credit-reporting agency followed “reasonable procedures.” Federal law exempts both creditors and credit-reporting agencies from liability for their false statements about the victims of identity theft.

He then says

The credit-reporting agency’s only duty is to “reinvestigate” – if and when the person reported on demands it. In practice, the credit-reporting agency “reinvestigates” by sending the victim’s complaint and the disputed information to the creditor who initially furnished the information. The creditor who reconfirms false information is theoretically liable for its error. To activate this duty, however, the consumer must furnish the same information twice – once top the credit-reporting agency to force reinvestigation and a second time to the creditor “at the address specified” to alert the creditor to its error. And even a victim who has furnished the information to both still has no direct remedy against the creditor for repeating the falsehood. Only certain federal or state agencies can seek a remedy, and, for various reasons, none is likely to do so on the complaint of a particular victim.

Thus, shielded from liability, creditors and credit-reporting agencies who have misreported on an impersonated victim remain in a position of power with respect to that victim. The victim desperately needs to correct the records of the creditors and credit-reporting agencies involved so that he or she can obtain or preserve credit. The creditors and credit-reporting agencies, by contrast, need only maintain procedures sufficiently reasonable to avoid the wrath of public enforcement agencies.

In other words, the FCRA makes it unnecessarily difficult for consumers to deal with the problems that identity theft causes because the very creditors and credit-reporting agencies that they need to deal with to do this have no incentive to help them resolve these problems.

There’s lots of talk these days about what the government should or should not do about data breaches and the identity theft that it causes. Perhaps fixing the system that they caused by the FCRA would be a good first step.

Records, Computers and the Rights of Citizens

Although identity theft is now getting more media coverage than it once did, the need to protect the sensitive personal information that’s used to commit identity theft has been well known for many years. As far back as 1973 this was know to be a problem. That’s when the report Records, Computers and the Rights of Citizens was written for Caspar Weinberger, who was then Secretary of Health, Education, and Welfare.

This report discussed the problems of privacy and recommended that the following five principles be used to create a “federal code of fair information practice” that would be enforced by one or more federal laws:

• There must be no personal data record keeping systems whose very existence is secret.
• There must be a way for an individual to find out what information about him is in a record and how it is used.
• There must be a way for an individual to prevent information about him that was obtained for one purpose from being used or made available for other purposes without his consent.
• There must be a way for an individual to correct or amend a record of identifiable information about him.
• Any organization creating, maintaining, using, or disseminating records of identifiable personal data must assure the reliability of the data for their intended use and must take precautions to prevent misuse of the data.

The government has known for over 35 years that protecting sensitive personal information is a problem that needs to be addressed. Let’s hope that they can manage to do what needs to be done before we can say that they’ve known about the problem for over 40 years and still not addressed it.

Another use for standards documents

It looks like there may be unexpected benefits from reading standards documents. That's what I thought when I read the abstract to "Connections From Kafka: Exposure to Meaning Threats Improves Implicit Learning of an Artificial Grammar" by Travis Proulx and Steven Heine. Here's the abstract for this paper that was published in the July 2009 issue of Psychological Science:

ABSTRACT—In the current studies, we tested the prediction that learning of novel patterns of association would be enhanced in response to unrelated meaning threats. This prediction derives from the meaning-maintenance model, which hypothesizes that meaning-maintenance efforts may recruit patterns of association unrelated to the original meaning threat. Compared with participants in control conditions, participants exposed to either of two unrelated meaning threats (i.e., reading an absurd short story by Franz Kafka or arguing against one's own self-unity) demonstrated both a heightened motivation to perceive the presence of patterns within letter strings and enhanced learning of a novel pattern actually embedded within letter strings (artificial-grammar learning task). These results suggest that the cognitive mechanisms responsible for implicitly learning patterns are enhanced by the presence of a meaning threat.

In other words, reading things that are hard to make sense of, like an absurd short story by Kafka, may actually make you smarter. If this is true, I think that I may have found a good use for all of those documents that the PKIX Working Group of the IETF creates.

Picturing the central limit theorem

The central limit theorem tells us that if we add data that contains random errors then we tend to get a sum that's normally distributed, independent of the distribution of the original data. I was wondering how many errors you need to add together to get something that looked close to a normal distribution, so I created some random data from a uniform distribution in Mathematica that represents such errors. I then and plotted one of these errors, the distribution of the sum of two of these errors and the distribution of the sum of three of these errors. Here's what I got.

One random error.

The distribution of the sum of two random errors.

The distribution of the sum of three random errors.

It certainly looks like you're fairly close to a normal distribution after adding together only three errors. I was surprised to see how quickly this happened.

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.

How secure is hardware?

Many  people assume that using a hardware security module (HSM) to store their keys is much more secure than storing their keys in software. This is probably true, but exactly how secure is hardware? I claim that it's really not that secure, and here's why. This is roughly based on a talk I gave at NIST's Physical Security Testing Workshop a few years ago.

The following graph shows the chances of an adversary being able to beat a cryptographic algorithm.

 

As their budget increases, they can apply more and more computing resources to the problem. This particular problem scales perfectly linearly. If you double your budget you double your chances of beating the crypto, etc.

For most crypto algorithms, it takes an incredible amount of computing power to get to a reasonable chance of beating most algorithms. The sizes of cryptographic keys is deceptive. Although 128 sounds like a relatively small number, 2¹²⁸ is actually so big that we really have a hard time understanding how big it really is. The work required to recover a 128-bit key is a number that's that big, so the amount of work required to recover a 128-bit key is also so big that we have a hard time understanding how big it is. You can put billions of dollars of resources into recovering a 128-bit key and still not have much of a chance of success.

Hardware is nowhere near as tough to beat. This graph shows how your chances of beating hardware security change as your budget increases.

   

This graph is much different than the one for recovering a cryptographic key, and that's because the attacks against hardware are much different that the attacks against cryptography. If you're attacking cryptography, you develop the best attack program that you can and then you run your attack program with as much computing power as you can afford. To attack hardware, you have to take the hardware to your lab and you expensive tools to carry out the attacks against it. If you can't afford the expensive tools, then your chances of succeeding are zero. This explains the first part of this graph, the part labeled "1."

Once you can afford basic engineering tools, however, a certain class of attacks against hardware become possible. If you have a good logic analyzer then you can carry out timing attacks against the hardware, for example. And once you have enough budget to afford tools like these, you will almost always succeed in the attacks that you can carry out using the equipment in your lab. This explains the part of the graph labeled "2." There are still lots of attacks that you can't do at this level, and doing those requires moving to the next level of funding. But the attacks that you can do with the equipment that this budget provides, however, essentially always work. This is why the graph has big jumps in the chances of success as the funding increases. Once you have the right tools, attacks against hardware always work, which is much different that what we get with attacks against cryptography, where the chances of success increase steadily as the budget increases.

Once you get a higher level of funding you can carry out even more advanced attacks. If you have microprobing equipment, for example, then you can collect signals from places that you couldn't with a logic analyzer, and when you can do this, lots of new attacks become feasible. The part of the graph labeled "3" covers what you can do at this point. Even at this level of sophistication there are still things that you can't do, but those become possible at the next level.

If your budget is big enough you can afford to get the specialized types of equipment that integrated circuit failure analysis engineers use. This includes equipment like electron microscopes and focused-ion-beam systems. With these tools you can take apart a chip and look at its components at the lowest level, and there's essentially nothing that you can protect with hardware that equipment like this can't recover. The part of the graph labeled "4" shows what you can do at this point.

The big question for this model is exactly how much funding you need to be able to do the attacks in the various categories. This is only a rough estimate, but I'd say that with $50K or funding you're definitely in area 2 of this graph, with $500K, you're definitely in area 3, and that with $5 million you're definitely in area 4. The interesting things about time model is that it tells us that the security of any hardware device won't withstand a few million dollars of effort. That's equivalent to the level of effort needed to recover a fairly small cryptographic key by doing cryptanalysis.

There are certainly different constraints against an attack on crypto and an attack on hardware. It's reasonable to assume that an attacker can get all the matched plaintext-ciphertext pairs that he needs to carry out an attack against crypto. With hardware, on the other hand, it's almost always necessary for an adversary to take the hardware back to his lab where he has the tools needed to attack it. That's much tougher to get than what you need to attack crypto, but it's probably a reasonable assumption. After all, Kerckhoffs' principle tells us that we should assume that an adversary attacking crypto has everything that he needs except the key that's used to encrypt and decrypt. Assuming that an adversary has the ability to somehow obtain an HSM and take it to his lab for study seems a reasonable way to apply this principle to hardware.

NIST approval for AES-XTS

It look like the fact that AES-XTS will become an approved mode of AES is more than just a rumor. Last month, NIST posted a draft of SP 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Block-Oriented Storage Devices. SP 800-38E actually just refers to the IEEE P1616 standard, so it looks like NIST has essentially approved IEEE Std 1619-2007. The only additional requirement seems to be that a single key can't be used to encrypt more than 2²⁰ blocks of data.

NIST doesn't approve new modes of AES very often, so it's interesting to see what they think is worth of approval.

You can find the draft of SP 800-38E here.

 

Intel's AES instructions

I finally got around to looking at how Intel's AES instructions work. These are a new set of processor instructions that will soon be introduced that implement AES encryption and decryption. There are a total of six new instructions that do this: AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST and ASEIMC. The first four of these do the actual encryption and decryption, and do this a round at a time, with the *LAST being what you need to use on the last round. AESKEYGENASSIST and AESIMC do key expansion, and you need to use these before you can encrypt or decrypt.

When you hear that there are two separate instructions for non-final rounds and the final round of an encryption or decryption, you'll probably realize that using these instructions isn't as simple as calling a function that encrypts or decrypts data. Instead, to use these instructions, you need to have a fairly detailed understanding of how AES works.

Using these instructions, here's roughly what encrypting with AES-128 looks like, where the register xmm1 initially holds the plaintext input and xmm2 through xmm12 hold the round keys from the key expansion:

pxor xmm1, xmm2

aesenc xmm1, xmm3

aesenc xmm1, xmm4

aesenc xmm1, xmm5

aesenc xmm1, xmm6

aesenc xmm1, xmm7

aesenc xmm1, xmm8

aesenc xmm1, xmm9

aesenc xmm1, xmm10

aesenc xmm1, xmm11

aesenclast xmm1, xmm12

That's not as simple as I thought would be when I first heard about the AES instructions. I imagined something that would work more like this:

aesenc data, key

Using the key expansions instructions is even more complicated. If you really want to see how to do that, you can download Intel's white paper here.

It's good to see hardware support for encryption becoming more widespread. Encryption was often too hard to use in the past, and it looks like Intel's AES instructions should make it easier than ever to implement encryption. The fact that they also make it faster doesn't hurt, either.

The Chinese remainder theorem

Supose that n₁, n₂, …, n_k are positive integers that are have no common factors. Then the Chinese remainder theorem (CRT) tells us that for any integers a₁, a₂, …, a_k there is an integer x that satisfies the following system of congruences:

x ≡ a₁ (mod n₁)

x ≡ a₂ (mod n₂)

…

x ≡ a_k (mod n_k)

and that all solutions are congruent modulo the product N = n₁n₂…n_k. The CRT is particularly useful to know if you’re doing some of the number-theoretical calculations that you do in cryptography.

It turns out that the algorithm that’s used to get a solution the CRT is really just Lagrange interpolation in disguise. With Lagrange interpolation we find a solution to be

f(x) = d₁(x) y₁ + d₂(x) y₂ + … + d_k(x) y_k.

With the CRT we find a solution to be

x = d₁(n₁) a₁ + d₂(n₂) a₂ + … + d_k(n_k) a_k (mod N).

In both cases the ds have the property that d_i(n_j) = 1 if i = j and 0 if i ≠ j. They’re calculated differently, but their role in the calculation is really the same: to force a value of 1 in one particular case and a value of 0 in all other cases.

In the case of the CRT, here's how we do this. We first notice that N and N/n_i are relatively prime. There's essentially only one trick that you can use when things are relative prime, and that's to use the fact that we can find u_i and v_i such that u_i n_i + v_i N/n_i = 1. If we write d_i(n_j) = v_i N/n_j  modulo n_j, then this acts just we want it to.

We have u_i n_i + v_i N/n_i = 1, so that we have v_i N/n_i ≡ 1 (mod n_i), or that d_i(n_i) = 1.

And because n_j | (N/n_i) when i ≠ j, we also have that d_i(n_j) = v_i N/n_j ≡ 0 (mod n_i ) when  i ≠ j.

As I mentioned in the previous post about Lagrange interpolation, when I was in school, every teacher that I had presented Lagrange interpolation as a nasty formula involving lots of complicated expressions. The same thing was true for me with the CRT. Every time I saw this in a class, it was always presented as a nasty formula involving lots of complicated expressions. Nobody ever pointed out that it’s really the same thing as Lagrange interpolation.

I have to wonder why this was taught this way. If you understand what either Lagrange interpolation or the CRT is trying to do, it’s easy to reconstruct the complicated expressions that you need to calculate. If you don’t understand what they’re trying to do, you end up trying to memorize some complicated expressions and hoping that you get it right. I hope that things are taught differently these days. Its easy for me learn patterns and apply them in other places. It’s hard for me to memorize lots of stuff, particularly when I don’t understand exactly what I’m memorizing. I'm probably not alone in this, and I hope that the way things are taught today reflects this.

Lagrange interpolation

Lagrange interpolation is another thing that I wish that I’d had explained better to me when I was in school. There’s actually a connection between this and something that’s related to cryptography, but I won’t have a chance to mention that until tomorrow’s post. I only have enough patience to type and correct a little bit of math each day, and getting to the crypto connection would definitely take more than my entire daily supply of patience.

Lagrange interpolation is a way to create a polynomial that fits a sequence of data points (x₁,y₁),…(x_n,y_n). The way to do this is to create polynomials δ_i(x) that have the property that δ_i(x_j) = 1 if i = j and 0 if i ≠ j. If we have these, then we know that the polynomial

f(x) = δ₁(x) y₁ + δ₂(x) y₂ + … + δ_n(x) y_n

has to fit the data points that we’re given. At x = x₁, all of the terms of f(x) are equal to 0 except δ₁(x₁) y₁, which happens to reduce to y₁, at x = x₂, all of the terms of f(x) are equal to 0 except δ₂(x₂) y₂, which happens to reduce to y₂, etc.

Now let

p(x) = (x – x₁) (x - x₂) … (x - x_n),

and p_i(x) be p(x) with the factor (x – x_i) left out. This p_i(x_j) is almost what we want. We have that p_i(x_j) = 0 if i ≠ j but we don’t have that p_i(x_j) = 1 when i = j.

That’s easy to fix, though. If we divide p_i(x_j) by p_i(x_i) then we’re done. That forces a value of 1 when i = j and a value of 0 when i ≠ j. So if we define δ_i(x) = p_i(x_j) / p_i(x_i) then this gives us what we want, and the polynomial

f(x) = δ₁(x) y₁ + δ₂(x) y₂ + … + δ_n(x) y_n 

has to fit the data points that we’re given.

Lagrange interpolation seems fairly simple once you see what you’re trying to do: you’re just creating polynomials that are forced to fit your data because of the way they’re constructed. When I was in school, however, it was never explained to me that way. Instead, it was just written down as a big, complicated expression involving lots of sums and products and it was left to the students to figure out what was really going on. And because it was presented that way, the connection to the topic of tomorrow’s post wasn’t obvious at all.

Things that I didn't need to memorize

There are several things that I wish that I'd learned in school that nobody got around to teaching me. I had to figure these out on my own, and I still don't quite see why these things were overlooked by the teachers or professors that I had. Here's an example of this, and it has to do with trigonometry. It turns out that there's a quick and easy way to get the double-angle formulas for sines and cosines, or how to find sin 2x or cos 2x in terms of sin x and cos x. The easy way to do this is by looking at how the complex exponential works.

We know that

e^ix = cos x + i sin x

so we can write

e^2ix = cos 2x + i sin 2x.

We can also write

e^2ix = e^ix e^ix = (cos x + i sin x) (cos x + i sin x)

= cos²x - sin²x + 2i sin x cos x.

When we compare the real and imaginary parts of these two different ways of writing e^2ix we find that

cos 2x =  cos²x - sin²x

and

sin 2x =  2 sin x cos x

which are the double-angle formulas from trigonometry. You can use the same trick, of course, to get similar expressions for cos 3x, sin 3x, etc.

For me, it's much more useful to know a way to get these formulas if I need them instead of just memorizing them. But since nobody ever showed me how to do this when I was in school and I wasn't clever enough to figure it out on my own, I was stuck memorizing stuff that I really didn't need to memorize. Looking back, I wonder why I was never taught the easier way.

Encryption for compliance at ISRM 2009

At the ISACA Information Systems Risk Management Conference in Las Vegas this month, I'll be giving a talk there entitled "Encryption for Compliance: Challenges and Solutions" from 11:00 a.m. to 12:30 p.m. on Tuesday, September 29. It's advertised as being an advanced session, targeted at experienced IT security professionsals, so I'll be assuming that people showing up know the basics of encryption, etc.

It should be an interesting talk, and if you come to it, you'll almost certainlty learn something new about encryption and using it to be regulatory compliant. In addition to the obvious stuff about encryption and its challenges, I'll be talking about the trends in laws and regulations that cover protecting personally-identifiable information. I'll probably throw in something about Landauer's principle and why it's not feasible to crack a 256-bit key, also.

Why the Neanderthals became extinct

 

Avoiding a technology monoculture

At the recent National Cyber Leap Year Summit, there were lots of ideas discussed about how to make our current computing environment more secure. One of the ideas discussed was how to deal with the monoculture that success in the marketplace tends to cause. Some people thought that a technical monoculture was a very bad idea that led to all sorts of problems. Others saw the benefits to a standard technology outweighing the problems that it might cause. Still others didn’t see a feasible way to get people to diversify the technology that they use.

Having a single technology that’s used everywhere has the potential to cause all sorts of problems because if the technology fails in one place it fails everywhere. That’s why some applications that need to be extremely reliable, like those that run nuclear power plants or aircraft, need to have redundant systems that are also different from each other.

If there’s a single operating system used on 100 percent of computers and hackers find a way to exploit it, then they can also exploit 100 percent of the computers. On the other hand, having only a single platform to support can give you significant cost savings in the areas of support and maintenance. For large businesses, it’s possible to save hundreds of millions of dollars (according to people from large businesses at the NCLY Summit) by standardizing on a minimal set of supported applications, and it’s not clear that doing this causes anything close to hundreds of millions of dollars in losses due to the increased ease with which hackers can exploit the businesses that have done this. So there’s definitely a cost to standardizing technologies, but it’s not clear that these costs outweigh the benefits from it.

On a more practical note, it’s not clear how you could get businesses to not standardize their technologies. Would you require each business to use a diverse set of technologies? Or would you let each business standardize on a set of technologies but force diversification of technologies from company to company? If you somehow required businesses to diversify the technologies that they use, how would you compensate them for the additional costs that they might experience?

And exactly how would you define diversity? Is version 2.0 of a product the same or different from version 3.0 of a product? A quick look at the National Vulnerability Database seems to show that the vulnerabilities that a product has change a lot over its lifetime, so maybe it’s reasonable to say that version 4.0 is different enough from version 2.0 to justify being classified a different product for this particular purpose. This, of course, could lead to the bizarre effect of encouraging businesses to only patch and upgrade part of their systems, so that they’ll have enough diversity to meet whatever monoculture-banning rules that we come up with.

So maybe that’s a good challenge: find a reasonable way to get businesses to diversify their technology purchases in a way that doesn’t cause huge side-effects. Can it even be done?

Progress in quantum computing?

In the past few weeks, I've heard lots of comments about quantum computing. Because I heard so much about it, I thought that there must have been a big breakthrough of some sort. The last I had heard was that a team at IBM had managed to factor 15 using Shor's algorithm. Because of the sudden interest, I thought that this record must have been beaten in some way, and I don't mean by factoring 17.

But when I looked around the Internet, however, I couldn't find anything that talked about bigger successes, although others have reproduced the factorization of 15. This leads me to wonder what caused the sudden interest in quantum computing. Are there quantum computers out there that can do more than factor 15?

Being able to factor 15 with a quantum computer is actually a very impressive technical accomplishment, but it's not one that leads me to believe that existing public-key technologies are in danger of being rendered ineffective by the existence of quantum computers any  time soon. Perhaps ever. Or is there research out there that I didn't find?

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.

 

Collateral hacking

I heard the phrase "collateral hacking" for the first time recently, a term that some people are using to describe what can happen in a cloud computing environment when an attack on one tenant in a virtualized environment also affects another one of the tenants. At least that's what I think they mean. I haven't heard anyone actually define this term yet.

I'm definitely not an expert in this area, but I'm fairly sure that collateral hacking isn’t really a new idea. Virtualization has been around since at least 1972, when it was added to IBM's System/370 mainframes. It might have been around even before then. Cloud computing has probably increased awareness of virtualization and interest in the technology, but it has definitely been around for a while.

Because they've been doing it for so long, I have to wonder how much research IBM has done on the topic. If they've been doing virtualization for almost 40 years, they've probably looked at the security issues that the technology has once or twice. Maybe looking through the various in-house journals that IBM publishes for articles on the security issues related to virtualization could give us some insights that we could use in today's cloud computing.

Another NCLY observation

One more observation about the National Cyber Leap Year Summit. This one about the different perspectives of government, academia and industry.

At the NCLY Summit, I didn't meet anyone who knew more about data breaches and identity theft that we do at Voltage. We know a lot about those thing be case we have to. If we don't understand data breaches and identity theft, then we can't make the types of products that our customers will buy, which means that we'll soon be out of business. Only one person was there who knew much about the way in which payments are processed (he was from Visa).

On the other hand, the other people at the meeting might not have been experts on data breaches or payment processing, but they certainly knew a lot about other things, and I learned a lot by talking to them, way more that I typically learn at other big industry events, like the RSA Conference.

Maybe this was because the organizers of the event made sure that people were there from government, academia and industry, while the typical people you'll meet at the RSA Conference typically don't represent as wide a range or organizations. Maybe it was because they only invited people that were fairly knowledgeable in their fields, while people at the RSA Conference usually represent a wider range of backgrounds. In any case, the right mix of people was definitely there.

It's too bad that there aren't more events like this. Having a way to routinely exchange information between a group of knowledgeable people from government, academia and industry that represent different parts of the information security industry would be very useful.

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?

More free riding in security

Last week I mentioned how many businesses get a "free ride" on the effort that the US government has put into creating Social Security numbers or credit card companies have put into creating credit card numbers. In both cases, creating a unique identifier is hard and expensive, so there's a strong incentive to use the unique identifier that someone else has already made instead of creating one yourself.

It turns out that there's another area of information security that's full of people getting a free ride at someone else's expense, and this case is much bigger than what you get with Social Security numbers or credit card numbers. This case covers almost all aspects of information security. It's caused when foreign businesses and governments use the work of the US National Institute for Standards and Technology(NIST) without paying for it.

NIST creates dozens of security standards that cover everything from checklists for secure configurations for operating systems to the details of how to implement encryption securely. And because they're a US government agency, people are free to use these documents without worrying about any annoying copyright issues. And they do.

Is this really a good idea?

Do other countries absorb the cost of creating other standards? Is there some sort of international effort to coordinate the development of standards so that everyone contributes something? Or is the US just contributing their work on security standards while other countries get a free ride at their expense?