An idea for File Integrity Monitoring a powered off View Gold Template

Today I had an interesting question posed to me by a customer.

“What’s a way we can verify file integrity compliance of our VMware View gold image, at regular intervals, WITHOUT powering it on? Because powering it on would force us to recompose all VMs once it’s powered down again”

In order to verity file integrity of a VM, there will need to be a file integrity check at some point in time. [PCI DSS 10.5.5 & 11.5] This is not a point in doubt. The question arose regarding regular scheduled checks on file integrity, at a pre-set interval. That’s the key. They need to ensure it weekly or monthly.

10.5.5 Use file integrity monitoring or change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert)

11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly

(Note, Netapp does have an API inside call fpolicy, which 3rd party tools and integrate into it, and have instant notification of file changes, and other auditing.  In many situations, those may be a better or more comprehensive fit.  In this case, we needed a spot solution for a specific type of scenario not already covered by their existing toolsets)

The image would be scanned with a FIM tool such as Tripwire ChangeIQ. The VM would then be shutdown, and a (sha or sha256) checksum of all the VM files would be taken from the (NFS volume) the Datastore. (Possibly by a checked/safe scan box w/ a read-only mount of the NFS volumes)

Being that [CUSTOMER] utilizes Netapp storage, with NFS as the protocol for VMware data stores, there is an easy solution to this problem.

NFS is a file-based protocol. The storage has visibility into the blocks and files. The Netapp can also take snapshots of the volumes which hold the files. These snapshots are read-only views to a point in time mapping of the inodes on the system when the snapshot was created. There is absolutely no way to modify the contents of a snapshot.

Netapp Snapshots of the VMware datastore would be scheduled at regular intervals. Utilizing the view of the filesystem at the point of a snapshot, a checksum can be performed on the files within that snapshot guaranteeing that the VMDKs and config files are not able to be modified by a compromised scanning system or any system which may touch the storage.

The “known good” snapshot checksum would be compared to the file version within the recent snapshot.

This method should be arbitrary to script.

Example. (In this I used the same ESXi server to checksum, but the NFS volume can be presented up to a server to checksum, with the entire NFS mount being readonly as an additional layer of security.)

We can see that as long as the VM is considered good, being shutdown immediately after it’s initial scan, all future checksum matches of the readonly snapshots on the Netapp can be used to illustrate that the source VM is still intact and good.

Additional Reading:

• Netapp TR-4401: PCI DSS 3.0 and Clustered Data ONTAP 8.3 (Not yet public on the TR site, Ask your Netapp SE or VAR for a copy from the Field Portal)

Be Sociable, Share!

•