How to Evaluate Cloud Security Tools

Entities use a variety of security tools to monitor their data and applications. Although cloud providers may make certain assurances regarding security, organizations are likely to want to implement some of their own security controls, such as firewalls and intrusion detection systems (IDSs).

However, there’s often a choice to be made: to rely on security controls running within the hypervisor, or to implement security within each guest operating system. Each of these approaches has its own advantages and disadvantages.

Security Within the Hypervisor

Security controls, such as network firewalls and network IDSs, can be embedded within the hypervisor if it has an ability known as introspection. Introspection refers to the capability to monitor aspects of each guest operating system that is running. Examples of these aspects include network traffic, storage, memory and process execution, all of which have relevance for security. Introspection also can monitor activity between guest operating systems on a single server, such as network activity.

This is a natural spot to deploy firewalling, intrusion detection and other network security capabilities; especially since this network activity is contained within the physical server and cannot be monitored by security tools deployed on the actual networks between physical servers. Security policies can even be carried out with a guest operating system that is migrated from one hypervisor to another within the same cloud.

Unfortunately, using the hypervisor as a security monitoring mechanism can bring significant disadvantages. A hypervisor that has introspection enabled can access the contents of the guest operating systems, which means that the administrators of the hypervisors also have access to the guest operating systems. This can be a serious problem in terms of accountability, because the monitoring activities performed by the hypervisors are unlikely to be monitored and audited themselves. If a guest operating system contains sensitive data that is subject to regulations such as HIPAA or the Payment Card Industry Data Security Standards (PCI DSS), introspection might not be an option, particularly in public clouds.

Another significant problem with relying on the hypervisor as the security monitor is that this makes the hypervisor more complex, thus increasing the likelihood of exploitable vulnerabilities in its software. This vulnerability is aggravated when security controls such as firewalls are designed to “plug in” to the hypervisor, further increasing its attack surface.

Finally, in a public-cloud environment, it’s probably not feasible to monitor all guest operating systems on a host all together; such monitoring should be segregated by a guest operating system. Therefore, using security within the hypervisor is much more likely to be a viable option for private clouds hosted by an organization, and not for public clouds or for private clouds hosted by a third party.

Security Within the Guest Operating System

The alternative to performing security monitoring within the hypervisor is to bundle security tools within the guest operating system. These security tools generally include host-based versions of network-based tools (such as firewalls and IDSs), as well as typical host-based security tools, including patch management, access control and auditing/logging. These are usually cloud-specific versions of security tools; major performance problems commonly occur if regular security tools are run in cloud environments because of resource overconsumption. For example, anti-virus software often consumes all the processing capabilities on a server when performing a scan, since the software doesn’t realize that other operating systems are sharing the processors.

Because the security tools are encapsulated within the guest operating system, they automatically move when the guest operating system is migrated from one server to another. The encapsulation also means that cloud providers have no visibility into the guest operating system through the hypervisor, because introspection is not enabled, thus protecting the data and applications within the operating system from compromise by the provider.

Having the security tools in the guest operating system instead of the hypervisor generally works well for both public and private clouds. Typically it provides the opportunity to manage the security of workloads in different clouds in a consistent manner. However, as with hypervisor-based security, guest operating system-based security measures bring some disadvantages. If a compromise occurs within the guest operating system, it’s likely that malware or attackers will disable security tools, causing all security visibility to be lost. If the security tools were in the hypervisor, they would be protected from guest operating system compromise. Of course, the loss of visibility itself would be a strong indicator of problems.

Another concern is that the logs and other security data recorded by these tools must be securely sent to a central location for analysis, correlation and reporting purposes. Communication channels must be established and maintained between each guest operating system and one or more security systems within the enterprise. Communication also should take place between host-based tools and central management servers that handle tasks such as patch management, anti-virus and other enterprise security functions (such as pushing out new signatures to antivirus clients or new patches to patch management clients in the cloud). All of these communication channels make the guest operating system configuration more complex, increasing the risk of vulnerability, as well as enlarging the attack surface for the guest operating system.

Want to learn more? Become an insider and access CDW’s white paper, “Peace of Mind Security in Public and Private Clouds.”