Most large organizations are not quite ready to accept the security implications of renting unknown machines from public cloud providers, but transforming data centers to private clouds is in full speed and showing no sign of slowing down. While private clouds are under the control of the corporate IT department, it does not mean that migrating a data center to a private cloud is free of security implications.
Ensuring proper migration of security controls is only half the story, however. The second, and some would argue, the more important half is around ensuring application availability and business continuity. Many of our security controls, such as firewalls, traffic-filtering routers and secure web gateways, are not just in place to prevent threats. These devices enable network connectivity and data access which critical business applications need in order to function properly. Take a look at your firewall policy – chances are you will find more ALLOW rules than BLOCK rules.
Migrating the security policy is a long and tedious process. Given the level of automation that exists in other IT disciplines, it surprisingly still involves mostly manual work with lots of trial and error. I oftentimes hear from organizations we work with that moving the security policy is a major contributor to the length and complexity of private cloud migration projects.
There is no silver bullet of course, but I’d like to propose the following steps for consideration when planning security migration as part of a data center consolidation project.
Adopt an Application-Centric model – As security professionals, we tend to think in “threats” and “tools” – migrate the firewall rules, the IPS signatures, the DLP policy etc. – but a data center’s purpose in life is to deliver business applications. Everything else – the databases, storage, networking and yes, even security – are merely enablers (important ones nonetheless). Mapping out security requirements for each business application in business terms, and ensuring the migration of these controls will ensure application availability throughout the migration.
Reevaluate Security Controls in the Context of Private Clouds – Some security controls remain more or less the same in private clouds, while others do not. For example, many vendors have introduced hypervisor-level firewalls which can enforce a policy on VM-to-VM traffic. If you are mixing workloads with different security requirements on the same physical machines (E.g. PCI and non-PCI regulated workloads) this is an area you should look at. This nice post by Shaun Donaldson provides a good overview of how endpoint security solutions should be considered differently in cloud environments.
Inside/Outside/Really Outside the Private Cloud – As you migrate security controls, realize there are three options where each security control can be placed.
1. “Outside the Cloud” – This usually involves the same dedicated hardware to run the security control. If inter-VM enforcement is required, you will need to route traffic outside the VM for inspection and route it back in.
2. “Inside the Cloud” – This requires virtualizing the security control. Since the control no longer runs on dedicated and hardened hardware, there could be implications such as performance and even security that need to be evaluated before taking this route.
3. “REALLY Outside the Cloud” – Taking the time to reflect on your security architecture can be an opportunity to evaluate public cloud controls. Certain controls such as email security and URL filtering have a strong and proven track record of being delivered in the cloud, and can potentially offer advantages such as reduced management overhead, latency and costs.
The cloud is here to stay and the pressures on security teams to “make the cloud work” despite the security challenges will only increase. A proactive, well-thought out strategy on how your security should evolve will help position you as an enabler, and not an inhibitor, to your business’s success.
