Vol VII Book 07 — Federal Compliance — VMware Federal Control Compliance Automation

vSphere Configuration Profiles, VCF Operations, NSX Distributed Firewall, and vSphere Lifecycle Manager control state, operated as ServiceNow work

Author

Federal Cloud Services

Published

2026-07-29 22:05 ET

0.1 Draft Proposal — Subject to Review

Developed by the CSI Team (Cloud Services Infrastructure); not yet reviewed or approved by the Agency CIO Office, OIS, or leadership. Date Code: 2026-07-29 18:05 ET

Series Context — Volume VII Book 07. The VMware lane of the coordination layer, anticipated by Vol VII Book 03 §“The Azure Control Engines and Their Coordination Role” and Vol VII Book 06 as a later follow-up reconciling into the same ServiceNow queues. Unlike M365, Azure, and AWS, VMware is not a CSP boundary the agency reaches over a provider API from outside — it is the agency’s own on-premises (or agency-operated private-cloud) virtualization estate: ESXi hosts, vCenter, and NSX, running under the agency’s physical control inside the GCC Moderate boundary. This book operates that surface’s control state as ServiceNow work, on the identical loop as the M365, Azure, and AWS books. Actuation stays platform-native — vSphere Configuration Profiles remediation, VCF Operations findings, NSX Distributed Firewall policy fixes, and vSphere Lifecycle Manager (vLCM) remediations make the change; ServiceNow governs ownership, SLA, approval, and evidence.

1 What This Document Addresses

Where M365, Azure, and AWS are boundaries the agency reaches through a cloud provider, VMware is the agency’s own virtualization layer — the hypervisor, network-virtualization, and cluster-management estate the agency owns, racks, and patches directly. It carries the identical class of obligations the CSP books carry, at the virtualization plane instead of the provider plane: baseline configuration and settings (CM-2, CM-6), flaw remediation (SI-2), and vulnerability monitoring (RA-5). VMware’s native stack actuates all three; the coordination role is to make each one owned, clocked, approved where it changes state, and evidenced. CM-2’s registered closure sits in Vol III Book 03 (Patch & Systems Management); this book touches CM-2 only through vSphere Configuration Profiles’ actuation of that baseline, so its Authorities Closed Here table registers the coordination closures CM-6, SI-2, and RA-5 — the identical registration pattern Vol VII Books 03 and 06 use for Azure and AWS.

This book runs the same five-step loop as Vol VII Books 02, 03, and 06 — test → detect drift → raise a typed task against the reconciled CI → actuate on the native surface → close with evidence — over the three VMware control engines. The loop is deliberately identical across surfaces: one coordination pattern, four platforms, so the evidence and the assessor-facing story are uniform regardless of whether the workload sits in a hyperscaler or on the agency’s own racks.

2 The VMware Control Engines and Their Coordination Role

VMware engine Owns (actuation) Control ServiceNow coordination role
vSphere Configuration Profiles Host/cluster desired-state configuration compliance and drift remediation CM-2, CM-6 Non-compliant host/cluster → Change/remediation task against the CI; track native remediation to closure
VCF Operations + NSX Distributed Firewall Continuous compliance/benchmark posture across the VCF fleet; segmentation-policy (DFW) drift and rule hygiene CM-6, RA-5 Violation/finding → prioritized Vulnerability-Response task; SLA by exposure
vSphere Lifecycle Manager (vLCM) ESXi image/patch compliance assessment and remediation SI-2, SI-2(2/3) Non-compliant image state → Change/Incident; SLA-class task keyed to KEV/exposure

This volume governs the virtualization layer, by doctrine — not the guest OS, firmware, or physical hardware. vSphere Configuration Profiles, VCF Operations, NSX Distributed Firewall, and vLCM operate ESXi, vCenter, and NSX — the hypervisor and network-virtualization control plane. They do not patch the operating system running inside a VMware-hosted VM (that guest OS reconciles through its own native stack, Vol III Book 03, on the identical SI-2 discipline this book uses for the hypervisor), and they do not manage server firmware or physical hardware lifecycle (a separate, vendor-specific management-plane surface, Management-Plane Coordination Doctrine, Vol 0 Book 00). This volume coordinates the ESXi/vCenter/NSX virtualization surface only. OCI reconciles into the same ServiceNow SI-2 queue in a later follow-up (its native stack is catalogued in Vol III Book 03); ServiceNow already coordinates a single queue, so adding that surface later needs no rework here.

3 Control Engine 1 — vSphere Configuration Profiles (CM-2 / CM-6)

vSphere Configuration Profiles is the current desired-state configuration mechanism for ESXi hosts and clusters, superseding the older Host Profiles model. It checks hosts against a declared cluster-level desired configuration, reports drift, and can remediate a subset natively. The coordination role covers the rest — and the change control around all of it.

  • Test: cluster/host compliance state is read against the desired configuration (compliant / non-compliant, with the specific setting that drifted).
  • Detect + Raise: a non-compliant host or cluster becomes a ServiceNow Change (for a controlled configuration change) tagged with the drifted setting, the mapped control (CM-2/CM-6), severity, and the reconciled host/cluster CI. An exemption is not silent — it is a request with an approver and an expiry, so a configuration exception is reviewable (the same discipline as an M365 CA exception, an Azure Policy exemption, and an AWS Config exemption).
  • Actuate: vSphere Configuration Profiles remediation runs against the cluster (a pre-check confirms hosts can enter maintenance mode and DRS can evacuate VMs where needed), or the owning team applies the configuration through infrastructure-as-code (Vol VI Book 01/06). ServiceNow does not write the host configuration.
  • Close: the next compliance check flips the host/cluster to compliant; ServiceNow closes and stamps the evidence.

4 Control Engine 2 — VCF Operations + NSX Distributed Firewall (CM-6 / RA-5)

VCF Operations is the VMware Cloud Foundation posture engine within the GCC Moderate boundary; Vol III Book 04 owns the posture architecture and Vol III Book 02 owns the assessment doctrine. It continuously monitors the VCF fleet against industry benchmarks and custom policies, surfaces violations and risk areas, and — through the VMware Advanced Cyber Compliance service — layers continuous compliance enforcement on top of that visibility. NSX Distributed Firewall (DFW) is the micro-segmentation policy engine for east-west traffic between workloads; its rule state and rule hygiene (including stale/inactive rules) are visible through the same VCF Operations for Networks telemetry this engine consumes. (VCF Operations’ broader AIOps/capacity-management capabilities are a later follow-up, out of scope here.) The coordination role turns both engines’ findings into prioritized, owned remediation work.

  • Test + Detect: VCF Operations compliance-benchmark violations (misconfiguration against a declared standard) and NSX DFW policy/rule-hygiene findings (segmentation drift, stale rules) are read via the respective management APIs.
  • Raise: each finding becomes a ServiceNow Vulnerability Response task against the reconciled CI, with a severity and an SLA class derived from exposure and KEV status — the risk-based prioritization the PAIN-rating model (BOD 26-04; FedRAMP VDR-TFR-PVR) call for, detailed under Control Engine 3 below.
  • Actuate: the owning team remediates on the native surface — a configuration fix, an NSX DFW rule correction, or a patch (vSphere Lifecycle Manager, below).
  • Close: the finding clears on the next VCF Operations assessment; ServiceNow closes the task, and the mean-time-to-remediate becomes an SI-2(3) / KSI metric.

5 Control Engine 3 — vSphere Lifecycle Manager / vLCM (SI-2)

vSphere Lifecycle Manager assesses and remediates ESXi host image and patch compliance across the cluster. It is the SI-2 actuation engine for the hypervisor; the coordination role reconciles its results into change/incident work with the SLA discipline SI-2(3) requires.

  • Test: vLCM reports each host’s image/patch compliance against the cluster’s desired image (compliant / non-compliant, with the specific component that drifted).
  • Raise: a non-compliant host becomes a ServiceNow Change (scheduled maintenance window) or Incident (an out-of-cycle KEV exposure), with an SLA class keyed to KEV/exposure — the PAIN-rating model (BOD 26-04; FedRAMP VDR-TFR-PVR), detailed below. The same SLA discipline is what the OCI patch queue will reconcile into when it is added later (Vol III Book 03).
  • Actuate: vLCM remediates the host in the approved maintenance window — evacuating VMs via DRS, entering maintenance mode, applying the desired image, and exiting maintenance mode; ServiceNow does not push the image, it schedules and governs it.
  • Close + evidence: the post-remediation compliance check confirms the host matches the desired image; the Change record, approval, window, and re-check become the SI-2(2) machine-readable remediation-status evidence.

“SLA by exposure” has a name and a published table — the Potential Agency Impact (PAIN) rating. FedRAMP’s Vulnerability Detection and Response ruleset (VDR-TFR-PVR) sets mitigation/remediation timeframes by PAIN rating crossed with exploitability and internet-reachability:

PAIN rating Likely-exploitable, internet-reachable Likely-exploitable, not internet-reachable Not likely exploitable
PAIN-5 4 days 8 days 32 days
PAIN-4 8 days 32 days 64 days
PAIN-3 32 days 64 days 192 days
PAIN-2 96 days 160 days 192 days

A CISA-catalogued KEV must be remediated by the KEV catalog’s own due date regardless of PAIN rating (VDR-TFR-KEV), even after full mitigation. These are the actual numbers a ServiceNow SLA-class task should encode — “SLA by exposure” is this table, not a general-purpose severity field.

Baseline-based patching is being retired — this book targets vLCM Images. VMware deprecated baseline-based patching starting with vSphere 8.0, with full removal in a later major release; the desired-state Images model is the forward path and the one this coordination pattern targets. An estate still running baseline-managed clusters reconciles through the same ServiceNow SI-2 queue, but the reconcile-exception queue should track the Images migration itself as a tracked closure item, not treat baseline mode as a permanent parallel path.

6 Manual, Out-of-Band Actuation — Where No Orchestrator Reaches (CM-3, CM-5, CM-7, CM-11/CM-14, AU-2/AU-3/AU-12)

The three control engines above cover the cases where a native orchestrator — Configuration Profiles, vLCM, or infrastructure-as-code (Vol VI Book 01/06) — can actuate the approved change itself. Not every vCenter-side fix has that path today. When a ServiceNow task’s remediation is a script instead, the failure mode this section exists to rule out is: the task’s approver emails the script (or a link to it) to an operator, who opens an interactive vCenter session and runs it by hand. A CM-3 approval sitting upstream of that email does not make the run compliant — the approval authorizes a change, it is not evidence the change happened the way it was authorized to happen, and a person copy/pasting a command into a live session is direct modification with no pipeline validation regardless of what preceded it. This is the identical anti-pattern the Operator Runbook’s Task 5 (“Scripted Command Execution”) already rules out for the M365 surface — “parameters travel; commands do not” — restated here for the surface where no MID-Server-actuated Script Include yet reaches.

6.1 Who Actuates: The Approval/Execution Split

This is a derived design principle, not a citable rule. No NIST SP 800-53 control prohibits a human from executing an approved change, and FedRAMP’s own KSI-CMT-RMV — “Changes to machine-based information resources are executed through the redeployment of version controlled resources rather than direct modification wherever reasonable” (verbatim, verified against the source in References) — qualifies itself with “wherever reasonable”; that is a preference with a documented-exception path, not a prohibition. A prior draft of this section stated “human as approver, never executor” as though it were sourced; it is instead the least-cost way to satisfy a conjunction of separately mandated properties at once, and the derivation is shown here rather than asserted. A fourth Change Management indicator, KSI-CMT-RVP (“Reviewing Change Procedures” — “the effectiveness of documented change management procedures is persistently reviewed”), is the closest fit for the vCenter compensating control below: it is what a documented-process closure is actually evidencing, distinct from RMV/VTD’s automation preference.

Property required Source What breaks under manual execution
Approval precedes the change CM-3 Nothing, if the task carries it
The change artifact is access-restricted and controlled CM-5, CM-7, CM-11/CM-14 A script held on an operator’s workstation, or pasted into a message, is uncontrolled
Privileged execution is logged and attributable AU-2, AU-12, AC-6(9) A console session log, if one exists, is not bound to the ServiceNow task
Changes deploy from version control, not in-place edits KSI-CMT-RMV (text verified — see References) Direct modification, by definition — the pattern the indicator prefers against, “wherever reasonable”
Validation is automated through deployment KSI-CMT-VTD (text verified — see References); CM-3(2) (Testing, Validation, and Documentation of Changes) — Moderate-baseline-selected No pipeline, no pre-deploy test
Evidence is reproducible, not merely captured FedRAMP 20x assessment guidance (cited as characterized in external review; not independently re-verified — see caution below) “I ran it and it worked” is an assertion, not something an assessor can re-derive

The table’s control citations are two different kinds of source, and they should not be read as one list. KSI-CMT-RMV and KSI-CMT-VTD are FedRAMP’s own indicator text, verified verbatim against the official source in References. FedRAMP’s own control crosswalk for those two indicators is narrower than the “controlled artifact” and “logged and attributable” rows above — RMV’s crosswalk is CM-2/CM-3/CM-5/CM-6/CM-7/CM-8(1)/SI-3, and LMC’s (logging) crosswalk is AU-2/CM-3/CM-3(2)/CM-4(2)/CM-6/CM-8(3)/MA-2; neither lists CM-11, CM-14, AU-12, or AC-6(9). Those four are this book’s own broader NIST-derived reasoning, not FedRAMP’s stated mapping — legitimate support for the same argument, but cited on this book’s own authority, not FedRAMP’s. Two of them do have their own direct FedRAMP text worth citing separately: the official rules give CM-11 the parameter “Continuously (via CM-7(5))” and give CM-14 guidance permitting alternative cryptographic integrity checks (hashes, self-signed certificates) where formal digital signatures aren’t available — both cited in References, and both a closer fit for “the script is signed and version-controlled” than the KSI text itself provides.

An orchestrated execution produces all six as byproducts of running. A human at a console produces none of them unless each is separately, manually manufactured. That conjunction — not a named control or KSI banning manual execution — is the argument for routing execution through an orchestrator wherever one reaches the surface.

Note the control this is deliberately not citing. AC-5 (Separation of Duties) separates conflicting duties — requester vs. approver, developer vs. operator. The same person being both approver and executor of one already-approved change is not the AC-5 fact pattern, and citing it here would overreach in a way a reviewer who knows the control would use to discredit the rest of this section.

What the Moderate baseline actually adds. FedRAMP’s published Rev 5 Moderate baseline profile selects CM-5(1) (Automated Access Enforcement and Audit Records) and CM-6(1) (Automated Management, Application, and Verification) as enhancements — not merely CM-5/CM-6 at the base level — and separately selects SI-2(2) (Automated Flaw Remediation Status). Those three enhancements are baseline-mandatory, not optional, and each names automation directly, which is a stronger citation than the derivation above and should be read as reinforcing it, not as a substitute argument. CM-3(1) (Automated Documentation, Notification, and Prohibition of Changes) is not selected in the Moderate baseline — only CM-3, CM-3(2), and CM-3(4) are — so this section does not claim CM-3 itself requires automated actuation; CM-3’s role here stays what §Closure Necessity already states, an approval gate before the change, satisfiable manually. CM-3(2) (Testing, Validation, and Documentation of Changes) is Moderate-baseline-selected and is the direct NIST anchor for the “validation is automated through deployment” row above — added to the table for that reason.

A second-source citation review was checked against this section’s claims and against the same primary sources (the NIST Rev 5 catalog and the FedRAMP Moderate baseline profile already cited above); most of its proposed additions did not hold up. Confirmed and incorporated: CM-3(2), as above. Checked and rejected, with the reason:

  • CM-3(5) — proposed as supporting “automate change control enforcement”; actually titled Automated Security Response, and not selected in the Moderate baseline at all — an out-of-baseline citation for a paper scoped to Moderate.
  • AU-12(3) — proposed as “automated audit trail generation”; actually titled Changes by Authorized Individuals, and likewise not Moderate-baseline-selected.
  • “RA-5(f)” and “SI-2(c)” — not valid enhancement citations. NIST enhancements are numbered (N); letters like (f)/(c) denote sub-parts of the base control’s own statement text, not a citable sub-control — asking an assessor to “show RA-5(f)” finds nothing under that name.
  • AC-6(9) (Log Use of Privileged Functions, correctly used elsewhere in this section for privileged-session logging) was separately proposed there as meaning “privileged access automation — minimizing human privileged actions”; that is a different control’s territory (AC-6 base / AC-6(1)/(2)), not what AC-6(9) itself requires.
  • IA-5(2) was proposed for the certificates argument (§8 of this series) as requiring “automated issuance, automated renewal”; its actual statement (verified against the resolved Moderate baseline catalog) governs PKI-based authentication — private-key access enforcement, certificate-path validation, revocation checking — not issuance/renewal automation. Not cited here or in §8 for that reason.

None of the rejected items were ever incorporated into this book or the whitepaper; this note exists so a reader handed the same second-source review does not reintroduce them without re-checking.

A detection engine emailing a human directly is worse than a human emailing a human. If SailPoint, VCF Operations, or any other detector routes a finding to an operator’s inbox with a script attached rather than opening a ServiceNow task, the record never touches ServiceNow at all — contradicting the one-front-door discipline the cross-cloud whitepaper §11 states for every other control family in this series (the paper’s §4, “Who Actuates: Ticket-to-Machine, Not Ticket-to-Human,” states this book’s underlying recommendation directly, in the main body rather than as a limits footnote). Every finding, however it is detected, opens through the ServiceNow task; a notification email, if one exists, announces that the task exists — it is not the task, not the approval, and not the evidence, and it never carries the executable. Where the email becomes the workflow — where the record of what happened is a human’s reply that it is done — the coordination layer has been bypassed and the finding has reverted to the console-only condition the cross-cloud whitepaper §10 describes.

6.2 The Compliant Pattern

  1. The script is a catalogued artifact, not an email attachment. It is version-controlled, peer-reviewed, and signed before it is eligible to run against any managed resource (CM-5, CM-7, CM-11/CM-14) — the same discipline Task 5’s Script Include already requires; an ad hoc script pasted into a message is the failure mode, not an acceptable substitute.
  2. Where an orchestrator reaches the surface, it — not the human — executes. An Azure Automation runbook, an AWS SSM Document, Ansible Automation Platform, or the ServiceNow MID Server itself runs the signed script under a scoped service identity once the ServiceNow task’s approval gate opens; the human’s click is the CM-3 authorization, the orchestrator’s run is the actuation. That conversion — direct modification becomes redeployment of a version-controlled, orchestrator-executed artifact — is what makes the change pipeline-validated and machine-logged rather than a session a person happened to run (AU-2/AU-3/AU-12: operator identity, task correlation, and execution outcome are logged by the orchestrator, not self-reported in a closure comment).
  3. Where no orchestrator reaches the surface — vCenter is the named case today. The Aria Operations Management Pack and the VCF Automation ITSM plugin (cited in the cross-cloud whitepaper §11) integrate ServiceNow’s CMDB and Day-2 catalog with vCenter/VCF — but a general-purpose signed-script executor running under a service identity against vCenter, comparable to a MID Server Script Include or an SSM Document, was not found in this book’s research. Until one is confirmed, the compensating control is CyberArk Privileged Session Manager (PSM): the same platform Vol III Book 01 already vaults and session-isolates the standing privileged accounts JIT elevation cannot remove. The ServiceNow task’s approval gates the session; PSM proxies, time-boxes, and records it; the session recording — not a “run successfully” reply — is the closing evidence artifact.
  4. This is booked as a documented-process closure, deliberately, not implied as automated. A PSM-recorded manual session satisfies CM-3 (an approved, logged execution) but not KSI-CMT-RMV’s redeploy-over-direct-modification preference or KSI-CMT-VTD’s automated persistent validation — there is no pipeline testing the change before or during the run. What it can evidence instead is KSI-CMT-RVP (“Reviewing Change Procedures”): the recorded session, reviewed on a cadence against the catalogued script and the task it closed, is exactly the kind of persistent review of change-procedure effectiveness RVP asks for — a different, and honest, indicator to cite than RMV/VTD. The Authorities table entry and any KSI evidence citation for this path should read as documented-process against RVP, tied to the session recording as the artifact, not as tool-attestable against RMV/VTD; claiming otherwise is the same “closed collapses back to human assertion” failure the Closure Necessity callouts throughout this series exist to prevent. The exception path is real and used deliberately here, not discovered by an assessor after the fact.

KSI-shaped, not KSI-met. Agency operating this loop is not a Cloud Service Offering seeking its own FedRAMP authorization, and this book does not claim otherwise. The defensible framing is that this pattern’s evidence is voluntarily modeled on FedRAMP 20x’s Change Management indicators — because a coherent internal control is worth having regardless of who assesses it — not that Agency’s ConMon practice “meets” a KSI, which is a CSP obligation this book’s audience does not hold.

This book’s KSI-CMT-RMV, KSI-CMT-VTD, and KSI-CMT-LMC text and control crosswalks are now checked against an external source, not just cited from a reviewer’s memory of one. The source is FedRAMP’s own Consolidated Rules for 2026 — a public-domain US Government work published by the GSA/FedRAMP PMO in the public FedRAMP/rules GitHub repository (see References) — not anything this project authored. What was actually checked is a SHA-256-verified, dated mirror of that external file (version 2026.06.24.01, retrieved 2026-07-01) that this series’ compliance-spine tooling already maintains; it was not a live fetch performed in this session, since outbound web access remained unavailable — see the caution below for what that leaves open. That mirror’s KSI-CMT theme carries four indicators, not three: RMV, VTD, LMC, and RVP (added above and in item 4). Baseline allocation for CM-5(1)/CM-6(1)/SI-2(2)/CM-3(1) was likewise checked directly against the published Rev 5 Moderate baseline profile, not asserted.

What “verified” does and does not mean here. The KSI-CMT text above was checked against FedRAMP’s own external, public-domain publication — not against this project’s own assertion — but the copy checked is a dated mirror (retrieved 2026-07-01), not a live read of github.com/FedRAMP/rules or fedramp.gov performed today. FedRAMP could have revised the text in the roughly four weeks since that mirror was taken; nothing in this book’s research surfaced such a revision, but nothing ruled one out either, because live access was not available. Two further items remain genuinely unverified regardless: the “evidence must be reproducible, not merely captured” characterization of FedRAMP 20x assessment guidance is still cited only as named in external review — it does not appear verbatim in the mirrored file and was not otherwise confirmed. And the external review’s claim that FedRAMP “renumbered” KSI families “in February 2026” does not match the mirrored file’s own updated metadata, which dates the current KSI-CMT text to 2026-06-24 (“Official launch of the FedRAMP Consolidated Rules for 2026”), not February — either the reviewer’s date was imprecise, or an earlier February 2026 change was itself superseded by the June consolidation; this book does not know which. Before any of this section’s KSI citations inform an authorization package or an assessor conversation, re-check them live against github.com/FedRAMP/rules or fedramp.gov and the mirror’s retrieval date, per the Vendor Currency Doctrine.

7 Continuous Monitoring Roll-Up (CA-7)

Each engine’s loop emits its result into the continuous-monitoring feed: Configuration Profiles compliance percentage, open VCF Operations/NSX DFW findings by severity and age, vLCM image-compliance conformance. ServiceNow rolls these into a per-control VMware posture that Vol VII Book 04 turns into attestation and KSI evidence, keyed to the same reconciled asset identity the M365, Azure, and AWS postures use — so all four platforms produce one compliance picture, not four.

8 Closure Necessity

8.1 Closure Necessity — VMware actuates; the estate still needs an owner and a clock

vSphere Configuration Profiles remediates, VCF Operations and NSX DFW surface, vLCM patches — the native stack is genuinely sufficient to change state, on the agency’s own hardware exactly as it is on a hyperscaler’s. What it does not supply is the governance wrapper: who owns this finding, by when, under whose approval, with what evidence. Strip the coordination layer and vCenter’s own console shows green while the authorization package has no owned-and-evidenced record an assessor can trace. CM-6, SI-2, and RA-5 are closed by VMware; they are operated — owned, clocked, evidenced — here.

9 NIST SP 800-53 Rev 5 Control Closure — Authorities Closed Here

Generated from the series compliance spine (federal-compliance-compliance-spine.yml) by render_authorities_table.py; not hand-edited here. Coordination closures — the VMware control state operated as tracked work — not a re-closure of the posture/patch mechanisms Volumes III and VI own.

Authorities Closed Here — VMware Federal Control Compliance Automation († = Closure-Necessity anchor: no alternate closure path)
Control Title Closing mechanism (function, not product) Accreditation gate Authority drivers Evidence slot FedRAMP 20x KSI Tool-attestable?
CM-6 Configuration Settings vSphere Configuration Profiles / VCF Operations findings raised as ServiceNow remediation tasks; Configuration-Profiles-native remediation actuates, ServiceNow tracks to closure FedRAMP Moderate NIST SP 800-53 Rev 5; CISA SCuBA Security / supply chain KSI-CMT No
RA-5 Vulnerability Monitoring and Scanning VCF Operations / NSX Distributed Firewall findings on the VMware estate flow to ServiceNow Vulnerability Response as prioritized remediation tasks FedRAMP Moderate NIST SP 800-53 Rev 5; CISA BOD 26-04 Security / supply chain KSI-MLA No
SI-2 Flaw Remediation vSphere Lifecycle Manager (vLCM) image/patch results reconciled into ServiceNow Change/Incident with SLA-class tasks keyed to KEV/exposure (actuation platform-native) FedRAMP Moderate NIST SP 800-53 Rev 5; CISA BOD 26-04 Endpoint KSI-SVC, KSI-MLA No

10 Honest Limits

  • A task closes when the native re-evaluation passes; Configuration Profiles/VCF Operations assessment latency means “closed” can lag actual state by an evaluation cycle. Evidence timestamps record the cycle, not the instant.
  • This book governs ESXi/vCenter/NSX only; guest-OS patching inside a VMware-hosted VM, physical-server firmware, and hardware lifecycle reconcile in from their own native stacks (Vol III Book 03). Treating this book as the whole management plane is a doctrine violation the reconcile-exception queue is meant to catch — the identical failure mode the Arc note in Vol VII Book 03 and the hybrid-activation note in Vol VII Book 06 guard against.
  • Native vSphere Configuration Profiles remediation still carries a Change record — automated actuation does not waive change control (CM-3); it makes the change record’s actuator the Configuration Profiles engine rather than a person.
  • NSX Distributed Firewall’s microsegmentation capability requires NSX Advanced edition or higher; an estate licensed below that tier does not have DFW policy state to reconcile, and that licensing gap belongs in the reconcile-exception queue rather than being silently absent from the posture roll-up.
  • Baseline-managed clusters (the pre-vLCM-Images patching model) are on a deprecation path; see the caution under Control Engine 3.
  • No confirmed orchestrator runs a signed script against vCenter under a service identity today. The manual-actuation compensating control (CyberArk PSM session recording, see above) is a documented-process closure, not a tool-attestable one — it should not be cited as though a pipeline validates these changes the way Configuration Profiles or vLCM does.
  • The KSI-CMT-RMV/VTD/LMC/RVP text and control crosswalks are verified against this repo’s official FedRAMP CR26 snapshot (2026.06.24.01) — see References. The “evidence must be reproducible” characterization of FedRAMP 20x assessment guidance, and the external review’s claim that KSI IDs were renumbered “in February 2026” (the CR26 snapshot’s own metadata dates the current text to 2026-06-24, not February), remain unverified against fedramp.gov — see the caution under Manual, Out-of-Band Actuation.
  • “Human as approver, not executor” is a derived design principle argued from a conjunction of CM-3/CM-5/CM-7/CM-11/CM-14/AU-2/AU-12/AC-6(9) plus KSI-CMT-RMV/VTD, not a single citable rule. An earlier version of this section stated it as though it were sourced; see the Approval/Execution Split subsection for the corrected derivation. Note that FedRAMP’s own KSI-CMT-RMV/LMC control crosswalks are narrower than this book’s broader NIST-derived property table (they omit CM-11, CM-14, AU-12, AC-6(9)) — do not cite the principle itself to an assessor as a named control or KSI requirement, and do not conflate this book’s own reasoning with FedRAMP’s stated mapping.
  • A second-source citation review proposed CM-3(5), AU-12(3), “RA-5(f)”, “SI-2(c)”, and mischaracterized glosses of AC-6(9) and IA-5(2) for this section; all were checked against this repo’s NIST catalog and the Moderate baseline profile and rejected — see the note under Approval/Execution Split for the specific reason each failed. CM-3(2), the one proposal that held up, is now cited in the property table and References.

11 Cross-References

  • Vol III Book 01 (Privileged Access Management) — the CyberArk vaulting and session-isolation platform this book’s manual-actuation compensating control (PSM session recording) relies on.
  • Vol III Book 02 (Vulnerability Management) — the assessment half whose findings this book routes to remediation tasks.
  • Vol III Book 03 (Patch & Systems Management) — the SI-2 queue this book’s vLCM results reconcile into (VMware/hybrid now; OCI in a later follow-up).
  • Vol III Book 04 (Cloud-Native Posture) — the VCF Operations posture architecture this book coordinates findings from.
  • Vol III Book 07 (Multi-Cloud Evidence Fabric) — where VMware VCF Operations/NSX feeds join the cross-environment evidence fabric; this book is the VMware-native coordination source for that fabric, not a re-statement of it.
  • Vol VI Book 01/06 (Landing Zone / Baselines as Code) — the IaC that actuates many VMware remediations.
  • Vol VII Book 01 — the reconciled CIs every VMware task is raised against; Vol VII Book 04 — where the VMware posture roll-up becomes attestation.
  • Vol VII Book 03 (Azure) / Vol VII Book 06 (AWS) — the sibling coordination books this one mirrors structurally; all three now reconcile into the same ServiceNow queues.
  • Compliance Operator Runbook (Day-2, Compliant), Task 5 — the “parameters travel; commands do not” discipline this book’s manual-actuation section restates for the vCenter surface.
  • ticket-to-machine-not-ticket-to-human whitepaper §4 — the customer-facing statement of this section’s core recommendation, promoted into the paper’s main body; §11 — the one-front-door doctrine the manual-actuation anti-pattern caution enforces.

12 Provenance

Draft. vSphere Configuration Profiles, VCF Operations, VMware Advanced Cyber Compliance, NSX Distributed Firewall, and vSphere Lifecycle Manager are deployed examples; the detect→raise→actuate-native→close→evidence loop is the invariant, identical to the M365, Azure, and AWS books. Vendor claims cite vendor documentation (see References) and are dated, not permanent — see the Vendor Currency Doctrine; this book’s own initial “no ServiceNow↔︎VMware integration exists” assumption was itself corrected within weeks once native Aria/VCF Automation connectors were confirmed, which is the doctrine’s own cautionary example. The compliance-loop figure is authored as committed house-style SVG.

The Manual, Out-of-Band Actuation section was added 2026-07-29 in response to external architecture review of a proposed pattern (SailPoint or another detector emailing a human, who runs a script directly against vCenter) that this book explicitly rules out — the review correctly identified it as direct modification with no pipeline validation, contradicting both this series’ own actuation doctrine and FedRAMP 20x’s Change Management KSI text as cited by the reviewer. The section’s KSI-CMT-RMV/VTD/LMC citations and the “no confirmed vCenter script orchestrator” claim both carry their own unverified-pending-confirmation caveats, per the doctrine above.

A same-day second review pass corrected the section’s initial framing: “human as approver, not executor” had been stated as a citable rule, and no such rule exists — no 800-53 control prohibits manual execution of an approved change, and KSI-CMT-RMV’s own text qualifies its redeploy-over-direct-modification preference with “wherever reasonable.” The Approval/Execution Split subsection replaces the unsourced assertion with the actual derivation (a conjunction of separately mandated properties an orchestrator satisfies as a byproduct of running and a human does not), explicitly declines to cite AC-5 (a different fact pattern — conflicting duties, not approver/executor of one approved change), and checked CM-3(1)/CM-5(1)/CM-6(1)/SI-2(2) directly against FedRAMP’s published Rev 5 Moderate baseline profile rather than asserting their allocation: CM-5(1), CM-6(1), and SI-2(2) are baseline-selected automation enhancements (a stronger, now-verified citation); CM-3(1) is not baseline-selected, so this book does not lean on it.

A same-day third pass checked the KSI-CMT text itself, which the second pass had still left flagged as unconfirmed pending fedramp.gov access. The source consulted is external, not internal: FedRAMP’s own Consolidated Rules for 2026, published by the GSA/FedRAMP PMO as a public-domain US Government work in the public FedRAMP/rules GitHub repository (see References) — the same authority the earlier draft’s caution was asking to be confirmed against. What this series’ compliance-spine tooling holds is a dated, SHA-256-verified mirror of that external file (version 2026.06.24.01, retrieved 2026-07-01), and it confirms KSI-CMT-RMV/VTD/LMC’s text essentially verbatim against what had been cited from external review, plus a fourth indicator (KSI-CMT-RVP, Reviewing Change Procedures) this book had been missing — now cited in item 4 as the honest indicator for the vCenter documented-process path, rather than continuing to measure it against RMV/VTD. The pass also surfaced that FedRAMP’s own control crosswalks for RMV/LMC are narrower than this book’s derivation table, and that the mirrored file’s own metadata dates the current KSI-CMT text to 2026-06-24 — not “February 2026” as the external review characterized the renumbering — a discrepancy this book flags rather than silently absorbing. This is a check against a dated snapshot, not a live fetch of github.com/FedRAMP/rules or fedramp.gov performed in this session — outbound web access remained unavailable throughout; see the caution below for what that distinction still leaves open.

A fourth pass checked a separately-authored citation review’s proposed additions (CM-3(5), AU-12(3), “RA-5(f)”, “SI-2(c)”, and glosses of AC-6(9) and IA-5(2)) against the same two primary sources already in this book’s tooling — the NIST catalog and the Moderate baseline profile — rather than accepting them on that review’s own stated confidence. One addition held up (CM-3(2), now cited in the property table); the rest did not, for reasons documented in the note under Approval/Execution Split. None of the rejected citations were live in this book or the whitepaper before this pass; the point of checking was to keep it that way.

13 References

Claim Source
vSphere Configuration Profiles (desired-state config, drift, remediation) Broadcom TechDocs — https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/managing-host-and-cluster-lifecycle/using-vsphere-config-profiles-to-manage-host-configuration-at-a-cluster-level.html
VCF Operations (compliance management, benchmark violations) Broadcom TechDocs — https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/overview-of-vmware-cloud-foundation-9/what-is-vmware-cloud-foundation-and-vmware-vsphere-foundation/vcf-operations-overview.html
VMware Advanced Cyber Compliance (continuous compliance enforcement, VCF advanced service) VMware Cloud Foundation Blog — https://blogs.vmware.com/cloud-foundation/2025/11/03/vmware-advanced-cyber-compliance-is-now-available-to-vcf-customers/
NSX Distributed Firewall (microsegmentation, licensing tier) VMware NSX Datasheet — https://www.vmware.com/docs/vmware-nsx-datasheet
vSphere Lifecycle Manager (vLCM) baselines, images, and the baseline deprecation path Broadcom TechDocs — https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/managing-host-and-cluster-lifecycle/about-vsphere-lifecycle-manager-new/vlcm-baselines-and-images.html
Risk-based remediation prioritization (KEV catalog) CISA — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
PAIN-rating remediation timeframes (VDR-TFR-PVR) FedRAMP — https://www.fedramp.gov/2026/reference/vulnerability-detection-and-response/
ServiceNow as workflow/CMDB/evidence coordination hub Expansion Plan §16 — docs/customer-documents/federal-compliance-series/Compliance_Series_Expansion_Plan_Substrate_Accreditation.md
KSI-CMT-RMV (redeploy over direct modification, qualified “wherever reasonable”), KSI-CMT-VTD (automated persistent validation), KSI-CMT-LMC (logging and monitoring of changes), KSI-CMT-RVP (persistent review of change-procedure effectiveness) — text and control crosswalks checked against this external source, version 2026.06.24.01 FedRAMP / GSA, official, public domain — FedRAMP/rules GitHub repository, fedramp-consolidated-rules.json — https://github.com/FedRAMP/rules. This series’ compliance-spine tooling holds a SHA-256-verified mirror of that file retrieved 2026-07-01; the check above was against that dated mirror, not a live fetch performed in this session — see the caution above
CM-11 “Continuously (via CM-7(5))” parameter; CM-14 guidance permitting alternative cryptographic integrity checks where digital signatures are unavailable — supports “the script is signed and version-controlled” more directly than the KSI text alone Same external source and mirror as the row above, the controls-guidance section of the same file
“Evidence must be reproducible, not merely captured” — characterization of FedRAMP 20x assessment guidance; does not appear verbatim in the mirrored file and remains not independently re-verified against FedRAMP’s current published release for this book Cited as named in external review — pending direct confirmation at fedramp.gov or github.com/FedRAMP/rules per the Vendor Currency Doctrine
External review’s claim that KSI IDs were “renumbered in February 2026” does not match the mirrored file’s own metadata, which dates the current KSI-CMT text to 2026-06-24 (“Official launch of the FedRAMP Consolidated Rules for 2026”) — flagged as an open discrepancy, not resolved here Same external source and mirror as above, info.last_updated and per-indicator updated fields, vs. external review characterization
CM-3(1) not selected / CM-3(2), CM-5(1), CM-6(1), SI-2(2) selected as Moderate-baseline enhancements; CM-3(5) and AU-12(3) checked and confirmed not selected — all checked directly against the published baseline, not asserted FedRAMP Rev 5 Moderate baseline profile (OSCAL), trestle_fedramp package resources, baselines/rev5/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml and the resolved-profile catalog for control titles
CM-3(5) titled “Automated Security Response” (not “automate change control enforcement”); AU-12(3) titled “Changes by Authorized Individuals” (not “automated audit trail generation”); IA-5(2) governs PKI-based authentication, not certificate issuance/renewal automation — second-source citations checked and rejected, see the note above docs/customer-documents/federal-compliance-series/reference/nist-800-53r5-controls.json (this repo) for titles; FedRAMP Rev 5 Moderate baseline resolved-profile catalog for IA-5(2)’s statement text
CyberArk Privileged Session Manager (PSM) — session proxying, time-boxing, and recording for privileged interactive sessions Vol III Book 01 (this series) — CyberArk vaulting/session-isolation for standing privileged accounts
“Parameters travel; commands do not” — the compliant scripted-command pattern this section restates for vCenter docs/customer-documents/federal-compliance-series/Compliance_Operator_Runbook_Day2_Compliant.qmd, Task 5
VMware Aria Operations Management Pack for ServiceNow / VCF Automation ITSM plugin (CMDB/Day-2 integration; not a signed-script executor) ticket-to-machine-not-ticket-to-human whitepaper §11 (this series)
Back to top