Superconductor

HR 2221 - the DATA Act

The House of Representatives passed HR 2221, the Data Accountability and Trust Act, last month, a bill that tries to set up a nation-wide, common way to handle data breaches. I really don't like the way the US government feels the need to make almost-clever names for laws that also create related acronyms (CAN-SPAM, DATA, etc.), but that doesn't make the content of HR 2221 any less interesting.

Here's how the House summarizes this bill:

Data Accountability and Trust Act - Requires the Federal Trade Commission ( FTC) to promulgate regulations requiring each person engaged in interstate commerce that owns or possesses electronic data containing personal information to establish security policies and procedures.

Authorizes the FTC to require a standard method or methods for destroying obsolete nonelectronic data.

Requires information brokers to submit their security policies to the FTC in conjunction with a security breach notification or on FTC request.

Requires the FTC to conduct or require an audit of security practices when information brokers are required to provide notification of such a breach.

Authorizes additional audits after a breach.

Requires information brokers to:

(1) establish procedures to verify the accuracy of information that identifies individuals;

(2) provide to individuals whose personal information it maintains a means to review it;

(3) place notice on the Internet instructing individuals how to request access to such information; and

(4) correct inaccurate information. Directs the FTC to require information brokers to establish measures which facilitate the auditing or retracing of access to, or transmissions of, electronic data containing personal information. Prohibits information brokers from obtaining or disclosing personal information by false pretenses (pretexting). Prescribes procedures for notification to the FTC and affected individuals of information security breaches.

Sets forth special notification requirements for breaches:

(1) by contractors who maintain or process electronic data containing personal information;

(2) involving telecommunications and computer services; and

(3) of health information.

Preempts state information security laws.

You can find the full text of the bill here.

Similar bills (HR 958, HR 3997, and HR 4127) have been introduced before, but none made it out of the House before this one.

There's a similar bill making its way through the Senate – S 1490, the Personal Data Privacy Act of 2009. Previous efforts in the Senate (S 495, S 1332 and S 1789) didn't go anywhere. It will be interesting to see how the House's attempt at addressing the problem of data breaches is received by the Senate.

A Bayesian approach to understanding data breaches

A new report from Javelin Research, Data Breach Notifications: Victims Face Four Times Higher Risk of Fraud, has some interesting information in it. In particular, it says that 11 percent of American consumers received a data breach notification letter in the past year. Of the people who received these letters, 19.5 percent claimed to have been victims of identity theft in the same period, while only 4.3 percent of those who didn't receive such a letter were victims.

Any time I see data like this, the first thing I do is try to apply Bayes' theorem to it. Here's what I get when I do that.

Let T represent the event that a person suffers identity theft and N be the event that a person receives a breach notification letter. If my interpretation of Javelin's data is correct, this means that we're given that

 P(T|N) = 0.195

P(T|not N) = 0.43

P(N) = 0.11

and

P(not N) = 0.89

From the data that the Department of Justice has, it looks like

P(T) = 0.0275

Using Bayes' theorem we have that

P(not N|T) = P(T|not N) P(not N) / P(T)

= (0.43) (0.89) / 0.0275

= 0.22

In other words, if you're a victim of identity theft, there's probably about a 22 percent chance that you won't have received a breach notification letter. On the other hand, that also means that there's about a 78 percent chance that you will have received a breach notification letter. I'll bet that number's higher than it was a few years ago.

The HITECH act and compliance trends

The Health Information Technology for Economic and Clinical Health (HITECH) Act that recently went into effect has provisions that encourage, but don't require, covered entities to encrypt PHI. The Interim Final Rule (45 CFR Parts 160 and 164) that implements part of the HITECH Act requires notification of the unauthorized use or disclosure of unencrypted PHI that "poses a significant risk of financial, reputational, or other harm" to an individual.

Some conspiracy theorists seem to believe that this wording was included to allow businesses to avoid the high costs of breach notifications by arguing that their analysis shows that their breach didn't cause a significant risk of harm. A more reasonable explanation is that similar language dates back as far at the original Privacy Act of 1974, and is already included in the existing state breach notification laws.

But if the breach notification requirements of the HITECH Act aren't there to let businesses freely violate our privacy while giving us the illusion of it being protected, why are they there?

The breach notification requirements of the HITECH Act are probably best understood as part of a trend that's slowly but surely increasing the protection that sensitive data needs to have. This started with laws and regulations that required organizations to protect sensitive information, although the exact way in which they protect it is typically very flexible. It then moves to requiring notification of breaches of unencrypted sensitive information. At this point, encryption still isn't required, but there's a strong incentive to use it to avoid expensive breach disclosures. The next step is to require organizations to encrypt sensitive information.

The HIPAA Privacy Rule was the first step in this process for PHI. It required health care organizations to protect PHI, although they could implement this protection in many ways. The HITECH Act is the next step. It essentially requires the notification of breaches of PHI that isn't encrypted. In the future, we will probably see a federal law that actually requires the encryption of PHI. This has already happened in some states.

In 2008, Nevada law (NRS 597.970) required the encryption of Nevada residents' sensitive information when it's transmitted outside a business' secure network. The Massachusetts encryption law (201 CMR 17.00) did the same for Massachusetts residents a short while later. Legislators are now considering similar laws in other states, and similar data encryption laws will probably become widespread over the next several years. It's now hard to avoid complying with these state laws, and it's going to get even harder in the future.

How to comply with these laws in a reasonable way is still an unsolved problem. Legislators want businesses to protect sensitive information, but not at cost that's too high to be practical for a business that needs to be profitable to survive.

Encryption is notoriously hard and expensive to use, but a combination of newer technologies and motivated IT departments is leading to solutions that are much more practical than they were a few years ago. Technologies like identity-based encryption, for example, are at least a factor of three less expensive to own and operate than the aging PKI technology that dates back to the dot-com boom. That's often enough of a difference to make encryption practical where it once wasn't.

Once the states find what works and what doesn't, it's likely that the federal government will raise the bar and require the encryption of all PHI, and when they do this, they will probably base exactly what they require on the lessons that the states have learned. Let's hope that this happens soon.

There has been lots of media coverage of the recent data breaches that have exposed millions of credit card numbers to hackers. But while it's relatively easy to cancel a compromised credit card and get a new one, it's not really practical to cancel and get a new medical history. Once it's compromised, it's compromised forever. Because of this, PHI deserves to have strong protection, and encrypting PHI is the best way to do this. The breach notification requirements of the HITECH Act only encourage encryption, but they're a good step towards ensuring that PHI gets the protection that it deserves.

Identity theft and the Fair Credit Reporting Act

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

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

He then says

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

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

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

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

Records, Computers and the Rights of Citizens

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

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

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

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

More on visualizing data breaches

How much do big data breaches contribute to the overall number of records exposed? This picture, which is based on the breaches in the OSF's database since the beginning of 2006 might give an idea of how important the contributions of the big ones are. The area of each circle is proportional to the number of records exposed in each breach. Can you find your favorite data breaches here?

 

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.

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.

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.

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?

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.

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.

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.

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?

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.

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.

News from Maine

Yesterday, the Portland Press Herald reported how a federal judge has decided to look at the question of whether or not the Hannaford Brothers supermarker is liable for damages from the data breach that they suffered between December 7, 2007 and March 10, 2008.

This breach disclosed the personal information ofabout 4 million people and resulted in about 1,800 fraudulent charges to credit cards, none of which were passed on to consumers. This case may set some interesting precedents about exactly how responsible merchants are for protecting credit card data and what the consequences are if that data is stolen.

Hannaford is claiming that damages are inappropriate because its customers didn't actually suffer any financial damage and that all they suffered was some slight inconvenience. If the judge rules that the lack of financial damages is enough to greatly limit Hannaford's liability, that could have a dramatic effect on how legal actions from future data breaches can proceed.  

The transcript of yesterday's House hearing

FYI - the transcript and video of yesterday's hearing in the House of Representatives' Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology that tried to answer the question “Do the Payment Card Industry Data Standards Reduce Cybercrime?” is now available.

Does the PCI DSS reduce crime?

Today I listened to the podcast of the hearing before the House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology on the topic of “Do the Payment Card Industry Data Standards Reduce Cybercrime?”

Lots of the testimony was very predictable.

• The PCI SSC stuck to their position that no PCI DSS compliant organization has ever suffered a data breach, and dodged questions about exactly how much feedback on the standard from banks and merchants they’ve actually listened to.

• Visa stuck to their position that lots of issues with the PCI DSS aren’t their problem because they’re really issues between merchants and acquiring banks.

• Retailers complained about the cost of complying with the PCI DSS. They also want increased security in the form of smart cards, and they want the credit card brands to pay for it.

• The PCI SSC and Visa dodged the question about metrics that indicate success or failure of the PCI DSS by saying that’s information that acquiring banks need to track.

To her credit, the Chair of the Subcommittee, Yvette D. Clarke (D-NY), did seem concerned that the costs of complying with the PCI DSS are significant yet there is no data available that shows that the PCI DSS is actually having any measurable benefits. Acquiring banks have that information. They should probably be more forthcoming with it.

The best place to encrypt data

The best source of information about data breaches is probably the database maintained by the Open Security Foundation. This information shows that there are three sources of data breaches that are much more common than all the others. Based on the fraction of breaches that are due to each source, here are the big three:

Source	Fraction of breaches
Stolen laptop	21%
Hack	17%
Web	14%

Based on this information you might think that encrypting your laptops is the most important thing to do. On the other hand, looking at the number of records compromised gives a much different picture.

Here's how the big three compare based on that metric:

Source	Fraction of records lost
Stolen laptop	3%
Hack	45%
Web	1%

That looks much different, doesn't it?

From that point of view, laptops aren't your biggest concern. Instead, getting hacked is. If you encrypt your laptops, you'll be protecting against a loss of less that 3 percent of all the records that data breaches compromise. Protecting your data so that it's not useful to a hacker is probably a better use of your limited security budget, and you can do that by encrypting the data in a persistent way so that the encryption stays with the data. That may not protect against the biggest number of data breaches, but it looks like it will protect against the worst losses.

It's legal in Florida

The term 'corpus delicti' is technical, and means the body of the crime, or the substantial fact that a crime has been committed.

Melville Davidson Post, The Strange Schemes of Randolph Mason

Even though the RIAA’s ad campaigns say it is, copying your friends’ music CDs isn’t theft. That doesn’t mean it isn’t illegal. If you copy a CD you may be committing a crime, but that crime isn’t theft. One important element of the corpus delicti for theft is that property is lost by the owner, and this clearly isn’t the case for copying music. If you copy a CD, the owner of the music doesn’t lose their property, so you haven’t committed theft. What you’ve done is violate copyright law.

So suppose that a business dumps lots of documents containing sensitive personal information in their dumpster. Have they committed a crime or not, and if it’s a crime, exactly what law did they break?

In Sarasota, Florida, for example, a company recently dumped lots of documents containing sensitive information including Social Security numbers and driver's license numbers into their trash. Workers at a nearby business noticed this and called the police, but when the police arrived, they found that no actual crime had been committed. Apparently disposing of sensitive information in a way that makes it easy for it to be compromised isn’t actually against the law in Florida.

What's even stranger about this incident, is that it has been established that there's no reasonable expectation of privacy when things are left in the trash. That's what California v. Greenwood established in 1988. So it's apparently legal to dump sensitive information in a place where there's no expectation that it will stay private. At least it is in Florida.

PCI DSS needs to be stricter

Complying with PCI DSS is a good first step towards protecting credit card numbers from the cyber-criminals who steal them and resell them to other cyber-criminals. On the other hand, the large and high-profile data breaches that we've seen in the past few years show that what the PCI DSS doesn't actually do is to actually provide any reasonable assurance that credit card numbers won't be stolen. Because there's a significant gap between complying with the PCI DSS and real security, the PCI DSS may actually end up protecting businesses who just worry about complying with the standard instead of using more meaningful security. Here's why.

Negligence is the failure to use reasonable care. If you don't meet an appropriate standard for care then you're negligent, and you’re liable for any damages that you might cause. If you do meet the standard of care then your unlucky victim bears the full cost of his injuries. As a general rule, government regulations can be used to establish a standard for reasonable care. So if you're in compliance with government regulations then you can argue that you're using reasonable care and you're not liable for injuries that you might accidentally cause. This is true for government regulations, but it wouldn't be too surprising if other regulations might also work this way. In particular, because there's no government standard for protection of credit card information, it wouldn't be too surprising if you could successfully argue that the PCI DSS establishes a standard for reasonable care.

This means that it's not hard to imagine a case where a company that's suffered a data breach but has also passed their PCI DSS audit can argue that they've used reasonable care with the credit card numbers that they lost. Suppose that they can also show that they've passed other audits. Maybe their data center has passed a Type 2 SAS 70 audit and they have an ISO 27002 Certificate of Compliance. In this case, it's probably even easier for them to convince a judge or jury that they've used reasonable care. The problem is, of course, is that there may not actually be a connection between passing these audits and having strong and meaningful security. But if they can make a convincing case that they've used reasonable care, they may be off the hook, even if their security is weak enough to allow hackers to easily bypass it.

In the case of PCI DSS, there doesn't seem to be much of a connection between being compliant with the PCI DSS and having strong security. Could this end up actually protecting companies that focus just on compliance instead of trying to actually protect their sensitive data against hackers?

Sources of identity theft

Despite the hefty blame – largely perpetuated by the media – placed on the Internet and cyber-crime, online identity theft methods (phishing, hacking and malware) only accounted for 11% of fraud cases in 2008.

Javelin Strategy & Research, 2009 Identity Fraud Survey Report: Consumer Version

Millions of credit card numbers are routinely lost to cyber-criminals from the data breaches that are becoming more and more common. There's even a thriving underground economy in the credit card numbers that are compromised by these data breaches. But what are cyber-criminals doing with these credit card numbers? They must be using them in some profitable way, or they wouldn't be willing to pay for them. A recent report by Javelin Strategy & Research, their 2009 Identity Fraud Survey Report: Consumer Version, has some data that's hard to reconcile with this.

Javelin's survey suggests that most victims of identity theft have their identity stolen in ways that don't cyber-criminals don't use. The results of their survey is shown below. Curiously, their survey shows that the most common way for identity theft to happen is through lost or stolen wallet with data breaches in a distant fourth place.

 

So how do we find a way to believe both that millions of credit card numbers are being lost in data breaches and that these credit card numbers only account for a small fraction of identity theft? I'd guess that the stolen credit card numbers are being used and people don't even know it. If that's true, that's even more disturbing that the fact that the credit card numbers are being stolen.

Another big data breach?

It looks like there has been another data breach at a large credit card processing operation. The details haven’t been made public yet, but it’s already being discussed on web sites that track data breaches. As soon as the forensics experts finish collecting the evidence that they need, there will probably be a public announcement that describes exactly what happened. We’ll probably find that the operation that has hacked has passed their PCI DSS audit yet was still vulnerable to hackers. This shouldn’t be too surprising to anyone by now. It probably shouldn’t even be considered newsworthy any more.

As I’ve mentioned before, there are good reasons to require any business that handles credit card transactions to be PCI DSS compliant. Credit card numbers are the main target of the determined cyber-criminals that are part of the multi-million dollar underground economy in sensitive information. The number of stolen credit card numbers outnumbers other sensitive information that’s traded by cyber-criminals by roughly a factor of 20 to 1, so they’re much more popular than even information like ATM PINs or bank account numbers.

Even though many politicians seem painfully oblivious to it, the law of supply and demand affects all markets, even those in stolen sensitive information: as the number of credit card numbers stolen in data breaches has increased dramatically over the past few years, the value of each stolen credit card number has dropped just as dramatically. This means that cyber-criminals now need to get millions of credit card numbers from a single hacking operation to justify the risk and the expense of such an operation. This seems to have led them to target credit card processing operations instead of merchants, and they’ve apparently been fairly successful at this, despite the increased level of security that the PCI DSS have required. This is probably because the evolution of the PCI DSS wasn’t designed to keep up with the current threat.

The first version of the PCI DSS didn’t require much more than what are considered best practices for information security. The subsequent versions increased the level of security required, and future versions will probably increase it even more. This has been a gradual and incremental process, and it clearly hasn’t kept up with the threat that professional cyber-criminals pose. As long as this process stays gradual and incremental, it seems likely that the cyber-criminals will be able to stay ahead of the security that PCI DSS compliance requires. What’s probably needed is a bigger step forward in security, and the combination of encryption and key management is probably the way to make that step.

The current version of the PCI DSS requires encryption of sensitive cardholder information, but it doesn’t require particularly strong key management processes, even though strong encryption and key management provide the basis for protecting sensitive information against even the most determined cyber-criminals. That’s how national governments protect their diplomatic and military secrets, after all. It seems to have worked fairly well for them, and there’s no reason to believe that the same model can’t also be applied to protecting other types of sensitive information. Any other way seems to be too weak to stop determined adversaries.

If the PCI Security Standards Council is serious about protecting sensitive cardholder information, and there’s no reason to believe that they’re not, we’ll probably see strong encryption and key management required in future versions of the PCI DSS. Until then, we’ll probably see more of the large-scale data breaches that have been in the news recently.

It's like brewing beer

Several years ago I used to brew beer. If you've never done this, you let the beer ferment in a glass container called a carboy that's topped by a fermentation lock. A fermentation lock is a clever device that lets the carbon dioxide from the fermenting beer escape but doesn't let the outside air get in and contaminate your beer.

Once I noticed that the fermentation lock on a batch of fermenting beer had become clogged, so I took it off to clean it. This caused a dramatic reaction. Imagine shaking a five-gallon bottle of beer and then opening it. That's pretty much what happened. But because a five-gallon container is much bigger than a 12-ounce beer this didn't happen right away. Instead, I got to watch the bubbles streaming up from the bottom of the carboy for a second or two, fully knowing that there was no possible way to stop them and that they would almost certainly make the biggest mess that I'd ever seen once they made good their escape from the carboy. Fortunately, my wife was in Japan on business for a few weeks, so I had plenty of time to clean up the spill that resulted from this incident.

Every now and then I'm reminded of the mess that this particular incident caused. There's no clear analogy to popping off the fermentation lock, but the unstoppable flow of fermenting beer and the mess it made often reminds me of the huge amounts of sensitive information that's routinely revealed in data breaches and the high costs of cleaning up after the breaches. I was lucky enough to have a few weeks to clean up after the mess that I made. Few companies are as lucky with data breaches.

Not really a trillion

I’ve commented before on the lack of accurate data for information security threats. It certainly looks like you really can’t trust vendors to give you accurate and unbiased data, and the latest news from McAfee’s blog is probably an example of this.

McAfee estimates that lost data cost the world’s economy a trillion dollars last year. Unless it’s the U.S. government talking about how much they’re going to spend, you should probably be suspicious of the accuracy of any number that large. I certainly was. Puzzled by this number, I found a copy of the McAfee report, Unsecured Economies – A Trillion Dollar Headwind, that this blog cites.

I wasn’t terribly surprised when the $1 trillion number didn’t actually appear in this report. The report does estimate that the average company lost $4.6 million in data last year. I have to assume that someone just estimated the number of businesses in the world and multiplied it by $4.6 million to get the astounding $1 trillion estimate.

I don’t believe this estimate at all. Part of my skepticism is due to the fact that it’s so much larger than other estimates. The fact that it’s from a security vendor who wants to sell you products and services that can reduce the amount of data that you lose doesn’t help, either.

The 2008 CSI Computer Crime & Security Survey gives a much lower estimate for the value of lost data, for example. And in the several years that this survey has been done, it hasn’t even come close to the McAfee estimates. The 2008 estimate was $288,618, which was down from the $345,005 estimate in 2007. Two years ago, the estimate was $167,713. None of these are close to $4.6 million.

And without estimates of exactly how much information is out there, it’s hard to put estimates of information loss into a useful context. The November 2008 issue of Johns Hopkins Magazine had a feature about the high cost of health care in the U.S. and how to control it. They mention that uninsured people and others who can’t pay their bills cost the U.S. health care system about $30 billion per year. That certainly sounds like a lot of money, but when you consider that it’s only 1.4 percent of the total $2.1 trillion that’s spent on health care in the U.S. every year, it sounds much less important.

So let’s suppose for a moment that McAfee’s estimate of $1 trillion in loss is actually accurate. Does that $1 trillion represent 20 percent of the total value of information, or is it only 0.1 percent of the total value of the information? Without knowing that, the $1 trillion number isn’t really of much value.

Is compliance a cost?

There's a post on McAfee's web site that answers the question "Is information security compliance really a cost center?" like this:

No. Absolutely and unequivocally not. I am drawing the line in the sand. Business leaders need to understand there is no more need for proper security to justify itself over and over again. It saves you time and money (period).

Properly implemented information security provides business process improvement, technology improvement and threat reduction. Compliance controls that cover each of these areas to accepted “best practices” will save your organization money by the truckload and provide for expansion of your business tenfold if not more.

Far too often businesses require “measurable” savings when the cost reductions and business enablement is as obvious as a freight train hitting you while you are siting on the tracks. Below I will detail a simple walk-through of a compliance driven organization versus a non-compliant organization which makes it obvious that it is better and more efficient to be compliant as a business.

In most situations, the term "compliance" means regulatory compliance, or being compliant with data security and privacy laws and regulations. If this is how we interpret "compliance," then compliance is definitely a cost center, at least in many cases. Here's why.

Businesses tend to make investment decisions that maximize the benefits that they receive from the investments. They might be maximizing profit, or something else like market share. This means that when they decide to use a particular security technology, there's probably a good reason for doing so. It also means that when they decide not to use certain security technologies, there's probably a reason for that also. This means that you'll almost never hear discussions like the following:

CSO: We should encrypt the hard drives on our laptops. Our model shows a 60 percent ROI over a three-year period for the total cost of deploying and supporting full-disk encryption software.

CFO: Bah! I don't care about ROI arguments. Instead, we should wait for the government to mandate that we use that technology.

So it's reasonable to assume that investments that are made purely as a requirement for regulatory compliance are ones that wouldn't have been made on the basis of the value of the investment alone. This means that they don't make sense from a business point of view, and that mandating them forces businesses to make investments that they really shouldn't make.

Passing data security and privacy laws may force some security spending, but it's probably at the cost of other security projects that deserved to be funded instead. This means that the net result of data security and privacy laws may be just to reallocate spending from projects that had a good justification to ones whose only justification is to become regulatory compliant. That's probably not a good idea.

There are cases where it makes sense to do some of the things that are also required by regulatory compliance. Data breaches can be extremely expensive, for example, so it's often the case that there's a valid business case for using encryption. This means that there's a strong business case for using persistent encryption of sensitve information. There's also a strong business case for using encrypted email.

If you're really curious about the details of these business cases and don't mind slogging through some detailed risk models, you can take a look at Kevin Soo Hoo's doctoral dissertation "How Much Is Enough? A Risk-Management Approach to Computer Security." He did a careful analysis of the cost-benefit analysis of several information security technologies and found that the case for encryption is strong. The business case for encryption is still valid in the absence of the need for compliance. Other security technologies aren't as lucky.

Compliance may not always be a cost center, but in many cases it is.

The need for persistent encryption

The recent data breach at credit card processor Heartland Payment Systems may be the biggest ever, and it happened even though Heartland passed the PCI DSS security audit that credit card companies require. Heartland fell victim to a well-organized attack by cyber-criminals. These are adversaries that are part of the huge underground economy that obtains sensitive information and sells it for a profit. They're both determined and well funded.

It certainly looks like traditional security mechanisms aren't able to defeat such attackers. New approaches are needed, and the businesses that handle sensitive information that's valuable to cyber-criminals need to ensure that security vendors develop technologies and products that meet their needs. This isn't happening yet.

Encryption is probably the best way to protect against data breaches. If a cyber-criminal manages to get encrypted data but not the key used to encrypt it, the data is useless to him. If this is the case, then cyber-criminals won't be able to run profitable businesses that steal and resell sensitive information, and they'll have to look for another line of work. Unfortunately, the encryption products that are commonly used today don't provide enough protection for data. They provide good protection for it in some situations, but not in all situations.

In many cases, sensitive information was encrypted while it was stored in a database, but it loses this protection when it leaves the database. That can leave the door open to an attack that can compromise millions of credit card numbers. Almost all uses of encryption work similarly, providing protection in some situations but not others. This means that they don't stop cyber-criminals. Instead, they just limit the number of places where they can carry out their attacks. As long as there is a single place where the data is vulnerable, cyber-criminals will find it and exploit it.

Persistent encryption: protection by default

The best way to stop cyber-criminals is probably to encrypt data in a way that the data always stays encrypted until it's needed by business logic. You might call this "persistent encryption," or "protection be default," and it's a fundamentally different approach to information security than what's used today.

In today's IT environments, data is only encrypted if an application explicitly encrypts it. If no application encrypts data, it's in the clear where it's vulnerable. You might say that data is unprotected by default.

An alternative to this model is to have all sensitive data encrypted, and to only decrypt the data when it's needed by authorized business logic. You might say that data is protected by default in this situation. If data is protected by default with persistent encryption, then it's much tougher for cyber-criminals to get it. No matter where they manage to collect the data, it's going to be encrypted, and there's now no place at all where the data is vulnerable.

If you're using persistent encryption, you can copy sensitive data to your laptop and not worry about it being compromised if your laptop is lost or stolen. You can also copy the sensitive data to a USB drive or CD-ROM and not worry about the data being compromised if the drive or disk is lost or stolen. In each of these cases, because there's no authorized business logic that's decrypting the data, the data stays encrypted. This means that it's useless to an unauthorized user who might get it, either by accident or other means. Persistent encryption keeps it safe all the time.

Unfortunately, security vendors have been slow to create products that provide persistent encryption. This means that it's up to their customers to demand it. Software vendors finally took security vulnerabilities in their products seriously when their customers demanded security audits of their products as a condition of buying them. The result of this has been software that isn't vulnerable to some attacks that were once common. It seems likely that security vendors will be similarly reluctant to develop the tools that let enterprises implement persistent encryption. If you could benefit from this technology, let your security vendors know, and the rest will probably take care of itself.

Was Scott McNealy right?

"You have zero privacy anyway. Get over it."

Scott McNealy

Scott McNealy made his famous comment about privacy in the digital age at an event launching Sun Microsystems's Jini technology back in January 25, 1999. His comment immediately drew angry comments from privacy advocates. Some claimed that they were "astonished" that he could say that we don’t have privacy any more. Others called his comment "irresponsible." It's probably more telling, however, that nobody actually said that he was wrong. Perhaps they knew better. Today is Data Privacy Day, so it might be a good day to think about this.

Privacy may be an admirable goal, but it's not clear that people really want it. People claim that they want privacy, but their behavior doesn't always support this claim. People may say that they want to keep their shopping habits private, but will shop at on-line retailers that keep a record every click of the mouse they make and every web page they view.

On the bright side, it's not clear that the companies who get our private information actually do much with it. On-line giant Amazon.com has been logging everything that I do on their web site for several years now, and still feels compelled to recommend things that aren't even remotely related to anything that I've ever bought from them or would ever consider buying from them. Sometimes their recommendations can almost be entertaining. Almost all of what I've bought from Amazon.com over the past several years has been books, electronics or software. Despite this history, they still feel the need to recommend that I look at women's underwear on a fairly regular basis, and the fact that they continue to recommend it after I still haven't looked at or purchased any of the underwear that they've recommended makes me wonder exactly how well they're using all of that data that they've collected.

The real and serious threat to privacy is probably from the underground economy of cyber-criminals who steal huge amounts of personal information and resell it to other criminals who then use it to commit all sorts of fraud. Based on interviews with McNealy after his controversial comment on privacy, it certainly looks like he was thinking about the case that Amazon.com represents. In this case, he's probably right. You really don't have any privacy when you do on-line shopping, but there's probably not much harm that results from that particular loss of privacy. The convenience that you gain and money that you save from shopping on-line probably makes up for the privacy that you give up to do it.

Back in 1999, however, cyber-criminals weren't as numerous or as well organized as they are today, so it's unlikely that McNealy was thinking about the threat that they represent. The data that cyber-criminals are after is the data that they can make money from. Today, that limits the valuable data to things like credit card numbers, bank account numbers, and ATM PINs. There's a huge market in this type of information, and there's so much of this information available that the law of supply and demand has dramatically reduced its value to cyber-criminals. Data that might have been worth $20 to them a few years ago can now be worth as little as $1. And because cyber-criminals are determined and well equipped adversaries, they seem to succeed fairly often. The recent data breach at Heartland Payment Systems is just the latest example of this.

Because the financial fraud that results from the misuse of the data that's compromised in data breaches is now a real a significant cost to the financial services industry, it's now worth taking privacy seriously. In the past, the worst that you might suffer from your privacy being compromised was being shown recommendations for products that you had absolutely no interest in. Today, the stakes are much higher. So although McNealy's comment about getting over the lack of privacy might have made sense in 1999, ten years later, it probably doesn't. Instead of just accepting that fact that it has been hard to keep any significant level of privacy on-line, it's now time for businesses that handle sensitive data to get serious about protecting it. That won't be cheap or easy, but it's a step that they need to take.

Why PCI DSS?

It's probably no secret to anyone reading this that the information security requirements for anyone handling credit cards have been increased dramatically recently. These requirements are reflected in the Payment Card Industry Data Security Standard (PCI DSS). As you'd expect, there's been a fair amount of grumbling by the merchants who are the most affected by the new standards. This is to be expected, of course. Nobody wants to spend money on information security that they don't need. So one question to ask is whether or not the PCI DSS is really needed. A look at the market for stolen or compromised sensitive information seems to show that PCI DSS is badly needed and may not even be enough.

One of the best studies on the underground economy of stolen or compromised sensitive information is probably the one done by Jason Franklin, Vern Paxson, Adrian Perrig and Stefan Savage. Their paper that describes their research and what they learned is "An Inquiry into the Nature and Causes of the Wealth of Internet Miscreants." You can find a copy of it here. It's well worth the time and effort that it takes to read. One graph from this paper shows the most common types of data that were advertised as being for sale by cyber-criminals. Here's what that graph looks like. 

     

This graph seems to show that credit card information is widely available. It's more available than Social Security numbers or ATM PINs by a factor of roughly 20 to 1. This means that it's probably the case that credit card information needs to be protected much more than it's being protected now.

The PCI DSS is probably a good first step in this direction, but even complying with the latest version of the PCI DSS isn't enough to guarantee that credit card information won't be lost or stolen, as the recent data breach at Heartland Payment Systems shows. Heartland passed their PCI DSS audit, but hackers still managed to penetrate their system and compromise millions of credit card numbers.

What they aren't saying

The big data breach at Heartland Payment Systems was announced two days ago, and Heartland quickly set up a web site to announce the breach. Here's the headline from the web site:

Heartland Payment Systems Uncovers
Malicious Software In Its Processing System

No merchant information or cardholder Social Security numbers compromised.

If you read further, you find this:

No merchant data or cardholder Social Security numbers, unencrypted personal identification numbers (PIN), addresses or telephone numbers were involved in the breach. Nor were any of Heartland's check management systems; Canadian, payroll, campus solutions or micropayments operations; Give Something Back Network; or the recently acquired Network Services and Chockstone processing platforms.

That certainly doesn't look too bad, does it? What they don't include in the list of information that wasn't compromised is customer's credit card numbers. So it certainly looks like credit card numbers were what the hackers were after and were also what the hackers got. Why not be clearer about this? Why not replace the headline on the we site with this one?

Heartland Payment Systems Uncovers
Malicious Software In Its Processing System

Millions of credit card numbers compromised.

The truth is going to come out eventually. Probably very soon. If credit card numbers were compromised, why not just admit it? Hoping that people won't read your announcement too carefully probably isn't the best way to deal with a data breach.

Largest Data Breach

It looks like Heartland Payment Systems is the latest victim of a data breach, although it might be more accurate to say that both they and their customers are the victims. In this case, hackers appear to have sniffed transactions with the Heartland system, all of which were unencrypted. Heartland's CEO has been quoted as explaining that they need to have the transaction data unencrypted to process it. Here's a summary of what's known so far:

• Heartland Payment Systems processes payroll and credit card payments for more than 250,000 businesses
• They reported that they discovered an intrusion last week that exposed consumer credit card data last year
• They were alerted to suspicious activity in processing Visa and MasterCard transactions—auditors then discovered malware that had compromised the company’s data
• Company spokesperson says they “understand that this incident may be the result of a widespread global cyber fraud operation, and we are cooperating closely with the United States Secret Service and Department of Justice"

This incident highlights the fact that achieving PCI compliance does not imply that a business has achieved real security. For example, PCI does not currently require that credit card data be encrypted as it is moved between machines on a corporate network, which is highly likely where this breach occurred. This incident should serve as a wake-up call that PCI should be used as a starting point instead of an end point in the effort to protect sensitive data.

Robust encryption technologies and innovative solutions that leverage them exist today that could have prevented this breach altogether. In fact, best-in-class businesses are currently implementing software that can address these types of attacks. However, Heartland appears to be an example of an organization which assumed that simply passing its PCI audit meant that it was truly secure.

Why were they targeted? Data can now be easily monetized, creating demand for criminal data theft, and increasingly, multi-tiered networks of organized hackers have replaced bored teenagers as the perpetrators of computer attacks. TJX, Hannaford, RBS Worldpay and now Heartland are just a few of the organizations that have fallen prey to orchestrated offensives. The perpetrators here are likely multi-tiered networks of hackers and social engineering manipulators who can gather and auction bulk data to the perpetrators of credit card fraud. This attack could potentially have been enabled or even initiated by an insider, even though Heartland says in this case it was not.

How can organizations reduce this type of risk? Most processors – even if PCI compliant – currently have, as standard practice, sections of their network where data is not encrypted or in the clear in order to communicate with the upstream clearinghouses and card companies (e.g. Visa, Mastercard, American Express). These gaps create excellent attack points for hackers, as data is fully exposed.The only solution to eliminate this threat is end-to-end encryption. New techniques such as Format-Preserving Encryption (FPE) and Identity-Based Encryption (IBE) allow organizations to encrypt information at the point of capture, and data is persistently protected all the way to the trusted clearinghouse. No air gaps, no exposure. Even if a hacker gains access to an intermediary system, no actual data can be stolen.

It's certainly true that many encryption technologies don't protect data as it moves through a network. Database encryption, for example, may protect data while it's in a database, but doesn't do anything for the data once it leaves the database. Even SSL doesn't protect data all the time. SSL may protect data while it's moving, but after it's moved, the sensitive data then typically sits on a server somewhere, where's the protection provided by SSL is gone.

Some encryption technologies, however, do indeed provide the capability to protect data no matter where it goes. Format-Preserving Encryption(FPE), the new mode of AES that's been submitted to NIST, lets you do this. Data encrypted with FPE has the very same format as unencrypted data. A 16-digit number gets encrypted to another 16-digit number, for example. If you use FPE to encrypt sensitive information, it's easy to keep the protection provided by the encryption, even as the encrypted information moves through a network.

Other ways to encrypt sensitive information may cause problems, particularly in legacy environments. In these, there's often a system somewhere that won't be able to handle encrypted information because it's format is different than the unencrypted information that it's expecting. If you encrypt a 16-digit credit card number, for example, and the encrypted credit card number may be longer than 16 characters or may be no longer just digits, This means that many legacy systems will be unable to handle encrypted information gracefully. On the other hand, if the format of the data is unchanged by encryption, then even the most complicated legacy systems will be able to easily handle it.

This is exactly what FPE does, which means that if you use FPE to protect sensitive information then there's absolutely no problem with keeping sensitive information encrypted at all times. If that's the case, all a hacker can get by sniffing a network is encrypted information, which is totally useless to him.

T.J. Hooper

T.J. Hooper (short for In re Eastern Transportation Co. (The T.J. Hooper), 60 F.2d 737 (2d Cir. 1932)), is a legal ruling that may have interesting implications in future legal battles that result from data breaches. In this case, Judge Learned Hand established the precedent that prevailing practice is not a valid way to avoid liability.

When two barges sank and their cargoes were lost in heavy weather, the owners of the lost barges and their cargoes claimed that their loss was caused by negligence on the part of operator of the tugboats. Their claim was that if radios that could receive weather reports had been installed on the tugboats then their losses would have been avoided when the tugboat operators were warned of the heavy weather. Because the tugboats did not have radios installed, this meant that the owner of the tugboats was negligent for not using them.

The owner of the tugboats claimed that they couldn't be expected to have radios installed because they were new technology and their use was not common. In the T.J. Hooper case, the operator of the tugboats was found negligent. This set the general precedent that the fact that technology is new and its use is uncommon does not mean that not using it is a way to avoid liability.

Today, data breaches are very common, yet the use of encryption is not very widespread. There may be good reasons for not wanting to encrypt information. Encryption has historically been difficult and expensive. This isn't the case any more, but when it was, it was a valid reason not to use encryption. Now that encryption is easy enough to use, however, the precedent of T.J. Hooper becomes relevant. Prevailing practice is not a valid way to avoid liability, and just because many other organizations aren't protecting their information with encryption doesn't mean that you shouldn't do it yourself. You can still be found negligent if that's the case. Not using encryption because there's no valid business case for it makes sense; not using it just because other people don't use it doesn't.

Do we have enough data breaches?

Do we have enough data breaches?

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

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

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

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

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

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

NRS 597.970

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

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

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

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

2. As used in this section:

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

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

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

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

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

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

UPDATE: From the WSJ - October 16th, 2008

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

Why key management?

There's lots of talk these days about key management. It certainly looks like lots of it is from vendors trying to position themselves as leaders in key management, although it's not always clear what they mean by that. So what exactly is key management and why should you care about it?

A cryptographic key is much like the combination to a safe. If you have the combination, it's easy to open a safe, but it's hard to open one without the combination. Similarly, if you have the right key, decrypting encrypted data is easy, but it's impractical without this key. But if you're careless with the combination to your safe, someone else can easily find it, and once they have it, the protection provided by the safe is compromised. Similarly, the cryptographic keys that you use to encrypt data need to be handled carefully. If you're careless with them then the protection provided by cryptography can be essentially eliminated. Key management covers all the details of how to handle keys carefully enough to ensure that this does not happen. It ensures that you don't do the cryptographic equivalent of writing the combination to your safe on a Post-it note and sticking it to the wall next to your desk.

An example of why key management is important can be seen in the recent news of ATM PINs being hacked. The news stories that covered these security breaches didn't give much detail about exactly what happened, but you can be fairly sure that the cryptography itself wasn't broken. That's just too hard to make it worth doing. On the other hand, there have been cases in the past where ATM systems have suffered security breaches, and these breaches have been caused by poor key management. That's probably what happened in the recent cases of PINs being hacked, too.

ATM systems have been hacked when key installation, generation or storage has not followed the relevant standards developed by the X9F subcommittee of the Accredited Standards Committee X9, the group that defines information security standards for the financial services industry. There have also been cases where inappropriate access to hardware security modules has made it possible for hackers to get keys that they shouldn't have been able to get. None of these is involves an attack on the cryptographic algorithms; they're all attacks that take advantage of poor key management. Keys weren’t handled carefully enough, and hackers took advantage of the careless processes.

So encryption alone isn't enough to protect sensitive data. It's part of a good solution, but it’s not the entire solution. To get a complete solution you also need good key management. It's almost always much easier for hackers to defeat key management than to defeat cryptography, so that’s probably where they'll focus their efforts. They'll attack your key management not your encryption. This means that to to protect your sensitive data you need to ensure that your key management is done carefully and securely. That's why you should care about key management.

Sutton's law

When asked by a reporter why he robbed banks, the famous bank robber Willie Sutton is said to have replied, "Because that's where the money is." It turns out that Sutton didn't really say this: a reporter looking for a noteworthy quote actually just made it up. But despite this slight inaccuracy, we still may be able to gain some useful insight into enterprise encryption strategies by applying what has become known as "Sutton's Law" to enterprise data.

Data in storage can be the biggest compliance headache because storage contains so much sensitive data. This means that a hacker can obtain more sensitive information from a single backup tape than he can from years of trying to intercept data that's being transmitted. Because of this, Willy Sutton might advise twenty-first century hackers to target storage systems, "because that's where the data is."

If this is what hackers are going to do, what's the best way to counter them?

One easy way to protect data in storage is to encrypt it. Encrypted data is no more useful to a hacker than stacks of blank paper would have been to Willie Sutton, and we would expect that Sutton would have found a different line of work if that's all he would have gained by robbing banks. He would certainly have advised hackers to focus their efforts elsewhere if they could only recover encrypted data from storage.

Data-centric security

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

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

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

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

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

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

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

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

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

Don't trust the government?

A recent report by Symantec has some interesting information about data breaches. According to this report, government organizations managed to expose more identities that all other sectors put together. Although they were responsible for only 20 percent of the total number of breaches, they were also responsible for 60 percent of the number of identities exposed.

The financial services industry was responsible for most of the remaining number of identities that were exposed. They were responsible for 14 percent of the total number of breaches and 33 percent of the total number of identities exposed.

According to this report, there are so many compromised identities available to criminals that the law of supply and demand has reduced the street value of a complete identity to as little as $1.

The financial services sector is responsible for so many lost identities because criminals can readily profit from the type information that this sector deals with. Information like account numbers and credit card numbers are valuable to criminals, and because of this they actively target this sector. So although this sector invests heavily in information security, it's also the best target for hackers. So deliberate attacks add to the number of data breaches caused by lost or stolen equipment.

The large number of identities compromised by government data breaches should not be surprising. Governments, after all, may have information about all of their citizens while commercial entities typically only have information about their customers, which may be only a small subset of the total population. So a data breach at a government organization has the potential to disclose much more sensitive information than a similar breach at a business.

In the case of governments, it's also fairly easy to understand how large expenditures on information security may not actually correlate to better security. After all, governments tend to have different criteria than other organizations when it comes to purchasing. Government budgets are the result of a political process that reflects many conflicting criteria, only one of which is to provide a high level of security. Other criteria, like buying products from local vendors, buying products from a wide range of vendors or buying from vendors with political influence, are often equally important. And the high level of risk aversion that governments almost always have means that they are often slow to adopt new technologies, even ones that can effectively address security concerns. Because of these factors, it shouldn't be too surprising that governments often perform in a less than stellar fashion when they need to deal with something that changes as rapidly as the information security threat environment does.

The performance of government organizations in protecting personal information has been so poor that it might be wise to assume that any large database of data that governments have will eventually be compromised, and it seems foolish to trust governments to keep sensitive personal information protected for long, no matter how good their intentions are. P. J. O'Rourke may have summarized this situation best when he said, "A little government and a little luck are necessary in life, but only a fool trusts either of them."

Governments may one day learn to stop the massive losses of personal information that they cause, but don’t expect it to happen any time soon.

New Cyber Crime bill passes Senate - Identity Theft Enforcement and Restitution Act

A new act - the Identity Theft Enforcement and Restitution Act of 2007 was passed by the Senate Committee on the Judiciary. Introduced by Senator Patrick Leahy, the Chair of that Committee, last October, the bill's purpose is “to enable increased federal prosecution of identity theft crimes and to allow for restitution to victims of identity theft.” This Anti-Cyber Crime act has now passed passage in the Senate and now needs action by the House to be enacted into law.

This bill will make it easier to prosecute criminals, but the onus still remains on corporations to protect sensitive data that they hold on consumers and employees. Another act - Identity Theft Red Flags - will provide the impetus to ensure that companies create pro-active identity theft protection plans that are signed off - in Sarbanes-Oxley style - by their boards.

Recently companies have begun employing a new form of cryptography - format-preserving encryption - to protect structured information like credit card numbers and social security numbers in databases and applications - the primary beneficiary of this approach is you and me - the consumers - as data that is encrypted - even if it is stolen - cannot be used to steal identities. The FPE approach is available as part of Voltage SecureData which can be deployed on average 5 times faster than other approaches - saving huge amounts of time and cost.

Fox Business News features Voltage Security CEO

Voltage's CEO, Sathvik Krishnamurthy was recently featured in the CSuite Sitdown segment of the Money for Breakfast show on the Fox Business Channel discussing how Information Encryption solutions can dramatically reduce identity theft risks, speed time to regulatory compliance and enable developer access to production data without compromising sensitive customer information.

The interview focused on consumer privacy, identity theft and Voltage's information encryption strategy for persistently protecting sensitive data wherever it goes. Sathvik highlighted the problems the industry is facing, threats to consumers and the growing popularity of Voltage solutions in solving this problem.

For more details visit www.voltage.com/data_protection

Top Gear Data Protection

My favourite British commentator, journalist and presenter of "Top Gear" the fantastic BBC car show - Jeremy Clarkson- just had his identity hacked and his bank account breached. Unlike many victims of identity theft, he had recently published his bank account details in his column at the Sun newspaper. Why you ask ? Well he was simply fed up with the furor around the loss of 7.25 million records of British citizens lost by Her Majesty's Revenue and Customs agency in November. His thesis being that all those identities were not at all at risk and that bank security details are perfectly secure. This weekend he revealed in his Sunday Times column, that yes, his bank account had been tampered with and 500 GBP had been debited from his account and sent to the account of a British charity. Now he's advocating stringent measures to deal with people that commit identity fraud.

Here at Voltage we're about to introduce a new cryptographic approach, known as Format-Preserving Encryption, that will help foil identity theft in its entirety. Read about the solution that protects credit card numbers, bank account numbers and other structured personal data inside the vast databases and applications used by financial services companies around the world, here.

And Today's Security Breach Is...

With a new incident of lost or stolen consumer financial data coming to light seemingly every day, it's beginning to feel like it's just something to be expected. But this latest incident, in which a database belonging to a credit card processing company was compromised, is particularly interesting, in that the database contained data that should not have been persitently stored in the first place:

"The official, John M. Perry, chief executive of CardSystems Solutions, indicated that the records known to have been stolen covered roughly 200,000 of the 40 million compromised credit card accounts, from Visa, MasterCard and other card issuers. He said the data was in a file being stored for "research purposes" to determine why certain transactions had registered as unauthorized or uncompleted. . . .Mr. Peirez of MasterCard said that the data inappropriately retained by CardSystems was particularly sensitive because it included cardholders' three- and four-digit security codes, making it more attractive to potential thieves because it can double or triple the black-market value of a cardholder's account."

What's particularly concerning is why CardSystems had access to data such as the security codes in the first place.  I'm by no means an expert on credit card transaction processing, but according to this nice graphic by the Times, it seems the primary function of the processing agents is to route the transaction to the correct place.  If that's the case, it's not clear why these agents need access to anything other than the card number; any other information (cardholder name, billing address, security code, etc.) would seem extraneous to the routing process.

At least in this case, then, it seems as though a protocol change would have prevented any important data from being compromised.  The most obvious fix would be to encrypt various pieces of the transaction such that they could only be read by the parties who actually need access to them.  For example, there's probably no reason for anyone other than the cardholder's bank (and potentially any contracted processing company, according to the Times's graphic) to be able to see the cardholder's billing address.  So encrypting that data with the public key of the bank (e.g., with IBE, you could just use the first 6 digits of the credit card number, which identify the card issuer) would ensure that any misbehaving processing organizations in the middle can't jeopardize the security of the really sensitive data.

In general, these types of protocols are so widely deployed that modifying them is next to impossible.  But it will be interesting to see what sort of action, beyond requiring more frequent audits of the processing companies, the card organizations and banks take, as there seem to be far too many points along the transaction path at which an unscrupulous (or simply negligent) party can compromise data.