Due primarily to security concerns associated with public cloud, many firms elect to favor private cloud deployments...
over public counterparts. And, while security pros are on their guard when it comes to public cloud, private cloud computing security doesn’t always garner as much attention. Private cloud grants more control to in-house staff, but increased control isn’t a license to ignore security. On the contrary, there are some very real security risks associated with allcloud models, private included. However, because security pros are less sensitive to risks in the private model, it can lead to a situation where risks go overlooked.
And while every deployment is different (thereby leading to unique constraints and security risks in each), there are a few notable cloud computing security issues to consider within a private cloud deployment.
Private cloud computing security: Comingled regulatory environments
Security professionals know not every IT environment fits every situation. It goes without saying, for example, that an entity regulated under PCI would find a non-PCI-certified environment unacceptable for systems in their cardholder data environment. This is equally true in both the public and private cloud. Just because an infrastructure is dedicated to your use alone doesn’t mean everything can go there with equal ease. And just because private cloud grants greater control over security, regulatory compliance should always be at the forefront of planning, particularly when multiple types of regulated data are in play, such as a comingled mix of payment card data, sensitive business intelligence and customer data.
Viability of security tools
When an organization “virtualizes” a physical host (i.e. moves it from dedicated hardware to a virtual image), it always needs to evaluate how network-aware tools will be impacted. Any tool that presupposes visibility into traffic may be impacted: network IDS, traffic monitors and sniffers. For example, consider an n-tier Web application with separate Web, application and DB servers attached to one switch that’s monitored by an IDS. If those three devices are moved to virtual slices on a hypervisor, traffic is no longer visible on the wire, causing the IDS to lose visibility. This is a known issue in public deployments, but often is given less scrutiny in a private scenario. Unless the organization plans accordingly, for example by deploying a “virtual tap” or configuring the hypervisor to offload traffic, existing tools may stop working. This is particularly true when large numbers of hosts are virtualized at one time; more hosts (typically) mean less time spent planning per host.
Cloud is a fantastic enabler when it comes to resource centralization. For example, a virtualized environment can allow far-flung resources to come together under one environment. However, as resources centralize, data becomes correspondingly “denser.” While this is a boon for management, it can become challenging from a security standpoint, particularly when considering tools that operate across that data in aggregate. Bulk encryption, antimalware scanning and data “discovery” tools have a harder time dealing very large amounts of data (the case in most cloud deployments, private or public). Existing tools should be examined to determine how they will be impacted as data volumes increase and new tools considered when operation would be impacted severely.
For a public cloud deployment, quite a bit of energy goes into defining who does what, when and how. In a private cloud deployment, responsibility for operational aspects of security may change hands too -- from one group to another or (depending on where the private cloud is hosted) to a service provider. Defining who is responsible for what and outlining minimum levels of service is just as important. This is particularly true when security controls are “close” to end users -- i.e., when business owners responsible for applications/services have informal arrangements with groups that maintain infrastructure technically. When responsibility changes hands, care should be exercised to formalize existing arrangements.
Many individuals assume private cloud means “on-premise,” but this doesn’t have to be the case. The defining aspect of “private” cloud is about who uses the infrastructure, not who maintains it. So while many private cloud deployments will use on-premise infrastructure, it’s not a given. And even if a deployment uses on-premise or dedicated resources today, that doesn’t prevent it from migrating off-premises to a service provider or onto shared infrastructure tomorrow. Organizations going through the process of moving to a private cloud infrastructure should know the barrier to moving from private to public cloud is low -- meaning, what they put into a private environment today could easily migrate tomorrow.
It goes without saying that private cloud deployments have many security advantages. However, “advantages” does not mean organizations can forego due diligence. A private cloud deployment is every bit as serious an endeavor as a move to public cloud and needs to be planned for accordingly.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of Security Curve.