Skip to main content

How to secure a Virtual Infrastructure: White Paper by Bluelane


Security is getting a lot of attention. A lot of environments have heard of security but have applied it into their IT in a very limited way. I have worked at and seen organizations grow from being a totally hacked places into a "reasonably" secure environments. Its not just the security its also the policy. Policy makers and enforcers in the legacy IT infrastructure have found ways to do things in the typical DMZ/Secure infrastructures.

Although I do notice a considerable shift from the DMZ/Secure into more of a "Application Pooling" the security still remains in the same place. The pix needs to be configured but cannot enforce a typical fine-grained IPS/IDS from its end. I am not saying that its impossible but I see a severe need to do it in a more "Per Application Pool" basis.

But how are you going to enforce and even manage the great new way of provisioning a fully tested and patched "Appliance" from environment to environment? Virtualization makes all of things possible due to its flexibility. Today I have the flexibility to provision and patch a single development server for a contracted developer myself. But imagine if you have to have that whole suite of applications that need to be patched, conforming to the ITIL that an organization may have in place, move it from development to test to staging to production? And they go about it and do the patching in the production. So all I am saying is that the flexibility and enhanced productivity comes at a cost. Your security policy has to be really rock hard and tested before you begin buying all kinds of pormises and tools and finally cannot find an adequate fit within the exisiting (physical infrastructure) and the new (Virtual Infrastructure). Business has to go on and end users do not have to notice the change from physical to virtual and in production the changes through breakthrough technologies like VMotion (from VMware). Security may sound like a hype to many but since Virtualization is becoming a serious business, its time for serious actions.

An excerpt from the White Paper: (Virtual Shield data sheet will be released on monday):

In today’s data center, most of the security is provided by special purpose appliances. Contrary to the general trend of virtualization, these appliances are all-too-tangible. If a data center manager was to arrange all the servers in a big pool, the security devices would, by necessity, form a static ring around the
pool. Segmentation of some sort is necessary, since the server pool may contain servers of different “tiers” of criticality (for example, Web servers facing the public and databases containing sensitive data). The servers need to be protected from the outside world, but they also need to be protected from each other. If a single server in the pool is infected with a rapidly propagating threat then it will be able to cross-infect all other servers that contain the same exposed vulnerability.

Up to now, data center, security and network architects have had to reach a compromise of sorts – servers are on separate virtual networks (VLANs), which are switched through firewalls sitting in a ring around the server pool. Effectively, we end up using network virtualization to compensate for the lack of
security virtualization. This approach is far from ideal, however. Since the security devices are static, they cannot respond to changes in the virtual servers. Let’s say for example that a virtual server has to be moved to another physical server for maintenance. The security associations have to follow that server, so
in order to keep things working, the server must retain the same IP address and VLAN as before.

Because of limited orchestration between the virtual servers and the non-virtual security, everything has to be done with VLANs. The disadvantage is that VLANs are difficult to manage and they are too coarse-grained for use as security controls. If you bunch all databases together you end up with the risk of cross-contamination. If you split each server into a separate VLAN you run out of VLANs. And in either
case you have a management mess on your hands.


Excellent paper and an eye opener. Thanks to Blue Lane VP for letting me peek through their Virtual Shield as well. Watch out for the paper on monday. This ought to come out by monday. Do check out some self-explanatory screenshots:





Virtual Shield Manager




In the meantime get this copy here.

Comments

Popular posts from this blog

Security: VMware Workstation 6 vulnerability

vulnerable software: VMware Workstation 6.0 for Windows, possible some other VMware products as well type of vulnerability: DoS, potential privilege escalation I found a vulnerability in VMware Workstation 6.0 which allows an unprivileged user in the host OS to crash the system and potentially run arbitrary code with kernel privileges. The issue is in the vmstor-60 driver, which is supposed to mount VMware images within the host OS. When sending the IOCTL code FsSetVoleInformation with subcode FsSetFileInformation with a large buffer and underreporting its size to at max 1024 bytes, it will underrun and potentially execute arbitrary code. Security focus

Splunk that!

Saw this advert on Slashdot and went on to look for it and found the tour pretty neat to look at. Check out the demo too! So why would I need it? WHY NOT? I'd say. As an organization grows , new services, new data comes by, new logs start accumulating on the servers and it becomes increasingly difficult to look at all those logs, leave alone that you'd have time to read them and who cares about analysis as the time to look for those log files already makes your day, isn't it? Well a solution like this is a cool option to have your sysadmins/operators look at ONE PLACE and thus you don't have your administrators lurking around in your physical servers and *accidentally* messing up things there. Go ahead and give it a shot by downloading it and testing it. I'll give it a shot myself! Ok so I went ahead and installed it. Do this... [root@tarrydev Software]# ./splunk-Server-1.0.1-linux-installer.bin to install and this (if you screw up) [root@tarrydev Software]# /op