5 Steps To Secure SaaS

To keep your off-site data safe, don't let vendors dodge the hard questions.

Adam Ely

March 3, 2011

6 Min Read
Network Computing logo

Just about any business function supported by enterprise IT has the potential to be delivered as a service or hosted externally. Software as a service is particularly popular. Our 2011 InformationWeek Analytics SaaS Survey showed a 13-point jump in the percentage of companies using SaaS, up to 60% from 47% in just 11 months. Need a new community outreach application? Build it for the cloud. E-mail maintenance got you down? Ship that app out. Can't get what you want from Amazon, Google, IBM, Microsoft, or Salesforce? Take a look at the hundreds of new SaaS providers, all of which are making grand promises of uptime, scalability, and cost efficiency.

But what about security?

SaaS vendors tend to shy away from that discussion. They disclose very little about their security practices, your rights as a customer, or exactly how your company's data is protected while in their care.

We predict that the growth of SaaS and other cloud services will eventually stall as compliance failures and data compromises are uncovered, at which time cloud providers will be forced to divulge more information. Until then, it's up you to perform due diligence before allowing sensitive data to reside off site.

What's In A Name? A Lot

When I managed security for a division of Walt Disney, my team evaluated several cloud providers for small community applications--for a contest on ESPN, for instance, or a short-lived Flash game built to promote a show debuting on ABC. These were applications with no sensitive data or even logins. Since Disney is so large, we usually got our security questions answered. We knew we were still taking some risks, since we had no day-to-day insight into the provider's network, virtualization infrastructure, or any internal controls, but we gathered enough facts to make informed decisions. We followed the same process when we launched a Google Apps pilot in some smaller divisions. Again, because it was Disney, Google was willing to share information to get the company signed on as an early adopter.

When you're Disney, life is good. But as I found recently when discussing security with a cloud vendor without disclosing the company I work for now (TiVo), not every customer has that leverage. This time, the rep wouldn't provide security information. He simply recited the marketing line and offered a SAS 70 report for the vendor's data center. This company had taken the stance that providing information on security controls is, in itself, a security vulnerability and said we should just trust it. Once the laughter died down, I asked a serious question: Why should I trust you with my data and the reputation of my company when you won't trust me with documentation or insight?

Unfortunately, for the vast majority of companies, it's difficult to get the formal information we need to make smart decisions about risk. In these cases, we need to take matters into our own hands.

How would you describe the security of your SaaS apps?

1. Go through back channels. We all have a duty to officially document controls so we can prove due diligence if anything goes upside down, but getting some off-the-record information never hurts. Ask around. Use social networks. Often, you'll be introduced to someone who can grease the wheels for official and unofficial answers.

2. Don't put stock in reference customers. Instead, seek out current or former customers on your own and ask them to share with you any relevant information they can, without breaking confidentiality agreements. Never believe a vendor's practices are acceptable simply because it has big-name clients, or clients you believe to be security-minded. Recently, we began talks with a vendor that had some impressive names on its roster. When we dug into the application, however, we found serious vulnerabilities that could expose data to attackers. The vendor was unwilling to discuss its internal practices, so we walked away.

We realize all companies have exploitable gaps. But no one should accept vendors that ask for trust but inspire none. I can't repeat this enough: Never rely on a client roster as validation of risk management practices. Every company has IT providers that slipped in the back door. This is especially true of SaaS vendors, which are often brought in by businesspeople without involving the risk team.

3. Go online to investigate the vendor's presentations and responses to any past security incidents. Some providers, such as Google, publish statements about their views on security and risk management; reading those can tell you a lot. Providers that show some level of understanding and due diligence may rise above the competition. Oxygen Cloud, for example, is a startup storage vendor that openly discusses its controls and uses security as a competitive differentiator. This doesn't mean Oxygen is more secure than a comparable rival, but all else being equal, this may move it higher up my list.

4. Ask to test controls. You'll never be allowed--or able--to evaluate every control that matters, but even a few vulnerability scans and code reviews can provide considerable insight into a SaaS provider's practices. Most reputable vendors let clients do some testing, with advance notice. If the provider shows weak controls on the simplest of items, it's rational to think that more advanced protections are lacking as well.

5. Use your leverage to its fullest. SaaS vendors, like the rest of us, are trying to build their businesses, and they always need marketing fodder. An attorney I once worked with added a line to every contract stating the vendor couldn't use the company logo or name in any way without written consent. Even if your company isn't in the Fortune 500, its particular use case or industry sector may make it a valuable reference account to the vendor. Use that as a bargaining chip to gain more security insight and other information.

Always ask for what you want--don't assume you won't get anywhere. Even a high-level overview gives you a starting point. While a SAS 70 certification may not mean a lot, it at least shows that the provider took the time to do something about security. See if the company has public-sector clients; the Google Apps infrastructure dedicated to government customers has been certified as fully compliant with FISMA standards; the rest of us can expect to receive some benefits from that compliance.

If the vendor reps you speak with can't, or won't, give you straight answers about security, if its responses vacillate, or if it outright refuses to provide any security-related insights, can you really trust it to have your best interests at heart? Don't buy the excuse that revealing information on controls is in itself a security risk. Security is more than vulnerabilities and remediation. It's about a company's ability to manage risk and remain compliant on an ongoing basis.

Sometimes it comes down to a gut feeling. If a vendor doesn't inspire confidence, or if you find reason to doubt it's doing a good job managing risk on your behalf, move on. New providers are popping up all the time, and if enough of us force the security issue, we'll all benefit from better visibility.

Adam Ely is the director of security for TiVo. Write to us at [email protected].

About the Author(s)

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights