STIGViewer Support

The ESXi Image Profile and vSphere Installation Bundle (VIB) acceptance levels must be verified.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-256410ESXI-70-000047SV-256410r984242_ruleCCI-001749high
Description
Verify the ESXi Image Profile to only allow signed VIBs. An unsigned VIB represents untested code installed on an ESXi host. The ESXi Image profile supports four acceptance levels: 1. VMwareCertified - VIBs created, tested, and signed by VMware. 2. VMwareAccepted - VIBs created by a VMware partner but tested and signed by VMware. 3. PartnerSupported - VIBs created, tested, and signed by a certified VMware partner. 4. CommunitySupported - VIBs that have not been tested by VMware or a VMware partner. Community Supported VIBs are not supported and do not have a digital signature. To protect the security and integrity of ESXi hosts, do not allow unsigned (CommunitySupported) VIBs to be installed on hosts. Satisfies: SRG-OS-000366-VMM-001430, SRG-OS-000370-VMM-001460, SRG-OS-000404-VMM-001650
STIGDate
VMware vSphere 7.0 ESXi Security Technical Implementation Guide2025-02-11

Related Frameworks

3 mappings across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (11) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-01Configuration Management Program
1.00
CFG-02Secure Baseline Configurations
1.00
CFG-03Least Functionality
1.00
CFG-03.2Prevent Unauthorized Software Execution
1.00
CFG-03.3Explicitly Allow / Deny Applications
1.00
CFG-05User-Installed Software
1.00
END-03Prohibit Installation Without Privileged Status
1.00
BCD-11.4Cryptographic Protection
0.50
CRY-04Transmission Integrity
0.50
CRY-05Encrypting Data At Rest
0.50

+1 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (30) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-17(2)Protection of Confidentiality and Integrity Using Encryption
1.00
AC-2(10)Shared and Group Account Credential Change
1.00
AC-3Access Enforcement
1.00
AC-3(4)Discretionary Access Control
1.00
AC-6(10)Prohibit Non-privileged Users from Executing Privileged Functions
1.00
AC-6(8)Privilege Levels for Code Execution
1.00
AU-4Audit Log Storage Capacity
1.00
CM-11(2)Software Installation with Privileged Status
1.00
CM-14Signed Components
1.00
CM-5(1)Automated Access Enforcement and Audit Records
1.00

+20 more (top 10 by confidence shown)

NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.4.8
1.00
CCI3 mappings
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (3) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

8 NICE work roles and 8 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-256410r984242_chk)

From the vSphere Client, go to Hosts and Clusters. Select the ESXi Host >> Configure >> System >> Security Profile. Under "Host Image Profile Acceptance Level", view the acceptance level. or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $esxcli.software.acceptance.get.Invoke() If the acceptance level is "CommunitySupported", this is a finding.

Fix Text (F-60028r892863_fix)

From the vSphere Client, select the ESXi Host and go to Configure >> System >> Security Profile. Under "Host Image Profile Acceptance Level", click "Edit...". Using the drop-down selection, set the acceptance level as "VMwareCertified", "VMwareAccepted", or "PartnerSupported". The default is "PartnerSupported". or From a PowerCLI command prompt while connected to the ESXi host, run the following commands: $esxcli = Get-EsxCli -v2 $arguments = $esxcli.software.acceptance.set.CreateArgs() $arguments.level = "PartnerSupported" $esxcli.software.acceptance.set.Invoke($arguments) Note: "VMwareCertified" or "VMwareAccepted" may be substituted for "PartnerSupported", depending on local requirements. These are case sensitive.