Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Misunderstanding of issues of security and trust

Prev | Contents | Next

I think Carr's understanding of data security is "cloudy" at best.  If we talk about security then cloud computing should probably be named swamp computing.  Along with mobile technologies it is really dissolving the corporate perimeter, where most security efforts were concentrated in the past. 

First of all he need to extend his dictionary by including into it the term "boondoggle" which is equally applicable to his recommendation "Focus on vulnerabilities, not opportunities" as well as to many enterprise security projects.

 Boondoggle, in the sense of a term for a project that wastes time and money, first appeared during the Great Depression in the 1930s, referring to the millions of jobs given to unemployed men and women to try to get the economy moving again, as part of the New Deal.

It came into common usage after a 1935 New York Times headline claimed that over $3 million had been spent teaching the jobless how to make boon doggles.^[1]

Focus on vulnerabilities gave nothing if there are serious architectural problems. It's like trying manually catch all mosquitoes in the swamp.

The tyranny of innocent fraud

And the main danger is not the security on documents inside the "cloud" service providers, although it is also an issue (and blatant disregard for security is certainly possible as for "cloud centers" staff.  But the main danger to security is that to survive the "cloud centers" need to be really big and too big is often too big to exist and definitely too big to secure properly.

It is the amplification of consequences of  accidental errors (like typo in e-mail address used) to create serious security problems like sharing sensitive documents with complete strangers. This "amplification"  of innocent or not so innocent errors due to the size of the datacenter and sharing of computer facilities between many (sometimes criminal) clients is very underappreciated problem in cloud computing. It even can lead to FBI raid of the "cloud datacenter" the possibility that is often overlooked in adverting cloud computer model (When the FBI Raids a Data Center- A Rare Danger)

For example,  Google has millions of users and while in "normal" corporate environment in most case typo lead to bouncing of email of document sharing attempt, in Google gmail the story is can be different as you can see below.  also in a regular corporate email even if  the address obtained by introducing a typo exists this person belongs to the same corporation, which minimizes consequences. The mere scale of Google userbase creates additional problem.

Also Google in its infinite wisdom does not distinguishes between two email address if two names differ only by dots (like in "joe.user" and "joeuser"). And this doe not mean that there are no technical means to prevent this.

Google Apps for Your Domain (the pay service Google offers) actually includes a setting that admins can turn on that will either prevent users from sharing Google Docs or internal web pages with email addresses outside the company domain, or prominently warn users when they attempt to do so. But as you can expect in most cases this setting is disabled. So this is mainly the problem of fallible humans who get another powerful amplifiers for their errors and misjudgments. 

Here is a recent (Aug 27, 2008)  NYT article by David F. Gallagher that explains this danger quote nicely I’m in Your Google Docs, Reading Your Spreadsheets.   Please note that this is different situation from a misdirected e-mail: he not only could read the spreadsheets, he could also monitor updates to them over time through handy e-mail alerts, and even edit them, which could have led to some real mischief if he was the mischievous type. He essentially became an invisible member of the team. This is not something that is unique to "in the cloud" sharing system like  Google Docs.

Sharing documents with your co-workers via Google Docs sure is convenient. It can also be hazardous. Make one little typo and your sensitive data could fall into the hands of… someone like me.

Last spring a batch of invitations to collaborate on some Google Docs spreadsheets showed up in my Gmail account. The spreadsheets had something to do with Web advertising. I forgot about them until I signed up recently for Google Analytics, a free service that lets Web-site owners track visitors and monitor traffic trends.

Waiting for me there were live Web traffic reports for a whopping 130 sites, most of them belonging to heartland newspapers like The Muskogee (Oklahoma) Phoenix, The Oskaloosa (Iowa) Herald and The Shelbyville (Illinois) Daily Union. All of these are part of Community Newspaper Holdings Inc. (CNHI), a company based in Birmingham, Ala., that owns more than 90 daily papers around the country.

Closer examination of the spreadsheets, along with some online digging, indicated that a CNHI employee had most likely intended to share the reports and spreadsheets with an employee named Deirdre Gallagher. Instead, he or she typed in my Gmail address and handed me the keys to a chunk of CNHI’s Web kingdom, including the detailed financial terms for scores of Web advertising deals.

The spreadsheets were shared among several CNHI advertising and Internet executives, including Chris Muldrow, vice president for Internet operations, who said earlier this year that the company’s sites were getting tens of millions of page views a month.

Mr. Muldrow is on vacation this week, and other CNHI employees did not respond to phone and e-mail messages asking about the glitch. Someone at the company did, however, rescind most of my sharing privileges Wednesday.

There was a time when it would have taken a fair amount of criminal activity to get access to this much information about a company’s internal workings and Web site performance. Now an employee can accidentally drop it into the lap of a random outsider without even knowing that anything is amiss. That’s the power of cloud computing at work.

Most of the discussion about the security of online applications revolves around whether or not you can trust Google and its competitors to protect your data. In this case, CNHI needed to be protected from its own employee. Google could help with this by, for example, flashing a warning before you share a document with a person you have not exchanged e-mail with in Gmail. But in the end, security requires careful typing — and perhaps some careful decisions about whether some documents would be better left behind the corporate firewall.

Several reader responses provided additional facets of the problem:

Issues of control over data

First of all, most companies want control over their data. That means that using outside data storage increases anxiety. Which in turn mistake stupid and expensive solutions adopted without thorough review of benefits or under direct marketing pressure. Which in turn decease reliability. which in turn increase anxiety :-)

History shows quite convincingly that outside data storage could be also compromised by disgruntled employee or random hacker. there were several high profile cases of such compromises with Web hosting providers. Moreover the company that uses the service provider has no control on social atmosphere at the service providers (who probably will feel tremendous pressures to cut costs and might well have atmosphere of a sweet shop -- much like outsourcers). And nobody wants to give their intellectual property to somebody else due to glitches at the provider, no matter how cheap it is (usually it is not; see below) or how reliable the service is. 

Stealing electricity doesn't do the kind of damage that stealing  payroll data with SSNs does. In a way Nicholas Carr lives in the dream world of unpatented, unprotected information.  Information that does not matter. The real world is different.  As I mentioned before, any large scale breach into an ISP affects all its customers and PR losses can be tremendous, up to and including going out of business.  Such intrusions happened with several WEB services providers in 2007 and before. There is no reasons to believe that this trend will not continue as the most reckless customer providers with the most unsecure software serves as an entry point for intruder. and if this customer has access to root account the game is over.  Often the game is over even if he does not as availability of local account in many cases is enough for discovery of the vulnerability that can be exploited for getting root. 

Low attention to security happens in WEB providers world more often then Carr would like to assume and actually can be attributed to misdirected cost cutting efforts.  Putting lip stick on the pig after the fact with "Hacker Proof" certificates etc. does not solve the problem: infrastructure is complex, user population is diverse, staff is overloaded with other problems and overall security is as good as the  weakest link.  As Bill Thompson aptly noted in his BBC article:

It is often useful to conceptualize online activities as cyberspace, the place behind the screen, but the internet is firmly of the real world, and that is one of the greatest problems facing cloud computing today.

In the real world national borders, commercial rivalries and political imperatives all come into play, turning the cloud into a miasma as heavy with menace as the fog over the Grimpen Mire that concealed the Hound of the Baskervilles in Arthur Conan Doyle's story.

The issue was recently highlighted by reports that the Canadian government has a policy of not allowing public sector IT projects to use US-based hosting services because of concerns over data protection.

Under the US Patriot Act the FBI and other agencies can demand to see content stored on any computer, even if it being hosted on behalf of another sovereign state.

If your data hosting company gets a National Security Letter then not only do they have to hand over the information, they are forbidden from telling you or anyone else - apart from their lawyer - about it.

The Canadians are rather concerned about this, and rightly so. According to the US-based Electronic Frontier Foundation, a civil liberties group that helped the Internet Archive successfully challenge an NSL, more than 200,000 were issued between 2003 and 2006, and the chances are that Google, Microsoft and Amazon were on the recipient list.

Important problem with SaaS is that you data are data are stored in another firm in the format that might be proprietary — and then the firm going out of business. What happens to that data? Will you ever get it back? In what format and will it be usable? What about if their servers get hacked and your data is modified? If you are a regulated entity, will their policies about data loss affect you?

Another problem is connected with lawsuits. Situation is definitely more dangerous if company email is stored on the provider server:

Companies have no real choice but to comply with the law in countries where they operate, and I don't expect a campaign of civil disobedience from the big hosting providers. Those of us who use the cloud just need to be clear about the realities of the situation - and not send or store anything on GoogleMail or HotMail that the US government might want to use against us.

The latter is one of the most powerful argument against using "in the cloud" mail services.  France's decision to ban government ministers from using Blackberries since the messages are stored on servers sitting in data centers in the US and the UK belongs to the same category.

Encrypting the data stored in data centers won't always work as that denies the user benefits of using local processing power: the data need to be decrypted before that can be processed on the remote server. encryption might work for storage but this is a huge overhead and potential source of problems as encrypted archive is much less reliable source of backup then unencrypted: recovery of any damaged encrypted archive usually is not possible.  My experience suggest that company usually lose more data to encryption snafus than to any other data corruption source.

Issue of trust as applicable to providers, consultants and system integrators

Issues of trust are even more complex. IT managers also should think twice before assuming that consultants and systems integrators are always acting as objective advisers when recommending best-of-breed products and technologies, experts say. Many companies  [clients] still view consultants as neutral and bringing the best solution, but that's often not the case. They don't view it as a problem until a large project blows up in their face.

Recently, however, the ties linking vendors and service providers have grown tighter. Consultants and vendors have been investing in one another and launching joint companies.  Cisco Systems Inc., for example, invested $1 billion in KPMG Consulting LLC when it launched in January as a separate company from KPMG LLP.

As I mentioned above it's a myth to think you can bring in a systems integrator at the beginning and delegate responsibility for architecture to the integrator.  Just as the companies may be forming alliances with specific vendors, they also have varying levels of experience and skills in different technologies. And having final "résumé control"—in other words, being able to handpick the specialists from consultancies and integrators that will work on a project might be a limited remedy. The last thing you want is a consultant to come in and not be familiar with the technology you're implementing and use the company as a testbed. Among questions to ask

• What types of vendor alliances are in place?
• Does the consultant personally or his firm have an equity stake in the vendors?
• What commission or compensation does the consultant or his firm receive for selling vendors' products?
• How many consultants of the firm the consultant represents were trained on a vendor product through a given alliance?
• Does the consultant firm have any exclusive relationship with vendors? How many alliances does the consultant firm have in a specific category and how do they differ?
• What measures should be taken to limit influence of alliances on the strategy and technology recommendations

Actually not only storage of data is a privacy problem. In his book on Google, The Search, John Battelle  noted fundamental problem with "in the cloud" services:

" Every search we make, every link we click, every word we write, every moment we spend looking at a page - each is a little piece of data about ourselves that we leave behind.

Here is another warning. Garett Rogers made several interesting observation about possible pitfalls for users of  Google apps:

Things you need to think about:

• You are putting your application in Google’s hands
  Think about that for a minute. You are at the mercy of Google — if disaster strikes and Google one day disappears, you are done too. Or, more realistically, if the Google App Engine goes down for an hour, you are also down for an hour — and you will have no idea what happened. Even if you try and get an answer from someone at Google, you won’t. Just like Google Apps, it will be impossible to explain things to your end users.

  What if you are violating some terms of service (which likely won’t, but theoretically could happen to people without their knowing)? You thought making your company’s revenue dependent on AdSense was risky — what if your whole application was banned because of something you didn’t know about? Like I said, this scenario isn’t likely to happen — but it’s true that it could.

• Once you are in, you are really in
  Using Google’s infrastructure is very tempting. But any smart company should have some sort of plan for the future. What if you realized that you didn’t want to host your application on Google App Engine anymore? Good luck, almost everything you are given access to is proprietary — that means all your data is locked into BigTable in a format that isn’t like a traditional relational database. It’s also very tempting to use the API’s Google provides to interface with things like Google accounts.

  On top of that, you will be using the “webapp” framework that Google built that makes writing Python applications real nice — but good luck porting that to another language or putting it on a machine of your own.

• It’s free right?
  Not only are you locked in, you are completely at the mercy of Google’s future pricing strategy for the Google App Engine. It’s true that it’s likely to be cheaper than anything else comparable, but are you willing to take that risk? Right now it’s free, so everyone and their dog wants to at least give it a try — but what if your application actually really takes off? You will one day have to pay for your success, or shut down your service.
• Privacy should not be taken lightly
  Google has a very strong privacy policy — and personally I trust them. However, I’m trusting them with my personal information — you will be trusting them with all of your company’s data. These are two completely different things. If you have a low trust tolerance, you may not want to risk putting everything that belongs to your company behind Google’s doors. That said, I personally would still feel comfortable putting company data on their infrastructure — simply because I know it’s proven to be secure, scalable and robust over the last several years with their own services.

The quality of backups is another problem that is more complex then it looks in advertising materials. Often there is some kind of "vendor lock" that stimulates users to keep everything on the remote server, because remote application they are using does not provide a friendly way to backup data locally.  In such cases situations where a lot of data were lost due to the crash are not that uncommon.  Here is one relevant blog entry (The Problems and Challenges with Software as a Service  Gear Diary):

Gear Diary is a WordPress enabled site, so many team members use the online WYSIWYG editor to create and edit content. It saves drafts, allows you to upload (and even watermark) graphics/pictures, and is, for all intent and purposes, an online word processor, much like Google Docs.  When the site went belly up, most of the content headed south the border as well.  Most team members had not saved a local copy of their work…which got me thinking…

One of the biggest and hottest trends I’ve been hearing a lot about lately is software as a service, a la Google Docs, Office Live, etc. If you take the Gear Diary site issue as a point of reference, and apply software as a service (which is basically what WordPress is acting as), you get an interesting and fairly destructive situation.  WordPress doesn’t offer any kind of method of saving its documents locally, or in a format that can be read (or edited) by any other local application. Despite the fact that WordPress creates HTML documents, all data stays on the server.

If you bump into a server issue, i.e. you go down, your data gets lost. It happened to Gear Diary. It can happen to any user that uses a software as a service app. what bothers me more, is that unless there’s a specific viewer or offline editing tool for the document type, the data is useless.  Further, if the app doesn’t allow you to save data locally, an off line viewer isn’t going to do much good anyway.

Many users here (those that wor of WordPress and saving it as a text or HTML file. That at least gets the data out and saved to your local hard drive.  However, it doesn’t address disaster recovery on the client side (which was one of the big draws, aside from cost savings and the lack of deployment problems…all you need in most cases is a compatible browser…).

Focus on vulnerabilities vs. focus of architecture

As we noted above, Carr's recommendation to focus of vulnerabilities instead of opportunities is extremely dangerous.

The key to minimization of "technical glitches, outages, and security breaches" is the "state of the art" IT architecture which naturally belongs to the category of "opportunities".  This is an area were I spend several years of my professional career and I can attest that there is no better way to waist a lot of money (millions for a large enterprise) then concentrate on  vulnerabilities instead of opportunities which new technologies provide.

Part of the reason why many organization have multi-million dollars security boondoggles is that security like love is a very complex notion and its interpretation by end users, administrators and system integrators are all different:

• Users want to be reasonably secure, but without any additional hassle

• Administrators want the same, but without sacrificing the flexibility of their systems or existing administration tools and complication their daily workload

• System integrators and software providers want to sell you as much security solutions as possible, pushing it through the throat if necessary.

The key issue here is that security department actually serves as a Trojan house of system integrators and software providers. They just want the problem to go away, because they have no technical or architectural knowledge necessary for understanding what exactly caused the problem in the first place. thus they are easily believe in miracle cures and "snake oil" type of security products. What is even worse they sincerely believe that spending money on additional products will solve the issue just because they are completely unaware about the real roots of the problems and the ways of implementing  practical solutions. The view their mission more from the point of view of  "protecting their own butt, by adopting additional policies and procedures": the goal is the compliance with existing regulations and best practices, even if they are completely inapplicable to the particular situation. 

At the same time they do not possess the understanding of the infrastructure necessary for the creating of feasible policies and procedures so their creation usually suffer from heavy doze of red tape and are hated and by-and-large ignored.

the real solution is to view security problem as one (tiny) sign of architectural problem in the current infrastructure and as the first line of defense always try to improve the architecture in such a way that the problem can be compartmentalized, minimized or eliminated. That requires the presence of talented architects who need to have institutional power to bring the other parties to the table and  hammer down the best solutions even they are not understood by administrators (that can happen, not not very common) or security department (which is a usual situation).

Prev | Contents | Next