Reprise: On-Demand SaaS Vendors Able to Secure Assets Better than Customers?
Back in August I wrote a post debating against the notion that SaaS vendors were apparently, by definition, "…able to secure assets better than customers."
My position on the "quality" levels of security from SaaS vendors was reasonably straightforward. I’ll summarize it here:
Not one to appear unclear on where I stand, I maintain that the SaaS
can bring utility, efficiency, cost effectiveness, enhanced
capabilities and improved service levels to a corporation depending
upon who, what, why, how, where and when the service is
deployed. Sometimes it can bring a higher level of security to an
organization, but so can an armed squadron of pissed off armed Oompa
Loompa’s — it’s all a matter of perspective.
So just to be clear, I believe in SaaS. I encourage its use if it
makes good business sense. I don’t, however, agree that you will
automagically be *more* secure. You maybe just *as* secure, but it
should be more cost-effective to deploy and manage. There may very
well be cases (I can even think of some) where one could be more
or even less secure, but I’m not into generalizations.
This is all a matter of context; what sort of data is stored, what value does it hold, who can access it and what assessment of risk has been performed to determine the impact to the company should it fall into the wrong hands?
Many times the "security" of the SaaS service comes right down to basic security practices such as access control. For example, I’ve seen multiple times that SF.com login accounts of salesfolk that went to competitors were left enabled after separation, potentially exposing the forecast, pipeline, customer service records and customer details of the entire customer base. That’s not the SaaS vendor’s fault, but is a potential issue systemic to the model.
As the adoption of SaaS increases 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 those supposedly impenetrable perimeter boundaries we’ve spent all that time and money on.
Again, that means more than reviewing a SAS-70 or taking the vendor’s word that they are secure. It means making sure your policies extend and are applicable "outside the castle." It means potentially engaging a third party to test the assertions the company makes about their posture.
A great example are two recent debacles from SaaS vendors Salesforce.com and Monster.com. Brian Krebs from the Washington Post recently did a great job illustrating the issues that a breach from an SaaS vendor causes; there’s a "secondary market" for breach data and once the information is loose, the lost trust can mean lost business:
A database of e-mail addresses and other contact information stolen from business software provider Salesforce.com
is being used in an ongoing series of targeted e-mail attacks against
customers of several Salesforce.com business clients, including SunTrust and Automatic Data Processing Inc. (ADP), one of the nation’s largest payroll and tax services providers.
In August, job search giant Monster.com‘s resume
database was breached by hackers, exposing confidential data on 1.3
million job seekers. The attackers then used the contact information
from that database to send users targeted e-mails that appeared to come
from Monster.com. Recipients were directed to click on a link in the
message, which tried to install malicious software through Web browser
Salesforce.com and Monster.com provide valuable SaaS functions to corporations globally and it illustrates the fragile mantle of trust upon which we tread. There exists a tenuous balance when outsourcing applications and information processing/storage to a third party.
Some folks argue that any information entrusted to a third party business partner or vendor (email addresses included) are "private" while others might suggest that if you’ve decided to outsource this function beyond the realm of your ability to protect it, any information outside the castle should be considered public and dealing with its exposure should be something you’re prepared for.
This comes down to a maintaining a posture of what I call Information Centricity and an appropriate level of information classification paired with the assessment of risk assuming something ‘bad’ happens to it.
As a free piece of advice to SaaS vendors and customers alike, comments like this are not a good way of handling the press regarding a breach:
Salesforce.com’s Bruce Francis, the company’s vice
president of corporate strategy, declined to say whether any
customer-specific data was stolen, and refused to answer direct
questions about the alleged incident, saying that doing so would not be
in the best interests of its customers. He did, however, stress several
times that "phishing is a fact of life for any company that does
business on the Internet these days."
Update: Bill Brenner just did a nice write-up on this same topic and was kind enough to reference/quote me and the RS Blog. You can read his piece here. I also got some interesting feedback from Bob Warfield over at the SmoothSpan blog ( a fantastic SaaS reference) which I will ask if I can reprint.