Web Applications vs. Hosting on the desktop/server - Security? (updated)

As the owner or manager, or even employee, of your company, you need to be aware of the security of the data you entrust to computer systems. You don't want to have it deleted by flaw, crook or crash, and you certainly don't want it stolen and used for nefarious purposes by crooks - or even inadvertently published to the world for all to see. This has been a problem since business started using computers, but the potential for the crooks or the world to see your data has increased recently with the advent of web-enabled applications providers and their sale of access to their facilities where your data is entered and manipulated by their software, on their computers, and with their security model.

This is no more true than in the centralized e-mail business as a recent article about Yahoo's system (now fixed according to The Register - June 19, 2007) points out a huge vulnerability in their web front end - one that can allow someone to take over your account and at minimum read all your e-mail, and at worst pry their way into your life in many different ways; sending nasty e-mails as if from you being the least of them.

You should understand that just because someone is "good" at doing a particular thing (like e-mail, or Customer Relations Management) as an internet service provider doesn't mean that they do a good job of protecting your interests. Only contractual, balanced agreements that include provisions for testing and data protection, with real penalties for transgressions, can protect you, your company, and your customers' information from damage. The typical "EULA" for many sites is so one-sided that you might just as well publish your data in the local laundromat yourself and cut out the middle man - well, almost anyway.

A bit of history will put this into perspective.

Away back in my past, computing was done on centralized systems - mainframes. The data and applications were looked after by the gods of the data center, and all was good, if a bit expensive. Even if the center was a "service bureau" (Like Dataline Systems, a company I worked for in the mid '70s - several DEC System 10 mainframes in Toronto with customers across Canada) there were contractual service guarantees and potential lawsuits if something got lost, strayed or stolen.

Then along came the mini-computer revolution; PDP-8, DG-Nova, and the like, and we took control of the data and programs and put it closer to the office where it was generated and needed. But we still mostly let the gods of computing look after the data's security, backups, etc. There were few networks, and no "inter-networks" so most security was internal and/or disaster related (off-site backups, etc.)

And in the early 1980s came the micro-computer revolution - and the data security suffered greatly. Individuals, most of whom had no clue where the data was no matter whether they were in front of a micro-computer, mini-computer terminal or card-punch machine, ended up with the data on their desktop - and lots of it got lost, strayed or stolen - and many times deleted or just plain screwed up.

Then Novell (and others) came along and the micro-computer network server was born. No longer was the data all on the desktop - it was on that server in the corner (again) and policies/procedures were ingrained into some relatively technical person made responsible for doing backups and setting permissions, etc. And things were good, even when Microsoft decided to compete in this area with their own networking systems.

And in the early 1990s came the Internet, and shortly, the Web; and security became a problem of a whole new kind. Now someone on the other side of the world could enter your local network, steal stuff or delete it, and be gone before you knew it had happened. The days of firewalls and massive changes to the "security" of the typical Windows desktop were upon us.

In all this time though, the applications we used were under the control of either us as individuals, or of out chosen IT personnel. We knew who to talk to about security problems, and even if we didn't do a good job of it, the security of our information was in our hands.

Today we are coming full circle it seems; our applications are starting to be run on massive, centralized systems again. This time though there is a difference; we don't have any view into the data and systems security of those who run these Web-centric applications, and there is a whole new class of security problem associated with the fact that their interface faces the "wild-wild-web".

Our Customer Relations Management (CRM) application may run on one company's facilities while our desktop search on another, and our shared document editing on still another. Our data is mixed with potentially hundreds or thousands (or more) others' data, and presents a wonderful target for attack by "interested parties" - the crooks. Yet we have no way of testing our suppliers' systems for vulnerabilities; well, we have ways, but we're not allowed to use them because we'd be tarred as being the bad guys ourselves. That's the problem!
You see, when you own an application and run it on your own systems/servers, part of what your IT department can do is test it for errors and vulnerabilities. They can create a test network and apply many of the tools the crooks are using on the real internet to crack applications - cross-site scripting, SQL injection, buffer overflows, and the like. These are all points of entry into web-based applications that, due to the complex nature of the web itself and the fact that many programmers either  don't know how to write secure applications for the web, or through just plain bad luck have ended up leaving a hole that only "penetration" testing will find.

But if I have my application running on someone else's servers and all I see is the web front-end, how do I know my supplier has a secure system? I don't, and unless I get my supplier's permission, I can't do any testing of the system to see if I can break it (and if I can break it, you know others can too) and in most cases there is no other "independent" testing done for exactly the same reason - the owners of the sites won't give permission to anyone to attack their site and "prove" it secure (or more likely insecure) - so only the crooks , who don't care and hide behind their millions of bots in their bot-nets to avoid being found out, will find the vulnerabilities.

So as the owner or manager of your company, you have to take into consideration whether or not such a web service provider can or is doing a good job - or whether your company can stand the potential loss of the data that your employees are putting into the web application - loss in terms of "escaped to the hands of the crooks" as much as "lost as in gone forever" due to server crashes, malicious acts, etc.

I'll note that one of the things I do for my customers is risk assessment along with financial assement of various ways of achieving the ends that I'm called upon to study. Managing the risk is all important - but even understanding that it even exists is sometimes difficult for some to get.