On January 5, 2016, I was joined by Mike Foley, senior technical marketing architect for VMware vSphere Security, and Kapil Raina, HyTrust VP of product marketing, on the Virtualization and Cloud Security Podcast to discuss moving to a hybrid cloud IaaS model. As always, we strive to provide actionable advice. The key question we tried to answer was “Can you just extend your security into your cloud?” The answer was not as simple as one would expect. Have a listen and let us know what you think. In the meantime, here are our thoughts.

We chose to simplify our conversation by discussing clouds that are like-for-like. In other words, the underlying hypervisor is the same in the cloud as it is in your data center. This is a cloud that generally uses the same management tools your administrators know already. Amazon is the notable exception, with its own cloud management tools. Yet, there are tools out there that can even make that the same. If you want Amazon and vSphere to use the same tool, Amazon also has a plugin for VMware’s management tool, vCenter. The discussion, however, was not all about vSphere. We also looked at Azure Stack and Azure.
There are third-party management tools that join the data center to the cloud, such as Embotics, HotLink, and many others. We see VMware and Microsoft entering this fray with their like-to-like products. This is a telling story, one that cannot be ignored, and one that needs security.
The key takeaway from the podcast was surprising. Instead of a resounding “yes, we can extend our security into the hybrid cloud,” there was an underlying note of caution. There will always be a need to plan before such activities happen and a need to do research, and the reasons are significant:

  • On one hand, you have tools that work well within your controlled environment. On the other hand, you have an environment where much is out of your control.
  • On one hand, you have a set of practices, policies, and controls. On the other hand, you need to trust but verify many of those controls and policies.

As more of the underlying infrastructure leaves your control, the amount of controls, attestation, and other aspects of security need to move higher up the stack. They become more a people and process problem than a technology problem.
The real question you should be asking is:

Do you feel comfortable with your current set of processes around security?

Let us take identity as an example. In our data center, we control identity by using, in most cases, Active Directory. Is there an equivalent in the cloud? Do I need to set up a new forest in the cloud? Can I use SSO to access my identity store remotely? What happens if the data center is unavailable to the cloud or vice versa? Do you have a security disaster recovery plan?
What is a security disaster recovery plan? Unlike standard disaster recovery plans, which are about restoring data, the security disaster recovery plan looks at how to restore security services only. How do you work around availability of identity? How can you federate role-based access controls? Or how do you ensure your firewalls and other security tools have the latest updates when they are outside your immediate control?
When you go to the cloud or use a hybrid cloud, you have some aspects of the cloud you can control and others you have to trust but verify. Part of any security disaster recovery plan should be the means to attest that everything is as it should be. As you move more and more services to the cloud, you need to federate or loosely couple your security services between the cloud and your data center. To do that, you need to first ensure that your data center is set up correctly, then launch into the cloud. We need to:

  • Ensure that data is properly classified. Encrypting everything may not be required. Using encryption only where it’s needed can reduce costs. If we do use encryption, how are the keys managed and created?
  • Ensure that role-based access controls have least access. We need to look through our identity stores to ensure that least access is in play. In other words, not everyone is an administrator!
  • Centralize and automate management of security. Cloud implies scale; it implies not being tied to any one server. Is our automation around security good enough? Is there a centralized way to manage security policy?

Can we answer all these questions as we move to the cloud or before? Some can be answered before the move. Others need to be asked once we reach the cloud, as once the journey begins, plans tend go astray. Have a listen to the podcast.