Cyber Security Institute

§ Current Worries

Top 3 Worries

  • Regulations
  • Old Firewall Configurations
  • Security Awareness

§ Listening

For the best information

  • The underground
  • Audible
  • Executive Excellence
  • Music (to keep me sane)

§ Watching

For early warnings

  • 150 Security Websites
  • AP Newsfeeds
  • Vendors

Tuesday, August 20, 2013

Handling Incident Management in a Virtualized Environment

Good article on Incident Response in a Virtualized Environment - summary:

In my experience, this rush to a virtualized data center assumes that either existing controls are enough or that - for some unexplainable reason - virtualized servers are isolated from common attack vectors and therefore more secure. Although this increase does not correlate to an increase in disclosed virtualization vulnerabilities, as shown in Figure 1, the overall increase of vulnerabilities does track with the increase in growth of virtualization as a strategic technology. It also indicates that the increase in the number of virtualized servers increases the attack surface for those attackers focusing on the hypervisor as a high-value breach target.


… however, this is still reason for concern: a large majority of reported vulnerabilities allow an attacker to gain full control of a single hardware platform’s multi-server environment. Consequently, a close look at detection, containment, and response capabilities for the unique needs of VMs is an important step in integrating virtualization into the organization’s security program.

It is in this phase of incident management, security and infrastructure design teams address the unique challenges associated with virtualization.

A few simple steps - not always so simple to implement - will ensure an organization’s ability to detect unwanted behavior and effectively respond as virtual servers spread across the enterprise, including:

For example, critical or high-value breach targets might reside on a host with more than the recommended two NICs (one for partition management and one for VMs to access the physical network).

Implemented using VLANs configured in a virtual switch and VLAN access control lists (VACLs), this example is one way to help ensure unwanted traffic does not pass from a compromised VM to other VMs on the same host.

Remember that many controls you implement on the physical network must be configured in virtual environments, but VMs are by design isolated from controls on your physical network.

Security teams often face two challenges when trying to remove a physical server from service: retention of potential evidence in volatile storage or removal of a device from a critical business process.

For example, removing power from a server starts the process of mitigating business impact, but it also denies forensic analysis of data, processes, keys, and possible footprints left by an attacker. A VMware snapshot is a point-in-time image of a VM, including RAM and the virtual machine disk file (Siebert, 2011). Administrators typically strive to meet four goals when a virtual server is removed from service: 1) contain a breach or malware infestation by removing the affected server from the network; 2) prevent any further damage to, or loss of, information residing on local storage; 3) remove the server to a secure location for forensics analysis; and 4) restore services provided by the VM.

As I wrote in Step 3: Segment virtual networks, this is easily accomplished using documented steps to isolate one or more virtual network segments.

They examine and help remedy system, network, and process design challenges associated with VM placement, incident detection and containment, and business process recovery unique to virtualization.



Posted on 08/20