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 vga Only 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 firewall, 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.
I hope this has been informative and thank you for reading!
