CIP 9 and Hypervisors

Carlo asked a question about CIP 9 in comments to a previous post.

I hope this answers it well enough:

Backup solutions are going to be specific to your Hypervisor choice. If you're working with a Type I Hypervisor (Bare Metal) your backup solution (for the Hypervisor itself) may very well be “install fresh from vendor media” because there is very little specific data to be restored and which Host the Guest resides upon is transparent to the Guest and/or users of the system. If you have a Type II Hypervisor that includes an operating system, and possibly performs functions other than Hypervisor in addition (which I would strongly recommend AGAINST), then your backup solution may be more complex.

In most cases, backups for Hypervisors are not urgent because you plan and implement swap space capacity into your infrastructure. You should have more Hypervisor capacity than is necessary for the Guests in each. This allows for maintenance of Hypervisors (patching, upgrades) without taking any functionality offline. You simply move Guests from the Hypervisor being taken offline to other Hypervisors for the duration of the procedure. In an unplanned outage, the same process is used. Guests don’t rely on any specific Hypervisor, they simply need a Hypervisor.

Backup solutions for Guests can work exactly the same as your traditional network-based backup management software. I wouldn't do it that way, but it's possible.

Most Virtual Cluster Management consoles allow for "snapshots" of the running state of your Guest. This is much more complete than a backup of files and directories, and requires merely rebooting to a previous state rather than a process of restoring files and settings to a base image.

The advantage here is that if your target to be restored is participating in a security domain such as Active Directory, you're merely restoring a previous state, not deleting and recreating AD objects with unique and possibly conflicting GUIDs. It's more complicated if it is an AD Domain Controller; this may require authoritative or non-authoritative restore procedures (depending on the state of the AD domain and how corrupted it may be).

Depending on your Hypervisor choice, the Guest’s configuration data (number of processor cores, RAM, storage targets etc.) may be contained in the image of the Guest or in your private cloud cluster manager. This configuration data is rather static and rarely changes. In most cases, the cluster manager is a virtual machine itself and can be rebooted from a snapshot. It could also be backed up across the network using a traditional backup application.

If you’re using standalone, unmanaged Hypervisors (perhaps for cost reasons) then you have more manual planning to do. You have to make sure that you have a process to identify target destination Hosts with adequate resources and you should also maintain functional redundancy or security zone separation for manual moves of Guests during planned or unplanned outages. For automating Guest movements, this is managed by setting affinity of certain Guests to targeted Hosts.

For CIP-009-6 specifically, nothing changes until CIP-009-6 R1.3. Here we need to note that the Hypervisor doesn’t have any BES Cyber System Information. The Hypervisor is just a container, and doesn’t interact with the code base of the BES Cyber Systems themselves. So “processes for the backup  and storage of information required to recover BES Cyber System functionality”  {emphasis added} apply more strictly to the Guests individually (Cyber Asset) and to the Hypervisors as a general function (Cyber System).

R1.4 and 1.5 are also going to have to be applied at a Cyber Systems level rather than Cyber Asset.