On any given enterprise network there are dozens if not hundreds of virtual environments. Interestingly, I find that most of these virtual server farms and VLAN environments are wide open for attack.
When considering how to implement virtualization firewall strategies with meaningful policy, there are a number of factors to consider:
1. What are the business function requirements in and around each virtual environment? Who needs access to which virtual environment?
2. How are your unique virtual environments currently at risk? Are there misconfigurations, missing patches or open ports that can be exploited?
3. How can you apply, or improve, the principle of least privilege to ensure that only those with a business need can access these systems?
4. In the event that your virtualization security controls fail, what other barriers are in place to prevent the exploitation of a vulnerability using Metasploit, the perusal of network shares to find PII, the launching of denial of service attacks or the spread of malware?
How to segment traffic in a virtualization firewall strategy
Once you determine these things, you’ve got to step back and think about how you can use virtualization firewall strategies to your advantage to properly segment traffic and provide systems access only to the people who need it. This may come in the form of traditional network firewalls and personal firewall software running on each OS. Many shops have successfully utilized native hypervisor and OS controls combined with homegrown tweaks to establish a relatively secure virtual environment. But the reality is that such environments are still not as secure as physical hosts. Furthermore, in all but the most simplistic of virtual environments, you’re likely going to have exponential growth in systems complexity which will make your pursuit of security even more difficult.
Given that complexity is the enemy of security I believe that many, if not most, environments would be better off using something like VMware’s vShield or virtual firewall product available from third-party vendors such as Reflex Systems, Altor Networks (now Juniper) and TBD Networks. Going this route will buy you benefits such as greater visibility into your virtual environment, more granular controls, as well as better performance and scalability.
Security holes in the LAN
One thing to keep in mind through all of this is that you should never underestimate the skills and intent of insiders. Most of the vulnerabilities I find in a virtual context are easily exploited using free tools and step-by-step instructions outlined in books and on the Web. The same goes for malware. I’ve seen huge enterprise networks and their virtualized environments riddled with command and control bots and similar malware all because of some relatively simple security holes on the LAN that could’ve been prevented.
About the author
Kevin Beaver is an information security consultant, expert witness and professional speaker with Atlanta-based Principle Logic, LLC. With over 22 years of experience in the industry, Kevin specializes in performing independent security assessments revolving around information risk management. He has authored/co-authored nine books on information security including The Practical Guide to HIPAA Privacy and Security Compliance and the best-selling Hacking For Dummies, 3rd edition. In addition, he’s the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at www.principlelogic.com and you can follow in on Twitter at @kevinbeaver.
This was first published in April 2011