Administrators have been installing guest OS virtualization toolsets, the drivers and agents that integrate VMs with the hypervisor, by downloading them from a third-party mirror site. What should the security policy require instead?
Select an answer to reveal the explanation.
Short Explanation
Guest tools run with deep privileges inside your VM and talk straight to the hypervisor, so you only take them from the vendor, sealed and signed. A random mirror is like buying brake parts from a stranger's trunk. And don't freeze them in place; they need patches like everything else.
Full Explanation
Guest OS virtualization toolsets install paravirtualized drivers and agents that run with high privileges in the guest and communicate directly with the hypervisor for functions such as time synchronization and optimized I/O. Because of that privilege, a tampered package is an efficient way to compromise every VM it is installed on. Policy should require obtaining the toolset from the hypervisor vendor's official distribution channel or the platform's built-in installer, verifying its signature or published hash, and maintaining it through normal patch management so security fixes are applied. Antivirus scanning detects known malicious signatures but cannot confirm that a package is the authentic vendor build; a subtly modified driver or agent may contain no known signature. Abandoning toolsets is unrealistic: they provide drivers and management functions that many VMs need for performance and stable operation,. Freezing a version in the golden image and excluding it from patching leaves known vulnerabilities in a privileged component across the whole fleet. Exam caveat: this objective concerns installation of guest toolsets in Domain 5; supply-chain integrity in general is covered under application security in Domain 4. Operational check: confirm that the installed toolset version and signature match the vendor's current release and that toolsets are included in the patch compliance report.