Superconductor

An information security kriegsspiel

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

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

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

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

College 2.0

The "killer app" of the Internet seems to be communicating in some way. Email is wildly popular, as are social networking sites. The use of the Internet for communicating will probably have other unexpected affects. Maybe not overnight, but in a decade or two, the Internet is going to fundamentally change how higher education works, and what we're left with after it's changed may not look much like the system that we have today. This will be what I call "College 2.0."

The funding that university departments get is highly dependent on how many students they teach. That means that those huge freshman classes in chemistry, physics, math, economics that fill the big lecture halls heavily subsidize the operation of the departments that teach them. These classes are also the ones that are the easiest to replace with an on-line version of the class. That's even cheaper than using a graduate student, and it's probably the model that universities will move to in the future, and when they do this, the funding that they get may be dramatically reduced.

Without the funding provided by filling auditoriums full of undergraduates, the classes offered by universities will probably end up being limited to upper-level classes. Students will get their first two years of college on-line, and only go to a classroom for the last two years or so. When this happens, the number of faculty positions needed will decrease dramatically. I'd guess that maybe half of them won't be needed any more. Eliminating that many faculty positions is certainly a major and significant change, but that's where the Internet may be taking us – to College 2.0.

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.

The real reason for cloud computing

At the recent RSA Conference, cloud computing was one of the topics that everyone was talking about. In every talk that I sat through at the conference, I heard a single reason being given as the big driver for cloud computing, and that's the unresponsiveness of corporate IT departments. I heard this reason given again and again, and I didn't hear any other reason proposed as a serious alternative to it.

Business units need to get their job done and they're apparently told fairly often by their IT support organization that the resources that they need to do this either aren't available or that the support that's needed will be extremely expensive. Faced with an IT department that either can't or won't support them, many business units are using cloud computing as a way to bypass the troublesome support organization.

This is more than a bit like how corporate IT departments came to support WiFi, isn't it? In the early days of WiFi, the IT departments didn't want to get involved with the technology, but people started using it whether or not the IT department had any say in the matter. After a year or two of this, IT departments had to get involved, and now the technology is ubiquitous.

There are good reasons not to use cloud computing for some types of data: there may be regulatory compliance issues if some types of data are put into a cloud, and there are still security issues that aren't fully addressed. But despite these problems, it certainly looks like cloud computing has found a niche, and that IT departments will have to deal with it.

Come to think of it, this may actually be the same path that almost all new technologies follow: the people that need them find a way to use them, and it's only much later that the new technologies are understood well enough to be accepted by the people whose titles begin with the letter "C." I can't think of an obvious counterexample.

Why do data breaches have a lognormal distribution?

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

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

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

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

• the concentration of gold or uranium in ore deposits

• the latency period of bacterial food poisoning

• the age of the onset of Alzheimer's disease

• the amount of air pollution in Los Angeles

• the abundance of fish species

• the size of ice crystals in ice cream

• the number of words spoken in a telephone conversation

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

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

Interactive Data Breach Map - Zoom into local breaches

  

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

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

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

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

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

Benford's law and the size of data breaches

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

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

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

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

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

   

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

The next Big Thing

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

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

It could happen.

Summarizing the RSA Conference expo

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

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

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

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

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

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

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

How useful are digital signatures?

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

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

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

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

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

More on the lognormal model

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

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

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

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

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

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

 

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

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

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

Free shipping

It turns out that you can now get this blog on your Kindle e-book for only $1.99 a month. Other items that Amazon.com sells aren't quite as cheap. I stumbled across a textbook today that actually sells for $7,790. This is Nuclear Energy, by many contributors.

Here's the product description:

The three volumes VIII/3A, B, C of Energy Technologies should primarily serve scientists, engineers, and students to gain information on physical, chemical, and technical properties of all technologies to provide, convert, distribute, store, and finally use energy. They are supplemented with economic background information and with specific concepts, to allow the reader a proper comparison of different energy technologies. In this way these volumes on energy technologies should help human society pave the way towards sufficient and environmentally safe provision and use of energy. The various contributions have been written by experts from all around the globe working in universities, public research institutions, and private industrial companies.

One of the targets is students, but how many students can afford a book that costs $7,790?

On the bright side, you definitely qualify for free shipping if you buy this book. Or you could save 20%, or $1558, if you decide to read Nuclear Energy on your Kindle instead of getting a printed copy. At least it's not as bad as Mrs. Skagg's Husbands, which you can't get for anything less than $7.6 million. That's not available for the Kindle yet, though.

A new type of standard

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

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

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

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

Update on the Hannaford suit

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

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

Here's how the Judge summarized his thoughts:

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

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

Hashing and the PCI DSS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An unusual contract opportunity

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

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

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

Data breaches have a lognormal distribution

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

  

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

Violating the end-to-end principle

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

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

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

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

What clocks can tell us about usability

 

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

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

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

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

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

Information security insurance isn't practical

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

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

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

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

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

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

The newspaper effect

 

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

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

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

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

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

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

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

A big red flag

Seeing the phrase “up to” should make you very suspicious of what comes after it, particularly when it’s used in phrases like “may be up to 10 times faster.” One of Voltage’s competitors actually used that phrase to describe how the performance of their products compare to the performance of Voltage’s. In this particular case, they weren’t being totally honest.

Consider the statement “my salary could be up to $1 million this year.” The unfortunate and harsh reality is that I make much less than that, but the statement is certainly true nevertheless. Similarly, our competitor's claim that their performance “may be up to 10 times faster” is also true for much smaller multiples. It’s even true if they’re performance is actually worse, isn’t it? A multiple of 0.5 is also less than a multiple of 10, after all.

I’ve seen one case where the phrase “up to” actually made sense. That was in one of Symantec’s reports on the underground economy. When they estimated the value of stolen credit card numbers had to cyber-criminals, they said that it was “up to $5 billion,” but that was because they didn’t know how many of the credit card numbers being sold were actually valid. If all the credit card numbers were valid, they’d be worth the full $5 billion, but because some were probably invalid, the actual value was probably less than $5 billion, and it was hard to estimate by how much. That’s a case where saying “up to” seems to make sense. In most cases, however, it should be a warning that what’s being said probably isn’t very accurate.

I plan to do up to 100 more posts that talk about this in more detail.

The Munitions List

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

22 CFR, §120.2

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

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

If only the government had used different words.

What FM 100-14 tells us

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

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

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

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

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

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

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

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

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