Superconductor

Gresham's law

There's a little-known observation called "Gresham's law" that may or may not have some relevance to today's security market. Gresham's law says roughly that the introduction of debased currency will tend to make non-debased currency disappear from circulation when people tend to hold onto the currency with more intrinsic value and spend the rest. It's named for Thomas Gresham, an advisor to Queen Elizabeth, but Gresham wasn't the first to note this behavior. Nicole Oresme described it in his 1357 book De origine, natura, jure et mutationibus monetarum.

This principle doesn't apply to all cases where low-quality and high-quality alternatives compete in the marketplace. It also needs some sort of regulation to make it happen. In the case of coins, there are laws that say that both the non-debased coins and the debased ones are worth the same amount, so the non-debased ones tend to disappear from circulation. In cases where there is no requirement that the low quality alternative be worth the same as the high quality alternative, Gresham's law doesn’t predict that the high-quality alternative will disappear.

In the case of the PCI DSS, however, we may have a situation where Gresham's law does hold. This is because compliance officers are often looking for a solution that lets them pass their PCI DSS audit instead of a solution that actually provides strong and useful security. The PCI DSS now acts like a regulation that makes the high-quality and low-quality products equal because they both will let their users pass their PCI DSS audit. If this is the case, then we would expect high-quality security products to disappear, leaving their low-quality competitors as the only alternatives. This hasn't happened yet. Should we expect it to happen soon?

According to "Gresham's Law or Gresham's Fallacy," a paper recently written by Arthur Rolnick and Warren Weber of The Federal Reserve Bank of Minneapolis, Gresham's law isn't as true as we might think. Here's the abstract for their paper that sums up what they found:

The claim that bad money drives out good is one of the oldest and most cited in economics. Economists refer to this claim as Gresham’s law. Yet despite its seemingly universal acceptance, this claim does not warrant its status as a law. We find it has no convincing explanations and many overlooked exceptions. We propose an alternative hypothesis based on the costs of using a medium of exchange at a nonpar price: small-denomination currency undervalued at the mint tends to disappear from circulation while large-denomination currency usually circulates at premium. Examining a variety of historical episodes when market and legal prices were different, we find our “law” can explain history much better than Gresham’s.

Like most things, the applicability of Gresham's law turns out to be more complicated that you might first think, and it takes a more careful understanding of a particular situation to predict exactly what will or will not happen. If this is the case, it looks like we may not have to worry about high-quality security products disappearing because of the PCI DSS.

The hard part of the PCI DSS

Most of the requirements of the PCI DSS are really just information security "best practices." The only real exception is Requirement 3: protect stored cardholder data. The easiest way to meet this requirement is by using encryption, but many businesses that need to handle sensitive cardholder data seem to have trouble doing that. That's not too surprising. Encryption is legendarily hard and expensive to use, and there are still some encryption technologies out there for which this is true. On the other hand, there are also lots of encryption technologies for which this isn't true. Voltage makes some of these. A few other vendors do also.

Because there are encryption technologies that make it easy to meet PCI DSS Requirement 3, I was surprised to read a recent report, "Lessons Learned: Top Reasons for PCI Audit Failure and How To Avoid Them" by QSA VeriSign. In the PCI DSS assessments that VeriSign does for its clients, Requirement 3 is the area that people fail the most frequently: a full 79 percent fail it. I found that surprising. Maybe those people should talk to someone at Voltage.

Friendly names for certificates

The naming of keys is a difficult matter,

It isn't just one of your holiday games;

You may think at first that I'm mad as a hatter

When I tell you a key needs to have a good name.

It should be the one that its users use daily,

Such as "This one's for email" or "For VPN,"

Such as "This one's for signing," or "Intranet access,"

All of them sensible everyday names.

If you use X.509 certificates, one problem that you might encounter is figuring out which certificate to use. Every certificate that I have has the same name for me in them, so unless I know the expiration date or the serial number of a particular certificate (which I never do), it's always a matter of trial and error when I try to figure out which one I need to use.

In Internet Explorer, however, there's a field for "friendly name" in the Certificates window that you can open by going to Tools→Internet Options→Content→Certificates. Once you get there, however, it's not obvious how to change the friendly name. You can do this if you select the Personal tab and then select a particular certificate. Then go to View→Details→Edit Properties, and you'll see a field where you can enter both a "friendly name" and "details" for your certificate. If you do that, you'll be able to easily tell the difference between your certificates without having to know their expiration dates.

In Firefox, it doesn't seem as easy. If you go to Tools→Options→Advanced→View Certificates, you can see which certificates you have, but I can't find a way to assign a friendly name to them. It looks like you'll just have to remember whether you need to use the one with serial number 48:CB:F9:8D:65:9E:B5:84:5F:AF:A4:A8:B4:08:E9:D1 or the one with serial number 22:4D:02:80:BC:DE:AD:E7:73:81:BF:6C:74:8A:B4:BF when you want to encrypt email. Or you can just try to remember the expiration date. Neither way seems to be very useful.

Names for big numbers

Cryptographic keys don't sound that big because we usually talk about how many bits they have, which is really just the logarithm of a number. The numbers that we're dealing with in cryptography are big. Really big. They're so big that most people probably haven't heard of the names for them.

A 128-bit key, for example, represents a number that's roughly 10³⁹, or about a hundred undecillion. A 256-bit key represents a number that's roughly 10⁷⁷, or about a hundred quattuorvigintillion. The numbers that are used in public-key algorithms are even bigger. A 1,024-bit key represents a number that's about 10³⁰⁸, or a hundred thousand centillion.

If you're using a 15,360-bit RSA key, like you need to do to get the same strength as a 256-bit AES key, you have a number that's roughly 10^4,623, or a trecentillion trecentillion trecentillion trecentillion trecentillion quintrigintillion. At that point, the words don't seem to work very well and it's probably better to just think of the number as having 15,360 bits.

Is AES secure enough?

There's been a lot of discussion in the past day or so about the security of the AES encryption algorithm. There's a paper by Alex Biryukov and Dmitry Khovratovich that describes an attack against AES-256 that can be done in much less time that brute-force exhaustion: 2¹¹⁹ trial encryptions instead of 2²⁵⁶. That's a huge difference. Is AES now so weak that we need to worry about it?

Absolutely not.

The attack that Biryukov and Khovratovich found also takes lots of data for it to work. Their attack that can be done in 2¹¹⁹ time also takes the same amount of data: 2¹¹⁹. That's a lot of ciphertexts.

The best estimates that I've seen say that the entire world produces a few exabytes of data per year. This estimate is actually from a few years ago, so it isn't that current. Let's suppose that the amount of data being created doubles each year. If that's the case, we probably have a few zettabytes of data being created per year right now.

A zettabyte is 10²¹ bytes, or about 2⁷⁰ bytes. That's a lot of data, but it's still a long way from 2¹¹⁹ ciphertexts. This means that an attack that takes that much data is totally impractical. Even if we assume that all of the data in the world is being used in an attack that's trying to recover a single AES key, it's still not enough. It would take roughly the amount of data that the entire world will produce in the next 50 years or so to get the amount of data that we'd need. And even then, the amount of time required is still prohibitive.

It's interesting that Biryukov and Khovratovich found a significant weakness in AES, and their work may give useful insights into how to design better symmetric encryption algorithms, but it's not the sort of weakness that anyone can actually use to actually recover data that's encrypted with AES.

The Virginian goes to the RSA Conference

Owen Wister's 1902 novel The Virginian was one of the first books that might be called a "western." It essentially defined the western genre and established many of what are now its clichés. One of my favorite parts of this book is when the Virginian ends an uprising by disgruntled cowboys by beating their leader in a tall tales contest. I'm often reminded of this showdown when I hear claims made by the marketing departments of security vendors, and it's entertaining to think of how a similar epic battle might take place today.

Imagine we're at next year's RSA Conference, drinking the free beer that some generous vendor has provided. A CISO from a big company is here. He's never been to the show before doesn't realize that he'll be swarmed by vendors if he attends an event like this one. To get his attention, the sales and marketing people from lots of security vendors make more and more outlandish claims about their technology.

There's someone there from a vendor that makes products that are designed to counter the insider threat. After a beer or two, the people at the party have forgotten that there's absolutely no basis for the claims that most attacks come from insiders, so they listen to him. He quotes some statistics from analyst reports that nobody has heard of and ends up with the estimate that over 150 percent of attacks come from insiders.

People are impressed, but take a quick break to get another beer. Surely someone can do better than that.

Next is someone from a tokenization vendor who claims that tokenization is actually more secure than encryption. Encryption is hard to understand when you've had a good night's sleep and a couple cups of coffee, and the free beer has made sure that nobody at the party is able to even come close to understanding it now. The lone cryptographer who's at the party is impressed by the daring that it took to make that claim, even to a room full of people drinking free beer, so he doesn't challenge it.

Unable to think of a way to one-up this, the other vendors gradually walk away, leaving the tokenization vendor alone with the CISO.

Ancient format-preserving encryption in FIPS 74

Although the format-preserving encryption algorithms that Phil Rogaway invented are very useful for encrypting data in a way that makes integrating encryption with legacy applications and complex IT environments particularly easy, it turns out that he wasn't the first to do this. An old, retired NIST document that describes how to use the DES encryption algorithm actually described a way to do it.

The NIST document that does this is the retired FIPS 74, "Federal Information Processing Standards Publication 1981 Guidelines for Implementing and Using the NBS Data Encryption Standard." This document is so old that it even refers to NIST as the National Bureau of Standards (NBS), a name that hasn't been used since 1988. FIPS 74 was withdrawn in 2005, so this technique should probably be considered obsolete. Here's how it works.

Suppose that we want to encrypt a credit card number that has 16 digits. The FIPS 74 technique encrypts one digit at a time. To do this it creates four bits that are XORed with the four bits that represent a digit. These four bits come from the lowest four bits of the output of a DES encryption. If the result of the XOR operation isn't a valid digit, then the next lowest four bits of the DES output are tried, etc. If all 16 of the four-bit values in the DES output don't give a valid digit, then the binary value 1001 is XORed with the plaintext input to get the ciphertext output. A new output of a DES encryption is used for each digit. Here's a diagram that shows how this works. This can easily be extended to more than digits. FIPS 74 describes techniques for encrypting both alphanumerics and arbitrary alphabets.

  

This technique seems to be fairly slow. Each digit it will take an average of (10/16)(1) + (6/16)(10/16)(2) + (6/16)²(10/16)(3) + ... + (6/16)¹⁴(10/16)(15) + (6/16)¹⁵(16) = 1.6 DES encryptions to encrypt, so that it will take an average of 25.6 DES encryptions to encrypt a single 16-digit credit card number.

Curiously, it looks like NIST hasn't defined a similar way to do format-preserving encryption with AES. Maybe there's really no need to do that because there exist other techniques that have strong proofs of security. The fact that a format-preserving encryption technique was included in FIPS 74 makes me think that there was an interest in the technology well before the PCI DSS increased the level of interest in encryption. Is the FIPS 74 technique used anywhere these days?

R. C. Matheson gets a certificate

Web site.

Find page.

Click "Login."

Enter Username.

Enter Password.

Click "OK."

Click "certificates."

Click "request certificate."

Click "request."

Click "request."

Yes, again.

Doesn't work.

IE8 problem.

Try Firefox.

Repeat steps.

First 10.

It works.

Click "next."

Select email.

Click "next."

Click "next."

Another duplicate.

Click "accept."

Click "next."

Click "finish."

Wait.

Check email.

Open email.

Click link.

Click "OK."

Certificate installed.

Now what?

Security through simplicity

If you're trying to estimate the security provided by a particular key management technique, you can essentially ignore the chances of any cryptographic algorithm being defeated. The chances of a peer-reviewed algorithm being weak, particularly when it has a rigorous proof of security is extremely small. On the other hand, the chances of a weakness in some component of a key management system is significant. It's very hard to implement and keep a secure configuration, and even if you can do this, you'll still exposed to bugs in the software and hardware that implements the key management system. You can formalize this if you really want to by writing an expression for the security of a system in terms of the security of each of its components, but even without explicitly writing that down, it should be fairly clear that simpler systems are inherently more secure than more complex ones.

Using this principle, let's look at two architectures and see which is more secure: one that implements X.509-based PKI or one that implements identity-based encryption. Here's a diagram that shows the components of a PKI system and how they interact when Alice sends an encrypted message to Bob. For this system to operate securely, each of its components needs to operate securely.

  

Now here's a diagram that shows the components of an IBE system and how they interact. Alice, who wants to send a message to Bob, just needs to get a set of public parameters from a secure key server that's usually called the private key generator, or PKG. Once she has these, she can encrypt messages to Bob. She can actually encrypt them to anyone else also, so she actually only needs to do that once. Once Bob receives Alice's message, he gets the key needed to decrypt it from the PKG. You don't need to do key look-up with IBE, so there's no component that acts like the LDAP directory does for a PKI, and because IBE keys are calculated as needed, there's also no need for a component that acts like a key archive server.

 

This system has only one-fourth the number of components of a system that implements PKI, which means that it has fewer ways to fail, which means that's it's more secure. Simpler is definitely better.

SSNs versus CCNs

There's lots of talk these days about securing credit card numbers. As I've mentioned before, people should have more of an interest in keeping information like their Social Security number protected. If your credit card number is compromised you can always have the old card canceled and a new one issued to take its place. With your Social Security number, however, you can't do that. Once it's compromised, there's no way to get it back.

It turns out that there's another big difference between credit card numbers and Social Security numbers, and that concerns how often they're exposed in data breaches. According to the information in the OSF's database of data breaches, incidents that expose a Social Security number are far more common than data breaches that expose credit card numbers. The last time I looked at the data in this database, for each incident that exposed credit card numbers there were almost seven incidents that exposed Social Security numbers.

Maybe the government should start a program like the PCI DSS to ensure that anyone handling Social Security numbers needs to have some basic security mechanisms in place.

The 2010 Key Management Summit

The web site for the 2010 IEEE Key Management Summit is now up. This event will be held on May 4-5, 2010 in Lake Tahoe, Nevada, and will be collocated with the IEEE Symposium on Mass Storage  Systems and Technologies.

We're already looking for speakers for this event and hope to finalize the list in roughly November of this year. So if you're interested in presenting at this event, it's not too early to send in your submissions.

More Bayesian thoughts

Encryption isn’t as widely used as it could be, and we might be able to understand this from the point of view of Bayesian statistics. Here’s why.

Much of the negative feelings that people have about encryption can probably be explained by the bad reputation that encryption has, and this reputation is probably justified. Many people who used some of the encryption products that were available back in the dot-com era are probably still suffering from the trauma that using encryption caused them. Older encryption products were hard to use, which made them expensive to support.

Even security specialists couldn’t use some of the early encryption products. When I worked at one of those dot-com era companies that made those early encryption products, I remember being stunned by a demo of an application that we had developed to let users authenticate to a server using the WTLS protocol. It was terrible, and this was from the point of view of a person who thought that using X.509-based client certificates was easy.

Many people suffered through using the early encryption products, and they’ve probably developed a significant bias against using encryption because of this. This is perfectly understandable. From a Bayesian point of view, they’ve built a knowledge base that tells them that encryption is hard and expensive, and this will affect how much they believe that newer products are actually easier to use.

Suppose that you tell a person who used older encryption technologies that the newer ones are much easier to use. If they're using Bayesian reasoning, they probably won't believe you, and this is because of what they're really estimating when you tell them this.

Let E represent how much someone believes that encryption is actually easy to use, N represent the claim that newer encryption technologies are easier to use than earlier ones, and K represent experience with the older technologies. If people are using Bayesian reasoning, instead estimating P(E|N), they're really estimating P(E|K∩N). If you’re really motivated, you can work through calculating P(E|K∩N), much like we did in an earlier post, and if you do this you’ll find that we can’t expect people to believe that the newer technologies are actually usable.

The problem is that they are.

Encryption has become much easier to use in the past five years or so, and it’s now feasible to use in many situations where it wasn’t practical at all in the past. That means that there’s now a solid business case for its use, even though people may not actually believe it. After all, the people who are making decisions about using encryption today are the same people who had to suffer through using the bad implementations of it that we had in the dot-com era. And because their experience has told them that encryption is hard and expensive, we can expect them to not believe that newer technologies are really any better.

One way to address this problem may be for researchers to look at the newer technologies and try to measure their usability. The famous paper “Why Johnny Can’t Encrypt” was followed by “Why Johnny Still Can’t Encrypt” a few years later, but the later work didn’t look at the newer technologies. Instead, it looked at how much the same technology used in the earlier study had improved. A more useful study might look at products like Voltage’s SecureMail, which is much easier to use than the previous generation of products.

The participants in the study that was described in “Why Johnny Can’t Encrypt” had to do some fairly low-level work with their keys. A user of SecureMail, on the other hand, doesn’t need to worry about those details at all. If they can click on the “Send Secure” button instead of the “Send” button in their email client then they can send encrypted messages. I can’t believe that any study would find that particular task too difficult for most people to do.

The problem may be finding a way to get people to believe that it’s really that simple. If they’re using Bayesian reasoning, however, they might not even believe it after they’re shown it. How do you work around that?

How to stop some data breaches

I just read an interesting paper, "Nobody Sells Gold for the Price of Silver: Dishonesty, Uncertainty and the Underground Economy," by Cormac Herley and Dinei Florêncio of Microsoft Research. Herley and Florêncio describe an interesting way to fight data breaches, and that's by contaminating the data that's available for sale by cyber-criminals. The reason that what they propose would probably reduce data breaches is based on the work that won George Akerlof the Nobel Prize in Economics in 1991.

Akerlof's insight was that if buyers can't tell the quality of what they're buying, then markets can fail. His favorite example of this is a hypothetical market for used cars.

Suppose that used cars are worth $10,000 if they're in good condition, but half of them require $1,000 in repairs and that buyers can't tell which cars are which. If this is the case, then a rational buyer would only pay $9,500 (= 0.5 * $10,000 + 0.5 * $9,000) for a used car. But at this price, the owners of the high-quality cars won't sell, because theirs are worth $10,000. This leaves only the lemons on the market, which will further depress the price of used cars, and will lead to the failure of the market for used cars unless buyers have some way to distinguish the good cars from the lemons.

Apparently, there are also quality uncertainty issues in the market for stolen credit card numbers, and this leads to a way to make this market fail. If we can add enough bogus credit card numbers into the market for stolen credit card numbers, if Akerlof's model is right, this will lead to a downward spiral in how much cyber-criminals can get stolen credit card numbers. If we can reduce this low enough, it will no longer be worth their effort to sell stolen credit card numbers and the market will essentially disappear. So flooding the underground market with bogus credit card numbers might be a way to stop some data breaches, in particular, the ones that are caused by hackers actively compromising a system to steal credit card numbers. 

That's an interesting idea, but I doubt that we'll see credit card companies doing it any time soon.

Signed malware

Associating a digital signature with software can be useful because it gives you a reasonable assurance of the source of the code. But because it’s easy to misuse a code signing certificate by using it to sign malicious code, there’s absolutely no reason to believe that all signed code isn’t malicious in some way. Exactly how common is signed malware?

The Microsoft Security Intelligence Report gives lots of interesting statistics about malware, and version 5 of this document, the one that covered January through June 2008, had some information about signed malware. Here’s how the Microsoft report described what they saw:

In the first six months of 2008, the MMPC received reports of about 22 million instances of distinct malware files, of which about 173,000 were distinct malware files with code signatures. Of this malware with code signatures, about 38,000 had signatures that were not valid for signing code, so approximately 135,000 validly signed malware files were reported to Microsoft. In total, approximately 0.6 percent of detected malware was validly signed.

That’s useful information, but what would be even more useful is an estimate of the probability of having malware given that software has a valid digital signature. That information isn’t available in the Microsoft report.

Security as entropy

It turns out that there may be a connection between security and entropy. Here’s why this is the case.

Let’s assume two things. First, let’s assume that security is a function S of the exploitability of the technologies that are used to implement it, where exploitability is some sort of probability measure P. Next, let’s assume that security follows these general rules:

1. The security provided by two technologies when they’re both used is greater or equal to the security of each of the components when they’re used by themselves
2. If two technologies are independent then the security provided by the two technologies when they’re used together is equal to the sum of the security provided by each of the technologies
3. The security provided by any technology is non-negative

If security follows these rules, it turns out that it has to be a function that looks like S(P) = -log(P). We can make the base of the logarithms anything that we want, but it has to be of this general form.

Now suppose that a particular technology X can perform n different security functions with probabilities p₁,p₂,…,p_n. If this is the case, then the average or expected level of security provided the technology X is 

which is just another way of writing entropy.

Some people that I've mentioned this connection to tell me that it's is obvious. Others don't think that it's that obvious at all. Just like you can think about Shannon entropy as what you don't know about information, you might be able to think of security as what adversaries don't know about your information, although that might be going a bit too far.

I doubt that there's anything profound about this observation, but because of this connection to entropy, some of the things that we observe about data breaches may turn out to not be coincidences. There are some things that seem to make sense if we think of them as coming from situations where entropy is maximized, for example. Maybe that'll be the topic of a future post.

A Bayesian approach to understanding tokenization

I had an interesting discussion last week about why most security experts don’t believe them when tokenization vendors claim that their technology is more secure than encryption. It seems that understanding this is good example of an application of Bayes’ theorem. Here’s why.

Let E represent the belief that encryption is the most secure way to protect sensitive information. Let K represents the knowledge that we have of the effectiveness of security technologies and T represent the belief that tokenization is more secure than encryption.

What we’re interested in is the probability that encryption is the most secure way to protect sensitive information given the claim made by tokenization vendors and our prior understanding of security technologies: P(E|T∩K). We can use Bayes’ theorem to write this as

P(E|T∩K) = P(E|K) P(T|E∩K) / P(T∩K)

= P(E|K) P(T|E∩K) / (P(E|K) P(T|E∩K) + P(NOT(E))|K) P(T|NOT(E)∩K))

Let’s assume that before we hear any claims about the security of tokenization, we’re fairly confident that encryption is the best way to protect sensitive information, so that P(E|K) = 0.99. If we don’t believe that encryption is the most secure way to protect sensitive information then it's reasonable to assume that we might believe that tokenization is a good alternative. To reflect this let’s assume that P(T|NOT(E)∩K)) = 0.9. On the other hand, you’d be hard pressed to find a single cryptographer who agrees that tokenization is more secure that encryption, so it’s probably the case that we should doubt the claim that tokenization is more secure than encryption. To reflect this, let’s assume that P(T|E∩K) = 0.1.

With these values we can now calculate P(E|T∩K) as

P(E|T∩K) = (0.99)(0.1) / ((0.99)(0.1) + (0.01)(0.9)) = 0.9167

so that Bayes’ theorem tells us that there’s no reason to assume that the claims that tokenization is more secure than encryption should really change our belief that encryption is the best way to protect sensitive information.

A better way to define cryptographic security

The level of protection that using cryptography actually provides can be confusing to many people. An 80-bit Skipjack key provides the same level of security as a 160-bit elliptic curve key or as a 1,024-bit RSA key, but understanding why this is true requires knowing more math than most people care to learn.

When it comes to quantifying the strength of cryptographic hash functions it gets even worse, because the strength of a hash function is very dependent on how it used. Finding a collision is the easiest attack on hash functions, and is the usual metric that's used to quantify the strength of one. But even if you can find a collision in a hash function, that doesn't mean that you can actually use that collision to defeat a cryptographic protocol. It's almost always more complicated than that.

This means that an accurate answer to exactly how secure something is can be so full of arcane crypto-details that only a specialist can understand it. This also means that the answer is useless to anyone other than specialists, which includes most of the almost 7 billion or so people that are currently alive.

Maybe there's a better way to quantify security that giving it in terms of bits of security. Maybe an arcane government regulation that dates back to 1967, 32 FR 11467, provides an example of a better way to do this.

32 FR 11467 defines the United States Standards for Grades of Green Olives. It's where the olive sizes like Large, Jumbo, Giant, Colossal, Mammoth, etc., are defined. It's also why olives always sound bigger that they are. If you open a can of Large olives, you'll probably be surprised by how small they really are. You need to get Colossal or Mammoth olives to really impress your holiday guests.

But despite the way in which it tricks people into buying a can of Large olives at least once in their life, the olive standard that's defined in 32 FR 11467 has been fairly successful and people seem to understand it better than they understand the way in which cryptographic security is quantified. Because it seems to work so well, why not model a standard for cryptographic security on it?

Instead of using bits of strength to quantify the strength of cryptography, the government could define several security levels that are defined by words instead of numbers. We could have levels like Secure, Very Secure, Highly Secure, Extremely Secure, etc. The level defined by "Secure" would have to be roughly the same as a fairly low level of security, of course, so that we'd be following the model that's worked so well with the United States Standards for Grades of Green Olives.

Some people might be tricked into buying something that is only Secure, but that wouldn't happen too often. People quickly learn that Large olives aren't really very big, and they'd learn quickly that something that's called "Secure" doesn't really provide that much protection against hackers.

I'll have to mention this idea to the people at NIST the next time that I talk to them.

Why use Secure Mail?

I predict that some day we'll notice that very few consultants encrypt their email. This will be because of the secure email products that they were forced to use when they worked at larger companies. My experience with ice cream leads me to believe this.

When I was a kid, we would frequently get ice cream on the way home from school. I always wanted to get a clown cone, a scoop of ice cream in a sugar cone that's decorated with candy to look like a clown. Clown cones don't actually taste that good because they've usually been sitting out for quite a while before you buy them, but they certainly look good, and that's why I always wanted one.

My parents, however had different ideas. They knew that clown cones don't actually taste very good, and they never let me get one. After years of being cruelly denied clown cones, now I'm the dad, and nobody (except my wife of course) can tell me that I can't get one. I do this every time I take my kids out for ice cream, cheerfully ignoring the fact that the clown cones really don't taste that good as I do it.

Now consider the people who have to use email encryption on the job. Many of these people aren't lucky enough to be using Voltage's SecureMail, which is extremely easy to use. Some of them even use PKI and S/MIME to protect their email. They probably hate every minute of this, but are forced to use S/MIME anyway.

Some of these people are going to become consultants one day. They'll be their own boss and won’t have a security department to force them to use S/MIME. I expect that many of these people will rebel against their terrible experiences with S/MIME by intentionally avoiding using encrypted email as much as they can, ignoring that fact that they really should be protecting sensitive information.

What's the solution to this? Use Voltage's SecureMail, of course.

Look out for yourself

Complying with the PCI DSS is definitely one of the biggest concerns that many businesses have these days. The PCI DSS isn't perfect, but there's probably a good reason for its existence. Data breaches expose millions of credit card numbers each year, and many of these are used for fraudulent transactions. Consumers, however, typically don't end up paying for these fraudulent transactions, at least not directly. It's still there, though, because the cost of the fraud gets built in to the prices that we pay.

According to the Federal Trade Commission's 2006 Identity Theft Survey Report (the most recent version), the median out-of-pocket loss cost that consumers experience from all forms of identity theft is actually ZERO dollars. Instead, it's the merchants and banks who really end up absorbing the losses and paying fines when they lose credit card numbers. So if you're a merchant that accepts credit cards, you have a serious interest in reducing the number of data breaches that expose credit card numbers. If you're a consumer, you probably have better things to worry about.

If you're a consumer and your credit card number gets stolen, your bank will cancel the old card and issue you a new one. You may suffer a little inconvenience, but having your credit card number stolen probably won't affect you that much. You're probably better off worrying about other sensitive information that can't be just cancelled and replaced. This includes things like your credit history, your Social Security number and your medical history. If any of these gets compromised, it can't be cancelled and reissued. Once it's exposed, your privacy is gone for the rest of your life and it's probably impossible to get it back. If you're a consumer, you probably have more of an incentive to worry about the security and privacy of this type of information.

The PCI DSS has attracted most of the attention recently, but consumers really should be more concerned about the protection of information other than credit card numbers. If you're going to lobby your government to do something, look out for your interests. Let the banks and merchants worry about reducing credit card fraud. You should worry the most about the loss of sensitive information that affects you the most.

Cloud computing security incidents

There's lots of talk about cloud computing and the security issues that surround it these days. There are some issues that deal with regulatory compliance that get tricky when data's in a cloud, but how many actual security vulnerabilities have been discovered that relate specifically to cloud computing? It's easy to answer this question if we look at the Cloud Computing Incidents Database. It's not clear how reliable or comprehensive the information in the CCID is, but it currently has information on 18 separate incidents that have taken place in the past two years.

All but one of these incidents are the loss of service or the loss of data. The single incident that's an actual exploitable vulnerability is a bug in the way Google used SAML 2.0 in their single sign-on service for Google Apps. This particular vulnerability even has its own listing in the National Vulnerability Database, which you can find here and you can find the original paper that described this vulnerability here. Here's how the abstract of this paper summarizes the vulnerability:

Single-Sign-On (SSO) protocols enable companies to establish a federated environment in which clients sign in the system once and yet are able to access to services offered by different companies. The OASIS Security Assertion Markup Language (SAML) 2.0Web Browser SSO Profile is the emerging standard in this context. In this paper we provide formal models of the protocol corresponding to one of the most applied use case scenario (the SP-Initiated SSO with Redirect/POST Bindings) and of a variant of the protocol implemented by Google and currently in use by Google's customers (the SAML-based SSO for Google Applications). We have mechanically analysed these formal models with SATMC, a state-of-the-art model checker for security protocols. SATMC has revealed a severe security aw in the protocol used by Google that allows a dishonest service provider to impersonate a user at another service provider. We have also reproduced this attack in an actual deployment of the SAML-based SSO for Google Applications. This security flaw of the SAML-based SSO for Google Applications was previously unknown.

Many people think of the confidentiality of data when they think of information security, but the history of cloud computing should be a good reminder that the integrity of data and the availability of data are just as important.

The Philosophy of Tokenization

In 1846, Edgar Allen Poe published the essay "The Philosophy of Composition" in which he described how he came to write The Raven. What Poe says in this essay probably isn't true, but it almost certainly tells you how Poe wanted people to believe how he came to write The Raven. In other words, Poe may have invented more than the detective story. He may also have invented marketing.

Over 160 years after Poe wrote "The Philosophy of Composition" we see security vendors telling us things about their products that aren't really true but they want you to believe are true. What some tokenization vendors are claiming about their technology is a good example of this.

A tokenization system implements two functions: tokenize and detokenize. When a requesting application calls the tokenize function with a plaintext input, a tokenization system creates a token from the plaintext using a proprietary tokenization algorithm. The tokenization system then encrypts the plaintext using a cryptographic key that it gets from a key server. It then archives a copy of both the resulting ciphertext and the key used to encrypt it, and returns the token to the requesting application. When a requesting application calls the detokenize function with a token input, a tokenization system retrieves the archived ciphertext that corresponds to the token from its encrypted data archive and the key that was used to encrypt the ciphertext from its key archive. It then decrypts the ciphertext and returns the decrypted value to the requesting application.

Note that the secure operation of a tokenization system relies on the secure operation of several components: the tokenization server itself, as well as the key server that it uses, the key archive system and the encrypted data archive. The failure or compromise of any one of the components of this system will compromise the entire tokenization system.

The chances of an application being inappropriately implemented, configured or maintained is much greater that the chances of an adversary being able to defeat modern cryptography, so the reliability of a security system is limited by the chances of the system failing rather than an attacker defeating any type of cryptography. This means that tokenization systems are inherently less secure than systems with fewer components, which includes systems that implement encryption.

The security of a tokenization system also relies on the security of a proprietary tokenization algorithm. The operation performed by this algorithm is identical to the operations performed by well-known cryptographic algorithms like hash functions or encryption algorithms, which transform a message into a form from which it's infeasible to recover the original message. Oddly, the fact that its output is called a "token" instead of a "ciphertext" or a "message digest" has let tokenization algorithms avoid the careful public review that other cryptographic algorithms are subject to.

"Security through obscurity" has been known to be a bad system design principle for over 125 years - ever since Auguste Kerckoffs wrote "La cryptographie miltaire" in 1883. There's no reason why tokenization algorithms should be exempt from this general principle, and anyone thinking of using tokenization to protect sensitive data should ensure that the technology that they're considering is secure enough to withstand careful public review.

Tokenization really isn't more secure than encryption. Tokenization vendors just want us to think that it is.

Locking Doors

A lot of people use the locked door as a metric for the quality of a community. They will say something like, "I grew up in a small town. It was full of good people, it was safe. We didn't even lock our doors." I've heard it said of big city neighborhoods as well. "We lived in this neighborhood where everyone knew everyone else. In our building there were maybe 20 apartments and no one had to lock their doors."

In a documentary once, some residents of a large, non-US city were proclaiming proudly that they don't lock their doors. Incidentally, I looked up some statistics on crime in that city (my sources were reports put out by that country's government), and it looks like they suffer more crimes in total and fewer violent crimes than the US average. Hence, it appears there are more property crimes per capita than in the US. I'd like to see a comparison between that city and US cities, but the report only included the US averages.

Sometimes when people talk about doors and locks, I get the impression they are saying it is morally superior to leave the door unlocked. That is, the unlocked door is not just a metric on the honesty and goodness of the population, but the character of the door owner.

By the way, I don't get this impression with all people who don't lock their doors. But every once in awhile it seems to me that an open-door person is saying, "You are so mistrusting. You have such a low opinion of humanity. But me, I choose to believe that people are mostly good." Or the subtext is a weird counter projection, "You believe people are dishonest and will steal from you because you yourself are dishonest. You expect other people to do what you would do. Only a dishonest person would lock their door."

I suspect some places where people leave their doors unlocked do so because the neighbors would be offended (or the door owner thinks they might be offended) if they did lock. "What? You think I might steal from you, so you lock your door? You think I'm a thief? I'm offended."

Another reason to leave the door unlocked is convenience, maybe you never want to get locked out. Perhaps you figure that a professional thief will have no problem getting past a locked door. If so, then locking doors won't prevent crime, it will only cause you to get locked out every so often. So why bother? Of course, the locked door might not stop the professional, but it might deter the amateur or the opportunistic. Or maybe the thieves simply go after the easiest targets ("I don't have to outrun the bear, I only have to outrun you"). They know enough doors are unlocked so they don't have to bother with the locked ones.

If you leave your door unlocked, it's possible you don't get robbed because no one tries your door. A common security measure is "do nothing and hope nothing bad happens". It often works.

I believe that there are thieves in this world. Some of them live in small towns, some in large cities (large cities have more targets and more opportunities to be anonymous, so thieves gravitate to larger metropolitan areas). Some of them are drug addicts trying to get money for a fix (and they might live in small towns or in the supposedly safe apartment building). Some of them are kleptomaniacs or teenagers looking for a thrill or see it as a game. I think it is a wise policy to try to protect yourself from the thieves as best you can. Locking your doors is easy. It's not an indictment of your neighbors, the town, or your own character to lock doors.

An information security kriegsspiel

In 1824, George Leopold, better known as the Baron von Reiswitz, published a set of rules for a game that simulated tactical situations that a commander of a Napoleonic-era army might face. These rules were called Anleitung zur Darstelling militarische manuver mit dem apparat des Kriegsspiels (Instructions for the Representation of Tactical Maneuvers under the Guise of a Wargame). The story goes that when presented his game to General von Muffing, the Chief of Staff of the Prussian Army and his General Staff, von Muffing was skeptical of the game, but after seeing his staff play it, he said "This not a game! This is training for war! I must recommend it to the whole army."

Not too long after that, each brigade in the Prussian army had their own copy of Leopold's game and regularly played it. When the Prussians soundly defeated the French in the Franco-Prussian war (1870-71), in part due to the training that the Prussian officers had received from playing Leopold's kriegsspiel, other armies started to take the game seriously. Even today, similar games are used today to train military officers. The ones that I played used little lead models of tanks to fight out various scenarios in a hypothetical invasion of Germany through the Fulda Gap by the USSR. You definitely got to try scenarios in the games that you'd very reluctant to try in real-life, and it was very interesting to see the outcome of these unusual scenarios.

If wargames are useful for training military officers, similar games might be useful to train information security professionals. Instead of making tactical decisions, in such an information security kriegsspiel you'd have to make decisions about how to spend your budget. Once you allocated your budget, you'd go through a series of security incidents, the outcome of which would depend on how you allocated your budget. After resolving enough incidents to represent a year, you'd begin the process again. Maybe a referee would periodically provide updates to the information security threat that would require you to reprioritize your spending.

After playing such a game a few times, you'd be able to try lots of "what if" situations, and might have a better idea of exactly what the implications of making certain decisions would be. This could be a very useful training tool for CIOs, CSOs, CISOs, etc. Maybe someone already does this and I just haven't heard about it.

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.

Why do data breaches have a lognormal distribution?

In a previous post, I noted how the size of data breaches seems to follow a lognormal distribution. The available data seems to support this claim, but this raises an interesting question: exactly why do the sizes of data breaches have a lognormal distribution?

One way to get a lognormal distribution is to have a distribution that's the product of several independent normal distributions. If we try to apply that interpretation to data breaches, we might think of a data breach as resulting from the failure of one or more security mechanisms, with the failure of each mechanism being independent and having a normal distribution.

On the other hand, just because a distribution is lognormal doesn't mean that it's derived from the product of several factors, at least not in a meaningful way. There are many examples of things that follow a lognormal distribution, but don't seem to be derived from a product of normal distributions. There's an interesting article by Eckhard Limpert, Werner Staehel and Markus Abbt, "Log-normal Distributions across the Sciences: Keys and Clues," that was published in BioScience magazine that gives some examples of where this is the case. You can find this article here.

According to this article, the following values have a lognormal distribution:

• the concentration of gold or uranium in ore deposits

• the latency period of bacterial food poisoning

• the age of the onset of Alzheimer's disease

• the amount of air pollution in Los Angeles

• the abundance of fish species

• the size of ice crystals in ice cream

• the number of words spoken in a telephone conversation

• the length of sentences written by George Bernard Shaw or Gilbert K. Chesterton

Because the lognormal distribution seems to be so common, the fact that data breaches follow it shouldn't be that surprising. And just like it's hard to explain why the number of words spoken in telephone conversations follows a lognormal distribution by thinking of a lognormal distribution as being derived from the product of several independent normal distributions, there may also be a limit to how much we can understand data breaches by analyzing the lognormal distribution. The size of data breaches seems to follow a lognormal distribution, but it may be a mistake to analyze that fact too much.

Interactive Data Breach Map - Zoom into local breaches

  

Today, we introduced the new Voltage Data Breach Index, a single at-a-glance view into the state of national and global data breaches. A visual map brings data breach reporting to life, summarizing historical and real-time breaches, size and scope, types of records, regions affected, industry and more. Perhaps most interesting is that patterns in the data enable the creation of a predictive data breach model. This model predicts, for example, that 14 data breaches will, over the next year, each expose 1,000,000 or more records to potential use by criminals. And, at least one breach of over 10,000,000 records will affect nearly 5 percent of the U.S. population.  You can read more about the details of the analysis here.

Digitally used and stored data is now part of every economic sector and the applications that touch our daily lives. Organizations entrusted with our personal information should have a responsibility to protect it beyond what’s mandated by regulatory compliance laws, industry standards and directives. The goal of the Voltage Data Breach Index is to make data loss reconnaissance more widely available and easier to understand. It should serve to educate organizations about the risks they, their customers and other constituencies face. And it should advocate the value of end-to-end encryption, with an industry call-to-action of this as critical mandate—not simply something that’s “nice to have.” Technologies coming to market are changing the game by making it faster, cheaper and easier to achieve.

We worked very closely with the Open Security Foundation's DataLossdb.org, which provides independent, accurate, detailed, current, and unbiased security information. DataLossDB's goal is to provide accurate and unbiased information about breaches of personally identifying information when lost by or stolen from third parties. DataLossDB is a searchable database that promotes research and the sharing of information by professionals and enthusiasts alike. Data is acquired from verifiable media and government resources and is open for community participation.

We hope the Voltage Data Breach Index map and predictive analysis tool will become standard for measuring and anticipating data breach activity and, ultimately, a powerful instrument for preventing future losses. We believe the need has existed for some time; there have been virus maps for many years and they've proven valuable in illustrating threats and trends. The new frontier is the large and rapidly growing area of data theft and fraud.

Please visit www.voltage.com/data-breach for more information and feel free to link/embed the map to your blog or website - just click on embed or use the badge to copy the necessary code snippet.

Benford's law and the size of data breaches

In a previous post we noted how the size of data breaches seems to follow a lognormal distribution. This happens when the data doesn't follow a normal distribution, but its logarithm does. It turns out that there's some more interesting structure in the size of data breaches, and this is due to the way in which the size of data breaches follows Benford's law.

Benford's law says that if you look at first digit of data, each digit appears with a probability of roughly p(d) = log(1 + 1/d). Data that follows Benford's law starts with a '1' about 30% of the time and with a '9' about 5% of the time, for example. Not all data follows Benford's law, but enough data does to make it interesting.

Benford's law often holds when data comes from an exponential process, like you might see in population growth. To see why this happens, consider the population of a country that starts with 1 million people and grows at 10% per year. Here's what you get for the population as it grows for 25 years. Note that the first digit of the population is a '1' more often than it's a '2' and so on. After 25 years we're back to having '1' for the first digit so that we'll see it more frequently over the next 25 years also.

Year	Population
0	1,000,000
1	1,100,000
2	1,210,000
3	1,331,000
4	1,464,100
5	1,610,510
6	1,771,561
7	1,948,717
8	2,143,588
9	2,357,946
10	2,593,740
11	2,853,114
12	3,138,425
13	3,452,267
14	3,797,493
15	4,177,242
16	4,594,966
17	5,054,462
18	5,559,908
19	6,115,898
20	6,727,487
21	7,400,235
22	8,140,258
23	8,954,283
24	9,849,711
25	10,834,682

The size of data breaches also seems to follow Benford's law. Here's a graph that compares the frequecies of two sources of initial digits. One comes from the size of the data breaches that are currently listed in the OSF's data breach database. The other is what you'd expect from Benford's law. That looks like a good fit to me, but I'll leave it to someone else to do a more careful analysis of whether or not there's a significant difference between what we see and what we expect.

   

The fact that the size of data breaches seems to follow Benford's law tells us that there may be a relationship between the size of data breaches and some sort of exponential process. What sort of process could that be?

The next Big Thing

There are many sites on the Internet that let you create polls for others to take. Many of these user-created polls help you decide important issues like which Star Wars character you are most like, which  character from The Lord of the Rings you are the most like, or even which character you are the most like from classic '70s sitcoms like Welcome Back Kotter and Mork and Mindy. There are so many of these sites out there that I have to assume that they're popular.

Eventually, however, people are going to run out of popular culture references to use for these polls, and that's when cryptography will have its chance for 15 minutes of fame. Imagine millions of people taking polls that tell them which public-key algorithm they're most like or which mode of AES they're the most like.

It could happen.

Summarizing the RSA Conference expo

I like detective stories; I read them, I write them; but I do not believe them. The bones and structure of a good detective story are so old and well known that it may seem banal to state them even in outline. A policeman, stupid but sweet-tempered, and always weakly erring on the side of mercy, walks along the street; and in the course of his ordinary business finds a man in Bulgarian uniform killed with an Australian boomerang in a Brompton milk-shop. Having set free all the most suspicious persons in the story, he then appeals to the bull-dog professional detective, who appeals to the hawk-like amateur detective. The latter finds near the corpse a boot-lace, a button-boot, a French newspaper, and a return ticket from the Hebrides; and so, relentlessly, link by link, brings the crime home to the Archbishop of Canterbury.

G.K.Chesterton, Illustrated London News, May 6, 1911

If Chesterton he were around today, he would probably have enjoyed this year's RSA Conference. If he had attended it, he might have noticed that it was fairly easy to summarize many of the pitches that you heard on the expo floor. He might even have felt compelled to comment on them. The pitches of most the vendors in the expo went roughly like this:

More than <random big number> data breaches occur each <random unit of time> causing over <random big number> dollars each year

Source: <reference to an analyst report that’s too vague to actually verify>

And the only way to stop this massive problem is to buy my products

I'm sure that some of the products that I saw at this year's conference are actually very useful for stopping data breaches, but it was hard to take some of the claims seriously. I know that I really can be PCI compliant without buying the equivalent of secure fuzzy dice, after all.

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.

More on the lognormal model

When I recently pointed out how the records exposed in data breaches seem to follow a lognormal distribution, an astute reader, Patrick Florer, asked how a very large breach would affect how well the lognormal model fits the data. It turns out that it essentially doesn’t affect it at all. I’ll try to explain this in three ways. One appeals to intuition, one is a proof by picture, and the third actually crunches some numbers to show this.

Let’s suppose that there has been a data breach that’s been reported but we don’t know the size of yet. Let’s suppose that this hypothetical data breach has exposed 200 million records and see how adding that single extra data point to the existing would affect the accuracy of the lognormal model that has a logmean of 3.5 and a logdeviation of 1.2. I'll be a bit sloppy here and use "mean" instead of "logmean" and "standard deviation" instead of "logdeviation," but that's just to make the following a bit more understandable. I've also used base 10 logs here. That's because most people immediately know what the base 10 log of 1 million is, while almost nobody knows what the natural log of 1 million is.

In the first place, note that the lognormal model deals with the logarithms of the sizes of breaches. So while 200 million certainly sounds like a big number, it’s log is only 8.3, which doesn’t sound quite as big. And note that 8.3 is only 4 standard deviations above the mean of 3.5. Events 4 standard deviations from the mean aren’t that common, but they’re also not really that rare. The so-called Six Sigma quality control process tries to manage events that are 6 standard deviations from the mean, for example.

And because the lognormal distribution is symmetric about its mean, we would expect that a really large breach would have the same effect on the accuracy of the model as a really small breach would. So while our intuition might lead us to believe that a really large breach to throw off a lognormal model, it actually has essentially the same effect as a very small breach.

That’s the appeal to intuition (also known as “hand waving”) part.

Another way to look at how a single large breach affects the lognormal model is to look at how well the data fits the model after this additional data point is added to it. Here is a graph that shows how well the existing data fits the lognormal model. In this graph, the straight line is the model and the squares represent actual breaches. There’s already a breach that exposed close to 100 million records, where the log of the number of records exposed is about 8. Our hypothetical big breach just adds a single data point slightly past that one and fairly close to it. In this case, you might expect that this doesn't really change things much. 

 

That’s the proof by picture. It’s still not very rigorous, but it might give you an idea of why adding a single breach that exposed 200 million records doesn’t really affect the lognormal model of breaches much.

A more careful approach would add the hypothetical point to the data set and see if the distributions that you see in the old data set and the new, bigger data set are significantly different. If we look at these two distributions, we find that the two are both lognormal with a logmean of 3.5 and a logdeviation of 1.2. We can use a Shapiro-Wilk test for normality, for example, to check this. If we do this we get p-values that are much greater that 0.05 in both cases, so both the distribution with the additional data point and without the additional data point both agree with the same lognormal model with a reasonable degree of accuracy.

So the bottom line is that the lognormal of data breaches seems to model the available data fairly well, and it’s still fairly accurate if we add a hypothetical very large breach to the historical data.

A new type of standard

On May 7 there was a meeting in Plano, Texas, to discuss the plans for developing a standard for end-to-end encryption. This standard is a new work item that was recently approved by the X9 Accredited Standards Committee, the group that creates information security standards for the financial services industry. The meeting was jointly sponsored by Heartland Payment Systems and the Merchant Advisory Group, both of which clearly showed that they're now taking the security of credit card information very seriously.

The usual suspects showed up at this meeting - a combination of banks and security vendors. What was good to see was that some businesses also showed up that accept credit cards for payment for either goods or services. This was a good thing, and it should happen more often.

Most standards groups comprise just the vendors who make whatever technology is being standardized. This is usually bad, because vendors tend to create standards that reflect how they want to do things instead of how their customers want things to be done. But because their customers usually don't take part in the standards process, that's they best that the vendors can do.

Because the customers usually don't get involved in developing new standards, it's sometimes hard to feel sympathy for them when then end up with a standard that doesn't reflect their needs. So the fact that the merchants who will be using the end-to-end encryption standard are interested enough to get involved in developing a standard for it is definitely a good sign. There seems to be a good chance that the unprecedented level of involvement by the end users of the standard will end up making the standard fairly useful. It will be interesting to see how this standard develops over the next few months.

Update on the Hannaford suit

In a recent post, I mentioned how a US District Judge was considering whether or not consumers had the necessary standing to sue Hannaford Brothers over the data breach that Hannaford suffered in 2008. There's now been a ruling on this that may have interesting implications for both security and privacy.

The judge essentially ruled that if consumers didn't suffer any financial damage from the data breach then they have no damages to recover, and their claims were thrown out. In most data breaches involving credit cards, consumers end up suffering no financial damages - those are typically absorbed by the merchants that accepted the fraudulent transactions on the stolen credit cards. Because of this, consumers who have their credit card number stolen may find their options limited if they don't actually suffer any losses from the breach.

Here's how the Judge summarized his thoughts:

But if the merchant is not negligent, or if the negligence does not produce that completed direct financial loss and instead causes only collateral consequences—for example, the customer’s fear that a fraudulent transaction might happen in the future, the consumer’s expenditure of time and effort to protect the account, lost opportunities to earn reward points, or incidental expenses that the customer suffers in restoring the integrity of the previous account relationships—then the merchant is not liable.

This ruling may make data breaches much less costly for the businesses who suffer the breaches, and may leave the PCI DSS as the only effective tool to use to get businesses to take the security of credit card information seriously.

Hashing and the PCI DSS

Some people want to use hashing to render cardholder information unreadable, but a closer look at hash functions shows that this technique ends up either being non-secure, or if it's done in a secure way, then it's equivalent to encryption because the security depends on the secrecy of secret information.

The FAQ for the PCI DSS has the following to say about using a cryptographic hash function to render cardholder data unreadable:

Are hashed Primary Account Numbers (PAN) considered cardholder data that must be protected in accordance with PCI DSS?

One-way hashing meets the intent of rendering the PAN unreadable in storage; however the hashing process and results, as well as the system(s) that perform the hashing, would still be in scope to assure that the PAN cannot be recovered. If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS. If however, the system hashes and stores the data on the same system, that system is considered to be storing cardholder data and is within PCI DSS scope. The difference lies in where the data is hashed and then stored. More on hashing: A hash is intended to be irreversible by taking a variable-length input and producing a fixed-length string of cipher text. As the PAN has been 'replaced', it should most often be considered out of scope in the same manner receipt of truncated PANs are out of scope. However, PCI DSS Requirement 3.4 also states that the hash must be strong and one-way. This implies that the algorithm must use strong cryptography (e.g. collisions would not occur frequently) and the hash cannot be recovered or easily determined during an attack. It is also a recommended practice, but not specified requirement, that a salt be included. Since the intent of hashing is that the merchant or service provider will never need to recover the PAN again, a recommended practice is to simply remove the PAN rather than allowing the possibility of a compromise cracking the hash and revealing the original PAN. If the merchant or service provider intends to recover and use the PAN, then hashing is not an option and they should evaluate a strong encryption method.

Note that including a salt is recommended but not required. The PCI SSC should consider revising this to require a salt and to reconsider how this affects determining exactly which systems are in scope and which ones are not for a PCI DSS assessment.

A hash function H takes a message M and calculates a message digest or hash D=H(M) from it. A cryptographic hash function is one in which the following three operations are adequately hard:

1. Finding two messages M₁ and M₂ such that H(M₁)=H(M₂). This is called finding a collision.

2. Given a message digest D, finding a message M with H(M)=D. This is called finding a preimage.

3. Given a message M₁ and its digest D=H(M₁), find another message M₂ that produces the same digest, or that D=H(M₂). This is called finding a second preimage.

When a hash function is used to render cardholder data unreadable, we're really saying that it needs to be hard to find a preimage for a given message digest. If it's easy to do that, then an attacker can recover a PAN from a hash of the PAN, which means that the hash wasn't really unreadable. Making a hash of a PAN unreadable really requires more than just running a PAN through a cryptographic hash function. This is because there really aren't that many PANs possible.

You can divide a 16-digit PAN into three parts. The first six digits are the Issuer Identification Number (IIN). The next seven digits are an account number. The last digit is a checksum that's calculated from the previous 15 digits.

With a 16-digit PAN, there are 10¹⁶possible PANs. Calculating all 10¹⁶ possible message digests for these PANs sounds hard, but it doesn't require the level of effort required to make it as hard as breaking other forms of cryptography. It's roughly equivalent to the work required to break a 53-bit cryptographic key. That's a non-trivial amount of work, but one that isn't enough to really be considered secure against hackers today.

On the other hand, because the first six digits of a PAN can often be guessed, it's probably even easier to reverse a hash of a PAN than that because it's very reasonable for a hacker to be able to guess the IIN.

The IIN just tells you what type of card a PAN is from and what bank issued the card. If you're a hacker that manages to breach the security of a particular bank, for example, then it's very easy to greatly limit the range of possible IINs, leaving only the account number and the checksum that are unknown.

If you know the first six digits of a PAN, then reversing a hash function from a hash of the PAN is very easy. You only have to calculate 10¹⁰ possible message digests, which is roughly the work required to break a 33-bit cryptographic key. That's an amount of work that's fairly easy with today's computers, and one that's feasible for many hackers to do.

This means that if an attacker knows the IIN part of a PAN then replacing the PAN by a hash of the PAN doesn't really provide that much security for the PAN. It provides some security, but not enough to really defeat a moderately-determined attacker.

One way to make it harder for an attacker to recover a PAN from a hash of the PAN is to add additional information called a salt to the PAN when it's used to calculate a hash of it. So instead of calculating D=H(PAN), you might calculate D=H(PAN||SALT) instead. This makes it much harder for an attacker, but it also requires keeping the value of the salt secret to make it difficult for a hacker to find the value of a PAN from a hash of the PAN.

If the salt isn't secret then using it doesn't make it harder for an attacker to find a preimage of D, which means that it's no more difficult to recover a PAN from a hash of the PAN. If this is the case, then the reason behind replacing a PAN with a hash of the PAN doesn't make sense any more because the hash function is no longer reversible.

On the other hand, if the difficulty of recovering a PAN from a hash of the PAN depends on the secrecy of a salt, then there's no real difference between the protection provided by replacing a PAN with a hash of the PAN and replacing a PAN with an encrypted version of the PAN. In the case of using encryption, we call this value a cryptographic key. In the case of using a salted hash, we call this value a salt. In both cases, reversing the transformation is easy if an attacker has access to a secret. This means that for the purposes of complying with the PCI DSS, the two probably ought to be considered equivalent.

An unusual contract opportunity

There's an unusual opportunity for a couple of thousand dollars of contracting work that's posted on the GetAFreelancer web site. Here's what someone wants:

Looking for bluetooth chip and software, and or GSM setup that can be installed in pos terminals that will temporarily backupcard swipe info & pin info, in case of power/system failure before daily purge... Chip must be able to be installed internally, and terminal function properly. Backup info must be recorded prior to encryption, and must be able to be downloaded to bluetooth wireless device. Serious and knowledgeable electronic engineers wanted!!!!!!

In other words, they want someone to build a bug for POS devices. The current bid is only $2600, so it looks like someone's going to get this bug built fairly cheaply.

Data breaches have a lognormal distribution

In many parts of information security, there's very little reliable data that you can use to help you make decisions. For data breaches, however, there's a fair amount of data available, and you can get a database of almost 2,000 data breaches from the Open Security Foundation at their web site datalossdb.org. There's lots of information in this database, and it shows some interesting patterns. In particular, here's what you see if you plot the number of records ("TotalAffected" in the OSF database) compromised by each breach from 2006 to the present. It's hard to see a pattern in this data.

  

On the other hand, if we make a histogram of the logarithm of the data, we get the following graph. That certainly looks like data from a normal distribution, so that the size of data breaches follows a lognormal distribution fairly closely, which is the blue line in this graph. That's a fairly good fit, isn't it?

Violating the end-to-end principle

It’s sometimes convenient to divide communication systems into the end points that attach to a network and the network itself. This provides the framework for thinking about the end-to-end principle. This tells us that whenever possible, operations should take place as close to the end points as possible instead of being implemented in the network. Conventional wisdom tells us that the closer we follow the end-to-end principle, the easier it is to create reliable systems. This principle has guided the evolution of the Internet for many years. Is it still appropriate today?

There are certainly some cases where it’s proved to be useful to violate the end-to-end principle. It’s usually not practical to do content scanning and filtering at end points, for example. These work better when they’re implemented in the network instead, like at a gateway appliance or a firewall. That's where these functions are typically carried out these days, although it's also common to have the same functionality at the end points. An example of this is how virus scanning is often done at both an anti-virus appliance in the network as well as on a user's desktop.

Some types of encryption also work better when they’re implemented in the network instead of at an end point. This frees users from the burden of managing cryptographic keys, and can make technologies like encrypted email much easier to use. This has also proved to be a useful alternative to end-to-end encryption, and most encrypted email today is encrypted at a gateway appliance instead of at an end point.

Not all cases where it’s useful to violate the end-to-end principle involve security. Network address translation (NAT) is a useful technology that’s not implemented at end points but has nothing to do with security, but many of the examples where it’s useful to push functions away from end points seem to. Could this be a general principle: that security often needs to be implemented in the network instead at an end point? There seems to be a fair amount of resistance in the IETF to technologies that violate the end-to-end principle, so if this is true, we may never actually see standards for many useful security technologies.

What clocks can tell us about usability

 

Information security is easy. You just want to keep unauthorized users from getting data that they’re not allowed to get and let authorized users get the data that they’re allowed to get. That doesn’t sound that hard, does it? You can do that by using cryptography. How hard can that be?

I may be even more biased than the typical information security person. Except for a few years working in mergers and acquisition consulting, I've been working with cryptography for over 20 years and I’ve more or less figured out how things work by now. I've actually never thought that it was that difficult, but I also understand that not everyone feels this way about it. So although I can both encrypt and decrypt S/MIME messages, I also understand that most people find it hard. Mechanical clocks played a role in getting me to understand this.

Every time I visit the British Museum, I visit the horological gallery, a collection of over 300 spectacular examples of mechanical clocks and watches from medieval times onwards. This exhibit makes me feel lucky that I was born in the twentieth century. If I had been born in medieval times I would probably have only had the skills to qualify for the position of village idiot. I can look at medieval clocks for hours and still not quite understand how they work. I apparently just don't have the right aptitude needed to understand mechanical clocks.

Many people in the information security industry would probably benefit from a similar experience. The people who make security products are often very out of touch with what the average user can and can’t do, but understanding this would almost certainly help them make better products. Many enterprise security architects would also benefit from this for a similar reason.

Both of these groups often assume that just because a technology seems simple to them that it’s simple to everyone. That’s often not the case. Sometimes, it’s not even close. Useful technologies even need to be usable by those of us who don’t quite understand how those clocks work.

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.

The newspaper effect

 

If you've ever been an eyewitness to a newsworthy event, it's always interesting to read the description of the event in the newspaper the next day. It's almost always the case that what you read doesn’t quite match the events that you witnessed. It might be the case that your memory isn't very accurate. That seems to often be the case after stressful situations, for example.

Another explanation is that the facts were distorted through numerous retellings before they reached the journalist. This is much like what happens in the game of "telephone" that children often play in school, in which a message gets badly distorted after being whispered around the room from child to child. So even if journalists are doing their best to get the facts right, by the time the message reaches them it may have been changed quite a bit, and this version may be the one that gets in print.

On the other hand, when we read in the newspaper about events that we weren't present at, we naturally assume that the printed version is accurate. After all, if it's in the newspaper, it must be accurate, right? This is what I call the "newspaper effect," and it may make us much too trusting of some information. So don't take for granted that everything that you read is true, and certainly don't base your IT strategies on it without double-checking the information for accuracy.

Much of the information that journalists get about the IT market comes from people at IT companies. Their point of view is far from being impartial, and they're unlikely to give an unbiased view of the market and the strengths and weaknesses of their products. And because journalists are as pressed for time as the rest of us, they often don't have the time to check each and every fact that they get from such sources. This has led to many IT companies having an unprecedented ability to influence the perception of both them and their products, and can sometimes make it difficult to distinguish between marketing hype and real journalism.

Back in the dot-com boom, for example, PKI technology was widely reported to be an important technology, and one that every CIO should be including in their strategic plans. Because this was so widely written about, almost nobody questioned this assumption. At the same time that PKI was being described as a vital technology, user experiences with the technology were less than adequate, and it has been estimated that over half of PKI products purchased were never actually deployed because it was simply too hard and expensive to use.

For some unexplained reason, the stories about PKI failing didn’t get the same level of coverage as the stories about how it was a vital part of any organization’s plans. The result was millions of dollars wasted on technology that turned out to be relatively useless. The newspaper effect is at least partially to blame for this. Many people who should have known better believed what they read, and didn’t think to question its accuracy.

Don’t fall into this trap. Look for reliable data to support claims that you see about any new technologies. That data is almost always available somewhere. It just may be very hard to find.

The Munitions List

The Arms Export Control Act (22 U.S.C. 2778(a) and 2794(7)) provides that the President shall designate the articles and services deemed to be defense articles and defense services for purposes of this subchapter. The items so designated constitute the United States Munitions List and are specified in part 121 of this subchapter.

22 CFR, §120.2

The US government maintains a list of technologies that whose export is controlled because they can be used in defense applications. This list is called the “United States Munitions List,” but there’s more on it that just guns and bombs. Spacecraft are on this list. So is some oceanographic equipment. Encryption technology also is.  

If the government had called this list the “Defense Articles and Services List,” it would have made things much easier for many people. The Department of Commerce wouldn’t have to answer hundreds of questions about exactly why encryption technology is a munition. We also wouldn’t have to listen to hackers trying to score points with their friends by saying things like, “Heh heh, encryption is a defense article, isn’t it? This means that by writing the RSA algorithm on my arm and going to Tijuana for the weekend, I’m becoming a trafficker in defense articles. Don’t worry, thought, they’ll never make me talk.”

If only the government had used different words.

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.

Lost knowledge

It was big news last year when Ed Felton’s group of security researchers released their paper “Lest We Remember: Cold Boot Attacks on Encryption Keys” in which they described at attack on full-disk encryption based on freezing DRAM and reading its contents before they’re lost. There was lots of media hype around this paper, with some people making claims like “full-disk encryption is totally non-secure.”

The fact that this paper was considered newsworthy is interesting in itself, and the interest in the so-called “cold boot” attack probably says more about how the background of information security professionals has changed over the past 20 years than it says about the security of full-disk encryption.

Security-conscious organizations like banks and governments have known for quite a while that it’s possible to recover cryptographic keys from DRAM. That’s why the standards that they’ve written often require the use of a hardware security modules to protect keys. So if it’s been known for quite a while that it’s easy to recover keys from DRAM, why the interest in the cold boot attack?

The reason for the interest is probably due to the way that background of the typical person who works in information security these days differs from their counterpart in the past. If you go back 20 years or so, the typical information security professional had a background in electrical engineering. If you study electrical engineering, attacks based on freezing DRAMs are fairly obvious. So are side-channel attacks, ways to recover cryptographic keys from physical measurements of operating cryptographic hardware. If you’ve designed and built hardware, the fact that the timing of calculations or the power consumed during calculations depends on the exact bits being processed is fairly obvious.

Today, however, the typical person who works in information security has a background in computer science. This means that they probably know a fair amount designing and writing software, but it also means that they probably don’t know much about hardware. And because they don’t know much about hardware, they’re often surprised by the properties of hardware that allow a cold boot attack to be carried out. It’s also why side-channel attacks aren’t that widely understood these days.

This doesn’t mean that today’s information security professionals are worse or inferior to those of 20 years ago. Instead, it just means that they know different things. If you go back 20 years, you’ll find that things like buffer overflow attacks, SQL injection attacks, or cross-site scripting attacks were totally unknown, but they’re fairly widely known today. They’re probably examples of the knowledge that’s replaced the understanding of hardware that was there in the past.

Add some rigor to information security

If you read scientific papers, you’ll find that there's a fair amount of precision in the way that data is analyzed, and that there’s a generally-accepted methodology for doing the analysis. This level of rigor is almost completely absent from studies about both the threats that information security deals with and the effectiveness of security technologies that address these threats. This makes making good decisions about information security harder than it needs to be.

Consider the fact that most people have an above-average number of legs. This is true, isn’t it? Most people have two legs, but a small number have either one or zero legs, so the average number of legs per person is probably close to 1.999. This means that most people actually do have an above-average number of legs. Without additional information about the distribution of the number of legs, it’s easy to jump to incorrect conclusions or to give unnecessary weight to this statement.

Similarly, it’s easy to create meaningless statistics about security. Suppose that most businesses have only one unit of security, but a few lucky ones have two units of security, making the average level of security close to 1.001. In this case, we can say that most businesses have a below-average level of security, can’t we? We can then act shocked that so many businesses don’t take security seriously. We might even try to lobby the government to create regulations that require a higher level of security as a way to address this problem. Without a more careful analysis of the data, it’s possible to reach conclusions that don’t make much sense.

So the next time a security vendor or industry analyst quotes statistics about threats or the effectiveness of security technologies, be sure to ask them for some additional detail to make sure that they are really telling you the full story. If they tell you what an average value is, ask them what the variance or standard deviation of the value is. If they show a model that predicts something, ask them about the sensitivity analysis that they did for the model. If they can’t answer questions like those, the numbers that they’re quoting may not be very useful.

There’s not much information available about threats or the effectiveness of security technologies, but there’s no reason to accept careless or sloppy analysis of the data that is available.

Avoid large data breaches - if you can

What happens after a data breach? Is the data recovered, or does it stay lost? Do lawsuits typically follow a breach? These statistics aren't widely known, but we can find reasonable estimates for them by looking at the a database of almost 2,000 data breaches that's available at datalossdb.org.

It turns out that the lost data is only recovered about 5 percent of the time. Usually, it's never seen again.

Oddly enough, lawsuits are even rarer, and only happen about 3 percent of the time.

For larger breaches, these statistics are quite different.

For data breaches that expose 1 million records or more, the data is recovered about 18 percent of the time and lawsuits happen 68 percent of the time.

Avoid those big breaches if you can.

Why hackers hack

In his autobiography, Nobel Laureate Luis Alvarez said that he believes that one trait that a good scientist has to have is a passion for finding answers, even if there are obstacles in their way. He said that they'll ignore a "KEEP OUT" sign on a door if they really want to know what's behind it. This also seems to be a defining trait of many information security professionals, some of which are probably even motivated by a "KEEP OUT" sign to do things that they wouldn't otherwise do. This was certainly true of old-school hackers, although it may not be the case anymore.

When I worked for the government, I once had a class in how to open locks and safes. The final exam for this class included opening a four-wheel safe lock, the case of which was protected by a tamper-evident holographic seal. The seal was probably there to keep you from opening the lock to find what its combination was, although that was never explicitly stated. We were just told that we had to open the lock within four hours.

I probably wouldn't have thought to open the lock's case if the seal wasn't there, but I took the seal to be an interesting challenge (I hadn't had that particular class yet) and decided to try to beat it. This turned out to much easier than actually opening a lock by manipulation, which is actually fairly tedious once you know how to do it, and I finished by test well ahead of schedule.

I wasn't trying to finish my test faster by bypassing the tamper-evidenet seal; I did it just because it was an interesting challenge. That outlook was common in old-school hackers, who took security as a challenge and typically didn't do anything malicious once they defeated whatever security mechanisms that they came across.

Today, however, hacking is big business, and many people who do it are motivated by money instead by the intellectual challenge that bypassing security mechanisms poses. These days, instead of just looking behind the door labeled "KEEP OUT" and thinking, ah, this stairway leads to the roof, people are doing the equivalent of blowing the door to the safe and taking the money that's in it. Curiosity isn't the driver any more. Now it's just greed.

Thursday at the RSA Conference

Hackers are clever, and they’ll find a way to exploit almost anything. One example of this is how they’ve learned to use blogs to distribute spam and other malware. But for every hacker finding a new way to carry out attacks, there’s apparently a security vendor coming up with a response. At the RSA Conference this week, I saw some interesting demos of the counters that security vendors have created to the problem of hackers using blogs to help them carry out attacks.

In most cases, spam email outnumbers legitimate email by a huge margin. This seems to be true with comments that are posted to blogs also. If I go to the management console for this blog, for example, I now see over 3,400 attempts by spammers to get this blog to link their sites that claim to be selling interesting products, but are probably just trying to collect sensitive personal information. Looking through a queue of over 3,400 items just isn’t feasible, but security vendor Websense has a product that will do this for you, and in most cases, they’ll actually do this for free.

This product is Defensio, and I saw a demo of it at the RSA Conference yesterday. Websense claims to have sophisticated adaptive algorithms that let their technology adapt to the efforts of spammers to bypass their filtering. That’s not the sort of thing that’s easy to show in a demo, so I’ll have to trust that this really happens behind the scenes.

Defensio works by routing potential malicious posts through Defensio’s servers, which make a decision about whether or not the post is spam. This architecture also lets Defensio identify and react to new attacks on blogs as they’re developed and used by hackers. I seem to recall that anti-virus products worked this way at one time, but anti-virus vendors seem to have now discarded this model. It will be interesting to see if this also happens to Defensio’s technology in the future.

Unfortunately, Defensio is only available for blogs that are hosted by WordPress. This blog uses TypePad, which means that I can’t actually try it and see how well it works in practice.

In addition to blogs, it seems that newer social networking services like Twitter have already been abused by hackers. Twitter users are already receiving spam (twam?), and if you follow the Twitter user @spam, you’ll see updates on how this spam is happening, who it’s coming from, etc. You might even find it amusing that when you visit the Twitter page for the user @spam, you see the message “Hey there! spam is using Twitter.”

Maybe there’s a start-up out there right now that’s figuring out a way to keep Twitter uncluttered. I’ll have to look for this at next year’s RSA Conference.

Cloud security at the RSA Conference

Cloud computing seems to be one of the hot topics at this year’s RSA Conference, and many vendors seem to be trying to position themselves as leaders in “cloud security” in some way. I also heard several times in various presentations that cloud computing causes absolutely no additional security vulnerabilities, and that the real challenges of cloud computing are going to come from dealing with regulatory compliance issues.

It may be tricky to address data lineage (tracking data as it flows through an enterprise), data provenance (tracking the origin of data) and related issues, for example, if data is held in a cloud, yet these can be required by some regulations. These can certainly be considered parts of data integrity that information security products address, but not many vendors seemed to be looking at cloud security from that point of view. Until these issues are addressed, the data that’s suitable for being handled by cloud computing is probably limited to non-sensitive, non-regulated data - unless pro-active security measures e.g. end-to-end encryption are incorporated. Our own security SaaS solution, the Voltage Security Network, avoids data protection issues by not touching any content - simply providing keys for encrypting emails and documents.

Key management at the RSA Conference

There are lots of free copies of the latest issue of InformationWeek magazine floating around at this week's RSA Conference. I picked one of these up and looked at it because of the article that was featured on the cover: “Standards Matter.” Here's an interesting quote from this article:

If we’re not careful, standards for nascent technologies could be so splintered as to be worse than none at all.

This reminded me that the first meeting of the OASIS Key Management Interoperability Protocol (KMIP) Technical Committee is going to be this Friday. KMIP is probably the best example that you can think of for splintering standards that might turn out to be worse than none at all. The IEEE Security in Storage Working Group (SISWG) is already well underway with the P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data. The most recent project plan that I’ve seen for this standard shows it being completed late this year. SISWG plans to define two versions of its key management protocol in the P1619.3 standard: one that’s XML-based and another that’s TLV-based.

Oddly enough, an XML version and a TLV version also seems to be the plan for KMIP, which certainly should make you wonder exactly why KMIP is really needed. I seem to recall that the whole point of developing a standard for key management was to ensure interoperability between products from different vendors, and having two different standards for the same thing seems like the worst possible way to do this.

It certainly looks like IBM is responsible for the splintering into multiple and non-interoperable key management standards that the InformationWeek article talks about. They’re really the one behind the KMIP effort, even though they’re also involved in SISWG. It would be interesting to hear what their reason for essentially killing the possibility of interoperable key management was. Didn’t they like the direction that P1619.3 was moving in? If that’s the case, why didn’t they just speak up and make their opinion known? And do they really think that having two non-interoperable key management standards benefits anyone?

These questions shouldn't just be on a security vendor's blog; they're the sorts of questions that IBM's customers should be asking them. Maybe IBM has a good reason for starting KMIP, even though there seems to be a standard well underway that solves the same problem that KMIP does. If that's the case, then they certainly deserve support from those who will benefit from KMIP, which includes many security vendors and their customers. If they don't have a compelling reason, however, their customers should clearly explain to them that they want interoperable key management that they can use enterprise wide, and that the vendor community should act accordingly.

Another part of the InformationWeek article that caught my eye was this:

Technology must be developed and deployed with live customers before functionality can be standardized.

This is also relevant to the development of key management standards. Many vendors have shipping key management products. As I mentioned in an earlier post, the recent Burton Group report on enterprise key management seemed to indicate that only a few vendors (Voltage, RSA/EMC, nCipher, NetApp and SafeNet) have much experience in developing key management products that do much more than manage keys for their other products.

If this assessment is right, you might wonder how useful IBM’s thoughts on how to do key management will be. Their approach may be great for managing keys that IBM products need, but they may not be as useful for a general-purpose key management standard. It will be interesting to follow the development of KMIP to see if this turns out to be true or not.

ESPP at the RSA Conference

At the RSA Conference yesterday, I attended the Experienced Professional Program (ESPP). To attend this event, you nominally had to be invited by the Program Committee. I suspect that their criteria weren’t really that strict. If you had 10 years or more experience in the information security industry and signed up for the RSA Conference (even for just the expo), you were probably automatically invited.

I found one of the ESPP presentations particularly interesting. This was “The Ghosts of Security Past, Present, and Future.” The title of this talk tells about as much about its contents as the titles of some of my blog posts do (not much at all), but it was interesting nevertheless.

This talk could be summed up by the catch-phrase “there is nothing worse than a well enforced bad rule.” The Digital Millennium Copyright Act (DMCA) was used as an example of this, and there was lots of discussion that suggested that the Rockefeller-Snowe bill that’s now being considered by the Senate could be another example of it if it ever becomes law.

The problem with the DMCA is that it makes it very difficult to discuss any security vulnerabilities that you might find. If you find a security vulnerability, the responsible way to handle it usually considered to have two steps. First, you notify the vendor that makes the vulnerable product. After the vendor has a reasonable chance to patch it, you then publish your results. According to the lawyers that were on the panel for this discussion, this can get you in legal trouble.

If you do this, you might be threatened with legal action under the DMCA to keep any information about the vulnerability from being published. Instead of informing the vendor, the lawyers recommended that the first step after finding a security vulnerability is to talk to a lawyer about how to handle what you’ve learned in a way that will keep you out of court.

I had to wonder exactly what kind of advice you’d get from a lawyer if you actually did this. In my experience, lawyers tend to mention even very slight risks, sort of like a doctor telling you than any medical procedure could end in your death. That’s why you can get exchanges like this:

You: Should we go out for lunch today?

Laywer: You should be aware of the risks that can accompany going out for lunch. You could be involved in an accident that results in your death, the death of one or more of your coworkers, or of the driver or passengers of another vehicle.

You: Are you saying that we shouldn’t go out for lunch?

Lawyer: I can’t advise you on how to make that decision. I can only advise you of the possible consequences if you do.

It was interesting that Microsoft was mentioned more than once in this discussion as being an example of a company that tries to handle security vulnerabilities in their products in a reasonable way. Microsoft seems to be more interested in fixing security problems in their products, while other vendors may be more interested in threatening legal action against security researchers.

The authors of the DMCA may of may or may not have envisioned their legislation being used to threaten security researchers, but that’s apparently where it has ended up. The Rockefeller-Snowe bill also has the potential to have repercussions from unexpected consequences. The panelists claimed that this bill will effectively nationalize information security, making every computer in the US one of “national interest” that’s then covered by federal regulations. All panelists thought that this was an extremely bad idea.

The ESPP Program Committee plans to produce a “call to action” document, get feedback from the attendees at yesterday’s session, and then publish the document. This should happen in the next four months or so. This might be interesting to read when it comes out.