DISA Releases VMware vSphere 7.0 STIG - Version 1, Release 2

August 20, 2023

Reading time: 21 minutes

On July 26, 2023, the Defense Information Systems Agency (DISA) released the first VMware vSphere 7.0 STIG update. This update includes several minor updates to the checks and fixes across the ESXi, VAMI, vCA EAM, vCA Lookup Service, vCA Photon OS, vCA PostgreSQL, vCA STS, vCA UI, vCenter, and Virtual Machine STIGs.

What’s Changed?

What’s Changed?

VMware vSphere 7.0 ESXi STIG, V1R2

ESXI-70-000012 - Altered fix.

Previous fix:

From an ESXi shell, run the following command, adding or correcting the following line in "/etc/ssh/sshd_config":

IgnoreRhosts yes

Updated fix:

From an ESXi shell, add or correct the following line in "/etc/ssh/sshd_config":

IgnoreRhosts yes

ESXI-70-000032 - Altered fix.

Previous fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Select the "Security.PasswordHistory" value and configure it to "5".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Security.PasswordHistory | Set-AdvancedSetting -Value 5

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Click "Edit". Select the "Security.PasswordHistory" value and configure it to "5".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Security.PasswordHistory | Set-AdvancedSetting -Value 5

ESXI-70-000034 - Altered fix.

Previous fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit".
Select the "Config.HostAgent.plugins.solo.enableMob" value and configure it to "false".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value false

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit".
Select the "Config.HostAgent.plugins.solo.enableMob" value and configure it to "false".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value false

ESXI-70-000079 - Altered fix.

Previous fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit".
Select the "Config.HostAgent.plugins.solo.enableMob" value and configure it to "false".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value false

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings. Click "Edit".
Select the "Config.HostAgent.plugins.solo.enableMob" value and configure it to "false".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value false

ESXI-70-000081 - Altered fix.

Previous fix:

From the vSphere Client go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Select the "UserVars.SuppressHyperthreadWarning" value and set it to "0".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressHyperthreadWarning | Set-AdvancedSetting -Value "0"

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Click "Edit". Select the "UserVars.SuppressHyperthreadWarning" value and set it to "0".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name UserVars.SuppressHyperthreadWarning | Set-AdvancedSetting -Value "0"

ESXI-70-000087 - Altered fix.

Previous fix:

From the vSphere Client go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Select the "Mem.MemEagerZero" value and set it to "1".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Mem.MemEagerZero | Set-AdvancedSetting -Value "1"

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Click "Edit". Select the "Mem.MemEagerZero" value and set it to "1".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Mem.MemEagerZero | Set-AdvancedSetting -Value "1"

ESXI-70-000091 - Altered fix.

Previous fix:

From the vSphere Client go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Select the "Security.PasswordMaxDays" value and set it to "90".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Security.PasswordMaxDays | Set-AdvancedSetting -Value "90"

Updated fix:

From the vSphere Client, go to Hosts and Clusters.
Select the ESXi Host >> Configure >> System >> Advanced System Settings.
Click "Edit". Select the "Security.PasswordMaxDays" value and set it to "90".

or

From a PowerCLI command prompt while connected to the ESXi host, run the following command:
Get-VMHost | Get-AdvancedSetting -Name Security.PasswordMaxDays | Set-AdvancedSetting -Value "90"

ESXI-70-000093 - Altered fix.

Previous fix:

From an ESXi shell, run the following commands:

# \cp /etc/vmware/config /etc/vmware/config.bak
# grep -v "^vmx\.log" /etc/vmware/config.bak>/etc/vmware/config

Updated fix:

From an ESXi shell, run the following commands:

# cp /etc/vmware/config /etc/vmware/config.bak
# grep -v "^vmx\.log" /etc/vmware/config.bak>/etc/vmware/config

ESXI-70-000049 - Altered check.

Previous partial check:

...If any services are enabled on any Management VMkernel adapter, this is a finding...

Updated partial check:

...If any services other than "Management" are enabled on the Management VMkernel adapter, this is a finding...

ESXI-70-000085 - Altered check.

Previous check:

From an ESXi shell, run the following command:
# esxcli system syslog config get|grep 509

or

From a PowerCLI command prompt while connected to the ESXi host, run the following commands:

$esxcli = Get-EsxCli -v2
$esxcli.system.syslog.config.get.invoke()|Select StrictX509Compliance

Expected result:
Strict X509Compliance: true

If the output does not match the expected result, this is a finding.

Updated check:

If SSL is not used for the syslog target, this is not applicable.

From an ESXi shell, run the following command:
# esxcli system syslog config get|grep 509

or

From a PowerCLI command prompt while connected to the ESXi host, run the following commands:
$esxcli = Get-EsxCli -v2
$esxcli.system.syslog.config.get.invoke()|Select StrictX509Compliance

Expected result:
Strict X509Compliance: true

If the output does not match the expected result, this is a finding.

ESXI-70-000094 - Altered check.

Previous check:

If the ESXi host does not have a compatible TPM, this finding is downgraded to a CAT III.
# esxcli system settings encryption get|grep Mode

or

From a PowerCLI command prompt while connected to the ESXi host, run the following commands:
$esxcli = Get-EsxCli -v2
$esxcli.system.settings.encryption.get.invoke() | Select Mode

Expected result:
Mode: TPM

If the output does not match the expected result, this is a finding.

Updated check:

If the ESXi host does not have a compatible TPM, this finding is downgraded to a CAT III.
From an ESXi shell, run the following command:
# esxcli system settings encryption get|grep Mode

or

From a PowerCLI command prompt while connected to the ESXi host, run the following commands:
$esxcli = Get-EsxCli -v2
$esxcli.system.settings.encryption.get.invoke() | Select Mode

Expected result:
Mode: TPM

If the output does not match the expected result, this is a finding.

ESXI-70-000047 - Removed extra space before a period in the fix.
ESXI-70-000064 - Rule number updated from SV-256425r886056 to SV-256425r919425 due to changes in the content management system.

ESXI-70-000065 - Removed extraneous word “a” in the fix.

Previous partial fix:

...Click "Edit Settings". On the "Properties" tab, change the "VLAN ID" to a an appropriate VLAN ID and click "OK"...

Updated partial fix:

...Click "Edit Settings". On the "Properties" tab, change the "VLAN ID" to an appropriate VLAN ID and click "OK"...

ESXI-70-000084 - Altered check, fix, and discussion.

Previous partial discussions:

...Note: Audit records can be viewed locally via the " /bin/auditLogReader" utility over SSH or at the ESXi shell...

Updated partial discussions:

...Note: Audit records can be viewed locally via the "/bin/auditLogReader" utility over SSH or at the ESXi shell...

Previous partial check:

...
Audit Record Storage Active: true
Audit Record Storage Capacity: 100
Audit Record Storage Directory: /scratch/auditLog
Audit Remote Host Enabled: true

Note: The "Audit Record Storage Directory" may differ from the default above but it must still be located on persistent storage.
...

Updated partial check:

...
AuditRecordRemoteTransmissionActive : true
AuditRecordStorageActive : true
AuditRecordStorageCapacity : 100
AuditRecordStorageDirectory : /scratch/auditLog

Note: The "Audit Record Storage Directory" may differ from the default above, but it must still be located on persistent storage.
...

Previous partial check:

...'/scratch/auditLog' by default and does not normally need to be changed...

Updated partial check:

..."/scratch/auditLog" by default and does not normally need to be changed...

VMware vSphere 7.0 VAMI STIG, V1R2

VCLD-70-000007 - Altered check and fix

Previous check:

At the command prompt, run the following command:
# stat -c "%n has %a permissions and is owned by %U:%G" /opt/vmware/var/log/lighttpd/*.log

Expected result:
/opt/vmware/var/log/lighttpd/access.log has 644 permissions and is owned by root:root
/opt/vmware/var/log/lighttpd/error.log has 644 permissions and is owned by root:root

If the output does not match the expected result, this is a finding.

Updated check:

At the command prompt, run the following command:
# find /opt/vmware/var/log/lighttpd/ -xdev -type f -a '(' -perm -o+w -o -not -user root -o -not -group root ')' -exec ls -ld {} \;

If any files are returned, this is a finding.

Previous fix:

At the command prompt, run the following commands:

# chown root:root /opt/vmware/var/log/lighttpd/*.log
# chmod 644 /opt/vmware/var/log/lighttpd/*.log

Updated fix:

At the command prompt, run the following commands:
# chmod o-w <file>
# chown root:root <file>

Note: Substitute <file> with the listed file.

VCLD-70-000014 - Altered check and fix

Previous partial check:

At the command prompt, run the following command:
# /opt/vmware/sbin/vami-lighttpd -p -f /opt/vmware/etc/lighttpd/lighttpd.conf 2>/dev/null|grep "url.access-deny"|sed 's: ::g'

Expected result:
url.access-deny=("~",".inc")
url.access-deny=("")
...

Updated partial check:

At the command prompt, run the following command:
# grep "url.access-deny" /opt/vmware/etc/lighttpd/lighttpd.conf

Expected result:
url.access-deny             = ( "~", ".inc" )
...

Previous partial fix:

Add or reconfigure the following value:

url.access-deny=("~",".inc")
url.access-deny=("")
...

Updated fix:

Add or reconfigure the following value:

url.access-deny = ( "~", ".inc" )
...

VMware vSphere 7.0 vCA EAM STIG, V1R2

VCEM-70-000008 - Altered check.

Previous partial check:

...
# rpm -V vmware-eam|grep "^..5......"|grep -v -E "\.installer|\.properties|\.xml"
...

Updated partial check:

...
# rpm -V vmware-eam|grep "^..5......" | grep -v 'c /' | grep -v -E ".installer|.properties|.xml"
...

VCEM-70-000026 - Altered discussion.

Previous partial discussion:

...
Therefore, the Security Token Service must be configured with a catch-all error handler that redirects to a standard "error.jsp".

Updated partial discussion:

...
Therefore, the ESX Agent Manager service must be configured with a catch-all error handler that redirects to a standard "error.jsp".

VCEM-70-000028 - Clarified check.

Previous partial check:

...
If no lines are returned, this is not a finding.

Updated partial check:

...
If no lines are returned, this is not a finding.

If "XPath set is empty" is returned, this is not a finding.

VMware vSphere 7.0 vCA Lookup Service STIG, V1R2

VCLU-70-000007 - Altered check and fix.

Previous check:

At the command prompt, run the following command:

# find /var/log/vmware/lookupsvc -xdev -type f -a '(' -perm /137 -o -not -user root -o -not -group root ')' -exec ls -ld {} \;

If any files are returned, this is a finding.

Updated check:

At the command prompt, run the following command:
# find /var/log/vmware/lookupsvc -xdev -type f ! -name lookupsvc-init.log -a '(' -perm -o+w -o -not -user lookupsvc -o -not -group lookupsvc ')' -exec ls -ld {} \;

If any files are returned, this is a finding.

Note: Prior to Update 3h, the user and group should be root.

Previous fix:

At the command prompt, run the following commands:
# chmod 640 /var/log/vmware/lookupsvc/<file>
# chown root:root /var/log/vmware/lookupsvc/<file>

Note: Substitute <file> with the listed file.

Updated fix:

At the command prompt, run the following commands:
# chmod o-w /var/log/vmware/lookupsvc/<file>
# chown lookupsvc:lookupsvc /var/log/vmware/lookupsvc/<file>

Note: Substitute <file> with the listed file.

VMware vSphere 7.0 vCA Photon OS STIG, V1R2

PHTN-30-000054 - Altered check.

Previous partial check:

At the command line, run the following command to obtain a list of setuid files:
# find / -xdev -perm -4000 -type f -o -perm -2000 -type f | sort
...

Updated partial check:

At the command line, run the following command to obtain a list of setuid files:
# find / -xdev -path /var/lib/containerd -prune -o \( -perm -4000 -type f -o -perm -2000 \) -type f -print | sort
...

PHTN-30-000067 - Altered check.

Previous partial check:

...
Expected result:
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
...

Updated partial check:

...
Expected result:
-a always,exit -S all -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged
...

PHTN-30-000108 - Altered check.

Previous partial check:

...
Expected result:
/etc/ssh/ssh_host_dsa_key.pub permissions are 644 and owned by root:root
/etc/ssh/ssh_host_ecdsa_key.pub permissions are 644 and owned by root:root
/etc/ssh/ssh_host_ed25519_key.pub permissions are 644 and owned by root:root
/etc/ssh/ssh_host_rsa_key.pub permissions are 644 and owned by root:root
...

Updated partial check:

...
Expected result:
/etc/ssh/ssh_host_ecdsa_key.pub permissions are 644 and owned by root:root
/etc/ssh/ssh_host_ed25519_key.pub permissions are 644 and owned by root:root
/etc/ssh/ssh_host_rsa_key.pub permissions are 644 and owned by root:root
...

PHTN-30-000109 - Altered check.

Previous partial check:

...
Expected result:
/etc/ssh/ssh_host_dsa_key permissions are 600 and owned by root:root
/etc/ssh/ssh_host_ecdsa_key permissions are 600 and owned by root:root
/etc/ssh/ssh_host_ed25519_key permissions are 600 and owned by root:root
/etc/ssh/ssh_host_rsa_key permissions are 600 and owned by root:root
...

Updated partial check:

...
Expected result:
/etc/ssh/ssh_host_ecdsa_key permissions are 600 and owned by root:root
/etc/ssh/ssh_host_ed25519_key permissions are 600 and owned by root:root
/etc/ssh/ssh_host_rsa_key permissions are 600 and owned by root:root
...

PHTN-30-000114 - Altered check.

Previous partial check:

...
Expected result:
UMASK 077

If the output does not match the expected result, this a finding.

Updated partial check:

...
Example result:
UMASK 077

If "UMASK" is not configured to "077", this a finding.

Note: "UMASK" should only be specified once in login.defs.

VMware vSphere 7.0 vCA PostgreSQL STIG, V1R2

VCPG-70-000006 - Corrected typo in check and fix

Previous check:

At the command prompt, run the following command:

# /opt/vmware/vpostgres/current/bin/psql -d VCDB -x -U postgres -c "\dt;"|grep Owner|grep -v vc

If any tables are returned, this is a finding.

Updated check:

At the command prompt, run the following command:

# /opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres -t -A -c "\dt;" | grep -v 'table|vc'

If any tables are returned, this is a finding.

Note: Upgrades may introduce new tables that are owned by the "postgres" user and can be updated to be owned by the "vc" user.

Previous partial fix:

...
# /opt/vmware/vpostgres/current/bin/psql -U postgres -c "ALTER TABLE <tablename> OWNER TO vc;"
...

Updated partial fix:

...
# /opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres -c "ALTER TABLE <tablename> OWNER TO vc;"
...

VMware vSphere 7.0 vCA STS STIG, V1R2

VCST-70-000006 - Altered check and fix.

Previous partial check:

...
1catalina.org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter 
org.apache.catalina.startup.Catalina.handlers = 1catalina.org.apache.juli.FileHandler 
...

Updated partial check:

...
1catalina.org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter
1catalina.org.apache.juli.FileHandler.maxDays = 10
org.apache.catalina.startup.Catalina.handlers = 1catalina.org.apache.juli.FileHandler
...

Previous partial fix:

...
1catalina.org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter 
org.apache.catalina.startup.Catalina.handlers = 1catalina.org.apache.juli.FileHandler 
...

Updated partial fix:

...
1catalina.org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter
1catalina.org.apache.juli.FileHandler.maxDays = 10
org.apache.catalina.startup.Catalina.handlers = 1catalina.org.apache.juli.FileHandler
...

VCST-70-000026 - Rule number updated from SV-256770r889280 to SV-256770r918976 due to changes in the content management system.

VCST-70-000028 - Added additional information for port TCP 3128 to the check and fix.

Previous partial check:

...
Expected result:  
bio-custom.http.port=7080 
bio-custom.https.port=8443 
bio-ssl-localhost.https.port=7444 

If the output of the command does not match the expected result, this is a finding.

Updated partial check:

...
Expected result:
bio-custom.http.port=7080
bio-custom.https.port=8443
bio-ssl-clientauth.https.port=3128
bio-ssl-localhost.https.port=7444

If the output of the command does not match the expected result, this is a finding.

Note: Port 3128 will not be shown in the output prior to 7.0 U3i.

Previous partial fix:

...
Set the Security Token Service port specifications according to the following list: 
bio-custom.http.port=7080 
bio-custom.https.port=8443 
bio-ssl-localhost.https.port=7444 

Restart the service with the following command: 

# vmon-cli --restart sts

Updated partial fix:

...
Set the Security Token Service port specifications according to the following list:
bio-custom.http.port=7080
bio-custom.https.port=8443
bio-ssl-clientauth.https.port=3128
bio-ssl-localhost.https.port=7444

Restart the service with the following command:

# vmon-cli --restart sts

VMware vSphere 7.0 vCA UI STIG, V1R2

VCUI-70-000008 - Altered check

Previous partial check:

At the command prompt, run the following command:
# rpm -V vsphere-ui|grep "^..5......"|grep -v -E "\.prop|\.pass|\.xml|\.json"
...

Updated partial check:

At the command prompt, run the following command: 
# rpm -V vsphere-ui|grep "^..5......"|grep -v -E "\.prop|\.pass|\.xml" 
...

VMware vSphere 7.0 vCenter STIG, V1R2

VCSA-70-000009 - Corrected typo in fix.

Previous partial fix:

...
# /usr/lib/vmware-TlsReconfigurator/VcTlsReconfigurator/reconfigureVc update -p TLS1.2
...

Updated partial fix:

...
# /usr/lib/vmware-TlsReconfigurator/VcTlsReconfigurator/reconfigureVc update -p TLSv1.2
...

VCSA-70-000080 - Altered fix.

Previous partial fix:

...
By default, both locations are pulled from the cert. CRL location can be overridden in this screen, and local responders can be specified via the sso-config command line tool. See the supplemental document for more information.

Updated partial fix:

...
By default, both locations are pulled from the cert. CRL location can be overridden in this screen, and local responders can be specified via the sso-config command line tool. Refer to the supplemental document for more information.

Note: If FIPS mode is enabled on vCenter, OCSP revocation validation may not function and CRL used instead.

VCSA-70-000284 - Altered entire requirement.

Previous title:

The vCenter Server must restrict access to the cryptographic role.

Updated title:

The vCenter Server must restrict access to the default roles with cryptographic permissions.

Previous discussion:

In vSphere, the built-in "Administrator" role contains permission to perform cryptographic operations such as Key Management Server (KMS) functions and encrypting and decrypting virtual machine disks. This role must be reserved for cryptographic administrators where virtual machine encryption and/or vSAN encryption is in use.

A new built-in role called "No Cryptography Administrator" exists to provide all administrative permissions except cryptographic operations. Permissions must be restricted such that normal vSphere administrators are assigned the "No Cryptography Administrator" role or more restrictive.

The "Administrator" role must be tightly controlled and must not be applied to administrators who will not be doing cryptographic work. Catastrophic data loss can result from poorly administered cryptography.

Updated discussion:

...
In vSphere, a number of default roles contain permission to perform cryptographic operations such as Key Management Server (KMS) functions and encrypting and decrypting virtual machine disks. These roles must be reserved for cryptographic administrators where virtual machine encryption and/or vSAN encryption is in use.

A new built-in role called "No Cryptography Administrator" exists to provide all administrative permissions except cryptographic operations. Permissions must be restricted such that normal vSphere administrators are assigned the "No Cryptography Administrator" role or more restrictive.

These default roles must be tightly controlled and must not be applied to administrators who will not be doing cryptographic work. Catastrophic data loss can result from poorly administered cryptography.

Previous check:

From the vSphere Client, go to Administration >> Access Control >> Roles.

or

From a PowerCLI command prompt while connected to the vCenter server, run the following command:
Get-VIPermission | Where {$_.Role -eq "Admin"} | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto

If there are any users other than Solution Users with the "Administrator" role that are not explicitly designated for cryptographic operations, this is a finding.

Updated check:

...
By default, there are four roles that contain cryptographic-related permissions: Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, and vSphere Kubernetes Manager.

From the vSphere Client, go to Administration >> Access Control >> Roles.

or

From a PowerCLI command prompt while connected to the vCenter server, run the following command:
Get-VIPermission | Where {$_.Role -eq "Admin" -or $_.Role -eq "NoTrustedAdmin" -or $_.Role -eq "vCLSAdmin" -or $_.Role -eq "vSphereKubernetesManager"} | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto

If there are any users or groups assigned to the default roles with cryptographic permissions and are not explicitly designated to perform cryptographic operations, this is a finding.

The built-in solution users assigned to the administrator role are NOT a finding.

VCSA-70-000285 - Altered check and fix.

Previous check:

From the vSphere Client, go to Administration >> Access Control >> Roles.
Highlight each role and click the "Privileges" button in the right pane.
Verify only the "Administrator" and any site-specific cryptographic group(s) have the following permissions:
Cryptographic Operations privileges
Global.Diagnostics
Host.Inventory.Add host to cluster
Host.Inventory.Add standalone host
Host.Local operations.Manage user groups

or

From a PowerCLI command prompt while connected to the vCenter server, run the following commands:

$roles = Get-VIRole
ForEach($role in $roles){
    $privileges = $role.PrivilegeList
    If($privileges -match "Crypto*" -or $privileges -match "Global.Diagnostics" -or $privileges -match "Host.Inventory.Add*" -or $privileges -match "Host.Local operations.Manage user groups"){
    Write-Host "$role has Cryptographic privileges"
    }
}

If any role other than administrator and any site-specific group(s) have any of these permissions, this is a finding.

Updated check:

By default, there are four roles that contain cryptographic-related permissions: Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, and vSphere Kubernetes Manager.
From the vSphere Client, go to Administration >> Access Control >> Roles.
Highlight each role and click the 'Privileges" button in the right pane.
Verify that only the Administrator, No Trusted Infrastructure Administrator, vCLSAdmin, and vSphere Kubernetes Manager and any site-specific cryptographic roles have the following permissions:
Cryptographic Operations privileges
Global.Diagnostics
Host.Inventory.Add host to cluster
Host.Inventory.Add standalone host
Host.Local operations.Manage user groups

or

From a PowerCLI command prompt while connected to the vCenter server, run the following commands:

$roles = Get-VIRole
ForEach($role in $roles){
    $privileges = $role.PrivilegeList
    If($privileges -match "Crypto*" -or $privileges -match "Global.Diagnostics" -or $privileges -match "Host.Inventory.Add*" -or $privileges -match "Host.Local operations.Manage user groups"){
    Write-Host "$role has Cryptographic privileges"
    }
}

If any role other than the four default roles contain the permissions listed above and is not authorized to perform cryptographic-related operations, this is a finding.

Previous fix:

From the vSphere Client, go to Administration >> Access Control >> Roles.
Highlight each role and click the pencil button if it is enabled.
Remove the following permissions from any group other than "Administrator and any site-specific cryptographic group(s):

Cryptographic Operations privileges
Global.Diagnostics
Host.Inventory.Add host to cluster
Host.Inventory.Add standalone host
Host.Local operations.Manage user groups

Updated fix:

From the vSphere Client, go to Administration >> Access Control >> Roles.
Highlight the target custom role and click "Edit".
Remove the following permissions from any custom role that is not authorized to perform cryptographic-related operations:

Cryptographic Operations privileges
Global.Diagnostics
Host.Inventory.Add host to cluster
Host.Inventory.Add standalone host
Host.Local operations.Manage user groups

VCSA-70-000294 - Corrected typo in fix

Previous partial fix:

...
Select a vCenter Server >> Configure >> Settings >> Key Providers.
...

Updated partial fix:

...
Select a vCenter Server >> Configure >> Security >> Key Providers.
...

VMware vSphere 7.0 Virtual Machine STIG, V1R2

VMCH-70-000023 - Altered check and fix.

Previous check:

From the vSphere Client, select the Virtual Machine, right-click, and go to Edit Settings >> VM Options tab >> Advanced >> Configuration Parameters >> Edit Configuration.

Find the "mks.enable3d" value and verify it is set to "false".

or

From a PowerCLI command prompt while connected to the ESXi host or vCenter server, run the following command:

Get-VM "VM Name" | Get-AdvancedSetting -Name mks.enable3d

If the virtual machine advanced setting "mks.enable3d" does not exist or is not set to "false", this is a finding.

If a virtual machine requires 3D features, this is not a finding.

Updated check:

For each virtual machine do the following:

From the vSphere Client, right-click the virtual machine and go to Edit Settings.

Expand the "Video card" and verify the "Enable 3D Support" checkbox is unchecked.

or

From a PowerCLI command prompt while connected to the ESXi host or vCenter server, run the following command:

Get-VM "VM Name" | Get-AdvancedSetting -Name mks.enable3d

If the virtual machine advanced setting "mks.enable3d" exists and is not set to "false", this is a finding.

If the virtual machine advanced setting "mks.enable3d" does not exist, this is not a finding.

Previous fix:

From the vSphere Client, select the Virtual Machine, right-click, and go to Edit Settings >> VM Options tab >> Advanced >> Configuration Parameters >> Edit Configuration.

Find the "mks.enable3d" value and set it to "false".

Note: The VM must be powered off to modify the advanced settings through the vSphere Client. It is recommended to configure these settings with PowerCLI as this can be done while the VM is powered on. In this case, the modified settings will not take effect until a cold boot of the VM.

or

From a PowerCLI command prompt while connected to the ESXi host or vCenter server, run the provided commands as shown below.

If the setting does not exist, run:

Get-VM "VM Name" | New-AdvancedSetting -Name mks.enable3d -Value false

If the setting exists, run:

Get-VM "VM Name" | Get-AdvancedSetting -Name mks.enable3d | Set-AdvancedSetting -Value false

Updated fix:

For each virtual machine do the following:

From the vSphere Client, right-click the virtual machine and go to "Edit Settings".

Expand the "Video card" and uncheck the "Enable 3D Support" checkbox.

Click "OK".

or

From a PowerCLI command prompt while connected to the ESXi host or vCenter server, run the provided commands as noted below.

If the setting does not exist, run:

Get-VM "VM Name" | New-AdvancedSetting -Name mks.enable3d -Value false

If the setting exists, run:

Get-VM "VM Name" | Get-AdvancedSetting -Name mks.enable3d | Set-AdvancedSetting -Value false

Note: The VM must be powered off to configure the advanced settings through the vSphere Client. Therefore, it is recommended to configure these settings with PowerCLI as this can be done while the VM is powered on. Settings do not take effect via either method until the virtual machine is cold started, not rebooted.

VMCH-70-000024 - Corrected typo in check

Previous partial check:

...
Get-VM | Where {($_.ExtensionData.Config.MigrateEncryption -ne "opportunistic") -or ($_.ExtensionData.Config.MigrateEncryption -ne "required")}
...

Updated partial check:

...
Get-VM | Where {($_.ExtensionData.Config.MigrateEncryption -eq "disabled")}
...

Tags:

Compliance

Security

STIGs

DISA Releases VMware vSphere 7.0 STIG - Version 1, Release 2

What’s Changed?

VMware vSphere 7.0 ESXi STIG, V1R2

VMware vSphere 7.0 VAMI STIG, V1R2

VMware vSphere 7.0 vCA EAM STIG, V1R2

VMware vSphere 7.0 vCA Lookup Service STIG, V1R2

VMware vSphere 7.0 vCA Photon OS STIG, V1R2

VMware vSphere 7.0 vCA PostgreSQL STIG, V1R2

VMware vSphere 7.0 vCA STS STIG, V1R2

VMware vSphere 7.0 vCA UI STIG, V1R2

VMware vSphere 7.0 vCenter STIG, V1R2

VMware vSphere 7.0 Virtual Machine STIG, V1R2

See Also