News Stay informed about the latest enterprise technology news and product updates. and the debate over SaaS security, email confidentiality

Bill BrennerSoftware as a Service (SaaS) is growing in popularity, and along with it comes the inevitable debate over the security implications.

Driving the debate is recent news about a security breach affecting clients of SaaS vendor, including Automatic Data Processing Inc. (ADP) — one of the nation’s biggest payroll and tax services providers — and SunTrust. Security Blog Log

The Washington Post had an item on the incident a couple weeks ago, reporting that a database of email addresses and names for SunTrust and ADP employees was pilfered from The data was apparently exploited for a phishing scheme urging would-be victims to download a .pdf in reference to an identity theft claim. Thousands of email addressed were reportedly compromised, and about 500 people apparently received phishing emails.

Arieanna Schweber writes in the Absolute Software Laptop Security blog that the issue at hand is not phishing, since it’s a fairly universal problem now, but whether or not people should be notified if their email address is compromised.

That said, I want to use this week’s column to solicit feedback not only on the question of whether compromised email addresses should be treated like compromised credit card and Social Security numbers, but on the issue of SaaS security in general.

First, a little background on SaaS, courtesy of my friends at and Software as a Service (SaaS) is a software distribution model in which applications are hosted by a vendor or service provider and made available to customers over a network, typically the Internet. SaaS is becoming an increasingly prevalent delivery model as underlying technologies that support Web services and service-oriented architecture (SOA) mature and new developmental approaches, such as Ajax, become popular. Meanwhile, broadband service has become increasingly available to support user access from more areas around the world. SaaS is closely related to the ASP (application service provider) and On Demand Computing software delivery models. IDC predicted SaaS would make up 30% of the software market this year and will be worth $10.7 billion by 2009.

Benefits of the SaaS model include:

  • Easier administration
  • Automatic updates and patch management
  • Compatibility: All users will have the same version of software.
  • Easier collaboration, for the same reason
  • Global accessibility.

The question for some is whether or not a SaaS vendor can secure those Web applications better than its clients could on their own.

Rational Survivability blogger Christofer Hoff believes in SaaS in general, but isn’t so sure using it means better security.

“I believe in SaaS [and] encourage its use if it makes good business sense,” he writes. “I don’t, however, agree that you will automatically be more secure.”

Hoff wisely notes that as SaaS adoption grows, driven by compliance, outsourcing, or efficiencies of a leveraged business model, we’re going to have to pay more attention to what it means to have our data spread out beyond the supposedly ironclad perimeter companies have spent so much time and money on.

“It means making sure your policies extend and are applicable outside the castle,” he writes. “It means potentially engaging a third party to test the assertions the company makes about their posture.”

The security breach is a good example of why this is necessary, Hoff says. There’s a secondary market for stolen data and once the information is loose, the lost trust can mean lost business, he notes.

The other question, of course, is whether email addresses should be treated as confidential data.

Schweber presented both sides of the argument in her blog entry: Some would argue that email addresses are available in the public sphere, she says, but others would argue that some remain private and that access to emails in list form increases the risk for phishing scams and potential identity theft incidents.

Jack Dunning, keeper of The Dunning Letter blog, writes that email addresses are just like Social Security numbers — everywhere and fairly easy to access.

“The big difference,” he says, “is the connection between the address and a company which lends it the necessary credibility, and that is why we need to begin to secure this medium before this newest hoax gets out of hand.”

What do you think? Can SaaS vendors provide their clients with better security? Should emails be treated as confidential data?

I ask the readers to opine.

About Security Blog Log: Senior News Writer Bill Brenner peruses security blogs each day to see what’s got the information security community buzzing. In this column he lists the weekly highlights. If you’d like to comment on the column or bring new security blogs to his attention, contact him at

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Great article. I agree that perhaps vendors can step in and offer a solution to cover data not currently considered confidential. I think that no matter what type of data is breached, it is a hit to credibility. If that data is being used in creative ways by phishers, there is a greater issue of responsibility, not just compliance.
It's not "whether or not a SaaS vendor can secure those Web applications better than its clients could on their own." It's "will the SaaS vendor secure those apps appropriately for all clients." The decision of how much security is good enough will be made by the SaaS vendor, based on their financial model and risk tolerance, and most of their clients will never realize that their own risk model isn't considered except very indirectly. Likewise, notification of email address exposure shouldn't be left to the discretion of the compromised (and thus embarassed) vendor. Clients of SaaS vendors should include contractual requirements for notification of any breach or compromise, regardless of extent. It's part of the information required to properly evaluate SaaS vendor quality of service.