Wednesday, 21 January 2009

Top 10 security vulnerabilities of virtualization

Sponsored Links
Find high paying job. It's quick! It's Free!!Earn some quick money by spending just 5 minutes!!
There are some common areas where system administrators may be unknowingly undermining security of their computing architecture and thus causing vulnerabilities to possible future attacks. These issues range from improperly secured networks to trusting that technologies such as SSL and VLANs are fool-proof. Here are the top ten issues...

1. Virtualization administrators are not security administrators!
Virtualization administrators aren't security administrators, nor do they always consult or listen to their security administrators. This problem can be mitigated by educating security administrators about the realities of virtualization and also educating the virtualization administrators in the language the security administrators use.

2. The management appliances for virtualization servers are within improperly secured or unsecured networks.

3. Trust SSL.
SSL does not assure fool-prrof security. There is an attack against SSL that is easy to do and takes less than two seconds. Do not assume SSL is secure enough. Unless pre-shared certificates are in use, SSL is at risk. If you must use SSL-based management tools, use the Administrative network for this work where you can trust who is on the network. In addition, use good VPNs to access the administrative network from outside the network.

4. Virtual machines (VMs) are not considered a hostile environment.
VMs within a demilitarized zone (DMZ) or otherwise Internet-facing are a hostile environment, but all VMs are hostile when it comes to virtualization. An attack on one VM should never directly or indirectly lead to the virtualization host.

5. NFS and iSCSI storage networks are not segregated from all other networks.

6. VirtualCenter is placed on the outside of the administrative network.
While VMware ESX is firewalled, VirtualCenter is on the wrong side of the firewall. It should be as protected as the virtualization hosts.

7. Extra service console ports exist.
When attaching a NFS server to ESX, a service console (SC) port is also created. This is a mistake; iSCSI needs service console participation, not ESX. The service console should access the storage network through a router, gateway and preferably a firewall.

8. Service console is placed within the DMZ or hostile environment.

9. Trusting that VLANs will protect the network.
You need very good switching hardware to protect from most of the known VLAN attacks. Also, the use of VLANs introduces data co-mingling over the wire.

10. Not understanding security within the hypervisor.
If you do not understand the security within the hypervisor, you will be hard pressed to define how to secure your virtualization environment.

The bottom line: Security should never be an add-on; it should be part of the design, right from the beginning.

(Source: Excerpts from an article by Edward L. Haletky published in TechTarget)

Do not miss even a single tech update... Subscribe to RSS feeds now!

No comments: