The term Software as a Service (SaaS) has been around a long time. The term cloud is still relatively new for many. Putting them together has meant a world of hurt for many enterprises, especially when trying to integrate security into the mix.
During a joint panel discussion hosted by CSO Perspectives 2010 and SaaScon 2010 Wednesday, five guys who’ve been there sought to help attendees avoid the same ordeal. Perhaps the most important lesson is that contract negotiations between providers is everything. The problem is that you don’t always know which questions to ask when the paperwork is being written.
Panelists cited key problems in making the SaaS-Cloud-Security formula work: SaaS contracts often lack contingency plans for what would happen if one or more of the companies involved suffer a disruption or data breach. The partners — the enterprise customer and the vendors — rarely find it easy getting on the same page in terms of who is responsible for what in the event of trouble. Meanwhile, they say, there’s a lack of clear standards on how to proceed, especially when it comes to doing things in the cloud.
Add to that the basic misunderstandings companies have on just what the cloud is all about, said Jim Reavis, co-founder of the Cloud Security Alliance.
“It’s important we understand there isn’t just one cloud out there. It’s about layers of services,” Reavis said. “We’ve seen an evolution where SaaS providers ride atop the other layers, delivered in public and private clouds.”
Somewhere in the mix, plenty can go wrong.
“If you’re in a public cloud situation and Company B is breached, a lot of finger pointing between that company and different partners will ensue,” Reavis said. “If this isn’t covered in the terms of agreement up front, you have no hope of recovering data (or damages).”
Security vendors can be part of the problem as well. In a recent CSO article about five mistakes one such vendor made in the cloud, Nils Puhlmann, co-founder of the Cloud Security Alliance and previously CISO for such entities as Electronic Arts and Robert Half International, noted that the vendor — who was not named — did “everything you can possibly do wrong” when rolling out the latest version of its SaaS product, leading to users uninstalling their solution in large numbers.
Customers using a particular version of the SaaS product were caught unaware when the vendor decided to roll out a new version through the cloud. It was done in a way where, at the moment of the upgrade, any new endpoint that was added to be managed automatically got the new version. Customers were not asked or notified, and were forced into a mixed-version environment as a result. “In the past, I as a customer was able to choose if I wanted to do this, and I could choose the timing,” he said at the time. “Here, there was no control, no timing or notification.”
Keith Waldorf, VP of operations at Doctor Dispense, a point-of-care medication and e-prescription dispensing provider, said one of his company’s most painful experiences in this area was on the contract side. “The lack of common standards really surprised us,” he said.
Around 2005-06, Doctor Dispense started running its own virtual environment. The company knew it couldn’t manage it alone, but had to burn through five service providers before finding the right one. One challenge, he said, is that every vendor seems to do things differently with no common framework. “We thought the fine print in the contracts had no real relevance, but that thinking ultimately came back to bite us,” he said. The company ran into trouble migrating to a new platform. When switching from one service provider to the next, the company would find the old provider still trying to attempt network log-ins.
Another challenge, Reavis said, is that cloud providers aren’t always good at providing log information that’s critical during a data breach investigation. “A contract with very clear provisions on the level of logging required of the provider is very important,” he said.
Ed Bellis, CISO of Orbitz, said his company is just starting to use a virtual development grid and build its own cloud. If it uses SaaS externally within the cloud, it needs to federate all the identity information between partners. “It’s a challenge, working with partners to get on same page,” he said. “Early on there were many things we didn’t expect. Federation of identities in our internal systems became a challenge because of differences between our internal procedures and those of the SaaS provider.”
One thing that has helped is that his organization developed internal baseline questions to ask of itself in terms of whether a service really fits the need and if it makes sense to have A and B in cloud. That self-questioning can help a company avoid the pain that comes with rushing in, he said.
“In your SLAs, you need to have clear language for how data will be handled and encrypted and, in the event of a security breach, the contract must have clear language on who is responsible for specific aspects of the investigation,” Bellis said. “Build these considerations into the contract side.”
Jeff Spivey, president of Security Risk Management, noted that with SaaS there can be many hidden third-party relationships, and a good contract must account for that.
“Build data portability into your contracts,” he said. “Remember that one business relationship is actually 10 and you may even need multiple contracts with multiple assurances.”