According to the data from statcounter.com, the Symbian operating system is still more popular than the ones that we hear about in the news so much: iOS and Android. That might change in a year or so, however.
That probably explains why most attacks on mobile devices target Symbian, doesn't it?
I wsa just looking through my old copy of Computer Parables. Even though this book was published in 1989, well before the dot-com era, it seemed to understand what the Internet would one day become:
"A programmer once built a vast database containing all the literature, facts, figures, and data in the world. Then he built an advanced querying system that linked that knowledge together, allowing him to wander through the database at will. Satisfied and pleased, he sat down before his computer to enjoy the fruits of his labor.
After three minutes, the programmer had a headache. After three hours, the programmer felt ill. After three days, the programmer destroyed his database. When asked why, he replied: “That system put the world at my fingertips. I could go anywhere, see anything. Because I was no longer limited by external conditions, I had no excuse for not knowing everything there is to know. I could neither sleep nor eat. All I could do was wander through the database. Now I can rest.”
Looking back at the dot-com era, it might be no coincidence that this parable was called "The Navigator."
New innovation and emerging technology brings with it opportunities for streamlining costs, eliminating hurdles for end users and reducing risks to the business. However, implementing game changing solutions can be unique to your environment, policies and processes.
That's why I invite you to join Voltage Security at its first customer summit in New York City on November 9, 2011. The summit will focus on data-centric security and will feature top Voltage customers such as Amex, Wells Fargo, State Street and others, who will discuss how they implemented encryption projects for mail, data and payments. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently developing new analyses of how companies use encryption. The summit features customers talking to customers—at last count this includesAmerican Express, BJ's Wholesale Club, Citigroup, Deutsche Bank, Fidelity Investments, JPMorgan Chase, UBS, State Street Bank andWells Fargo. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices. If you're interested in attending, please visit www.voltage.com/live.
The theme is 'Data-centric Security for a Data-centric World,' it's an area of huge attention. Data is the lifeblood of industry, commerce and leisure, every business and every transaction. That's why protecting it is such a serious and difficult responsibility.
Here's a quick scan of the Hot Topics we have on tap at Voltage Security Live 2011:
|
|
There's no question that every company continues to face a long serious of challenges related to these topics. The conference is designed to tackle specific issues and help formulate achievable solutions. The areas to be covered include:
Voltage Security Live 2011 will bring together the brightest minds in our field, all with considerable experience. There will be representatives from teams responsible for implementation, as well as enterprise and security architects looking for, and developing, best practices for data-centric encryption.
The sessions will cover customer project case studies addressing issues such as how to maximize end-user adoption for your B2C implementations and implementing data-centric encryption projects, while the Customer Track focuses on panel discussions and presentations on topics such as protecting outsourced data, eDiscovery and Archiving and securing application emails. There's also an Architecture Track, featuring panel discussions and presentations on topics such as key management architecture, security policy, enterprise applications and the web services API and scalable design considerations. And there's the Security Panel, with a discussion and general Q&A featuring leaders from the security community—Gartner Security Analyst, Encryption Architects, QSAs.
There's going to be a broad cross-section of security specialists attending, but some executives will find it particularly enlightening: CXOs and security leaders responsible for security strategy and programs; VPs/Directors responsible for security implementation; and architects responsible for security and application and enterprise architecture. If you have one of these roles, we think this conference is exactly right for you.
We know there are constant demands on your time - we hope to see you there.
Register at www.voltage.com/live
Back in June, I wrote about my experience with a financial website and their rules that made it tough to use strong passwords. There were three parts, here are the links to one, two, and three. The people I talked to assured me that they were updating their security and better passwords would be allowed.
Well, they rolled out their new security measures. Sure enough, stronger passwords are allowed. They allow special characters and passwords can be as many as 20 characters (the old limit was 10).
This is much better. I wonder why there is still a character limit. Why not allow someone to go hog wild and use the password, "I remember the vacation I took to the Great Smoky Mountains. It was great"? My guess is that they are afraid people will forget longer passwords, or their website building software has a box in which users enter the password and the software requires a limit, or both.
There are other financial websites I use that disallow special characters. I need to call them up and request changes. I certainly hope anyone reading this blog will also check the financial websites they use, see if there are any that make it hard to use strong passwords, and call them up demanding change.
Because the 20th anniversary of the World-Wide Web was just a few days ago, I thought that I should commemorate this event by trying some of the older web browsers to see how well they would work today.
I first tried the Voltage web site. Here's what it looks like in the pre-dot-com-era Mosaic 1.0. It's clearly not optimized for that particular browser, is it?
It actually turned out to be fairly hard to find a web site that actually doesn't look really bad in Mosaic 1.0. The web sites that once had links to text-only sites haven't been updated in quite a while and almost all of the sites that they once linked to are gone.
But I finally found one that worked - the web site of the Kennedy Center. Here's what it looks like in Mosaic 1.0.
Now that's a user experience that I hadn't had in quite a while. Back in the pre-dot-com era things weren't as fancy as today's Internet, but they were definitely a lot less annoying. No advertising. And no social networking sites.
I was reading a recent edition (PDF) of Symantec's MessageLabs Intelligence report when I came across this interesting bit of information:
This month, MessageLabs Intelligence uncovered evidence of spammers establishing their own fake URL-shortening services for the first time. Shortened links created on these fake URL-shortening sites are not included directly in spam messages; instead, the spam emails contain shortened URLs created on legitimate URL-shortening sites. Rather than leading directly to the spammer’s final Web site, these links actually point to a shortened URL on the spammer’s fake URL-shortening Web site, which in turn redirects to the spammer’s final Web site.
So services like TinyURL are apparently so useful that spammers have created their own versions. That's probably the best endorsement that TinyURL could get. As Charles Caleb Colton once said, "Imitation is the sincerest of flattery."
In Parts 1 and 2 (here and here), I described how I asked one financial institution why they put undue restrictions on passwords.
My first questions were to the "gatekeepers", the people I can contact by email or phone. Two people I talked with were really financial advisors, but they were passing my questions on to others who would know the answers.
The two questions I wanted answered were, "Why do you have restrictions on passwords (10 character limit and no special characters)?" and "You say the login procedures are to be changed soon, will you lift the restrictions on passwords?"
I just got answers (I'm paraphrasing)
One: We're not allowed to divulge the reasons behind the restrictions.
Two: We agree that the limitations are outdated. In our upcoming change (this summer), the character limit will be raised to 20 and some special characters will be allowed.
It's nice to get answer number 2. I don't think I'm responsible for the change. It could be I was part of the reason for the change. That is, maybe many people complained and that turned some heads. I suspect, however, that the real reason for the change is a security audit. The institution likely hired a consultant to critique their security and recommended updating the login process.
I would still like to get an answer to number 1. While talking on the phone with one of the financial advisors, I mentioned that the reason was likely to avoid cross-site scripting and SQL injection attacks. He said he was interested himself and would ask if those specific attacks were indeed the reasons.
It would be nice if the institution did not say, "We are not allowed to divulg that information." I doubt I'll ever get an answer. I wonder if it's because they don't want to give attackers any ideas (security through obscurity), they store passwords in the clear and don't want to lose customers over this, or they are a bit embarrassed of the situation in general. My guess is "security through obscurity". Anyone reading this blog will know that's not a very effective policy, but some people probably are simply not as aware of just how weak obscurity is.
Is there a moral to the story? Well, I have a number of other online accounts with password restrictions. I'm going to start contacting them as well. I hope more people look at their accounts and complain about any password restrictions they find.
I recently came across an archive of older versions of web browsers. I was more than a bit surprised to see how many different browsers have been used over the past decade or so. Most of these didn't survive for long, and only a few are still supported today.
Here's a list of what browsers that I found archived. It's much longer than I expected it to be.
Browser |
Source |
1x |
Science Traveller International |
Air Mosaic Demo |
Sprynet |
AllWorld Explorer |
G.O. International Air Service |
Amaya |
W3C |
Arachne |
xChaos |
ArcWeb |
Stewart Brodie |
Ariadna |
Advanced Multimedia System Design |
AtomNet |
Change 7 |
AWeb |
AmiTrix |
Beonex |
Ben Bucksch |
Bobby |
Center for Applied Special Technology |
Bohemian Net Browser |
BohemianNet |
BrownIE |
Compunet |
Browse2000 |
1st Choice Software |
CAB |
Alexander Clauss |
Cello |
Thomas Bruce |
Charlie |
Mundial Avenue |
ChiBrow |
KCS & Associates |
Chimera |
University of Nevada Las Vegas |
Contiki |
Adam Dunkels |
Custom Browser |
LION |
Cyberdog |
Apple Computer, inc. |
CyberGate |
BlackSun Interactive |
Cyber Passage |
Sony |
DigiCams |
DigiBand |
DOSLynx |
University of Kansas |
DR-WebSpyder |
Caldera |
ELinks |
Mikulas Patocka, the ELinks team |
Emacs-W3 |
William M. Perry |
Emissary |
Attachmate |
Flock |
Flock |
FreeWebBrowser |
Yellow Tree Services |
Galahad |
Jean van Waterschoot |
goAnywhere! |
Mikey LeBeau |
Grail |
Corporation for National Research Initiatives |
GrassHopper MDI Explorer |
Santrim Software |
HandWeb |
Smartcode Software |
HexaBit Junior |
HexaBit |
Home Page Reader |
IBM |
HotJava |
Sun Microsystems |
I-comm |
Talent Communications |
I-O-D-4 - The Web Stalker |
Escape |
I-View |
EnReach Technology |
iBrowse |
Omnipresence International |
iCab |
Alexander Clauss & iCab Company |
Internet Explorer |
Sprynet |
Internet Explorer |
Microsoft |
Internet Plus |
Dean Software Design |
Internet WorkHorse |
MarketNet |
KidNet Explorer |
Resource Communications |
KidSafe Explorer |
Arlington Technology |
LIS Web Browser |
Lahman Internet Services |
Links |
Mikulas Patocka |
Lynx |
Distributed Computing Group |
MacLynx |
Olivier Gutknecht |
MacWeb |
TradeWave (EINet) |
MacWWW (Samba) |
CERN |
MathBrowser |
MathSoft |
Microviet First Explorer |
Microviet |
Minuet |
University of Minnesota |
Mosaic |
National Center for Supercomputing Applications |
Mosaic |
QuarterDeck |
Mosaic |
SpryNet |
Mosaic |
Spyglass |
Mozilla, incl. Firefox |
The Mozilla Foundation |
Multilingual Mosaic |
Accent Software |
MultiWeb Viewer |
MultiSource |
MyBrowser |
Softorange |
Navigator |
Netscape Communications Corporation |
NCompass |
ExCITE |
NeoPlanet |
NeoPlanet |
Net-Tamer |
Net-Tamer |
NetCaptor |
Stilesoft |
NetCruiser |
Netcom |
NetForKids |
WebData Communications |
Net M@anager |
Virtual Innovations |
Netomat |
Maciej Wisniewski |
NetPositive |
Be, Inc. |
NetSentry |
Natdat |
NetShark |
InterCon |
NetShift |
NetShift Software |
Nuthin' But Net |
PAKSoft Productions |
Off By One |
Home Page Software |
OmniWeb |
OmniGroup |
Opera |
Opera Software |
PowerBrowser |
Oracle |
ProStream Browser |
PS Group |
pwWebSpeak Plus |
The Productivity Works |
Pythia |
Appian Interactive |
QuickScape |
QuickScape |
Safari |
Apple Computer, Inc. |
Santa's Browser |
Branded Browser Technologies |
SimulBrowse |
Seaglass Software |
SiteKiosk |
ProVisio GmbH |
SlipKnot |
MicroMind |
Softerm Plus |
Softronics |
SuperHighway Browser |
Frontier Technologies |
Surfin' Annette |
SpyCatcher |
SurfMonkey |
MediaLive |
Talking Browser |
WeMedia |
Talva Document Explorer |
Talva |
Tango Multilingual |
Alis Technologies |
The Other Browser-Emailer |
Pixelogic |
UdiWWW |
Bernd Richter |
Video On Line Browser |
Video On Line |
Voyager |
VaporWare |
WannaBe |
David T. Pierson |
Web-O-Matic Digital Browser |
Circle Group Internet, Inc. |
Web SurfACE |
ToolPool |
Web-Talkit |
Grover Industries |
WebExplorer |
IBM |
WebProwler |
MacroByte |
WebRacer |
Software Savvy |
Websurfer |
NetManage |
WebTV Viewer |
WebTV Networks |
WebView |
South Pacific Information Services |
WebWhacker |
Blue Squirrel |
Wildcat Navigator |
Harmony International |
WinWEB |
TradeWave (EINet) |
WorldWideWeb (Nexus) |
Tim Berners-Lee |
In Part 1, I introduced the topic of password restrictions and how they weaken passwords. I was especially upset with financial institutions making login less secure.
The next part of the story is my interactions with one company. First, here is an email I sent to customer service.
I can access my account online, that's fantastic.
To log in to my account, I enter a username and password, that's normal. There are also some security questions, nothing out of the line there.
However, there are severe restrictions on the password. I think this is completely unacceptable, especially for a financial institution. You are practically requiring customers use an unsecure password.
The password must be a minimum length, fine, but there is a maximum length of 10 characters. That's inexcusable.
Furthermore, special characters (such as !@#$% etc.) are not allowed. That's awful.
My guess is that special characters are not allowed so as to prevent SQL insertion or cross-site scripting attacks. If so there are more acceptable ways to get around those problems than limiting the character set in passwords.
My only guess as to why you would limit the size of the password is that you save the password in the clear in some database entry and the schema limits the size of entries. If so, that's an unpardonable sin when you're protecting clients' money.
Please let me know why you limit password length and disallow special characters. And please let me know if there are any plans in the future to fix this absolutely horrendous situation.
The response I received said they understood my concern and appreciated I spent the time to send my comments. The individual who responded said he would forward my concern on to a "feedback" team where it would be analyzed.
The writer then said the company was in the process of making changes to how customers will access their accounts online.
There was no answer as to why they do what they do. So I still don't know. But the email response did say if they can be of further assistance, to please call, and gave a phone number.
I called. I asked. The person on the other end said he would forward my question on to the appropriate people and get back to me.
The questions he passed on were, "Why the restrictions on passwords?" and "Will the new procedures allow the password to be stronger?"
So I still don't know, but it appears I am getting closer to a response.
You probably have several online accounts. Or you have bank, credit card, or other financial accounts that have online access. For these accounts you most likely log in with a username and password. When setting up the account and choosing a password, the website will often impose requirements on the password, such as minimum length, or must contain at least one upper-case letter and one number. But they often place limits on the password. Maybe there's a limited length or you are not allowed to use upper-case letters or special characters (such as #$%^ etc.).
I think that's awful. The more restrictions you put on passwords, the easier they are to crack. I think you would be hard-pressed to find anyone in the computer security industry who would disagree with that.
Financial institutions (banks, brokerages, investment companies) are protecting our money. They are protecting enormous sums of money. So you think they would be very interested in making sure their online security is strong. However, many financial companies are some of the worst offenders in placing restrictions on passwords.
One company I work with has limitations. I decided to look into it. I wanted to find out why they have limitations and then see if I could somehow convince anyone to change their policy. So this is my story.
Part 1 of the story. Why?
First, I decided to look around on the web to see if there was any good reasons for limiting passwords. Mostly what I found was people complaining about it. There were some who gave reasons, but then would say they are bad reasons. For example ...
I couldn't find anyone who admitted to writing the code that limited passwords, so I didn't get an explanation from the horse's mouth. But the speculation I found seems like it is probably close to the truth.
Part 2 of the story: Check my accounts
Many of my online accounts allow long passwords that contain special characters. Some of them were even financial institutions. Hence, I know it can be done.
I also accessed accounts from Europe and Asia. When I was on vacation in Europe and on a business trip in Asia, I accessed some accounts that did allow special characters. They worked. In Europe it took me awhile to figure out the special characters on the keyboards I used, but they worked.
Part 3 of the story: Go to the source
My next step was to contact one of these online companies and ask why they limit passwords.
I'll continue this part of the story in the next post.
I was recently looking at the Burton Group's report "Selecting Secure Web Gateway Solutions." Secure web gateways strike me as a technology that may be necessary, but also one that's not inherently interesting. Not like elliptic curves, for example.
What did seem interesting in this report, however, was the size of the databases of URLs that today's secure web gateways use: up to 150 million URLs in over 100 languages. That's probably enough to make a very complicated piece of software, but it's just a small fraction of what's possible. I recall reading that there are roughly 5,000 languages in the world today. I also recall reading that Google has indexed over 4 billion URLs. If those numbers are accurate then there's plenty of room for secure web gateway vendors to increase the size of their databases.
In any case, when you start working with systems that are that complicated you probably have to overcome all sorts of technical challenges, so I'm sure that the engineers that work on this technology have their work cut out for them. But I still think that I'd prefer to stick to elliptic curves.
According to the State of the Internet 2010 just released by CA, it certainly looks like web browsers are the biggest single source of security problems. CA estimates that browser-based exploits now account for 84% of all actively exploited vulnerabilities. When we look at CA's estimates for what fraction of vulnerabilities each of the main browsers has and compare those to the usage share of the browsers we see something.
If we expect hackers to be targeting browsers to help them carry out some sort of cybercrime, we'd expect the number of exploited vulnerabilities to be roughly representative of the user base for a particular browser. If that's the case, I have to wonder why Opera seems to have more exploited vulnerabilities that we'd expect.
Don't you worry about Wikipedia. We'll change it when we get home. We'll change a lot of things.
Homer Simpson, "Apocalypse Cow"
The Open Security Foundation, the people who maintain the most comprehensive and useful database of data breach incidents, are now also maintaining a database of cloud computing incidents. This is available at cloutage.org.
There are currently 213 incidents in this data base. Of these, 128 are classified as outages, 40 are classified as autofails, 37 are classified as vulnerabilities, 4 are classified as cases of dataloss and 4 are classified as hacks. Here’s how that looks when you graph it. Clearly, outages are still the most common problem, although they probably don’t cause users of cloud computing the same headaches that having sensitive data compromised does.
Even though it's been almost four years since John Morgan and Jennifer Brown published "Reputation in Online Auctions: The Market for Trust," it looks like things haven't changed much since then. This article describes how people use lots of small transactions at on-line auction sites to artificially inflate their reputation. In some cases they then use that positive reputation to give unlucky buyers unwarranted confidence in them that they then exploit.
This article has a story, for example, about a person who bought lots of items being sold on eBay for the very purpose of increasing a user's reputation. They apparently spent about $100 on this and then used the positive reputation from lots of successful $0.01 transactions to open the door to shady real estate deals in which they made several thousand dollars.
In any event, I was curious whether this was still the case. In Internet time, four years is quite a while, so I thought that things might have changed since then.
Apparently they haven't.
A quick search for "positive feedback" on eBay returns a list of lots of items that are still being sold just to increase a user's reputation. I didn't see what things were like back in 2005 to 2006 when Morgan and Brown were doing research for their paper, but I'd guess that they weren't much different.
Morgan and Brown talk about things being sold for $0.01 that were designed to just boost a user's reputation, and it looks like prices are a bit higher these days. I don't see any "Buy It Now" auctions for $0.01 for which you really don't get anything, and it looks like $1 is a more typical price now. This makes be think that scams that take advantage of the trust created by positive feedback are probably more prevalent now than they were four years ago.
I recently read "Social Media and FINRA: Twitter and LinkedIn Considerations," a report from the Burton Group that talks about the regulatory issues that businesses may run into when their employees use either Twitter or LinkedIn. These issues are all related to FINRA's Regulatory Notice 10-06, "Guidance on Blogs and Social Networking Web Sites."
I'm certainly not an expert on the details of FINRA's guidance, but some of the conclusions of this report made me question whether or not some of the ways in which securities firms are regulated really make sense.
According to this report, for example, a securities firm may get into trouble with regulators if one of their employees has selected "Business deals" as one of the things that they're open to receiving messages about through LinkedIn. Providing recommendations for other people on LinkedIn can also apparently get you in trouble with regulators. The report lists several other examples, none of which made any sense to me at all.
So it if assume that the Burton Group's analysis is correct, which seems like a reasonable assumption, it certainly seems to me that the way in which the securities industry is regulated doesn't make much sense. And because it looks like we'll probably see more regulation of that industry in the future, I'd expect things to get much worse before they get any better
In a previous post, I noted a new social networking site called Blippy that basically lets you see what your friends are buying. Maybe if you're too young to remember the dot-com era, that sounds like a perfectly reasonable thing to do. To me it just sounds like a huge privacy problem just waiting to happen.
According the what's posted on Blippy's web site, the problems have already started. In particular, it looks like Blippy incorrectly considered raw transaction data to be harmless at one point, and some of it ended up the HTML on some of their web pages.
Yikes!
Blippy has a five-step plan for making sure that this doesn't happen again:
These steps look like a good move in the right direction, but why weren't these done in the first place? And with all the news about PCI DSS these days, who could possibly have thought that credit card transaction data wasn't sensitive and needed to be protected?
Not too long ago, Amazon introduced its EC2 Spot Instances, a new approach to cloud computing. Here's how Amazon describes this:
Spot Instances are a new way to purchase and consume Amazon EC2 Instances. They allow customers to bid on unused Amazon EC2 capacity and run those instances for as long as their bid exceeds the current Spot Price. The Spot Price changes periodically based on supply and demand, and customers whose bids meet or exceed it gain access to the available Spot Instances. Spot Instances are complementary to On-Demand Instances and Reserved Instances, providing another option for obtaining compute capacity.
Essentially, EC2 Spot Instances lets you bid for unused time on Amazon's systems, and it's the first real step towards making computing a commodity service. I believe that the biggest impact of cloud computing will be from EC2 Spot Instances and similar offerings, but probably not in the way that most people would guess.
I really don't see cloud computing ever becoming a true commodity service. Despite all of the talk about standards for cloud computing, cloud vendors really have no incentive to make their technologies interoperable, so I doubt that we'll ever see it become a reality. The huge number of different national laws will also make it very difficult for cloud computing to ever become a true commodity. You'll always have requirements that certain data essentially can't leave national boundaries either due to regulatory restrictions or other political issues. I don't foresee an easy solution to these problems, so I don't foresee the market for cloud computing ever becoming quite like markets for other commodities. I doubt that we'll ever see things like derivatives and hedging for cloud computing, for example.
Instead, I see the real change that Amazon's offering will create is that people will start to question the value of computing and do a better job of trying to quantify it. After all, you really shouldn't be bidding for computing services if you don't really know how much the computing is really worth to you. Once businesses get accurate metrics for the cost and benefits of enterprise software, the enterprise software market will change dramatically.
I believe that the opportunity to buy cloud computing as a commodity, even on a relatively small scale, will get businesses to start thinking about exactly how much computing is worth to them. This will then lead them to think about exactly which applications are really worth their cost. Once they have more accurate metrics, I believe that they'll find that some enterprise computing simply isn't worth what they're paying for it. We'll eventually find that while some types of enterprise applications make sense, others don't.
This will lead to either the collapse of parts of the enterprise software market or some difficult times for some software vendors as they try to make their offerings add value that's substantially more than the cost of the software. The products that remain after this big shake up will be the ones that should have been there in the first place. The products that disappear will be the ones that never should have been deployed. What we'll be left with will be much more efficient that what we have today, and that increased efficiency will be one of the biggest benefits from cloud computing.
According to a web site traffic ranking web site that I came across today, the most common upstream web site for Voltage's corporate web site is actually an on-line dating site. That made me wonder exactly who is coming to Voltage's web site and why. (It also made me question the accuracy of the rankings, of course.) I would have thought that people would come to our site to learn about either Voltage's technologies or products, but I appear to be wrong in this particular case.
An alternative explanation is that there are lots of single, attractive men and women who work at Voltage, and people who view their on-line dating profiles want to learn more about who their employer is. If that's the case, our marketing people might be able to use this slogan as the basis for a campaign of some sort:
Voltage: it's not just our technology that's hot.
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 and the fact that cryptography can go a long way towards solving some of the tricky problems that cloud computing can cause, it was rarely mentioned at this year's conference. This struck me as being a bit ironic.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
Hackers are clever, and they’ll find a way to exploit almost anything. One example of this is how they’ve learned to use blogs to distribute spam and other malware. But for every hacker finding a new way to carry out attacks, there’s apparently a security vendor coming up with a response. At the RSA Conference this week, I saw some interesting demos of the counters that security vendors have created to the problem of hackers using blogs to help them carry out attacks.
In most cases, spam email outnumbers legitimate email by a huge margin. This seems to be true with comments that are posted to blogs also. If I go to the management console for this blog, for example, I now see over 3,400 attempts by spammers to get this blog to link their sites that claim to be selling interesting products, but are probably just trying to collect sensitive personal information. Looking through a queue of over 3,400 items just isn’t feasible, but security vendor Websense has a product that will do this for you, and in most cases, they’ll actually do this for free.
This product is Defensio, and I saw a demo of it at the RSA Conference yesterday. Websense claims to have sophisticated adaptive algorithms that let their technology adapt to the efforts of spammers to bypass their filtering. That’s not the sort of thing that’s easy to show in a demo, so I’ll have to trust that this really happens behind the scenes.
Defensio works by routing potential malicious posts through Defensio’s servers, which make a decision about whether or not the post is spam. This architecture also lets Defensio identify and react to new attacks on blogs as they’re developed and used by hackers. I seem to recall that anti-virus products worked this way at one time, but anti-virus vendors seem to have now discarded this model. It will be interesting to see if this also happens to Defensio’s technology in the future.
Unfortunately, Defensio is only available for blogs that are hosted by WordPress. This blog uses TypePad, which means that I can’t actually try it and see how well it works in practice.
In addition to blogs, it seems that newer social networking services like Twitter have already been abused by hackers. Twitter users are already receiving spam (twam?), and if you follow the Twitter user @spam, you’ll see updates on how this spam is happening, who it’s coming from, etc. You might even find it amusing that when you visit the Twitter page for the user @spam, you see the message “Hey there! spam is using Twitter.”
Maybe there’s a start-up out there right now that’s figuring out a way to keep Twitter uncluttered. I’ll have to look for this at next year’s RSA Conference.
Cloud 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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
 |
|||
|
|||
 |
