Superconductor

Cloud computing at the RSA show

While too many of the pitches on the expo floor at this year's RSA Conference were about how various products or services could make you PCI DSS compliant, way too many of the talks this year were about cloud computing. Few of these talks really seemed to have anything new and interesting to say. Some seemed to be just thinly-veiled pitches for a cloud computing offering from vendors who had essentially bought speaking slots at the show with their sponsorship dollars.

Now, while cloud computing can be a very useful technology in some cases, it's also one that can create some interesting security challenges. But while talk after talk went on and on about the security challenges of cloud computing, one fairly obvious approach was rarely mentioned: encrypt your data before you put it into an external cloud computing environment.

The RSA Conference started out as a conference about cryptography. Despite this bit of history, the fact that cryptography can go a long way towards solving some of the tricky problems that cloud computing can cause was rarely mentioned at this year's conference struck me as being a bit ironic.

You are here

When I recently logged in to the ISSA web site, I was surprised to see that the web site apparently thinks that I'm in rural Libya somewhere. Here's what its map showed for my location:

Based on this, the 10 closest ISSA chapters to me are Italy, Abuja, Egypt, Spain, Switzerland, Istanbul, France, Romania, Israel and Lagos. Voltage often supplies speakers for ISSA meetings, but I don't think that we've sent anyone to any of these locations yet, even though they're apparently fairly close to us.

I didn't know that there are actually two chapters in Nigeria (Abuja and Lagos). Maybe keeping one step ahead of all of the spammers requires lots of security professionals. Maybe there's a different reason. The population of Nigeria is roughly 150 million, or about half the size of the US, so there must be lots of businesses there that need information security people.

What are they thinking?

There's a new social networking site that just made me think, "What are they thinking?!" This is Blippy, which apparently lets you broadcast to the entire world what you're buying. What worries me about this is the fact that the payments information that this service needs to use is fairly sensitive. How are they getting this? Is the process secure?

Here's what the Blippy web site says:

Blippy is a fun and easy way to see and discuss the things people are buying.

Automatically share your favorite purchases from iTunes, Amazon, Zappos, Visa, MasterCard, and more.

Yikes! Are they actually getting data about purchases from Visa and MasterCard? This is one (of many) social networking site that I definitely won't be signing up for.

Collateral hacking

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

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

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

An end of an era

Today marks the end of an era. It's the day that the web cam on the coffee pot in the Trojan Room of the University of Cambridge Computer Laboratory was turned off in 2001, after roughly 10 years of operation. This was the first web cam. It was also probably one of more useful ones, and its demise is worth commemorating.

Why businesses aren't profitable

Conventional wisdom tells us that the global recession that we're seeing now is the result of the recent problems with financial markets. A closer look at IT industry analyst reports, however, might tell us that there's another reason that businesses aren't doing as well as they'd like to, and that's because of their use of IT. In particular, if you add up the TCO estimates for all of the IT products that a typical business uses, you'll find that the cost of their IT systems is much greater than their revenue. In other words, there's absolutely no way that a business can both use IT systems and be profitable at the same time.

This leads me to believe that one of two things has to be true. One possibility is that the TCO estimates that we often see aren't really very meaningful. Another possibility is that it's just impractical to use modern IT products because they cost more that they're worth. If the first of these two is true, then we have nothing to worry about, except perhaps wasting lots of time on TCO estimates that don't really tell us anything useful. If the second is true, then the global economy is doomed until we revert to more primitive, pre-dot-com-era technologies. Which one is more likely?

NIST gets in the Cloud Computing game

It looks like NIST is now getting interested in cloud computing. I found it somewhat interesting that the information on their web site about Cloud Computing is provided by their Computer Security Division, possibly indicating that security is one of the most important issues that need to be addressed before Cloud Computing can become more accepted.

Apparently, it's even tricky for NIST to sort through some of the claims that people make about Cloud Computing. According to the NIST's "Presentation on Effectively and Securely Using the Cloud Computing Paradigm v20", for example, there's a fairly wide range of estimates for the potential cost savings that Cloud Computing can allow: from 18 percent to 90 percent. That's a fairly big range.

Something that saves you 90 percent is certainly a much bigger deal than something that can save you 18 percent. If I had to bet, I'd say that the estimates of 90 percent are way off, and the real savings that are possible are much lower.

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.

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.

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.

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.

Thursday at the RSA Conference

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

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

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

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

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

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

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

Privacy and cloud computing

Cloud computing may or may not be a technology that changes enterprise computing, but it definitely has serious privacy implications. The World Privacy Forum recently sponsored a report, Privacy in the Clouds: Risks to Privacy and Confidentiality, that made nine findings about these implications. Here’s a summary of these findings that should give you a rough idea of the issues that cloud computing may cause.

• Cloud computing has significant implications for the privacy of personal information as well as for the confidentiality of business and governmental information.
• A user’s privacy and confidentiality risks vary significantly with the terms of service and privacy policy established by the cloud provider.
• For some types of information and some categories of cloud computing users, privacy and confidentiality rights, obligations, and status may change when a user discloses information to a cloud provider.
• Disclosure and remote storage may have adverse consequences for the legal status of or protections for personal or business information.
• The location of information in the cloud may have significant effects on the privacy and confidentiality protections of information and on the privacy obligations of those who process or store the information.
• Information in the cloud may have more than one legal location at the same time, with differing legal consequences.
• Laws could oblige a cloud provider to examine user records for evidence of criminal activity and other matters.
• Legal uncertainties make it difficult to assess the status of information in the cloud as well as the privacy and confidentiality protections available to users.
• Responses to the privacy and confidentiality risks of cloud computing include better policies and practices by cloud providers, changes to laws, and more vigilance by users.

The full report has more detail and is definitely worth reading for its more in-depth discussion. It's one of the more interesting and thought-provoking reports that I've read recently.

Parkinson's Law and Security Budgets

 

The fact that “work expands so as to fill the time available for its completion” is often called “Parkinson’s Law.” This was actually just the beginning of the article “Parkinson’s Law” by Cyril Northcote Parkinson that appeared in the November 19, 1955 issue of The Economist. This article actually had nothing to do with what’s now called “Parkinson’s Law.” Instead, it proposed a model of how government bureaucracies grow exponentially over time.

Parkinson actually expanded his original article into a book that actually included the first statement of the now-famous “What color is the bike shed?” argument that Poul-Henning Kamp first noted on the FreeBSD mailing list in 1999, but that’s a subject for another post.

An IT version of Parkinson’s Law seems appropriate in today’s economy. This version might be stated as “purchasing expands to fill the entire budget.” In other words, if an IT department has a budget of $8 million per year, then they’ll spend the full $8 million, but if they have $10 million, then they’ll spend the full $10 million.

The interesting observation is that the difference in the quality or quantity of the service that they provide with the two budgets usually isn’t really that big. If you cut your IT budget, your IT staff are forced to find less expensive ways to do things. These people are typically fairly smart, and they can often come up with some clever solutions that do the same things, but at a lower cost. It almost makes you wonder why they weren’t being as careful with the larger budget.

Cloud computing

Cloud computing is one of the most overhyped phenomena to have hit the IT industry in a long time.

Cath Everett, ZDNet.co.uk

There seem to be three main reasons that are commonly used to justify cloud computing. The first is that it provides a cheap and easy way to create IT infrastructure. This makes it appealing to smaller businesses, which seems to be the set of customers that like cloud computing the most. Maybe the fact that they might only need the equivalent of half of a server for something makes cloud computing appealing to them when they don't want to pay for the entire server. In any event, this claim seems like a reasonable one.

Another reason that is used to justify cloud computing is that can provide "utility computing" that's always available and can easily scale. Cloud computing proponents claim that it's easier to just add additional cloud computing resources than to go through the hassles of getting additional budget approved, ordering more equipment and dealing with the overhead that operating the additional equipment would cause.

I have to say that I find this argument unconvincing. These sound more like management problems than technical problems, which means that trying to solve them with technology is probably doomed to fail. If your organization doesn't want to pay for additional computing resources that they run themselves, they're probably not going to want to pay for additional resources that someone else provides either.

Cloud computing is also supposed to give you the ability to react quickly to changing business requirements. It's supposed to let you bypass your corporate IT department that may be unresponsive and overstretched. This also sounds like a problem with management instead of with technology. Your IT department exists to support other business units, and if they can't react quickly enough to changing requirements, this may be more a reflection of the management of the IT department instead of limitations of the technology that they use. Because of this, I don't find this argument convincing either.

This leaves two of the three reasons for cloud computing in doubt. The way in which cloud computing has experienced success seems to support doubting the weak claims. After all, most of the success that cloud computing has experienced has been with start-ups and other small businesses. These are the very businesses that benefit from its ability to cheaply and easily create an IT infrastructure.

Enterprises, which are the ones that would tend to benefit from the two weaker claims, are also the ones that haven't been as interested in cloud computing. If the only reason to use cloud computing that can withstand much scrutiny is that it provides a cheap and easy way to create IT infrastructure, it may actually never end up experiencing much success in the enterprise market.

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.

Design goals

Our current Internet runs on the TCP/IP protocol suite that was designed for use in the ARPANET, which completed its switch from the old Network Control Program (NCP) to TCP/IP on January 1, 1983. There's an interesting paper by David Clark called "The Design Philosophy of the DARPA Internet Protocols" that describes how TCP/IP came to be. We can also trace some of the security problems that have plagued the Internet since its beginning to the design criteria that this paper describes. The ARPANET was retired in 1990, but we're still feeling its influence today.

This paper tells us that there was a single fundamental goal in the design of TCP/IP and seven second-level goals. The fundamental goal was this:

The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilizations of existing interconnected networks.

There's probably no way that you can interpret that as laying the foundation for today's security problems. The second-level goals are where this creeps in. Those were the following:

1. Internet communications must continue despite the loss of networks or gateways.

2. The Internet must support multiple types of communications services.

3. The Internet architecture must accommodate a variety of networks.

4. The Internet architecture must permit distributed management of its resources.

5. The Internet architecture must be cost effective.

6. The Internet architecture must permit host attachment with a low level of effort.

7. The resources used in the Internet architecture must be accountable.

The last three of these are the ones aren't quite what today's business use of the Internet needs. In particular, cost effectiveness can be detrimental to security, a low-cost of attachment can be detrimental to quality-of-service guarantees, and accountability can be detrimental to efficiency.

You might argue that being cost effective doesn't really conflict with being secure if the costs of not being secure are properly accounted for, but security just didn't seem to be a concern of the architects of TCP/IP.

Now THAT'S a blacklist

No, hacker's didn't really take over the entire Internet this weekend. Instead, a glitch at Google caused them to add the "This site may harm your computer" warning message to every search result roughly between 6 AM and 8 AM yesterday.

I've always found that message particularly annoying. Neither a manual process nor an automated one is ever perfect, but every web site that I've seen that warning for hasn't seemed to be trying to harm my computer in any way. It's been wrong so often that I just ignore the warning when I see it. Maybe I just don't visit the right kind of web sites.

The future of the Internet

A non-generative information ecosystem advances the regulability of the Internet to a stage that goes beyond addressing discrete regulatory problems, instead allowing regulators to alter basic freedoms that previously needed no theoretical or practical defense.

J. Zittrain, The Future of the Internet and How to Stop It

I recently heard that Jonathan Zittrain's book The Future of the Internet and How To Stop It was worth reading. There are supposed to be interesting insights into information security in this book, along with a discussion of ways that it either will or will not work on the Internet. I started reading this book, over my recent Christmas vacation but had to give it up after a while. There may be useful insights in this book, but I couldn't understand exactly what it was trying to say in many places. The quote above is from one of those places.

I can't quite understand stuff that's written this way. That doesn't mean that it's a bad book; it just means that it's written in a way that's not suitable for me. You can even download a free copy of the book here if you want to take a closer look at it. If the style of the quote above doesn't bother you, you'll probably be able to find those useful insights that others have found in this book.

After I put down The Future of the Internet and How to Stop It, I picked up a copy of The Cellar by Richard Laymon, which I managed to finish in a few hours. The Cellar is a horror novel from the '80s in which you learn what's been killing unlucky visitors to a small town in California. It has absolutely nothing to do with information security, but that turns out to be OK every now and then.

Classic crypto fun

It turns out that there's a much better way to kill a few minutes than looking at movies of cats playing with their favorite toys on YouTube. Instead, you can try a simulator of the classic Enigma machines, the devices that the Germans used to encrypt diplomatic and military communications in World War 2. The picture above may be a bit hard to see, but it shows that if you use the key "LWM" to encrypt the message "HELLOWORLD" with a three-rotor Enigma, you get the ciphertext "KSWKUXBXOV." This simulator also shows how the Enigma works. At each step, it shows you the path through the machine that creates each letter of ciphertext and how the rotors move to change the setup that the machine will use to create the next letter of the ciphertext. If you're even more interested, you can also find a paper that describes how to break the Enigma's encryption here.

Rationalizing Illegal Activities

One evening I had a conversation with someone who mentioned he had downloaded a movie and watched it. Upon futher examination it turned out this had been an unauthorized download. He paid nothing, he never got permission to download it. I suggested that what he did was possibly illegal, or at least unethical. He responded with what I consider rationalizations.

First, he said, he never would have paid for the movie if he had not been able to download. In other words, it wasn't his kind of movie, so the production company would never have gotten his money anyway. So I asked him, "Would you sneak into a movie theater? How about if it was a movie you would not pay to see? Suppose you sneak in and find plenty of empty seats? When you sneak in to a movie you'd never pay to see anyway, you do not deprive the theater or movie producers any money, so why not? How about a can of caviar? Would you ever buy caviar? No? So is it OK to take a can of caviar from a grocery store? They'll never get your money whether you take the can or not, so why not take the can?"

Another argument he made was that the production company will make so much profit on the movie, one guy downloading it for free is not going to affect their bottom line. "Only one guy? Are you the only person downloading? If not, how many people doing this would it take before it becomes a bad thing? Ten, twenty, one million, 100 million? If it's 100,000, then is the wrongness split among the 100,000, so that you have only committed 1/100,000th of a wrong? Or is it wrong for you to be one of 100,000? Or is the wrongness attributed to the 100,000, and each individual bears no responsibility?" I also asked, "Honda is making huge profits these days. If you steal a Honda they'll still make lots of money. So is it OK to steal a Honda?" Of course not, he replied, but the movie and the cars are different.

Cars are a big ticket item. So would the situations be different if we were talking about cans of caviar? How about coffee mugs? Or a cheap key ring? How about a post card from Disneyland ("Hey, it's only 20 cents and I'm actually providing them with some advertising.")?

These things are different. When you make an unauthorized download of a movie (as opposed to stealing an actual physical copy of the film in a container), that does not prevent the production company from selling another copy of the movie. When you steal a car, a cell phone, a key ring, or a post card, the seller no longer has the ability to make money off of that item. (This is why unauthorized downloads are copyright infringement, not theft.)

However, I still think the reasons given are rationalizations. I think that people can rationalize improperly downloading movies and music because there is no tangible thing that is taken. It's easier to overlook ethics when nothing touches your skin. Also, the actual act of downloading is fairly easy (well, for someone who makes the effort to find out how to do it). If you had to develop some skills or use your fingers to actually touch the thing you were taking, if you could see the thing as a physical entity, it would not be so easy to rationalize away. Another element is how much you like the think your taking. The more you want something, the easier it is to come up with a reason to get that thing by "alternative means." And, of course, so many people are doing it ("so many people are getting it for free, I'd feel like a sap if I paid for it").

"The record companies are big corporations, they won't miss it. They're evil, they've been stealing from the artists for years." The record companies steal from the artists, so it's OK for you to steal from the artists as well? And don't we hear that excuse given in lawsuits? "Sure the guy was drunk and should have never been smoking while he was siphoning gas from the the big corporation's car, and sure what he was doing was illegal, but we'll find for the plaintiff because it's a big corporation, they have plenty of money, the insurance company will pay for it so no one is hurt anyway." When we hear that we think it's wrong.

"Other artists are figuring out how to make money in this environment, so if someone won't adapt, that's not my fault." Newspapers are finding the new environment of the internet makes it more difficult to make money, some are adapting to it with online editions. But if a newspaper doesn't adapt, does that mean it's OK to take a newspaper without paying for it?

The issue of downloading material is not cut and dried, the whole world of intellectual property is complex made even more complex by the internet. I'm not going to say there is a moral, ethical, and legal absolute on this question. However, making rationalizations is the wrong way to come to a solution.

Some thieves rationalize their activities by saying they only steal from people who can afford it, or that they need to put food in their bellies and the capitalist system we have makes it impossible for them to do so unless they steal. Some even say that it is your responsibility to prevent the theft: if someone is able to steal something from you, it's your fault, the thief bears no responsibility. (I recall an English soccer hooligan who, after 39 people were killed in Heysel stadium in 1985 when the hooligans launched an attack on Italian fans, placed the blame on the Italian fans because they didn't fight back hard enough.)

We see these rationalizations for what they are, very few people would accept them as valid ethical justifications. We know the thieves employ the rationalizations to allow themselves to continue doing what they're doing without suffering the emotional pain of a guilty conscience. (Well, some thieves, others have no ethical qualms about doing what they do.)

So when it comes to improper downloads, don't rationalize.

The vendors' dilemma

Vendors of security products do not always provide accurate descriptions of the strengths and weaknesses of their offerings, although such behavior would benefit the industry as a whole. Mathematical game theory provides a framework for understanding why this happens, but it doesn't tell us how to avoid the problems that this can cause.

The prisoners' dilemma is a classic problem in game theory, the branch of mathematics that models the interactions of competitors and predicts their actions. In the prisoners' dilemma, two prisoners who collaborated in a crime are interrogated separately. The police do not have enough information to convict either of the prisoners, but offer each of them a light penalty in return for informing on the other, who will then receive a harsher penalty. So if both prisoners remain silent then both are released and suffer no penalty; if only one informs on the other then one suffers a harsh penalty while the informant gets off with a light penalty; but if both inform on the other, then they both receive a light penalty. The best case for both prisoners is for them to both to refuse to inform, but we can expect this not to happen.

John Nash, the mathematician whose life was depicted in the movie A Beautiful Mind, was awarded the Nobel Prize in Economics in 1994 for his contributions to game theory.  Nash showed that when the prisoners' dilemma is analyzed by rational participants we can expect to end up with both prisoners informing on their companion, so that both end up in a position that is not as good as they could achieved through cooperation. The uncertainty in their decision-making leads them to a decision that they would have avoided if they had better information.

The prisoners' dilemma can give us some insight into the way in which technology vendors compete for customers. Vendors typically know more about their technology than their potential customers do, and vendors are tempted use their superior knowledge and experience to gain an advantage over customers during the sales cycle.

If all vendors fully explained the weaknesses as well as the strengths of their technology, then customers could make informed choices. But if one vendor decides to give customers misleading or incomplete information in order to gain sales at the expense of their competition, then they alone gain while their competitors all lose. Much like we can expect the prisoners in the prisoners' dilemma decide that informing on the other, we can expect rational vendors to fully exploit the information advantage that they enjoy over their potential customers. This might be called "the vendors' dilemma." Game theory tells us that the result that we can expect is that all vendors take advantage of their position relative to their customers in an effort to minimize the impact of similar tactics that they expect their competition to be using.

So game theory tells us to expect vendors to present inaccurate and incomplete views of their technology to customers and that this can result in a market failure when customer demand drops due to their inability to find high-quality products that are worth their price. It is likely that some security products have experienced market failures attributable to these mechanisms.

It has been estimated that over 50 percent of Public-Key Infrastructure (PKI) products sold ends up as "shelfware," software that is purchased yet never deployed. PKI software is fairly expensive, and it is reasonable to assume that corporate IT organizations did not intend to make a significant purchase they would not deploy. So why did people buy PKI software?

PKI vendors (which included the author of this post at one time) told their customers that PKI technology could solve many of their security problems by providing strong authentication, unbreakable encryption and legally-enforceable digital signatures. What the PKI vendors did not tell their customers was that virtually no existing applications used the digital certificates that their PKI software created and managed, so that it was very difficult to actually create a sound business case for purchasing PKI software. And while the PKI vendors boasted about the capabilities of their PKI toolkits for PKI-enabling applications, they didn't mention the fact that the toolkits were just too complex for the average programmer to use.

The results were purchases of technology that could not live up to their expectations and whose limited benefits could not justify the cost of their deployment. Eventually the PKI market crashed. Both vendors and their customers felt the pain of this crash, all of which could have been avoided if vendors had been a bit more honest about the strengths and weaknesses of their technology.

The vendors' dilemma tells us that we cannot expect vendors to give us an accurate picture of the strengths and weaknesses of their products, but you should try to get the best estimate of these before buying anything.

Going, going, gone

The huge amount of transactions on eBay shows that auctions have become a popular way of selling goods. This is realy nothing new, because auctions have been around for thousands of years. One of the most notable auctions of all time took place in AD 193 when the Praetorian Guard auctioned the entire Roman Empire to the highest bidder.

The winner of this auction, Didius Julianus, offered each soldier 25,000 sesterces, or 10 times their annual salary, and became the next emperor only to be overthrown and slain by Septimus Severus 66 days later. It seems likely that toward the end of his life that Didius Julianus came to regret his purchase, and felt what is commonly known as "buyer's remorse."

The consequences of winning most auctions are not usually as severe as those suffered by Didius Julianus, but economists tell us that we should expect buyer's remorse to be fairly common because we can expect auction winners to pay too much. Their reason for believing this assumes that bidders in an auction will not know the exact value of what they are bidding on, so that the bidder who overestimates this value the most will end up winning the auction and suffering the winner's curse of having paid too much for their purchase. The lower-than-expected returns earned by winners of auctions for oil drilling rights or wireless spectrum licenses seem to provide evidence that this does indeed happen.

Economists call the familiar "going, going, gone" auction that is used by Christie's and Sotheby's an English auction. In this type of auction, bids increase until only one bidder remains. Another common type of auction is the Dutch auction, which is named after the way in which flowers are sold in The Netherlands. In this type of auction, the price starts high and is progressively lowered until a buyer is found. Dutch auctions are also used by the Federal Reserve Bank of New York to sell options on overnight repurchase agreements, and were used to sell Google shares in Google's initial public offering.

Although the analogy is not perfect, there is a parallel between the market for information technology (IT) and a Dutch auction: new technology is usually introduced at a high price, but drops over time, just like the price of an item sold in a Dutch auction. At some point the price of the technology may become low enough so that some firms can justify its purchase. To consumers of IT, this looks much like a Dutch auction, except for the fact that prices may continue to drop after a purchase is made.

So if purchasing information technology is like a Dutch auction we can expect the winner's curse to affect IT purchases and expect that many firms will pay more than they should for IT because they overestimate the return on investment that they use to justify its purchase. Early adopters of technology seem particularly prone to this problem because they tend to pay higher prices for technology than others who wait until the technology drops in price.

The overestimation of the value of IT purchases may also be caused by problems in the deployment of the technology. The Standish Group, a consulting firm that specializes in tracking the rates of failure in IT projects, estimates that the chance of a trouble-free completion of any IT project is small.

Their annual CHAOS Report tracks the state of IT implementations, and recently estimated that the chances for a trouble-free deployment ranged from roughly 2 per cent for larger projects to roughly 46 per cent for smaller ones.

This report also found that while only 15 per cent of IT projects resulted in total failure, higher-than-expected costs were common, deployments often took longer than expected and often resulted in fewer capabilities than first planned. Our understanding of auctions may provide an explanation of why so many projects end up troubled.

Firms tend to allocate funding to the projects that have the highest return on investment. So we can think of different projects as bidders in an auction, with funds going to the projects that estimate the highest rate of return on the investment that they require. This means that firms will tend to fund projects for which they have overestimate their value the most.

Similarly, if a firm uses a system integrator for an IT implementation, the contract for the project is usually awarded to the lowest bidder. The lowest bidder tends to be the one who underestimated the true costs of a project the most, which then tends to result in projects with difficulties with costs and schedules once the inaccuracy of the estimates is discovered.

Understanding why some IT projects may result in difficulties can provide insight into ways to address the problem. If you are planning to deploy a relatively new technology, you should carefully consider your business case for adopting the technology. In some cases the benefits will be clear and you should proceed with the deployment of the new technology.

In other cases you may find that unrealistic expectations of the benefits of the new technology have led you to a bad decision and that you are on your way to experiencing the winner's curse as you pay too much for it. The safe strategy is to assume that you have overestimated the value of the new technology and to revise your projections downward to compensate for this to avoid a possible case of the winner's curse.

Similarly, you should ensure that all of your IT projects will have an appropriate return on investment in the event that its deployment encounters difficulties. Costs will often be higher than first anticipated, schedules will often slip and deployed technologies will often not offer all of the features that you had anticipated.

Most projects will encounter some of these difficulties, and being prepared for this will let you increase your chances of success and avoid feeling buyer's remorse for your IT investments. Again, the safe strategy is to assume that costs and schedules have been underestimated and to plan accordingly.

Technology is hard

Back in the days of the dot-com boom, I was talking to a major US airline about replacing their username/password system with certificate-based authentication. They already had a PKI deployed, at least in a minimal way – the people in the security division all had certificates and they had plans to roll the PKI out enterprise wide. They planned to use hardware tokens to hold users’ keys, and that’s why I was talking to them.

Apparently the people from other token vendors didn’t know much about side-channel attacks and other ways to hack hardware tokens. Because I was at least able to talk about this stuff in detail, they probably assumed that our tokens were proof against such attacks, although I certainly didn’t say that. But that was enough to make us the leading contender for a big order of hardware tokens. Hoping that an in-person meeting and demo would convince them to buy our USB tokens, a few of us hopped on a plane (taking flights operated by the airline that we were visiting, of course) and flew to the airline’s offices to show them how well our USB tokens worked.

We failed miserably.

A representative from the airline’s security group brought in his laptop for us to use in the demo, but when we plugged our token into the laptop’s USB port absolutely nothing happened. We had tested our tokens on a wide range of machines before flying out for the demo, of course, and we felt very confident that our demo would go off flawlessly. We were stunned by this failure and flew home determined to find out why we failed.

After a painful week of testing and research we found that there was a well-known problem with a particular chip set that made it not work with USB hardware, and it turned out that were unlucky enough for that particular chip set to be the one used in the laptop that was used in the demo. We hadn’t done our testing on any computers that used this chip set, so we were totally unaware that this problem existed. Even if we had, it would have been difficult to avoid the problem caused by it. Imagine asking a user if their computer uses a particular chip set – almost nobody would know the answer. So even if we knew about this problem in advance, it would have been hard to avoid in the demo.

Things like this happen all the time. Modern technology is complicated and doesn’t always work like it’s supposed to. If you’re in the business of developing new technology, this can make your job very tricky at times. Whatever you create has to work with the huge installed base of other technologies, each of which has their own particular set of bugs.

Before this particular incident, I sort of expected technology to work. Now I accept that there are going to be problems and that it’s probably impossible to find them all.

Innovation is Everybody's Business

For the upcoming FORTUNE Innovation Forum in New York City, two of the co-founders of Voltage Security, Matt Pauker and Rishi Kacker, discuss innovation and security in the FORTUNE Innovation blog.