How can the industry avoid the same mistakes with virtualization? By tracking virtualization technology as it evolves, and thinking like an attacker. In this tip, we'll cover ways to proactively build security into a virtual server environment.
Server virtualization requires new thinking
First off, stop thinking about virtual machines the way they're currently used. The technology is widely deployed today, but tomorrow it will be universal. New applications simply aren't going to be deployed on physical hardware; soon nearly all application servers will be managed from a virtualization console.
Look at that architecture the way an attacker would: Virtualization controls every application in the enterprise. Therefore, virtualization infrastructure is the most valuable target on the network. It's the first thing they're going to go after.
Using policy and technology
Next, remember an iron law of IT security: no matter what policies and controls are in place, some machines will be compromised. Plan for it.
Before virtual machines, those compromised systems gave attackers access to the internal network. With virtual machines, not only do they get access to the network, but also any attached virtualization infrastructure, putting all virtualized systems -- and the data they contain -- at risk.
The most important challenge in virtualization security is to prevent that access from being a "game-over" threat that surrenders every other virtual machine in the enterprise. How can that be accomplished? Here are some tactics:
- Segment virtual machines by the information they handle. Yes, high-security virtual machines will manage credit card numbers, medical information and other data of the highest importance. But there will still be plenty of virtual machines designated for quality assurance and systems testing where the administrator password is "password". Count on it. Don't make the same mistake we made with VLANs: have a policy, spelled out up front, that those two types of virtual machines can never share the same hardware. However unrealistic it may sound today, assume that if an attacker can run code on one VM, they can run code on every other VM on the same machine.
- Watch out for cryptography. Enterprises use it in more places than you may think, like to power Active Directory servers, to secure SSL connections, and to generate session cookies on Web applications. Virtualization does an imperfect job of protecting cryptographic secrets, because of timing artifacts hidden in the underlying hardware. Don't deploy financial applications on virtualized shared hosting.
- Create standard locked-down images. Host security matters more under virtualization, because virtual machines that share hardware can often talk to each other directly. Your whole organization should use exactly one baseline Windows server installation, or exactly one Linux build. That build should be locked down tight; in other words, hardened and configured with a minimum footprint and maximum security controls.
- Secure storage, migration and backup. Virtual machines are often stored on storage area network (SAN) technology like iSCSI, migrated over standard TCP/IP networks, and backed up using FTP. What's key to remember about all of this is if an attacker can see and change those virtual machine bits in transit or at rest, he or she can easily rewrite the virtual machine, negating your security entirely. Control access to virtual machine storage as tightly as you do access to your domain Administrator passwords and SSH keys.
About the author:
Thomas Ptacek boasts more 10 years of product development and security research experience prior to founding consultancy Matasano Security. Thomas has owned technical operations at Chicago's most popular ISP, authored Insertion, Evasion, and Denial of Service, a landmark paper which broke every shipping intrusion detection product on the market, and at Arbor Networks led the development of a security product deployed on the backbone of virtually every tier-one ISP worldwide.
This was first published in June 2008