One of the most important aspects of running a good technical security program is giving your technical team members access to an environment where they can refine their skills, perform adequate testing and play with new technologies and applications. This usually meant spending significant money on hardware, systems, KVM devices, discreet network devices and all of the regular stuff that goes with building a lab.

Today, security teams can and should leverage several key technologies to lower these costs and hardware requirements. In fact, for less than a thousand dollars in many cases, you can build a multi-user virtual lab environment that will serve most needs of the security team in terms of testing and skills maintenance. Here is a look at the way we have been building prototype security labs on a shoestring (See chart below for breakdown).

The first need is one large desktop or server system. The faster the processor, the better. We have built labs to support 3 to 5 users and several virtual machines using mediocre desktop systems from fairly low-end manufacturers. Once you have a CPU, the next step is to load up on memory. Usually 1G-byte is the minimum but we usually shoot for 2 to 4G-byes to keep the virtual lab robust. We then add a large hard disk, the larger the better, with 200G-bytes being the bare minimum. Often, for keeping backups of virtual machines at the ready, we also pair the system with a USB2 or Firewire external drive. These make archives easy to create and handle and can even be moved with little effort between virtual lab systems as needed.

The next step is to take your new hardware and install a base operating system. We try to use the lowest footprint for the base operating system as possible, since the sole purpose of the base OS is to manage the VM environment of choice. We never use the base OS for anything other than management of the VM environment, and perhaps a FTP server or the like to serve files between the virtual machines in the virtual lab.

As for choosing a VM platform, there are many choices available today, each with their pros and cons. For a massive comparison matrix of a myriad of different options ranging in price from free to thousands of dollars, check out Wikipedia. With just a little Google time, and a few hours of playing with the different solutions in your short list, it should be easy to pick a winner. No matter which one you choose, flexibility and stability are the keys for picking the platform for your security lab.

Now that you have your platform and it is ready to populate, keep a few tips in mind. For example, many platforms have pre-installed images of many operating systems freely available. You can save a load of time by downloading these OS images. Of course, pay careful attention to sources and never trust an OS completely that comes this way, but they are a quick and easy shortcut to getting the lab operational quickly. Another tip is to keep LiveCD images in mind. Many VM platforms will directly load the .iso image right off of a hard disk and these can be quick systems for doing focused tasks like forensics or vulnerability testing. I'm a big fan of LiveCDs and these days there are a ton of focused ones available for a multitude of specific tasks and projects.

Remember that your new virtual lab is a play space, so bad things might happen there. As with any lab environment, make sure you segregate your lab from the rest of your network environment. I suggest a firewall with very powerful egress rules to prevent anything nasty from spreading around the network from the lab. In many cases, folks simply attach the lab system to a switch and only allow outside network access when needed. Many VM platforms assist with this by providing virtual networking capabilities for the various systems running in the VM environment, without the need to expose them to the real network. Play with network access safely.

Last, remember that your virtual lab may expose unpatched systems, various services etc. as you play with, analyze and study them. Some of these virtual systems may have easy to exploit vulnerabilities, so be aware of that as well. Attacker compromise of a virtual system is just as bad as compromise of a real one if the attacker can then leverage that system for sniffing, trust relationships, passwords or as a beachhead for further scans and attacks. Be careful with virtual systems, and use software firewalls, AV and all the other normal security measures whenever possible. It is not just sound practice, it often gives you deeper insight into the manageability and flexibility of the various security products you ask your user base to live with every day.

That's about all there is to it. You can create a fully functional, multiple OS, application serving test lab on a shoestring budget - a few dollars in hardware and some time spent building the base OS and VM platform.

With some practice, your team can learn to work together to test new applications, perform all kinds of experiments and train to keep their skills current.

All in all, not a bad investment.

Chart:

* optional

MicroSolved, Inc.

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine