Superconductor

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.

Information security is easy

Some things may seem easy, but turn out to be fairly difficult once you start looking at the details. Economics may provide a good example of this. Once when I was in a college class in economics, one of the other students asked the professor what we should study for our upcoming exam. "Economics is easy," he replied. "If you know how to increase the GDP without causing inflation or unemployment, you'll do just fine on the exam." This may sound easy enough, but nobody's quite figured out how to do it yet.

Information security is much the same way: it sounds easy in principle, but the details of getting it right are very difficult. And much like economists still don't really know how to do what sounds very simple, information security specialists still don't really know how to keep computer networks secure, although we're definitely getting better at it.

Technology is making some things easier to do, but much of it is still too hard for the average user to use. Information security seems to attract people with an uncommon set of aptitudes, and these people sometimes don't understand exactly how hard some things can be for the average user, who typically doesn't share the same uncommon set of aptitudes.

Unless security technologies are easy enough for the average user, they won't be used widely enough to make a difference. Until then, information security will stay harder that it first sounds. After all, it's really nothing more that ensuring that people can get the data that they're allowed to get and that others can't. That doesn't sound too hard, does it?

Multi-factor authentication

The Accredited Standards Committee X9 develops American National Standards for the financial services industry. One of these standards, ANS X9.49, Secure Remote Access Mutual Authentication, is undergoing its mandatory 5-year review now. In a recent X9 meeting when we discussed updating this standard, we had an interesting discussion about exactly what “multi-factor authentication” is. Everyone agreed on the two following points:

1. It’s not really defined in any standard

2. The generally-accepted definition and its interpretation is really the result of vendors’ marketing efforts rather than anything substantial

Many books, articles, etc., define three “factors of authentication” which are typically defined roughly as:

1. Something that you know, like a password

2. Something that you have, like a token of some sort

3. Something that you are, like a biometric

There’s clearly some fuzziness here because of the way these are defined. One type of biometric is a behavioral biometric, like biometrics that look at how you type on a keyboard or write with a pen. Within this framework, you could argue that a password is just a behavioral biometric that tests whether or not you can remember a particular string. You could even argue that proving possession of a cryptographic key, like you do in the X.509 authentication protocol, is just like a behavioral biometric that tests whether or not you can flip a coin and get a particular series of heads and tails, although you probably wouldn't get many people to agree with you at this point.

Multi-factor authentication is usually assumed to be a technique that uses more than one of these factors. It’s often claimed that multi-factor authentication is inherently more secure than single-factor authentication, but if you look at the history of this claim, it actually came from a vendor that wanted to make their multi-factor authentication product sound better than competitors’ products.

Is there any substance to this claim?

Let’s compare two authentication schemes:

Scheme A, which requires a username/password plus a biometric 

Scheme B, which requires two different username/password combinations

Which one is more secure and why? Is there any reason to say that one is inherently more secure than the other? Particularly because it’s easy to force people to use reasonably strong passwords but essentially impossible to get the same level of security from biometrics, does using a biometric just because it’s a different authentication factor really add anything? Or will it actually provide an overall weaker authentication scheme when it's used?

Nobody at the X9 meeting was convinced that authentication using two or more authentication factors is actually any more secure than authentication using two or more independent means of authentication that happen to be the same factor, so the updated standard will probably reflect this. I’m looking forward to seeing the comments on this when the document gets voted on.

Ping

Back on March 7, 1999, "A reader from Upper Volta, Uzbekistan" posted the following review of the book The Story of Ping on Amazon.com. The Story of Ping is a children's book about the adventures of a duck named Ping who lives in China. Here's what the reader from Uzbekistan said about this book. This was even mentioned on the web page of Mike Muuss, the person who wrote the first version of the UNIX utility ping.

Excellent, heart-warming tale of exploration and discovery. Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most venerable networking utilities. Even more stunning is that they were clearly working with a very early beta of the program, as their book first appeared in 1933, years (decades!) before the operating system and network infrastructure were finalized.

The book describes networking in terms even a child could understand, choosing to anthropomorphize the underlying packet structure. The ping packet is described as a duck, who, with other packets (more ducks), spends a certain period of time on the host machine (the wise-eyed boat). At the same time each day (I suspect this is scheduled under cron), the little packets (ducks) exit the host (boat) by way of a bridge (a bridge). From the bridge, the packets travel onto the internet (here embodied by the Yangtze River).

The title character -- er, packet, is called Ping. Ping meanders around the river before being received by another host (another boat). He spends a brief time on the other boat, but eventually returns to his original host machine (the wise-eyed boat) somewhat the worse for wear.

The book avoids many of the cliches one might expect. For example, with a story set on a river, the authors might have sunk to using that tired old plot device: the flood ping. The authors deftly avoid this.

Who Should Buy This Book

If you need a good, high-level overview of the ping utility, this is the book. I can't recommend it for most managers, as the technical aspects may be too overwhelming and the basic concepts too daunting.

Problems With This Book

As good as it is, The Story About Ping is not without its faults. There is no index, and though the ping(8) man pages cover the command line options well enough, some review of them seems to be in order. Likewise, in a book solely about Ping, I would have expected a more detailed overview of the ICMP packet structure.

But even with these problems, The Story About Ping has earned a place on my bookshelf, right between Stevens' Advanced Programming in the Unix Environment, and my dog-eared copy of Dante's seminal work on MS Windows, Inferno. Who can read that passage on the Windows API ("Obscure, profound it was, and nebulous, So that by fixing on its depths my sight -- Nothing whatever I discerned therein."), without shaking their head with deep understanding. But I digress.  

Someone at Amazon.com, probably one of those managers who were overwhelmed by the technical aspects of the book, apparently decided that this review wasn't serious enough and removed it. Fortunately, this review is back, although under the name of a different reviewer. It's now actually rated as the most helpful review.

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.

Bad wireless security

Some myths about wireless security never die. The short-list of these includes the benefits from things like MAC filtering, using static IP addresses and hiding SSIDs. The perception is that using techniques like these actually adds some security to a wireless network. They don't, and there are even good reasons not to use them. Despite this, they're presented as "best practices" in a distressingly-large number of places.

Suppose that a hacker is going to try to hack your wireless network. The first thing that they'll do is run a wireless sniffer like Kismet against it. This will find all of those IP addresses and SSIDs very quickly. Spoofing MAC addresses is only slightly more difficult because you have to download a second utility like SMAC to do it.

Running these programs is probably the very first thing that a hacker will do because they tell you so much useful information about a network. So by spending the time and money to configure and support these techniques, you've slowed down the hacker by a total of roughly zero seconds. This means that these techniques don't provide another layer of security - they provide absolutely no security at all. On the other hand, they do have costs in terms of the time and effort required by your wireless network administrator to configure and maintain them. What the ROI for that investment?

Real wireless security gives you real protection and is what you should be using. Don't be fooled into thinking that you're getting any security at all from some of the easier techniques.

Malware to Watch: Conficker C

The SRI report on Conficker C makes for some fascinating, and terrifying, reading.  Conficker is a nasty chunk of malware has spread very widely on Windows XP machines.  When it infects a machine, it sets up a sophisticated ring of defenses that prevent the user from removing it, then sits and monitors a set of outside websites looking for a digitially signed payload that contains a program that does.....something.  Conficker has updated itself several times already (there is a Conficker A, B, B++, and C) and updated its ability to neutralize host-based and network based defenses.  At the moment, it blocks all network access to Microsoft updates, Symantec, and a number of other security vendors.  It prevents many anti-malware tools from running on the machine.  It even patches a known network bug so that other viruses can't attack the machine.

I'm not a malware expert, but the thing in the SRI report that caught my eye is the level of cryptographic sophisticated exhibited by the author.  It checks digital signatures on all updates and downloads, and encrypts chunks of its own code to evade analysis.  Conficker uses the MD6 hashing algorithm, which is a brand new hashing technique developed by Ron Rivest as an entry in the NIST Advanced Hash Standard competition.  Conficker had incorporated this new algorithm within weeks of its announcement, so the author has to be spending some serious time monitoring cryptographic research.

2009 business risks

The 2009 Ernst & Young business and risk report is now available. The predictions that E&Y has made in previous editions of this report have been fairly accurate, so I always look forward to seeing the next edition of it. Like the reports from previous years, this year's report has a few interesting things in it.

The first thing that I noticed was an obvious non sequitur by Edmond Escabasse. He's the CEO of Asialis and a member of the board of directors of ParisTech Telecom. He's also the person who wrote the section of this year's report that talked about how regulation, convergence and the evolution of economic models are important to businesses. Here's what he said.

In the complex world of telecoms, care needs to be taken to avoid confusing industry drivers with sector risks. Instability is driven by a number of factors, such as the capital intensive demands of infrastructure, constant technological disruptions and the rapid rate of service development. Taken together, they make for an industry that is as unstable as it is innovative.

He then follows with this totally unrelated statement.

In this light, regulation is key to ensure that all players get fair remuneration for their work, avoid economically unjustifiable network migration and are allowed to cooperatively evolve with other segments of the industry.

It's not at all clear to me why regulation is needed to ensure that companies make a fair profit, don't make bad investments and negotiate mutually-beneficial deals with other companies. Shouldn't successful companies do these things on their own? If they can't, they probably shouldn't be in business. Perhaps Mr. Escabasse's view of the world has been affected by the telecom bubble of 1997-2003. But even if this is the case, it's not clear why regulation will keep managers from making bad decisions, which was really what caused the telecom bubble.

One thing that's interesting in this year's report is the fact that there a new threat to businesses listed. This year "business model redundancy" is the 9^th biggest threat, and appears on the list of the biggest threats for the very first time. This is a threat because "technological change and industry transitions are making long-established business models obsolete, forcing industry-leading firms to reinvent their corporate strategies and structures."

This reminds me of the hearings before the Subcommittee on Economic Goals and Intergovernmental Policy of the Joint Economic Committee, back in June of 1982 when the Post Office tried to get their monopoly extended to cover email. The Post Office's pitch, "The future of mail delivery in the United States," is hard to track down these days, but it shows how they tried to justify this. Luckily, the Postal Rate Commission and the Federal Communications Commission didn't let them do it, and the use of email became widespread. And you didn't need to deal with the Post Office to get it. That's a bit of email history that's probably not widely known.

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?

Security for mobile banking

It looks like the Accredited Standards Committee X9, the group that makes American National Standards for the financial services industry, is soon going to start work on its ANS X9.112 Part 3, Wireless Management and Security Part 3: Mobile Banking, even though work on Part 2: ATM and POS hasn’t even started yet. The sudden interest in mobile banking security is apparently due to the introduction of vans that go to events like fairs and other festivals. These vans act like a mobile bank and have a wireless connection back to a brick-and-mortar bank. These banks-in-a-van use commonly accepted protocols like SSL to protect transactions that are sent over wireless connections, but that’s not good enough for the more security-conscious banks.

Banking information security standards are fairly strict, particularly when it comes to the use of cryptography, and there are X9 standards that define in great detail how encryption and key management need to be done if it’s to be considered good enough to protect financial transactions. The use of SSL in off-the-shelf web servers doesn’t even come close to the level of care required by X9’s key management standards, and the ANS X9.112 Part 3 will try to correct that.

Creating an SSL server certificate is relatively easy with most web servers, but the process isn’t done in a way that meets the level of security that security-conscious banks want to see. They’re used to the careful key management processes that are used to generate and install the keys that are used to protect ATMs, for example, and these are much stricter that what controls that a web server can provide. They require the generation of keys in secure hardware devices instead of in software, and require careful protection of the keys throughout their life. Most commercial web servers don’t provide a way to do key management that carefully, but that’s what ANS X9.112 Part 3 wants to require.

There’s probably a fairly small market for web servers that are secure enough to keep security-conscious banks happy, but security-conscious banks may be willing to pay a fairly high price for products that meet their needs. It will be interesting to see how the ANS X9.112 Part 3 standard evolves and how widely it’s implemented.

Maslow's hammer

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Abraham Maslow, Psychology of Science: a Reconnaissance

Although he’s most famous for Maslow’s hierarchy of needs, Abraham Maslow also noted that people with incomplete knowledge or understanding tend to propose the same type of solution to every problem that they encounter. This phenomenon isn’t widely known as “Maslow’s hammer,” although there’s probably a good reason to use that term for it. Maslow may not have been the first person to notice it, but he was probably the first to describe it in a way that’s easy to understand and explain. I see Maslow’s hammer fairly often in the field of information security, but that’s probably just because that’s an area I know something about. It probably happens in other industries too, but I don’t know enough about those industries to see it.

There are lots of people out there that understand a little about PKI, for example. Some of them learned it when PKI was trendy and fashionable during the dot-com boom. Others learn a little about it when they get their MCSE certification. In most cases, they really don’t use it much because very few applications support it. So even if they’ve set up a PKI in their organization, they probably haven’t done much with it. But because they know a little bit about PKI, that becomes the hammer that Maslow’s hammer describes, and they often treat every encryption project that comes along as one that can be solved by PKI. Some can, but even more can’t.

Voltage’s sales managers often meet people who have the PKI hammer in their toolbox, and have to convince them that there’s a better alternative. That can be tricky, but the benefits of using identity-based encryption are fairly significant. In most cases, it turns out to be worth the time and effort that it takes customers to learn about how IBE can be a good alternative to PKI.

One day, someone will probably invent a technology that’s better that IBE in some way. IBE already has lots of users – roughly 10 million users at several hundred businesses. So when the better technology comes along, the company that’s selling it will probably have to overcome the resistance of customers who will be viewing IBE as the hammer with which to solve all of their encryption problems. But with any luck, Voltage will invent that next step.

Going Postal

The Post Office lost yet another package of mine. This happens at least once per year and it's always for the same reason. The letter carrier scans the delivery confirmation bar code of a package while they are sitting in their truck but forget to actually carry the package to my house. The package then gets returned to the Post Office, where it sits in limbo until I can convince the Post Office to track it down. They usually don't want to do this because the package shows as being delivered in their system even though it wasn't actually delivered.

I finally realized why this happens. It's easier to tell the story of how this came to be instead of giving the precise details, so here's "Going Postal."

Come to think of it, this might actually explain more than my missing packages.

Going Postal

When the doorbell for Shocker Books rang at precisely 10 am, Larry Schwartz knew that it had to be the mailman. Other visitors to his store were very rare these days. Although he still had a brick-and-mortar store that housed his inventory of rare and expensive horror books, almost all of his sales were now orders that he took over the Internet and shipped to his customers.

This made the Post Office an important part of his business, but because the Post Office was one of the most efficient and well-run organizations in the world, he had complete confidence in the white-uniformed mailmen that called twice a day to make deliveries from publishers and to pick up his shipments to his customers. Larry’s business was booming, and the Post Office was an important part of its success.

When the doorbell rang again about an hour later, Larry was surprised to see Mike Campbell at the door. Mike was an old friend from college who he hadn’t seen for quite a while. While Larry had followed his dream of opening a bookstore, Mike had gone into the army and had fought in the Gulf War back in 1991. After catching up on the events of the past few years, Mike showed Larry the antique, leather-bound book written Arabic script that he was carrying and explained how he was interested in selling it.

“I’ve had it in storage in a safe deposit box at my bank for the past few years,” said Mike. “I picked this up in Iraq and held onto it, hoping to sell it one day. You’re the expert on this stuff, and I was hoping that you could take a look at it and tell me if it’s worth anything.”

They agreed to meet again in a few days after Larry had had time to look at the book and assess its value, and Mike left Larry to his processing the huge backlog of orders that he had.

Later that day Larry started to get paranoid. It might just have been his imagination getting the better of him, but he was sure that he had seen suspicious figures lurking outside his store ever since Mike left. Following the example of Sam Spade in The Maltese Falcon, Larry decided to mail Mike’s book to himself to avoid the possibility of it being stolen that night. There was still time to get it into the 5 pm mail pickup, so he carefully packaged the book in bubble wrap, put it in a box addressed to himself, and gave it to the mailman when he came later that day.

That night, Larry received a panicked phone call from his friend.

“Be careful with that book,” said Mike. “I’ve learned that it’s a copy of the Al Azif by an Arab named Abdul Alhazred. It’s related to the occult in some way and it’s evil. Very evil. It’ll corrupt everything that it comes in contact with, so keep it away from your expensive books. Don't worry - I’ll come by tomorrow to pick it up.”

Larry made his living dealing in books that told stories with supernatural elements, but didn’t actually believe in the supernatural himself. This made it easy to write off his friend’s concerns, but he would still be glad to be rid of the book and the irrational fears that it seemed to cause.

Next morning was fairly leisurely. Few orders had come overnight, so Larry actually had time to enjoy his morning coffee and read one of the books in his inventory. Time passed so quickly that Larry didn’t even notice that it was afternoon before the mailman came. The sound of the damaged box being thrown to the ground outside his door caught his attention, as did the blue uniform that he saw on the mailman as he walked away.

Mike was right.

Updating FIPS 140-2

In the early days of Internet security, security consultants would often show a picture of an unplugged computer and tell you that the only safe computer was one that was unplugged. Only slightly more risky was one that was turned on but not connected to a network. Connecting your computer to a network was supposed to have the potential to cause all sorts of Bad Things to happen to you, and it made achieving a reasonable level of security extremely difficult to achieve.

Today, not connecting a computer to a network is almost unthinkable, and devices like PDAs and cell phones are part of the same networks that desktop computers are. The security of such networks is not perfect, but they certainly function well enough to keep businesses running. Many new security technologies have been invented to make such networks practical for business use. Some security technologies have fallen behind, however, and one of these is encryption, although it might be more accurate to say that some standards for cryptography haven't kept up with changing technology.

The leading encryption standard is the U.S. government's Security Requirement for Cryptographic Modules, also known as FIPS 140-2. This standard defines the best practices that cryptographic engineers should follow, and being validated as following these practices is required for any cryptography used by the US government.

FIPS 140-2 is a relatively successful standard. It is now recognized by many countries outside the U.S. and is the basis for the new ISO 19790 standard. It has its roots in the world of hardware, however, and doesn't adapt as well as it could to today's world where cryptography in software is far more common than cryptography in hardware.

The FIPS 140-2 standard evolved over the past few decades from the original standard for the venerable DES encryption algorithm. The first standard for DES mandated that the algorithm be implemented in hardware, a requirement that lasted for 11 years until the requirements were finally loosened to also allow implementing DES in software. The FIPS 140-2 standard is the direct descendant of these ancient standards for DES and they still strongly reflect their hardware roots.

So why can this be a problem? The recent experiences of an unlucky defense contractor may illustrate this.

I recently talked to people in the information security department large defense contractor. They had just received a mandate to encrypt all email messages tothe government using a product that was FIPS 140-2 validated and was operating in a government-approved mode, so that all cryptographic functions were performed as required by the FIPS 140-2 standard. As they looked into doing this, they were surprised to learn that none of the available email encryption products they found would actually operate in a useful way in a FIPS-approved mode.

By following the requirements of the standard, they had to effectively disconnect their computer from the network, putting their system in the same fairly risk-free state that security consultants used to joke about. They couldn't actually send an encrypted email using a FIPS-validated email encryption product because the restrictions of FIPS 140-2 were so strict. Their systems would probably be very secure when operating in an approved mode, but they would also be relatively useless.

The root of the problem turned out to be a requirement of FIPS 140-2 that makes perfect sense for hardware, but doesn't make as much sense for software. And when the email encryption products were configured to operate in strict accordance with the standard, they couldn't actually function. If the defense contractor operated any of the available products in non-approved mode they would work just fine, of course, and it seems that many users of FIPS-validated products end up having to implement such a workaround to get their products to function.

You can't help but wonder if the provisions of a standard that frequently require workarounds in this way are even worth having. If products can't actually be used in an approved mode, is the standard useful, or should it be updated to reflect the realities of a world in which cryptography is implemented in software?

Cryptography is a difficult and arcane subject, so having a standard that rigorously validates its correct operation is a good idea. But the current version of the FIPS 140-2 standard seems to have gone a bit too far and needs to be updated to reflect the realities of modern technologies and the way in which they are used. This standard is currently being reviewed and updated, and NIST should ensure that the result of their efforts is compatible with the technologies that need to be used by both the public and private sectors. Software is here to stay, and the security standards need to reflect this reality.

A cool IBE project

I just got back from a great demo of an IBE secured messaging web service, built as a masters practicum project by Nishant Dubay, Anusha Nagarajan, Tyelisa Shields, and Yash Shroff.  SAP sponsored the project, which was supervised by Yuecel Karabulut of the SAP Office of the CTO.  The basic idea here is that there's a central semi-trusted service that receives messages from a set of "smart devices", which might be water meters, cars, or mobile devices.  The devices want to secure messages so that only trusted recipients can read the messages (for example, messages from the water meter should only be read by the water company, and perhaps a usage optimization agency).  The devices don't know who the recipients are, so they encrypt the message to an attribute, which is turned directly into an IBE key.  Service providers can then go retrieve messages, and authenticate to a key server, which will give them the keys for only their authorized set of attributes.  They incorporate nonces so that the server can revoke attributes in case a service provider is no longer trusted to access some attribute.

In a certain way of speaking, IBE isn't really an encryption mechanism, it's a way to turn an access policy (like "This data can only be read by water company employees") directly into a key that can then be used to encrypt data.  The value here is that access control is no longer dependent on the behavior of the computers used to store that data (or the backup tapes that data is written to, etc.) but instead on a central key management server.  You can now just trust that the web service reliably stores and delivers data, and trust a separate element to keep that data private.  The key server that controls privacy can live as a third-party service, or be kept internal to a company.  Hopefully, someday, we'll have services like dropbox.com and xdrive.com that will serve up data, but it will stay encrypted in such a way that even a total loss of data by the service doesn't actually disclose any sensitive information.  IBE is really elegant, easy way to make that work.

The CMU team is off to build the next version of their service, which might incorporate some of Brent Water's innovative attribute-based encryption work to allow for complex policies that join together multiple attributes.  I'm looking forward to seeing what they come up with!

Why we need IP telephony

 

The reasons for and against IP telephony are the source of endless discussions between technologists. I finally heard a statement that may be useful in deciding whether or not the technology is as useful as its proponents claim:

IP telephony makes your phone as reliable as your computer.

IBE at CMU-West

Yuecel Karabulut invited me to give a talk on IBE and Key Management to the MSIT-Information Security class at CMU West last Friday.  It was fun to get to talk about key management in an academic context, and with a class of bright, informed students.  Kudos to CMU (full disclosure, I'm a CMU alumni) for offering an degree program that spans the entire gamut of security from a management perspective.  Two of the students in the class are building an IBE/attribute-based encryption system to secure a message based web service.  It sounds like an interesting use of IBE, and I should have more to report on later, as I'm meeting with the student team tomorrow.

As a side note, the CMU West campus is on Moffet Field, which also houses some NASA and military facilities.  When entering the field, a guard asks you to produce a driver's license, which is quickly glanced at, then you are cleared to enter.  This seems like a prime example of a bad access control system connected to a weak authentication system.  I guess this might make sense as a mechanism that can be dialed up in strength fairly quickly, but I'm not sure what it's accomplishing at the moment.  There are parking facilities in downtown SF that have the same system (one additionally searches your trunk) of glancing with intensity at a driver's license.  Baffling.

Schemes vs. algorithms

I’m often asked why I talk about public-key “schemes” instead of public-key “algorithms” like most people do. I’m one of those people who try to use words correctly. I cringe when I hear marketing people talk about “flushing” things out when they really mean “fleshing” them out. I often feel like sending people a link like this one that describes the difference, but I rarely do.

There’s actually a difference between a pubic-key scheme and a public-key algorithm, but most people don’t really care about it. Even people who understand the difference often use “algorithm” instead of “scheme” unless they’re writing or giving a presentation.

In any event, a public-key scheme is a technique for using public-key cryptography to do something useful like data encryption or digital signatures. More that one algorithm is used to implement a public-key scheme. In the case of DSA digital signatures, one algorithm used to create a signature and a different one used to verify a signature. If you talk about the “DSA algorithm,” which one are you really referring to? That sort of ambiguity is eliminated if you use “scheme” instead of “algorithm,” but it seems like that’s unlikely to ever catch on, and we’ll be talking about things like the RSA algorithm or the Diffie-Hellman algorithm well into the future, even if it's not quite accurate.

Classes of Crime Victims, Part 2

In Part 1, I described three classes of crime victims.

1. Innocent victims
2. Stupid victims
3. Complicit victims

The innocent victims take reasonable precautions yet still suffer losses. Why? Because sometimes the professionals are just too good or maybe it's just a matter of not knowing all the measures to take, despite attmpts at acquainting oneself with security.

The stupid victims don't take precautions. Maybe they just hope nothing bad happens, maybe they just don't want to take the time to learn, or maybe they think security is just too inconvenient.

The complicit victims know what precautions to take, they have the information, yet still engage in risky behavior. They are willfully vulnerable.

Remember, no one has the right to steal from you, whether you are innocent, stupid, or complicit. However, there are bad people in the world. I'd like to wave a magic wand and make it so that no one does any bad things to anyone else. But that's not going to happen, so unfortunately, we all have a responsibility to protect ourselves. One could argue that an individual's protection is someone else's responsibility (the police, the government, society, the world, etc.), but I'm going to say that as members of our society, we all have some responsibility to participate in our own protection. These other entities might have a responsibility as well, but I think each individual has to bear some of the burdon for protecting themselves.

But there's another aspect to this. In Part 1, I gave the example of Alice hiring an accountant. There were three scenarios, innocent, stupid, and complicit. She was a victim, yet we could see that in one case, there was little she could do to protect herself (innocent), in another case she did nothing (stupid), and in the third she had the info yet chose to ignore it (complicit).

There is another aspect to that example I'd like to discuss, Alice was not the only victim. In the example, she ran a company with 100 employees. When the accountant absconded with the company funds, not only Alice was hurt, but also the employees, the customers, the suppliers, and investors. If the company was insured, the insurance company suffers as well. You can probably think of more costs of this crime.

When Alice hired the accountant, she was putting these other people at risk as well as herself. However, these other people had no say in the process. To put it another way, the security measures surrounding the hiring of a new accountant were integral to the security of many people, and these other people had no power in determining, implementing, or reacting to the security measures.

When someone's security decisions significantly affect other people, then I think it is reasonable to say that some of the responsibility for the breach can be applied to the decision maker. The more security utilized, the less responsibility, the less security, the more responsibility.

Even though Alice did not steal the money and Alice cannot control someone else's actions, in scenarios 2 and 3 she bears some responsibility.

This is nothing new, think of negligence in a civil case. Even though someone did not do something bad, we hold them partially responsible because of the decisions they make. (It would be great if juries would render verdicts based on the fact that we cannot secure against all eventualities, nor can we be all-knowing so as to have complete knowledge of every measure possible, rather than simply deciding based on who has money. But I digress.) This is not new in the sense that we have laws concerning data breach (from HIPAA to various disclosure laws).

I just thought I would describe the thinking that leads to these laws.

Has secure email crossed the chasm?

 

The recent large deployment of secure email at Wells Fargo that Voltage recently announced is just one of many large deployments of Voltage's SecureMail in the past year or so. This might be enough to make you wonder exactly where secure email is on the technology adoption life cycle. Has it crossed the Chasm that was popularized by Geoffrey Moore and entered the Early Majority phase yet? Or is it still stuck in the Innovators phase?

To understand this, it might be helpful to describe exactly what the technology adoption life cycle is. It turns out to predate Moore's book Crossing the Chasm by over 30 years, and its first version actually modeled the adoption of a fairly different area: it was actually first used to describe how farmers adopt new agricultural technologies. The first discussion of the technology adoption life cycle was the 1957 report The Diffusion Process, by George Beal and Joe Bohlen that was published as a supplement to Iowa's Regional Extension Publication No. 1, How Farm People Accept New Ideas. This model was then described in the 1962 book Diffusion of Innovations by Everett Rogers, where Rogers generalized the process to more that adoption of agricultural technology by farmers.

Beal and Bohlen modeled the adoption of new technologies by farmers as a process with five stages: Awareness, Interest, Evaluation, Trial and Adoption. In the awareness phase, people know about a new technology, but lack details about it. In the interest stage, people want more information about a new technology. In the evaluation stage, people think about a new technology and whether or not it will benefit them. In the trial stage, people start small-scale experimental use. In the adoption stage people have large-scale, continued use of a new technology. What's interesting in Beal and Bohlen's discussion of these five stages is how the most common way for people to learn about new technologies change at each step in this process. The most common ways to learn about a new technology in each phase are shown below.

Awareness	Interest	Evaluation	Trial	Adoption
1. Mass media	1. Mass media	1. Neighbors and friends	1. Neighbors and friends	1. Neighbors and friends
2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies	2. Government agencies
3. Neighbors and friends	3. Neighbors and friends	3. Mass media	3. Mass media	3. Mass media
4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen	4. Salesmen

We can summarize this by saying that when people move past just interest in a technology and start to evaluate it, then the source of their information changes from the media to people that they know. At that point, it seems reasonable to assume that the marketing efforts of technology companies should change. I don't know if sales and marketing people at technology companies use this model, but I wouldn't be surprised if they do. Curiously, salesmen come in dead last in every phase. Maybe they're never perceived as being a good source of information because they can probably be relied on to give information that's biased towards their products.

When it comes to individuals, Beal and Bohlen divided them into categories that are determined by how soon they adopt new technologies. This is where they divided people into the categories of Innovators, Early Adopters, Early Majority, Majority and Nonadopters. This is the model that Moore popularized in Crossing the Chasm, changing Majority to Late Majority and Nonadopters to Laggards when he did. Where is secure email on the technology adoption curve? Has it made it past Moore's Chasm?

Technologies reach Moore's Chasm in the Early Adopters phase. This means that if a technology is in the Early Majority phase then it's definitely past the Chasm. If it's still in the Early Adopters phase, then it might or might not have. People who are early adopters tend to take risks, but only to achieve very focused goals. They'll even work with start-ups to do this. People in the Early Majority are pragmatic. They don’t like the risks associated with new technologies but are willing to look at technologies when they've been tested by others.

Based on my experience at Voltage in the past five years, it seems to me that secure email entered the Early Majority phase in the past year or two. Before then, it was definitely only used by Early Adopters. Back then, Voltage's customers were ones that felt willing to take the risk associated with a small company and a new technology because the technology solved certain problems cheaper and easier than alternatives. More recent customers, however, seem to see secure email as an established and proven technology. They're now willing to deploy it widely, and Voltage now has several customers with over 100,000 users of its SecureMail products.

If Voltage's experience is representative of the entire secure email market, then secure email has crossed Moore's Chasm and is on its way to becoming used by a majority of businesses. That means that we'll probably see even more adoption of secure email in the future, and large deployments like the one at Wells Fargo should get more and more common. They might even become so routine that they're not even interesting any more.

Classes of Crime Victims, Part 1

It seems to me there are different classes of victims of crimes. To explain, let's look at someone hiring a new accountant. My apologies to accountants for using your profession in this example, but well, it works. Besides, there are indeed some dishonest accountants.

Suppose Alice owns a company with a couple hundred employees. Now suppose she needs to hire a new accountant.

Scenario 1: She interviews Bob and is impressed. So she checks out his claims on his resume. Did he really graduate from the college he said he did? Did he work at the companies listed? She contacts his references and even some people not listed as references, and then googles him. Everything looks good. She hires him but for the first few months limits his authority and even hires an outside consultant to audit and evaluate his work. Despite all that, after a few months on the job, Bob embezzles some money and skips town. It turned out he had developed a cocaine addiction (unbeknownst to anyone) and "turned" bad.

Scenario 2: Alice interviews Carl and is impressed. She hires him. She gives him complete control of the company's monies and accounts. After a few months Carl embezzles some money and skips town. Afterward, Alice learns that he had a conviction for embezzlement already. Several people tell her they knew he was a shady character, and if Alice had asked them, they would have warned her.

Scenario 3: Alice interviews Dave and is impressed. She checks out his resume and discovers he exaggerated quite a bit. She discovers he had been convicted of embezzling before. One of his references had never worked with Dave, other people tell her they don't trust him. But Alice says, "I'm a good judge of character and I can look into his eyes and see that he's reformed. He's paid his debt to society and based on the one hour interview I had with him, I know that he will be a model employee." After a few months Dave embezzles some money and skips town.

In the first scenario, I think of Alice as an innocent victim, in the second, she's a stupid victim, and in the third, she's a complicit victim.

There are bad people in the world, some will want to steal from you. It's a good idea to take precautions, to try to protect yourself. Even if you do employ security, you might still be a victim, sometimes the professionals are simply too good, or sometimes someone is simply able to circumvent the measures. Sometimes you simply don't know what security measures you need to take, and sometimes you simply have a lapse. In those situations you're an innocent victim.

Some people don't take precautions. That does not give the thief the right to steal from them, it doesn't mean the victim is to blame. However, it is not smart to go through life oblivious to the dangers therein. These people are the stupid victims.

Some people know what the dangers are. They have been given the information necessary to make good decisions and take proper actions. Yet they ignore the information and do the things that leave them extremely vulnerable. That still does not give the thief the right to steal from them. However, I think these people are complicit in their own misfortunes.

It's hard to talk about this without being accused of "blaming the victim". However, I want to stress, no matter what security measures you take or don't take, no one has the right to steal from you. We are not responsible for other people's actions. Nonetheless, I think it is also important that people understand that it's hard to muster any sympathy for the willfully vulnerable.

Remember also, I think there's a difference between willful vulnerability and simply not knowing the dangers. It is possible to be security-aware, to make an effort, yet still miss some possible actions that could have prevented something bad from happening. That's not stupid, that's simply being human.

More on this topic in Part 2.

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.

Ten little Soldiers

Ten little Soldier boys went out to dine;

One choked his little self and then there were nine.

Agatha Christie, And Then There Were None

The number of key management standards has grown dramatically in the past few years, and now there are over a dozen of them either completed or being worked on. With that many different standards, it’s sometimes hard to keep track of exactly what has been defined and in which document. Luckily, there’s a good summary of all of the different efforts here.

Not all of these standards overlap. Some just tell you what you need to do, but they don't tell you how to do it. Others tell you how to do it in a precise, interoperable way. The older standards tend to be the ones that just tell you what to do. The newer ones actually tell you how to do it.

We’re now seeing two interoperability standards emerge as the ones that vendors will actually implement, and we’ve now seen the first key management standard admit that it’s going nowhere. This happened yesterday when Arshad Noor, the person driving the Enterprise Key Management Infrastructure standard, withdrew his support from it. Here’s what he said about this:

I believe the policies at OASIS makes it difficult to put out a coherent message [on key-management] that benefits users in the IT industry. In light of the following facts:

* that charter members of the KMIP TC chose not to engage with the EKMI TC despite observing its activities for over two years [from within the OASIS EKMI TC];

* that some of [the KMIP charter members] were surreptitiously working on [the KMI] protocol while giving the appearance of engaging with [the IEEE 1619.3] industry standards group;

* that OASIS facilitated the creation of a new TC with overlapping charters rather than encourage charter members of the KMIP TC to engage in a constructive discussion with an existing OASIS TC that has a Committee Specification; and

* that there is nothing in OASIS policy to prevent yet another splinter group from the KMIP charter members to start yet another [key-management] related TC within OASIS, if it serves the splinter group' purposes

it appears that OASIS' policies are more sympathetic to IT vendors than to IT customers. In light of this, I believe that the [key-management] industry is better served by having the EKMI vision evolve in the 'do-or-die' competitive environment of the global open-source community, where technology and standards are largely driven by IT users than by vendors.

In other words, it looks like he’s throwing in the towel because EKMI never found support from other vendors. That’s definitely not a problem with the other two leading standards, the IEEE P1619.3 standard and the OASIS Key Management Interoperability Protocol (KMIP). The big security storage and security vendors are still backing them, and we’ll probably seem them both supported in shipping products before too long. Don't be surprised if other key management standards join EKMI soon. There are still too many of them.

Why bother with source code?

Users of Linux often prefer to download source code and compile it themselves instead of downloading executable binaries. Some Windows users do this also, but the inclination to do this seems to be much more common with Linux users. Many Linux users want to download source code and compile it themselves because they worry about malicious code in binaries and feel that by compiling it themselves they avoid any malicious code that hackers might be trying to get them to run. This probably gives a false sense of security because few people actually take the time to look at the source code and check for malicious code.

Maybe they don't want to take the time and effort to look at the code. Doing a careful security review of source code is actually fairly difficult and time consuming, so few people are inclined to do it. The result is that most source code that gets downloaded gets compiled and run without much review at all. If that's what you're going to do, why bother with the source code at all? If you're not going to look at it, just save yourself the work of compiling the source and download binaries.

Mehrabian's rule

Albert Mehrabian’s 7-38-55 rule is almost always misinterpreted. These misinterpretations probably aren’t too far from the truth, however, and they can probably explain why the Internet is such an obstacle to communicating effectively. Mehrabian’s 7-38-55 rule actually says that when we communicate face-to-face, how well we like the person that we’re communicating with depends on three factors: the words used, the tone of voice used, and the body language used. He first described this in his 1971 book Silent Messages, where he estimated that 7 percent of the overall level is due to the words used, 38 percent is due to the tone of voice used, and 55 percent due to the body language used. 

This is often generalized to saying that in any face-to-face communication that 7 percent of the information that we send is verbal, 38 percent is sent in our tone of voice and 55 percent is sent through body language. Mehrabian’s research doesn’t actually support this generalized result, but that hasn’t stopped people from calling this conjecture “Mehrabian’s rule,” or inaccurately attributing the generalized result to Mehrabian.

It’s probably the case that most communication is non-verbal, even if it doesn’t follow the 7-38-55 rule, and that’s why the Internet causes so many problems. Even if the exact fraction of the information that’s lost when we communicate on-line isn’t exactly 93 percent, it’s probably a significant part of it, and this causes many more misunderstandings than you would ever get face to face. Here’s an example of how this recently affected me.

There are now three IETF RFCs that describe identity-based encryption and how to use it in secure email. While getting one of these standards through the IETF bureaucracy I had to get three new media types defined for the types of data that get transported over HTTP when IBE is used: IBE public parameters, an IBE private key request and the IBE key that a of key server returns to a user.

There’s a mailing list where you propose new media types and other list subscribers get to critique your proposal. In my case, we had a heated debate over my proposal that turned out to be just over a slight misunderstanding in how one particular parameter was defined. If we were sitting down face to face, this misunderstanding would have been obvious almost immediately. But because we were only communication over email, lots of information was lost. Maybe it wasn’t exactly 93 percent of it, but it was a significant amount. This led to wasting several days in a debate that wouldn’t have taken more than a few minutes to settle face to face.

Lots of communications over the Internet seem to be plagued by the same problem, and because there’s no easy way to indicate tone of voice or body language over the Internet, we’re probably stuck with the imperfect communication that it allows. I suppose that you could write an IETF standard of some sort that might help fill the gaps in communication that the Internet creates, tags like <humor> and </humor> that you could use to indicate where you’re not being serious. But because you’d have to develop this standard over the Internet, it would be much harder to do than it needs to be.

Types of indicators

There's a new report that's available from NIST that has some interesting ideas in it. This report is the draft of National Institute of Standards and Technology Interagency Report (NISTIR) 7564, Directions in Security Metrics Research.

The part of this report that I found particularly interesting is this:

Analogous to economic indicators, security metrics may be potentially leading, coincident, or lagging indicators of the actual security state of the system. The distinction is significant. A coincident indicator reflects security conditions happening concurrently, while leading and lagging indicators reflect security conditions that exist respectively before or after a shift in security. If a lagging indicator is treated as a leading or coincident indicator, the consequences due to misinterpretation and reaction can be serious. The longer the latency period is for a lagging indicator, the greater the likelihood for problems. That is, a lagging security metric with a short latency period or lag time is preferred over one with a long latency period, since any needed response to an observed change can take place earlier. It is important to recognize lagging indicators and, if they are used, to be prepared to handle the intrinsic delay and associated limitations.

That's obvious when you hear it, but I hadn't thought of that before.

Leading indicators are ones that tell you what's going to happen in the future. Coincident indicators tell you what's happening right then. Lagging indicators tell you what happened in the past. What you'd like to find is a leading indicator of the security that your systems have. If that indicator starts to drop, you have a chance to address the source of the lower level of security before it becomes a problem. If you have a lagging indicator, by the time that you find out that you once had a lower level of security, you may already have been compromised.

The problem is that it's not clear what a good leading indicator of information security is. If you can find one, you can probably have the basis for a good service or product.

Experimental security

 

Which keeps you drier – walking or running in the rain? It turns out that doing a careful analysis of this problem isn't that hard. There's a paper by mathematician David Bell that walks through a complete solution. Like most things, if you think carefully about the problem, it turns out to be more complicated than you first think. In the case of keeping dry in the rain, it turns out that the optimal solution depends on the direction that the wind is blowing. If the wind is coming from in front of you, you keep driest by running. If it's coming from behind you, you keep driest by keeping pace with the wind. With most problems, however, a definitive solution isn't as easy to find. Information security is particularly tricky in this respect.

When you take a careful look at the risks that come from using computer systems, it's very difficult to find all of the risks. Even if you find them, understanding how serious they are can be hard. Understanding the best way to address them is even harder.

Because most people probably aren't aware of Bell's solution to the walk-or-run-in-the-rain problem and don't seem to be inclined to derive the optimal solution themselves, they often try other approaches. If what you see on the Internet is true, many people have resorted to comparing how wet they get when they walk in the rain to how wet they get when they run in the rain to estimate which approach is best. Most of these seem to arrive at the right answer – that it's better to run.

In information security, we have a similar problem. Even if we want to do a careful model to help find the optimal way to get the security that we want, we can't do it because we don't have enough accurate data about security risks. In the absence of reliable risk information, a similar approach to information security may be the best that we can do – just try different things and see which works the best. You might call this approach "experimental security." There may be no better approach.

Size does matter

Voltage is known for its innovative technologies. We're also a small company. It turns out that that might not be a coincidence. I learned this while reading "Entrepreneurial Risk and Market Entry," by Brian Wu and Anne Marie Knott. This paper talks about two things that I found interesting. The first relates to how risk-averse entrepreneurs are. The second relates to how big companies behave differently that small ones do.

One of the common misperceptions about entrepreneurs concerns their willingness to accept risks. It turns out that entrepreneurs really don't like to take risks – they're actually more risk averse than average. This is apparently balanced by their overestimation of their own abilities. They think that they're smarter than they really are. This means that they'll do things that others wouldn't think to do. They don't do these things because they willingly accept risk. Instead, they accept the risk because they don't know any better. Economists call this the difference between "demand uncertainty" and "ability uncertainty."

When it comes to big companies versus small companies, it turns out that there are three big differences in how they behave. Big companies tend to have broad and general strategies, which leaves parts of markets under-served. Small companies tend to take advantage of this and go after the under-served parts. Large companies tend to engage in slow and gradual innovation, while small companies tend to engage in more radical innovations. And when big companies do innovate, they tend to abandon their innovations because they don't fit well with their existing plans. Small companies don't do this.

Not surprisingly, this sums up fairly well how Voltage has succeeded. Larger security companies have broad product strategies in which encryption is just a small part. These strategies didn't create products that made secure email easy enough for most people to use, which left the opportunity for Voltage to succeed with its SecureMail products. The ease of use of SecureMail is based on identity-based encryption, a fairly radical innovation that makes encryption simpler and easier to use. Just to show that we follow all three of the differences that Wu and Knott list, I could mention that we don't have any plans to abandon our IBE technology, but that should be fairly obvious.

How secure is fiber cable?

Several years ago, I worked for the US government, I had an experience that I still think of from time to time when I talk about security policies and procedures. In this particular case, we had just installed a new confocal microscope in our lab and were connecting it to the network of workstations in our office. To do this, we had to run fiber from the lab to our office, and we had to cross the spaces of a few other offices to do this. After we filled out the necessary paperwork, got all of the necessary approvals and coordinated with the people in the other offices, a coworker and I started to run the fiber.

We came to one particular office, the security person there decided that our fiber was a security risk and tried to stop us from crossing his space with a series of irrelevant questions about how our fiber would affect the security of his space. We eventually showed him the paperwork that we had that had all the necessary approvals on it, but he still wasn’t satisfied.

“I’ll have to call the point of contact in the engineering division to make sure this is secure,” he said.

The person who I was helping happened to be that point of contact. I could tell by the look on his face that he wanted to point this out, but he decided not to. Instead, he calmly said, “Sure, go ahead and call him and see what he says.”

We then went down the hall to our office and waited for the phone call, and a few minutes after that our microscope was connected to our network.

The Winchester Horror

I just finished reading The Winchester Horror, by William F. Nolan, the writer who's probably most famous for Logan's Run. The Winchester Horror is a novella that tells the story of a ghost that haunts the Winchester mansion in San Jose, California. If you don't have much time to read, novellas are great. They let you trick yourself into thinking that you're reading more than you really are because they're much shorter than most other books. Between January 1, 2009 and March 1, 2009, I actually managed to read 18 books. This may sound impressive, but when you consider the fact that that time includes part of my Christmas vacation and that most of the 18 books are actually novellas, it actually turns out to be much less impressive.

The Winchester mansion was built by Sara Winchester from 1884 to 1922 at a cost of roughly $5.5 million. Apparently, she was concerned that the ghosts of people killed by Winchester firearms would kill her if she stopped construction of the unusual building. The result of this 38-year project is a 160-room house that's truly bizarre. It has only 17 chimneys for its 47 fireplaces. It has stairs that lead to the ceiling. It has cupboards that open onto brick walls. It even has a door on one of the upper floors that opens onto a drop straight to the ground below. Much of it doesn't make any sense at all. It seems to have built without much planning, and it was fairly expensive. In other words, it's just like today's computer networks.

Much like the Winchester mansion grew in an unplanned way into what's there today, today's networks have also evolved in a similar way. And just like it's hard to make sense of some parts of the Winchester mansion, it's also hard to understand exactly how some networks could have ever got to the point where they are now. Nobody lives in the Winchester mansion today – it's now a tourist attraction. After Sara Winchester's death, it probably proved to be too annoying to actually live in. Unfortunately, it's not practical to just walk away from the networks that have grown over time into the unwieldy beasts that they are today. And although they may seem to be just as confusing as the Winchester mansion, it's unlikely that we'll be able to turn them into attractions that we can charge admission to, so we're stuck using them.

Because they've grown over time instead of being carefully planned, it's always very difficult to integrate two or more networks. Businesses often try to do this when they acquire other companies or try to work more closely with partners, and it's almost always much harder than you think it's going to be. You may have your version of the Winchester mansion, but the people that you want to integrate with have their own version, and it hasn't evolved in the same way that yours did. Your network may assume that all of your data is handled by the equivalent of the stairs that lead to the ceiling, and the other network may assume that all of its data gets handled by the equivalent of the cupboard that opens onto a brick wall. Getting these two networks to work together can be hard. Sometimes it's even impossible.

It's well known that most acquisitions don't out work very well. Incompatible corporate cultures are one big cause of this, but I have to wonder how many of these failures can be traced to the difficulties in getting different networks to work together.

What color pen to use

Sometimes it can be difficult to deal with large organizations because of the rigid policies and procedures that they often have. In some cases, they may not even know exactly what their own policies and procedures are. I came across an example of this several years ago when I worked for the US government and had to travel to Europe for a week or so. When I arrived at my destination, another US government office, I had to fill out some sort of paperwork, and I used the pen that I had in my pocket to do this. This prompted a conversation that went roughly like this:

Woman behind the counter: I’m sorry, I can’t accept that form. You used a BLUE pen to fill it out and regulations require that it only be filled out with a BLACK pen.

Me: Really? I don’t believe that. Show me the regulation that says that I can’t use a black pen.

The woman behind the counter then disappeared for a few minutes, clearly stunned by my unwillingness to accept that the use of blue pens was banned. When she finally returned she decided to accept the paperwork that I had filled out with a blue pen, but I could tell that she really didn't want to. I’ll never know if she gave up trying to find the regulation that banned the use of blue pens or realized that no such regulation existed. I know which one I think probably happened.