The last year has been very instructive in information security, and really highlighted that if security is a team sport — and it most certainly is — IT practitioners have a lot to learn about it. Ransomware in particular has been a massive wakeup call for everyone in the greater IT ecosystem. Defending against it requires a renewed commitment to the basics of security, the things that everyone knows matter in implementations but are hard because of organizational inertia and risk aversion.
At VMware we’ve always taken the approach of making security easy to use, making our products secure by default, but also allowing that security to be flexible. No two organizations are alike, after all. To help this we publish the VMware Security Configuration Guide (SCG), which is a set of best practices for hardening and securing vSphere. There is an edition for each version of vSphere, and as the product releases gain new features through Updates it is our goal to maintain the security guidance alongside the product. It isn’t just the product that shapes the guidance, though. It’s also the changing landscape of security and workloads. New threats, and new technologies, require new approaches.
New Releases of Security Configuration Guides
Today we release updates to the vSphere Security Configuration Guides for all supported versions of vSphere. For vSphere 6.5 and 6.7 the changes are minor, and make some recommendations based on improvements to those products (service disablement, and the deprecation of the svga.vgaOnly guidance). Most installations of vSphere 6.5 and 6.7 are fairly mature, and we didn’t want to “rock the boat” as the saying goes. If a vSphere Admin has to spend political capital to make changes in older environments I’d rather they did it on patching first. After all, patching and good access control hygiene are commonly accepted as the two biggest ways to improve security.
vSphere 7 is different. Most customers are building new environments based on vSphere 7, and as they work through system designs they use tools like the Security Configuration Guide as a input into their designs. With the Security Configuration Guide released with vSphere 7 Update 1 we took the opportunity to be more prescriptive about best practices in all parts of a vSphere implementation. Today’s update takes that a bit further. Isolating management networks, disabling SSH, better firewalling, better security practices, and even leaving behind some old security controls that cause more problems than they solve nowadays. Security is always a tradeoff, usually against usability, and making good choices about where to spend your time is a huge part of getting ahead. This fact is also what resonates with many of us at VMware as we develop guidance and products. How do we help organizations get back to their own work faster? How do we help vSphere Admins and their colleagues prioritize the risks? Tools like Carbon Black Workload Protection demonstrate some of that thinking in action.
If you’re interested in the vSphere Security Configuration guides you can download them at https://core.vmware.com/security-configuration-guide
What Changed with the Security Configuration Guide 7
The vSphere Security Configuration Guide 7 has been updated with quite a bit of cumulative feedback. Thank you for all of it. The document inside the kit .zip file tells you how to submit feedback..
- Corrected errors in the PowerCLI guidance for auditing VMs (I’d mis-pasted Get-VMHost instead of Get-VM)
- The first vSphere SCG 7 introduced spreadsheet tabs for ESXi, vCenter Server, VMs, and In-Guest controls. This version adds a tab for “Deprecated.” A big question that has always loomed over us is “where did a security control go?” It is our intention that, moving forward, when something isn’t a good idea anymore we put it out to pasture in the Deprecated tab. This keeps it visible, and allows us to document WHY we are making that change.
- Moved the svga.vgaOnly control to the Deprecated tab. That control limits a VM to only VGA resolutions, and many modern guest OSes do not like that. It’s a source of friction and confusion and the cause of a lot of calls to support (ours and others). Beyond that, though, modern guest OSes sometimes don’t display anything at all when they can’t get the video mode they like, and that means important diagnostic information may go unobserved. Security is a tradeoff, and the meager benefits we might get from this control are completely outweighed by the problems the control causes. You can certainly use the control if you want, but we don’t recommend it for general use anymore.
- Added and updated guidance for disabling SLP and CIM service daemons on ESXi. Security advisories are often good opportunities to assess the state of things, and most customers do not use these protocols. No VMware products use these protocols, either. We now have good methods and guidance for disabling them.
- Added controls for network isolation. It’s been commonly held as a sort of “tribal knowledge” that you should isolate management, vMotion, and vSAN. We finally wrote it down. We also include guidance about extending that down into hardware. Out-of-band management controllers like Xclarity, iLO, and iDRAC are wonderful, but they can sometimes be configured in ways that present opportunities to attackers, and we’d like you to think about that as part of your system designs.
- Added guidance to close a loophole in the SCG. For years we have included guidance about patching, because many organizations use the SCG as a checklist, and we’d like everyone to check off the “I’m Patched!” box because patching is the only way to remove vulnerabilities. However, the way it is phrased makes it possible to be running an unsupported version of vSphere, be completely patched, and still be able to check that box. Rewording it created other issues so we simply added esxi-7.supported and vcenter-7.supported controls to highlight that an organization still should be running software that has not reached end-of-life.
- Added guidance about procuring and enabling Trusted Platform Modules, or TPMs. TPM 2.0 is an inexpensive way to get some very advanced security out of VMware vSphere and ESXi, and we feel strongly that you should not be acquiring new hardware without these. Even our friends at Microsoft agree — the Windows Server 2022 certifications require them, too (BTW, great use of the virtual TPM feature in vSphere when the time comes).
- Re-added the vm-7.pci-passthrough guidance with updated guidance. Any time you allow a VM to directly access hardware you increase the risk that an attacker on that VM will be able to do something to the hardware. The PCIe bus was designed with certain assumptions in mind, and attackers can exploit those assumptions to cause disruptions on hosts (BTW, great reason to use vSphere HA, too).
- Added guidance about disabling the DCLI interfaces if you aren’t using them on vCenter Server. If you’re using them — great! They’re wonderful. But if not, shut it off like you’ve shut SSH off, too (BTW, with all the new APIs in vSphere 7 you don’t need SSH enabled anywhere — shut it off and save a lot of compliance headache with scanning).
Again, you can download the vSphere Security Configuration guides at https://core.vmware.com/security-configuration-guide (and the main vmware.com Hardening Guide page is being updated as we speak). Also feel free to look around at other security resources at https://core.vmware.com/security or our Compliance resources at https://core.vmware.com/compliance.
As always, thank you for being our customers. Help us help you — please let us know how we can make our products better, whether it’s a change to the product, better documentation, or anything. The truth is that you use our products in all sorts of interesting ways, and if there’s something bugging you we won’t know until you tell us. vSphere 7 has a new feedback mechanism in the vSphere Client. Please use it for any and all things. Give feedback to your account team and Solutions Engineer. Or email me — my address is in the SCG documentation. Please stay safe and secure, and thank you.
