• United States



by Senior Editor

5 Mistakes a Security Vendor Made in the Cloud

Sep 30, 20095 mins
Application SecurityCloud ComputingCloud Security

Here's the cautionary tale of how one security vendor went astray in the computing cloud, and what customers can learn from it. (Part 3 in a series)

When security experts sound the alarm about enterprises embracing cloud computing with little understanding of the risks, it’s usually a case where the expert — working for a vendor — is making a pitch for their employer’s products. That’s all well and good, but here’s the problem — some of them have trouble keeping their own side of the cloud clean.

That, according to Nils Puhlmann, co-founder of the Cloud Security Alliance and previously CISO for such entities as Electronic Arts and Robert Half International.

Puhlmann recently contacted CSOonline about one example where a sizable security vendor made multiple mistakes in the cloud. He spoke on the condition that the vendor’s name is kept anonymous, as he is working with the company to help address its problems.

“This major security vendor basically did everything you can possibly do wrong when rolling out the latest version of its SaaS (software as a service) product, leading to users uninstalling their solution in large numbers,” he said.

In listing the following five mistakes (most of which are rooted in a lack of communication with customers), his goal is to show other security vendors how NOT to do things, and to arm IT security practitioners with a list of questions they should ask of those they pay to give them secure cloud-based services.


Defining Cloud Security: Six Perspectives

Cloud Security: Danger (and Opportunity) Ahead

Cloud Security: Time to Smoke Another One?

Forrester: A Close Look At Cloud Computing Security Issues

Winkler: The Real Problems With Cloud Computing

MISTAKE 1: Updating the SaaS product without telling customers or letting them opt out 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. “Here, there was no control, no timing or notification.”

Customers using a particular version of the

MISTAKE 2: Not offering a rollback to the last prior version

The problem with the first mistake is that customers are now faced with compatibility issues in their environment that can cause a freeze-up of essential IT functions, including those related to security. The natural course for the IT security practitioner is to uninstall the new but incompatible version, dust off the CD with the last version of the product, and re-install the version that has proven itself stable in that environment. But in the cloud it’s not always so simple, especially in this case, where the vendor offered no rollback option. “You get forced into a mixed environment and have no way to react,” Puhlmann said.

MISTAKE 3: Not offering customers a choice to select timing of an upgrade In the case of Microsoft’s monthly Patch Tuesday updates, most IT admins run the updates through a roughly week-long gauntlet of testing and tweaking before deploying company-wide. But in this case, customers had no control over the timing of upgrades in their environments, Puhlmann said.

For IT security practitioners, dealing with new versions of a software or service that prove incompatible is nothing new. It happens just about every month when Microsoft releases its security updates. But in most cases, IT shops have control over when an update is pushed out in their environments.

MISTAKE 4: New versions ignore prior configurations or settings, which creates instability in the customer environment

The third mistake was particularly problematic because the new version of the SaaS product proved buggy. For example, it disregarded whitelist and firewall settings programmed into the previous version, causing computers to suddenly bog down with pop-up warnings for a variety of commonly-used applications, including those built and maintained in-house. “The client now doesn’t trust itself and blocks everything,” he said. “Integrity between a cloud and an endpoint is essential, and this sort of disconnect could be exploited for denial-of-service attacks and the like. Vendors need to be thinking about this.”

MISTAKE 5: Not offering a safety valve

Had the vendor offered some sort of safety mechanism in its cloud configuration, customers could have at least limited the damage upon realizing a bug was mucking up the works, Puhlmann said. But as far as he could tell, there was no such mechanism.

What customers can learn from this

Puhlmann does credit the vendor for its response to the mistakes he warned them about. They are now working to improve the process. For customers delving into the cloud who may have concerns about these things happening to them, his advice is simple: Ask a lot of questions before signing on the dotted line.

“You have to ensure things you did in the past, before the cloud, can still be done,” he said. “You have to know for sure that services managed in the cloud have the highest integrity, and that you will have choices over whether to receive an update and when the update is made.”

About this series: Enterprises are increasingly dependent on cloud-based infrastructure — virtualized resources provided as a service over the Internet. But security experts worry that many businesses are embracing the cloud without regard for the risks. This series will define how the cloud has changed business processes, where the security risks are and how to mitigate those risks.