Evaluating Cloud Solutions – What Type of Cloud is Right for Me?

Evaluating Cloud Computing Solutions – Public vs. Private Clouds? Hybrid Clouds? Which is Right for Your Business?

The first known reference to the “Cloud” as it related to computing was in Douglas Parkhill’s 1966 book The Challenge of Computer Utility. Parkhill explained his conception of a “Private Computer Utility.” He compared computing with the electrical industry and its extensive use of hybrid supply models. When the electricity grid was built, private on-site power generators were quickly cycled out. No longer did local businesses have to build, buy and maintain the hardware to create electricity, which was expensive both from a hardware as well as a human resource perspective. While it did carry some risk, electricity as a utility made sense in terms of finance and risk management. In the world of Cloud Computing, there are three different types of “clouds” – public cloudsprivate clouds and hybrid clouds. Depending on what type of service or data you’re dealing with, you’ll want to compare the different options of what private, public and hybrid can offer. In most cases, the most important variable is the degree of security and management the hardware or application requires.

While we as an industry like to think that Cloud Computing is new, it’s not. The concept was coined forty years earlier.

With that said, it’s time to figure out which cloud architecture is right for you.

Private Cloud

A private cloud is one in which the services and infrastructure are maintained on a private network—generally a local datacenter within an organization. These clouds offer the greatest level of security and control, but they still require the company to purchase and maintain all the software and infrastructure, which can significantly reduce cost savings. A private cloud is the obvious choice when:

·   Data is your business, so security and control are paramount on your list of requirements.

·   Your company is large enough to run a hyper-scalable cloud datacenter efficiently and effectively on its own. This generally implies large enterprises.

·   Your business is bound and gagged to conform to strict security and data privacy issues as well as compliance mandates like PCI-DSS and SOX.

Some vendors use the term “Private Cloud” to describe products and services as “cloud-like”, or that are described in their market-ecture as the ability to “emulate cloud computing on private networks.” These products are often virtualized solutions that have the ability to host applications and Virtual Machines in a company datacenter. Frankly, I see little value in “Private Clouds” as they’re more focused on virtualization than cloud computing.

Don’t get me wrong, I think virtualization has its place as well. It’s certainly used in cloud computing, but that doesn’t make cloud computing what it is. Virtual technologies are valuable to businesses but often tend to obscure the full capabilities of cloud computing. The term “private cloud” borders on deceptive advertising; it fails to deliver on the potential of cloud computing and those who attempt to use it are hanging onto the coattails of the cloud.

Depending on your industry, though, private clouds do offer some benefits including shared hardware costs, quick recovery from failure and upscaling/downscaling depending on demand. And that’s fantastic. But the organization still has to buy, build, support and manage the infrastructure. This solution doesn’t benefit from up-front capital costs and it lacks the economic model that makes cloud computing so compelling in the first place.

Public Cloud

A public cloud is one in which the services and infrastructure are provided off-site over the internet. At its essence, “Cloud Computing” refers to the public cloud. These clouds offer the greatest level of efficiency in shared resources as well as efficiency in cutting spending. However, they are also more vulnerable than private clouds. A public cloud is the obvious choice when:

·   You need incremental capacity, or, the ability to add computer capacity for peak times. When the proverbial crap hits the fan, you’ll have capacity available to handle that, but those resources can be used by other VMs for their own tasks when not in peak capacity mode.

·   Your standardized tools and applications are used by many employees. Examples include e-mail, contact management systems or a company intranet site.

·   You need a sandbox to develop applications across geographic locations. Development and testing are a great use case for Cloud, especially when collaboration is needed.

·   You have a SAAS (Software as a Service) application which is offered from a vendor who takes a hard line approach to security.

Public Cloud as a computing concept offers cheap, commoditized computing resources which outweigh the benefits of in-house resources that have limited added value (no capex, access to resources everywhere at any time, minimal support costs and employees for maintaining the resource, shared overall costs and no peak load concerns).

But one of the concerns associated with public clouds is security and reliability. Make sure you have your security and compliance/governance strategies well planned as the short term cost savings could become a long term nightmare.

Hybrid Cloud

A hybrid cloud offers a variety of public and private options with multiple providers. By using a hybrid approach, you’re able to spread things out over a number of providers to keep each aspect of your business in the most efficient possible environment. The major downside here is having to keep track of multiple security platforms and make sure all aspects of your business can communicate with each other. So, if the following situations describe your environment, then the hybrid cloud may be the best option for you:

·   Your company uses a SaaS application, but has security concerns. Private clouds are often used with VPNs (Virtual Private Networks) for additional security.

·   When your market is multiple verticals, you may be in a situation where you want to use private clouds for client interaction, but their sensitive data is kept in a Private cloud. This is an optimal use case for Hybrid Clouds.

When managing private, public and traditional datacenter models all at the same time, management can become complex. Maintaining a tool which will federate these separate pieces for the sake of SLAs and troubleshooting becomes the challenge.

Most of what people are calling “private clouds” share a number of qualities with public clouds and can thus be classed as a “hybrid cloud” architecture. Most large enterprises will be looking to run a hybrid architecture for several years to come (though many early adopters have already taken the plunge). The waters are tepid in different clouds for different reasons.

In summary, Public, Private and Hybrid cloud environments can all viable solutions based on your use case. Public clouds offer the greatest cost savings, but the least amount of security and control. Private clouds offer just the opposite, with costs being much higher due to hardware/software and maintenance costs; however, security and control are supreme. Hybrid is the best of both words, but can often be very complex to manage.

Take a step back, identify your use cases and requirements and then take the plunge. Cloud is not just the future. It’s today.

Advertisement

Securing your Private Cloud Environment

Strategies and Considerations for Securing Private Cloud Environments

On the back end of private cloud environments you’ll find multiple flavors of virtual software loaded directly onto hardware. This virtual software is essentially the host operating system. VM Host is the base hypervisor and hardware. Think of it as the house. The guest operating systems (Guest OSs) are the virtual machines living in the house.

Securing Private Cloud EnvironmentsAs the basis for all public and private clouds, virtual infrastructure is how it’s done. So this conversation we’re about to have is related to the back end of the private cloud. If you’re building one, it is important for you and your organization to understand how to maximize the benefits and mitigate the risks of a private cloud infrastructure. There are several key things to keep in mind when trying to secure the virtual environment before even loading guest operating systems.

Most virtual solutions are transparent, by design, to the guest operating systems. The same way machines are secured in physical environments, they are secured in a virtual environment. This includes segregating networks, defining domain security policies and installing antivirus.

But unlike their physical hardware cousins, Virtual Machine infrastructure security seems to be lagging behind, and although this virtualization is consuming datacenters worldwide, many organizations fail to recognize that security basics are still security basics.

According to Gartner, 16% of server workloads were running on virtual machines by the end of 2009. Gartner expects this to grow 50% (to 58 million) by 2012. Unfortunately, Gartner also predicts that 60% of these virtual machines will be less secure than their physical hardware predecessors.

Why are Virtual Machines insecure?

The reason that VM servers are less secure than their traditional hardware counterparts are as follows:

Security isn’t considered at the beginning of the project, which is often the case. In many situations a public cloud project is begun, and from there each project becomes a knee jerk reaction.

If the VM host OS layer is compromised, all guest OSs can be compromised. This is called Hyperjacking. More on that later.

Although most public cloud vendors maintain adequate controls for admin access to the virtual machine monitor, many private clouds do not.

Segregate and separate. VM hosts create flat networks. You’ll need to change that. In a non-virtual world, traditional data-centers had segregation and network traffic could be inspected, filtered and monitored by a number of security products. In a virtual world, these are a rare commodity. The local communication between virtual servers is largely untouched and unmonitored. If the traffic runs through a virtual switch it’s practically invisible because it never hits the wire. It’s just traffic between virtual hosts on virtual links. So virtual traffic between virtual machines needs to be monitored.

Separation of duties is something that we in security often push. Unfortunately, in a virtual server environment, the back-end of a private cloud environment, you’ll often find that the server team and the operations team are the same people who do both provisioning of machines and managing virtual switches. So that means that there’s rarely any integration between the tools and security controls to be implemented for the network and security groups. And what THAT means, is that without visibility into configuration and policy changes, topology specifications and audits, the network and security team has zero view into what’s taking place at the access layer.

In security circles, we also talk about the “principle of least privilege.” This says that you should not give anyone more security than the minimum security they need to do their job. Defining roles that can be used to give different levels of security will make life much easier.

How do you secure a traditional server? First, lock down the server OS (usually Windows or Linux). Now, as you go virtual, instead of just securing the server OS, you also have to lock down VMKernel and the VM layer (the host OS), as well as the console. The same thing you’d do with your weekly Microsoft patch plan is what you should do with your VM Infrastructure. Although extremely secure, stay up to date on patches. There are security updates in there, not just bug fixes.

What you really want to avoid is Hyperjacking, which involves compromising the hypervisor. This is the lowest level of the OS stack, and the hypervisor has more privileges than any other account. At this level it’s impossible for any OS running on the hypervisor to even detect that a hack has taken place. So the hacker can control any guest VM running on the host.

When you go virtual, you add that other layer to the mix, the hypervisor. So again, the hypervisor needs to be secured at all costs. It’s mission critical because an attack on the hypervisor can lead to the compromise of all hosted workloads, and successful attacks on virtual workloads can lead to a compromised hypervisor. Another concern would be a VM Escape, which is an exploit that is run on a compromised guest OS to attack and take over the underlying hypervisor, which can then result in a hyperjacking.

Moving up the stack are those OS patches. Although it’s super easy to spin up another guest operating system, admins sometimes forget that the virtualization software is there. So make sure that just as fast as virtual machines are spun up, patch distribution software should also be installed, and antivirus, service packs and security policy changes should be made to all of those virtual guest operating systems.

The biggest security concern, however, is the insecurity of the underlying virtual guest OS. The VM software you use will separate the guests from both each other as well as the VM Host, so if one of the guest VMs does get compromised it’s unlikely it could affect the host, with the exception of using more memory/processor/network resources.

Be aware that the easier move for a hacker to steal data would be VM Hopping. This is a situation where an attacker to compromise a virtual server and use that as a staging ground to attack other servers on the same physical hardware.

The last threat to VMs themselves would be VM Theft. This is the virtual equivalent of stealing a physical server. Take the whole box and run off with it. Then fire it up later and steal the data. Same concept, however, in this situation it is theft of the virtual machine file electronically, and then attack it later.

How can you make the private cloud more secure?

Start with the base layer. The lower stack. The hardware and traffic. Force all traffic between hosts to be inspected by an IDS (intrusion detection system). Each VM Host should also have a different ingress/egress VLAN pair. Then the IPS should be set with VLAN translation to configure each ingress VLAN and egress VLANs. The goal is to define all VM-to-VM traffic being sent across the wire where it can be inspected, monitored and potentially filtered. Of course, as the private cloud grows, it can become complicated and costly between data-centers and DR sites.

Another option is to define an IPS and firewall on each VM Host, and policies be configured to inspect the traffic. This makes sure all intra-virtual communication is inspected. Of course, there are some performance hits you’ll take running all those additional VM IPS and Firewalls, plus the monitoring for all traffic, however, in the end security should be paramount.

Next up is a ‘love connection’ between the above two. It’s a mix of both. Route traffic to an actual IPS where it’s filtered, can be monitored, etc. Then send the traffic off to a destination VM.

Another security option as you move up the stack after traffic would be securing your hypervisor. Keep your hypervisor console patched. Just like any OS, VM Servers will have security patches that need to be deployed. The majority of these patches are related to the Linux-based OS inside most service consoles.

Additionally, ensure that virtual machines are fully updated and patched and all provisioning is done with security tools etc before they are turned on in a production environment. Although VMs are much easier to move around and faster to deploy than physical machines, there is a greater risk that a VM that is not fully updated or patched might be deployed. To manage this risk effectively, use the same methods and procedures to update VMs as you use to update physical servers.

Another tip would be to use a dedicated Network Interface Card (NIC) for management of the virtualization server. By default, NIC0 is for the parent partition. Use this for management of the Host machine. Don’t expose it to untrusted network traffic and please don’t allow any VMs to use this NIC card. Use one or more different dedicated NICs for VM networking.

Lastly, before installing the private cloud services, (the reason you build this infrastructure) I’d recommend using disk encryption to protect the VMs. If one is stolen, it’s worthless to the thief, and the data at rest is also safe.

Summary

When building a private cloud, it’s important to remember that going VM isn’t as easy as moving servers to a host machine. Security is a bit different, but security practices are still the same. Recognize the additional components. Recognize that going VM often ends up in a flat network, and you’ll need to change that for security’s sake. Lock down your console and hypervisor. And remember the same lock down procedure you used in traditional servers is also critical, if not paramount. Follow these tips and you’ll be ready to host those apps to your user community in no time. Securely.