Cyber Assets vs Cyber Systems Confusion in the Virtual Environment

I'm concerned to still see discussion in the Nerc-isphere about how to categorize a VM in the most simple of clear-cut examples: the virtual server/hypervisor combination. Some folks still disagree that it is necessary to treat each virtual machine and hypervisor as separate Cyber Assets. They think:

"The hypervisor (parent) is the device or software which runs the virtual machine (child). The virtual machine (VM) cannot operate without the hypervisor. This shared relationship means that neither can be separate Cyber Assets. For example, if a VM has been identified as a BES Cyber Asset (BCA); the hypervisor that runs the VM is also a BCA; which also applies to PACS, EACMS, and PCA’s

Treating the VM and hypervisor as separate Cyber Assets can cause mixed-trust virtual environments; the hypervisor runs CIP and corporate VM’s. CIP controls are only being applied to the CIP VM and not the hypervisor; even though the hypervisor “if rendered unavailable, degraded, or misused” can impact the CIP and corporate VM’s."

 Allow me to counter:

The hypervisor (parent) is the device or software which runs the virtual machine (child).

The Hypervisor or Host merely provides a container or environment for the virtual machine. In this aspect the control plane of the Hypervisor operates certain control plane functions on behalf of the guest. However, the Hypervisor is not involved in the control plane¹ decisions made by the guest.  The Hypervisor does not need to (and should not be configured to) interact in the data plane of the Guests. They make computing decisions entirely independent of each other, including their reactions to inputs and malware. If an RE decided to treat Host and Guest as one Cyber Asset for compliance reasons, there is no logically consistent framework to require the long-standing and well-known security best practice of separating the management and data plane of the Hypervisor and Guests. The guest should be completely unaware of and unable to interact with the Host in a secure virtual environment. The Host and Guest more often than not run different operating systems, and it would be difficult to categorize that as one Cyber Asset for any practical purpose. 

The virtual machine (VM) cannot operate without the hypervisor.

This is not strictly correct. More precisely, the VM cannot operate without a hypervisor. It is not dependent upon any specific hypervisor (rather, it can exist on any Hypervisor in the cluster and this is one of its biggest advantages). Therefore treating them as one Cyber Asset is inappropriate because this approach would not require distinct vulnerability assessments, patching, baseline configuration etc.

This shared relationship means that neither can be separate Cyber Assets.

The assumption in this statement doesn’t work in both directions. Presuming that a Guest could not be a separate (meaning independent) Cyber Asset, does not preclude a Hypervisor from being an independent Cyber Asset. After all the Hypervisor is a complete hardware, operating system, (and potentially software) stack in itself. Depending on whether it is a Type I or Type II, it might even be the same operating system as the Guests with Hypervisor function software merely installed on top of a generic operating system. It exists with a hostname, an address, a particular set of open ports/APIs, network connection, and responds to network traffic. The Hypervisor can exist and operate without a single Guest inside.

For example, if a VM has been identified as a BES Cyber Asset (BCA); the hypervisor that runs the VM is also a BCA; which also applies to PACS, EACMS, and PCA’s

This may be true; it doesn’t negate the necessity of treating the Host and Guest as distinct Cyber Assets (for multiple reasons). At most it makes the entire assemblage a BCS.

Treating the VM and hypervisor as separate Cyber Assets can cause mixed-trust virtual environments; the hypervisor runs CIP and corporate VM’s.

This is known as argumentum ad consequentiam (appeal to consequences) and is a known logical fallacy. Whether or not shared infrastructure is allowed and whatever the consequences of doing so, it does not change the distinct character of the Guest vs the Host. It also presumes that sharing infrastructure between CIP-applicable systems and “Corporate” VMs is impossible to secure and must be prohibited. This remains to be proven.

CIP controls are only being applied to the CIP VM and not the hypervisor; even though the hypervisor “if rendered unavailable, degraded, or misused” can impact the CIP and corporate VM’s.

Again, this is an unproven assumption. Treating the Hypervisor and the Guest as separate Cyber Assets does not require a difference in controls. If both are BES Cyber Assets then the same requirements apply to both. Additionally, the technical configuration controls applied to a Hypervisor are generally different than those applied to a Guest (Mal-ware, for example). Again, The Host and Guest may run different operating systems with different open ports, APIs, software vulnerabilities, and baseline capabilities. 
The question is whether a BCA Hypervisor can host a PCA or non-CIP Applicable System safely. The advisability of this approach depends upon whether or not sufficient security controls can be put in place to render negligible the risk of unavailability, degradation, or misuse of the BCA Hypervisor and associated BCA Guests. Risk assessment and acceptance are highly subjective and specific questions that depend more upon the overall architecture and defense in depth posture, than upon a simplistic question of "to virtualize, or not to virtualize."

(1)Control plane functions are not directly accessible by users of the system, they are embedded in the logic of the code base, and are generally require modification to the code base to change them. Virtualizing a server involves abstracting the hardware interactions much like the Hardware Abstraction Layer (HAL) does in Windows. The difference being that the Guest operating system simply sends its hardware access requests to the Hypervisor rather than to firmware. This has a three-fold security benefit. 

1. The users and software accessing the Guest in the Data plane cannot substitute malware in place of authorized device drivers. Since device drivers are one of the worst vectors for malware after Phishng attacks, this narrows the attack surface of the Guest OS.
2. The Hypervisor can be a different operating system than the guest, which means attacks in the data plane against the guest firmware will be ineffectual against the Guest due to no device drivers present and no direct access to hardware, and will be ineffective against the Hypervisor because there is no Data plane access between the two, and the device drivers that actually do interact with hardware are for a different operating system than what is visible to the attacker.
3. Drivers that actually interact with the hardware are generally a smaller subset of better-vetted drivers approved by the Hypervisor vendor, as long as you make the smart choice and go with a Type I Bare Metal Hypervisor.