VCF Security Hardening Guidance

(Day 3 of 22 in our Cybersecurity Awareness Month series)

One of the cornerstones of security in VMware Cloud Foundation, and before it with vSphere, has been the Security Configuration Guides we publish. These guides, started almost two decades ago, form the basis of security configuration in and around the products themselves. Nowadays you can find the guides out in our GitHub repository:

https://github.com/vmware/vcf-security-and-compliance-guidelines

or via https://brcm.tech/vcf-security if you’re able to use a redirector.

What is the Security Configuration Guide (SCG)?

We deliver the SCG as a Microsoft Excel spreadsheet and a CSV, making it easily accessible to everyone, as well as to machines, now that AI agents are part of the landscape. These files have a lot of information in them and aim to cover all parts of VCF. The different fields are:

SCG ID: Each security control gets its own ID so we can reference it directly. In the 9.x guides we (mostly) standardized these across the different components so that common categories of controls, like timeouts and lockouts, share similar names.

Secure Controls Framework ID: The Secure Controls Framework is a project, hosted at https://securecontrolsframework.org, that cross-maps hundreds of different worldwide regulatory compliance standards. We use it as part of our regulatory compliance mappings because it makes the process easier.

DISA STIG ID: A STIG is a Security Technical Implementation Guide, written for the US Department of War’s Defense Information Systems Agency, or DISA. Broadcom develops the DISA STIGs for VMware and submits them to DISA for review. They meet the requirements set by the US government, which sometimes differ from general best practices (often going further in specific directions). You can find approved and published STIGs at cyber.mil. While DISA evaluates our submissions, we publish them as STIG Readiness Guides at https://www.vmware.com/resources/certifications/stigs.

PCI DSS 4.0.1, NIST SP 800-53R5 ID: Corresponding regulatory compliance controls. We now keep a larger set of mappings for compliance standards in our Regulatory Compliance Library at https://github.com/vmware/vcf-security-and-compliance-guidelines/.

Component Name: The major part of VMware Cloud Foundation that the control affects. This helps organizations and their auditors not worry about certain controls if they don’t have the component deployed.

Component Version: This is usually the same as the version of the Security Configuration Guide, but not always, and we leave it in for flexibility.

Feature/Function: Major VCF components have individual features you can enable or disable, and if you aren’t using a particular feature then you and your auditors can ignore the related controls.

Description/Title: In general, the title of a control is actually a standardized description of what the control is attempting to accomplish.

Discussion: Many of the security controls in the Guide have secure defaults. However, many do not, and that’s because they require you to make a decision, or have implications for functionality or recoverability of the system. As such, we try to spell these things out, telling you what the control is doing and why. That way you can make a good decision for your organization about whether to adopt it.

Potential Functional Impact if Default Value is Changed: An up-front accounting of functionality that might change or cease to function if you change a particular control. A good example is the virtual switch security settings. Setting them to what the Guide recommends may prevent clustered applications from working correctly. We also include hints and tactics for dealing with issues that might arise.

Implementation Priority: P0 is where there is not a secure default, and you should do this immediately. P1 has an acceptable default, but might not be as good as it could be (login banners also fall into this category). P2 controls have a secure default, but you should continue to audit them. And “Advanced” parameters are interesting new things that we’d like you to be aware of but don’t necessarily recommend yet. Often that is because we are concerned about the effect on third-party software or interoperability in your environment.

Configuration Parameter: The parameter itself, if there is one. Some security controls don’t have a specific parameter, and are more of an implementation strategy.

Installation Default Value: What the value was before you changed it, because once in a while you may want to undo what you changed.

Baseline Suggested Value: The recommendation for a secure setting.

Is the Default: If the suggested value and the default value aren’t the same then this will say NO. This column helps organizations filter controls.

Action Needed: This will be Audit or Modify, depending on whether you need to change something or not.

Setting Location: This is a description of where you can find the control, and we often use it when there isn’t a specific configuration parameter.

PowerCLI Command Assessment: A sample of PowerCLI to check the parameter.

PowerCLI Command Remediation: A sample of PowerCLI to set the parameter.

The Security Configuration Guide also ships with sample PowerCLI scripts. They tie all the assessment and remediation snippets together into one big script, as an example of how to do it.

Where Do I Start?

That is a lot of columns, but you don’t need all of them at once. Here is the approach we suggest:

Filter to what you run. Use Component Name and Feature/Function to hide the controls for components and features you haven’t deployed. There is no point in reading iSCSI guidance if you don’t use iSCSI.

Audit before you change anything. Run the assessment commands, or the sample script, to see where your environment stands today. Many controls are secure by default, so the list of real work is usually shorter than it first appears. Filtering Action Needed to “Modify” shows you that list.

Do the P0 controls first. These are the ones without a secure default. After that, work through P1, and leave the “Advanced” items until you have time to evaluate them properly.

Read before you set. The Discussion and Potential Functional Impact fields tell you what a control might cost you. Try the change in a test environment first, and note the Installation Default Value so you can go back if you need to.

Write down what you skipped, and why. You will not adopt every control, and that is fine. Your auditors will ask about the ones you skipped, as will anyone who inherits the environment after you.

Check again later. Settings drift, and upgrades and patches can change things. Rerun your audit after lifecycle operations and on a regular schedule, including the P2 controls that were already secure.

Security Configuration Guide Frequently Asked Questions

Q1: Is the Security Configuration Guide supported by Broadcom?

A1: Yes, Broadcom supports configuring the products according to the SCG. However, if you make a change and something is amiss, our support engineers may ask you to undo it. Similarly, some security features, like Secure Boot or Confidential Computing, require support inside the guest OS or from server hardware. Those portions may be out of scope for Broadcom support.

Q2: Why should I use this guidance, versus guidance from other sources on the Internet, like CIS Benchmarks?

A2: The people who build the products write the SCG, which covers the whole VCF stack and is the guidance Broadcom supports. Other sources of security information on the Internet may not be tested, may not be up to date, may not cover the whole VCF stack, and are not directly supported. Use them with care. People often ask about CIS Benchmarks in particular. A separate organization develops them, they cover only ESX, and they follow their own release schedule. If you must use them, use them; otherwise, use the SCG.

Q3: Should I use the DISA STIG or the Security Configuration Guide?

A3: The DISA STIG aims to meet the needs of the US government, and does include some specific additional hardening at the appliance level to meet those requirements. Beyond that, the STIG and the SCG are very similar. Our general advice is that if you must follow DISA STIGs, use the STIG; otherwise, use the SCG.

Q4: Which version of the Security Configuration Guide should I use?

A4: We file guides in the repository by product and version. Use the most specific guide available for what you are running. If there is a guide for your exact version, use that; if not, use the one for the nearest earlier release within the same major version. Guides for earlier releases of vSphere and VCF remain in the repository.

Q5: Can I use guidance for an older version on a newer one, like the VCF 5.2 guidance on VCF 9.1?

A5: We don’t recommend it. Between major versions we rename or remove parameters, change defaults, and add and retire components. Controls that mattered in the old release may no longer apply. Older guidance also knows nothing about features we added later, so you would have gaps and not know it. Use the guide written for the major version you are running. The same is true in the other direction: newer guidance may reference settings that do not exist in an older release.

Q6: How often is the SCG updated, and how do I know what changed?

A6: We publish a new guide with each major and update release of VCF, and we revise guides between releases when we need to correct or clarify something. Each guide includes a change log listing the controls we added, changed, or removed since the previous version.

Q7: Why aren’t there controls in the Security Configuration Guide for the VCF Management Services in VCF 9.1?

A7: VCF 9.1 introduces a new architecture for management appliances, via the VCF Management Services (VCFMS) platform. This is a Kubernetes-powered platform inside VCF itself that runs the VCF management functions. There are no user-configurable settings inside VCFMS, so there are no controls for it in the SCG.

Q8: Why doesn’t the SCG have Photon OS hardening guidance?

A8: We ship VMware appliances with their base operating system, Photon OS, pre-hardened, so they do not require further configuration. We do not directly support changing the configuration of the underlying appliance OS, so the SCG does not include those recommendations.

Q9: Does the SCG cover my workloads?

A9: The SCG covers the infrastructure, including the configuration settings of the virtual machines themselves. It does not cover what runs inside those virtual machines. For guest operating systems and applications, use the hardening guidance from their vendors.

Q10: Do I have to do everything in the Security Configuration Guide to be secure?

A10: The SCG is a set of guidelines and suggestions, so no. In fact, implementing the SCG controls is just one part of a holistic security design for your environment. That design should also include things like identity and access control, patching programs, isolation and firewalling, and so on.

Q11: If I implement the SCG, am I compliant with PCI DSS, NIST SP 800-53, or another standard?

A11: Not by itself. The mappings show which SCG controls relate to which requirements, which saves you and your auditors a lot of time. However, compliance depends on your scope, your processes, your people, and your auditor’s judgment, and no configuration guide can cover all of that. The Regulatory Compliance Library at https://brcm.tech/vcf-compliance has more detail for specific standards.

Q12: Are there security controls that aren’t in the Security Configuration Guide?

A12: Absolutely. The SCG lists concrete and actionable technical security controls. Other things, like the ideas of “least privilege” and “separation of duties,” are more design-oriented, so the SCG does not enumerate them. Same for identity and access control, firewalling, etc.

Q13: Does following the guidance in the SCG break anything?

A13: “Break” is a strong word, but all security comes at a cost, paid for with CPU cycles, administrator friction, or functional differences. Some things, like data-in-transit encryption, have a low cost. Some, like virtual switch security, do impact functionality for workloads. The “Discussion” and “Potential Functional Impact” fields for each SCG control cover these things.

Q14: Do I need to check my settings again after I patch or upgrade?

A14: Yes. Settings drift over time, new releases add controls and change defaults, and people make changes during troubleshooting that they never put back. Rerun your audit after upgrades and on a regular schedule. When you move to a new release, move to the SCG for that release too.

Q15: Are the sample scripts being actively developed? How do I request a feature?

A15: The sample PowerCLI scripts are simply there as an example of how you might automate security audits and remediation. They are about as complex as we want them to be. Feel free to download a copy from GitHub and edit them yourselves, have your AI agent help you, or whatever – they’re there to learn from and customize. If you do create something interesting, feel free to submit a pull request in the repository.

Q16: How do I report an error or ask a question about a control?

A16: Open an issue in the GitHub repository, or use the contact listed in the repository README. Tell us the SCG ID and the version of the guide you are using so we can find the control quickly.