How Virtualization Changes Audits

If you haven’t determined how server virtualization changes your audit plans, you better get moving. I’m not just talking about a virtualization audit (more on that later), but the audits that you typically do every year or on a multi-year cycle.

For example, if every year you do an audit on all networks, servers, applications, and databases that host your key financial reporting or PHI systems, you’re looking at policies and procedures, configuration management, security (including patching), user access, logging, and so on. But do you first consider whether those assets run on virtualized servers?

For an introduction to virtualization, see here.

Because virtualization changes everything, it should impact how you perform your current audits, because risks on a virtual host usually are shared with that host’s virtual servers (guests). If you are auditing your virtual servers like you audit your physical servers, you’re missing some major risks. If you don’t know whether the servers, applications, or databases you’re auditing are running in a virtual environment, you need to start asking those questions.

Your audit plans should consider the following areas and items (not by any means an exhaustive list):

Policies

• Do any policies specific to virtualization exist or does IT just “treat virtual servers just like physical servers”? Do your current policies cover items like those listed below? Virtualization adds another whole layer that needs to be managed. At the very least, organizations need to tweak their current policies to ensure virtualization is included.

Security Config

• Virtual Host
  • Do you review virtual host configuration, including patching? The virtual layer has its own set of configurations and security vulnerabilities that affect your servers, applications, and databases.
  • Since most virtualization methods reduce a server down to just a handful of files (which can easily be copied), do you periodically review who has access of the virtual host folders where those files reside? The same issue exists with server snapshots, which reside on the virtual server (guest). They can contain the contents of RAM, which could include encryption keys and other sensitive data. Are those snapshots secure?
  • Are you logging and reviewing admin tasks such as creating new virtual servers, virtual admin IDs, and changes to virtual infrastructure parameters, like turning logging off?
  • Are you logging and reviewing virtual host server performance, disk space, etc.? Do you aggregate logs from virtual servers to see how the lack of disk space on the host will affect other virtual servers on that host or the SAN container?
• Virtual server
  • Are the applications or tools installed on the virtual server (and used by the virtual host) periodically updated? In the case of ESX/ESXi, the VM Tools on the server need to be updated occasionally to close security vulnerabilities and provide enhanced capabilities.
  • Have you checked whether your production virtual servers are running on test virtual hosts? Usually, controls in the test environment are weaker than those in production. When admins run out of production space and budgets are tight, they are known to run production servers in test environments (just for a couple weeks, ya know, until I get more budget…).
  • Do you know whether your critical virtual servers reside on the same virtual host as test, low-security, “proof of concept”, or DMZ servers? Again, these are often mixed due to budgetary problems or because the organization doesn’t have a security classification policy.

User Access

• Are you reviewing admin access to servers, applications, and databases at the correct levels?

 For example, if your Exchange eMail servers are virtualized, you have the following sets of admins as you go up the various levels: Exchange Admins (application level), Windows admins (OS level), and Virtual admins (virtual level). Have you reviewed the policies and procedures for adding, removing, and periodically reviewing virtual admins?

Backup and Disaster Recovery

• What are your virtual host server backup/recovery procedures? Do they need to be different from your physical server procedures? Are you sure?
• Are virtual servers configured to start automatically when virtual host is restarted? Or do your admins need to remember to start them manually?
• If new virtual servers are created, do they automatically get backed up? How do you know that a virtual server added today will get backed up tonight? Are the proper parameters set or are you relying on the admin’s memory?

Snapshots

• Do procedures for using server snapshots exist and are they adequate? When a snapshot is taken and changes are made (such as transactions committed or changes in configuration, access privileges, patches, etc.) that affect security or efficiency, but later the server is reverted back to the snapshot, all changes are lost and all audit logs of those steps are also lost. This method could be used by admins or attackers to cover their tracks.

Change Control

• Since virtual servers do not require hardware acquisition, data center rack space, or network ports, or approvals, how do you know the servers are going through your change control process?

Expertise

• Do your admins have the proper training to manage virtualization? Especially since virtual servers are outnumbering physical servers…
• Do your auditors and managers know enough about virtualization to tackle these issues?

Again, this is by no means an exhaustive list, but it should be enough to make you rethink your audits and how virtualization affects your environment.

How to Virtualize Your Audits

Consider these steps to virtualize your audits:

1. Do your first virtualization audit.
   • Determine what types of virtual platforms your organization uses (Windows HyperV, VMware ESX/ESXi, Xen, Citrix, and all the UNIX flavors).
   • Determine which of your key servers run on each virtual platform.
   • Get some training.
   • Determine which key applications and databases run on those servers.
   • Narrow your scope and get started. Typically, companies use multiple virtual platforms, so pick the one that has the biggest risk. Even if you only look at one platform, you will find it difficult to limit your scope (and audit hours) because you have a lot to learn and virtualization is complex.
2. Based on what you learn, update how you test your yearly or cyclical audits. Identify the items that belong in a cyclical virtualization audit.
3. Do the next virtualization audit (the next platform or a deeper dive into a platform that was previously audited).
4. Go back to step 2.

Think about the same things regarding cloud computing, application virtualization, and desktop virtualization.

If you got through all this without being bored, you might also like my:

• Quote of the Weak (Securing Virtual Servers)
• Securing Virtual Servers
• Top 10 Reasons NOT to Virtualize

Advertisement