<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=352585001801011&amp;ev=PageView&amp;noscript=1">
Matt Kozloski

By: Matt Kozloski on July 14th, 2015

Print/Save as PDF

3 Tips to Secure Your Virtual Infrastructure

Cybersecurity


Intersection_of_Virtualization_and_SecurityYou’ve probably virtualized your environment and enjoy benefits such as high-availability, physical and operational efficiency, and greater time-to-market for application deployment. Virtualization, or abstraction really, is clearly the foundation of the modern software-defined-data-center (SDDC). Whether you have a couple hosts or thousands, ask yourself: are you giving due care to ensuring the security of your host/guest systems and information?

Here are three concepts, just to get you thinking:

Consider Role-Based Access-Control (RBAC)

Most hypervisor management systems (such as VMware vCenter) allow the use of targeted roles, with specific privileges, applied at different levels of your virtual data center. This allows you to apply the principal of least privilege, in conjunction with a centralized system for authentication and authorization (such as Active Directory). In addition, vSphere ESXi can also be protected by “lockdown mode” which only allows management and operational tasks through a vCenter Server; i.e. not directly at the host’s APIs. You wouldn’t give every person, even in the IT department, physical access to the server room or data center, so make sure your security directives carry forward to your virtual data center.

Review Your Security Posture and Information Systems Security Policy

An example regarding virtual machines: you should not generally allow copy-and-paste between any guest OS’s and a remote console. Here’s why: a user could have copied a password to the clipboard to paste into a software setup dialog. If another user or malicious application gains access to that console session, they could scrape that sensitive information. Now, this behavior in vSphere is disabled by default, but not in other hypervisors / hypervisor management systems. That’s also just one example. Simply put - make sure your information systems security policy has been updated to include provisions for the modern data center.

Secure Your IP Storage Configurations

One of the biggest security issues I run into, related to virtual environments, is insecure IP storage configurations. Whether it’s NFS or iSCSI, I see a lot of folks with storage networks blindly available to anyone on the trusted side of their firewall. Less common, but worse, I see arrays that auto-map/mask new iSCSI initiators to all available LUNs or NFS without host security configured. I rarely see CHAP implemented, never mind mutual CHAP or IPSec. Here’s the deal – think about defense in-depth for your storage networks. For example – turning off the auto-map/mask on your array is a great start but, if you only took that step, one could easily sniff then spoof an IQN and still gain access. Consider this approach: isolate your storage network as much as possible (completely if you can), use mutual CHAP, disable any auto-map/mask, use IPSec if you can, and audit your configurations regularly. Compromise on your IP storage network/array is likely undetectable and VM/data theft or integrity compromise should be of great concern. Almost all OS’s (including client OS’s) have software iSCSI initiators built-in, so the capability is clearly out there and in the hands of your users already.

Adequately consider how you’ve secured your virtual environment. It should be just as importantly as thinking about how you are delivering services and resources, to your end users. I see a lot of folks discuss (at length) the CPU and RAM requirements, host-sizing, VM-sizing, network and storage requirements, however, security seems to come in at the tail end – usually in the form of: well let’s set the root password to something “secure”. Embody the CIA triad in your virtualized environment: Confidentiality, Integrity, and Availability.

New Call-to-action

About Matt Kozloski

Matt is an IT industry veteran and well-versed in professional services. He is the former leader of the CT VMUG. VCDX # 194, CISSP # 526947.