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
security vulnerabilities.
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."
/Hoff
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.
The security of SaaS suffers from a large agency problem: the SaaS vendor is motivated to not notice or share knowledge of security incidents with its customers. (Perhaps we're seeing this with Salesforce.com?)
The customers might want to demand audits, but the SaaS vendor would be overwhelmed, and so customers are pushed to read a report already done.
Thus the security of SaaS is even harder to measure than in-house security.
Everything with SaaS is harder to measure. It's not as simple as "Just say no to SaaS", but I would say, "Just say no to SaaS unless you can have more than one SaaS back each other up".
This is no different than BPO (business process outsourcing). If you have managed firewall, have at least two managed firewall providers (one for internal corporate firewalls, the other for Internet data center, or DMZ). Be ready to pull the plug on either one of them, and maybe have a third vendor ready to take a pulled-vendor's duty. Also make sure that they know this and constantly keep them on their toes.
It also depends on which SaaS provider you are talking about and which potential customer you are comparing them to. If you are comparing Veracode with a mom-and-pop SMB that hired one IT administrator, but installed 2,000 laptops and 200 servers in the past 2 years… I'm gonna go with the SaaS provider to be placed in the "more secure" category.
If you not only "speak" compliance, but really "know" how much each compliance criteria and audit standard adds (as well as the audit/review companies involved in the process and what kind of work they do), then you probably have some sort of idea about how secure the SaaS vendor is compared to any other given organization with the same criteria. This is the nice thing about compliance. I know what SAS70 Type I and Type II mean. I know what SOX means, but additionally I can find out who is doing external (IT COBIT) or internal (COSO) auditing. I know that GLBA and PCI are top-dogs, and that FISMA and HIPAA amount to firewalls and anti-virus. Additionally, I can look at ISO standards (ISO27k comes to mind first) or audits. I can even consider security-related operations process-improvements such as SixSigma or ITIL. These can all give me an idea of who is secure and how secure they probably are without launching a shell prompt or opening a browser.
Penetration-testing costs money. It should cost about ten times what most companies pay for it considering the specialized skills. Software assurance costs even more money than penetration-testing. Companies can't afford these things; which is why they turn to compliance to protect them. Lawyers are also expensive, if you didn't already know that.
You said, "It means potentially engaging a third party to test the assertions the company makes about their posture". This never happens. Nobody just goes and hires a third party to test somebody else's security. The SaaS vendor would never agree to it. Plus, any penetration-test worth it's weight in paper-reports-that-sit-on-desks is going to find something extremely critical and nasty just about everywhere. And if it doesn't — does that make the SaaS vendor "secure"? (Answer == NO for those unfamiliar with hypotheticals).
Instead, third-parties must be handled/engaged BEFORE they write the software and sell the service for this to work properly. It's still going to require expensive lawyers, but thems the breaks when you are looking for medium-assurance with third-party software. We can't even get our Internet-infrastructure-critical vendors to assume any liability. You get FIRED for using the word "Monoculture" to describe Mircosoft, Cisco, EMC, IBM, or Oracle.
My suggestion: have a tailor-made, one-size-fits-me, solution customized to your business running on your infrastructure inside your data center. Before the third-party begins, make sure that there is a secure software contract annex in place – http://www.owasp.org/index.php/OWASP_Secure_Softw… – and specify your own audit/review certification framework that obviously allows you to penetration-test and perform any software assurance you want during the programming phase, integration phase, functional testing, or operations/maintenance testing. Otherwise, you have to consider that anything else is less than or equal to "low assurance".
Dre Sez:
>> You said, "It means potentially engaging a third party to
>> test the assertions the company makes about their posture".
>> This never happens. Nobody just goes and hires a third party
>> to test somebody else's security. The SaaS vendor would never
>> agree to it.
If you really meant to express this as a generalization, then I'll just shrug it off. However, I can personally tell you from experience that your statement is categorically inaccurate.
Financial Services firms as well as those in the public sector routinely engage in hiring third parties to perform penetration tests on SaaS/ASPs/Outsourced Business Partners.
*I* have personally written this into my contracts and executed on my ability to do so 4 (four) times.
The crude economics of the situation simply means that if millions of dollars are on the line for the vendor, they have no choice but to agree or lose the business.
It happens ALL the time. The reason you don't hear about it is because of NDA's and the fact that these vendors are usually forced to fix the discrepancies by contract.
Further, the reality is that while my expectations are that I *might* find something "…extremely critical and nasty," all I'm really doing is performing due diligence beyond just accepting somebody's SAS-70. "Trust me!" is not a strategy.
If my SaaS vendor is compromised on a basic issue, how am I supposed to explain that to my Board or regulators? "Ummm, they *told* me they were secure."
This stuff is *BASIC* third-party due-diligence and vendor diaper and powdering.
If you were a vendor and told me "no" in response to me wanting to perform a supervised and mutually-agreed upon pen. test, you better well have a damned good reason for thinking I'm going to simply accept that as an answer.
/Hoff
Dood you are so right. SAS 70 Type II doesn't cover anything. Nobody is ever going to trust SOX or any audit standard for that matter.
The only way is through information assurance. Does this mean that Qualys and Veracode have a specific team of internal auditors to handle every single customer that has a requirement for AS5, GLBA, PCI, et al? How are they supposed to handle that kind of load? Doesn't that affect their ability to function?
Doesn't this drive the cost of SaaS through the roof? Doesn't it separate SaaS vendors into two categories: the haves and the have-nots? Doesn't this create some strange legal ground that nobody wants to walk on?
I have so many questions as to how this is going to scale. I knew this was going to happen, but it's so ugly! We've created a monster!!!!
Kinfe fight! See you @ Shmoo!
Loser drinks.
Either way, you win 😉