If you're even asking the question "what's the secure way to launch a cloud initiative," your company is ahead of many organizations, experts say. The time to consider security is at the beginning of the planning stage for a cloud deployment.

"Traditionally -- and even today -- security is an afterthought, bolted on," says Becky Swain, co-founder of the Cloud Security Alliance. She says that's why there are so many new security providers emerging in the marketplace, hoping to help enterprises move sensitive data into the cloud with the aid of encryption and identity management.

"The cloud offers some unique risks and some tools can be used to manage the risk," says Benjamin Jun, VP and CTO of Cryptography Research, a division of Rambus. "You are sharing this infrastructure with a lot of people and have few controls on how people use the public resource. There are ways to make the system secure by design, as opposed to relying on attestations by your cloud service provider."


Step 1: Segment your data according to its sensitivity.

NASA's Jet Propulsion Lab recently launched its own mission into cloud computing, navigating through issues of security and access. At the recent RSA 2012 conference, CTO Tomas Soderstrom explained how JPL created a model it calls the Wheel of Security. The JPL team began their cloud effort by representing different data sets on a pie chart according to the security requirements for each slice.

Then, the JPL team began working its way around the wheel, from public data to classified. The least secure data can go into cheaper, least secure storage, for example. In JPL's case, Soderstrom's team chose to initially limit the cloud deployment to public and non-sensitive data – yet they treated it as sensitive, in order to evaluate security risk for subsequent rollout phases.

Step 2: Decide how much security you want to outsource. 

"If you decide ahead of time which resources you want to maintain and which go into the cloud, you will have a better RFP process," says Dave Asprey, vice president of cloud security for Trend Micro. To some extent, this depends on the level of security expertise of your internal operations staff.

While many threats remain the same no matter where your organization's data is hosted, Asprey points out that hosting confidential information on an outsourced, shared, and highly abstracted infrastructure raises the stakes for IT: "In a regulated environment, if you can't prove your data was only seen by authorized parties, you are in a world of hurt," he says.

While cloud service providers are starting to realize that security is a good differentiator, Asprey says that the majority of them don't see security as their job. Adds Swain, "There needs to be a shared understanding with the service provider and a governance process to manage the risk."

Step 3: Identify a "short list" of cloud vendors for evaluation.

Asprey recommends that organizations evaluate providers from a total capability standpoint, with the caveat that the lower you go into infrastructure, the more security responsibility you may have to take on. And if your organization chooses a provider that can't scale adequately, you'll have a problem regardless of the provider's security credentials, Asprey says.

The Cloud Security Alliance has a new initiative, the CSA Security, Trust and Assurance Registry, which is intended to become a free, publicly accessible registry that documents the security controls provided by various cloud computing offerings. While there are only a handlful of listings so far, the organization intends for the list to eventually provide a comprehensive comparison of security features offered by cloud service vendors.

Step 4: Write a solid RFP.

Eastman Kodak has implemented a vendor risk management program that it uses to maintain a list of potential vendors. The program includes a risk assessment tool for the purchasing department, as well as a supplier self-assessment tool.

At the RSA 2012 Conference, Brian O'Connor, Eastman Kodak's chief privacy and security officer, told attendees that he includes key contract clauses in the RFP, although vendors can negotiate or reply with edits. The four major areas are:

  • Security: That the vendor and subcontractors will comply with all applicable laws;
  • Indemnification: How the vendor and its subcontractors will indemnify Eastman Kodak against data breaches;
  • Liability: That the vendor has a legal liability to notify the company of a breach and to cover the cost of breach notices under relevant laws, as well as for third-party claims arising from the breach;
  • Audits: The highest-risk vendors are required to conduct and pay for third-party audits. The company's fallback position is that Eastman Kodak will pay for audits.

With this process, O'Connor says, "you can identify vendors that generate too much risk, and you [will] need support from management to walk away from them."

Step 5: Negotiate the contract and SLAs.

Both standard contract language and service level agreements should be specific about your security requirements. Says Swain, "The integrity of your data as it moves from one system to the next is also important. Assurances over data integrity and confidentiality should be included in the SLA."

JPL's Soderstrom says he learned to draw the line with vendors when it comes to data ownership: If an initiative ends, the lab gets all its data back, even if it has to be delivered on disks. He hinted that the lab even got Amazon to bend on some issues.

Step 6: Maintain your vendor risk management program and monitor supplier audits.

Bruce Jones, global IT security, compliance, and risk manager for Eastman Kodak, told the RSA conference audience that companies should create a process for ongoing assessment of vendors. Organizations should also contract with third-party auditors, so that they're ready when needed, he advised.

Soderstrom told the RSA attendees, "We don't believe in SLAs but in SLUs, service level understandings. Three strikes and you're out."

Step 7: Launch a prototype with sample data.

Security is tied to availability and reliability. Security features such as scanning may themselves reduce performance -- so make sure all security systems are in place and running during tests.

"Your system needs to survive poor performance," Jun says. "Any time you have a system where some process may crash or go away, you have to be able to resume from those errors. But resuming from errors can introduce security problems."

While the risk of hacking is persistent, Swain says, "The real risk with outsourcing any function -- to the cloud or not -- is understanding the level of control that has been lost and what kind of dependencies have been introduced."

Step 8: Perform penetration testing.

In this final stage, organizations should commission internal experts or security consultants to perform hack attempts on the system using commonly available tools. These security consultants may also be able to help you patch any vulnerabilities that they find.

Says Asprey, "If you have an advanced [in-house] security team that can do it, great. Otherwise, it's an easy thing to outsource. That's money really well spent." Jun suggests coupling this with a more detailed third-party design audit and code review.

At the end of the day, what is the key to a successful and secure cloud deployment? JPL's Soderstrom has this bottom-line advice: "Focus on real business problems, not IT experiments."

Susan Kuchinskas covers technology, business, and culture from Berkeley, California.