Of all the options for cloud services, Software as a Service (SaaS) provides the least amount of insight and control. With SaaS, organizations are consuming a software application and have to rely, in most cases, almost completely on the security controls and promises of providers. All we know is what they document, what they let us see and what they promise in their contracts.
SaaS is a software application shared with others, and even the most secure providers usually need access to our data at some point. They might never take a peek, and might have a hearty array of security and auditing controls around access, but in the end, our data is in a database someplace that someone else needs to manage and keep running. I'm not saying this to generate a bunch of FUD. I provide plenty of private data to the different SaaS providers we use to maintain our business, but that doesn't mean there isn't some risk involved. In our case, that sometimes means keeping certain data in-house. For some of you, this will mean using SaaS, but protecting your data in their environment.
SaaS security involves a number of different controls, including identity management (and federation), internal security settings and role management, incident response and service outage planning, and auditing. In this tip, we'll focus on techniques for protecting sensitive data stored within a SaaS application, including SaaS encryption.
There are four main options, but as you'll see unless you are using a file-oriented service, only two of the options are usually realistic:
1. Trust the provider and rely on their internal controls (which may include encryption, data dispersion and other options).
2. Encrypt data in a client application before sending it to the provider -- usually only an option if the service provides a client application with this capability.
3. Encrypt data locally before sending to the service.
4. Use a local or remote encryption proxy to encrypt and decrypt data going to the provider.
Relying on the provider isn't always bad; many have far better security controls than you probably do on internal applications. Still, we do see use cases where you might want to protect some of the information you keep with them, and that's where the other options come into play.
SaaS encryption options
Certain services provide a client application and don't necessarily run everything through a Web browser. This is common with file storage and backup applications that combine SaaS and PaaS capabilities. Some of those services allow you to encrypt your data in the client application before it's sent to their servers, and secure services even allow you to manage your own keys. This completely blinds them from your data, although they can usually see metadata. Over time I expect to see some of this expand to encrypt data within the Web browser, but I haven't seen anyone implement that yet.
Client encryption is great, but isn't always an option (especially for non-file oriented services). Another option is to use your own software to encrypt the data locally before sending it up to the Internet. This can be difficult to manage and I almost only ever see it used for file-based data. There are some niche masking solutions that will intercept Web forms locally to encrypt pieces of data, but that isn't in common use yet and is bleeding-edge early to the market.
The last option is to use some sort of network-based encryption proxy, and this is what we see most organizations turning to when they don't completely trust their provider.
The proxy is placed on the network and works like a Web gateway. When a user goes to access the SaaS website, they are redirected through the proxy. The proxy relies on deep knowledge of the SaaS application and intercepts key form fields in the webpages. Sensitive data placed in these fields is encrypted before going to the provider, and decrypted before going back to the user.
To the user it looks like normal access to the service as long as they are on the network with the proxy. But if they try and access, say, customer account numbers through a direct connection to the SaaS application, all they will see is encrypted data. For services that don't provide as fine-grained access controls as you want, you can mask data to users and gain security above and beyond the application's internal controls. Also, you can technically host the proxy itself in the cloud to support remote access.
It should be glaringly obvious that this option isn't available for anything except major cloud services due to the large effort it can take to build the intercept functions and seamlessly integrate with the destination service. Plus, one change in the SaaS application user interface can break functionality until the proxy provider can update things.
SaaS security recommendations
In light of those SaaS encryption challenges, I tend to recommend the following:
1. Your best bet is to work with a SaaS provider you can trust, and protect yourself with good contracts and maybe some audits.
2. If you are concerned about file-based data, there are plenty of encryption options that are effective; most file-based enterprise encryption tools will work well.
3. If you don't completely trust your provider, look for a proxy encryption solution. Encrypt as little as possible to reduce the risk of breakage. Understand that unless you put the proxy itself in the cloud, you may lose some mobility.
Encrypting data for SaaS isn't impossible, but your first bet should always be with a provider you can trust. If you need to go above and beyond that, these options should keep you covered.
About the author:
Rich Mogull has nearly 20 years of experience in information security, physical security, and risk management. Prior to founding independent information security consulting firm Securosis, he spent seven years at Gartner Inc., most recently as a vice president, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies, including DLP, and has covered issues ranging from vulnerabilities and threats to risk management frameworks and major application security.