Month: August 2013

… 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.

Link: http://virtualization.sys-con.com/node/2760475

Shutting down a system in response to an information security incident is arguably the most drastic option that can be taken, but it might be the best option in certain scenarios.

For example, if there were a possibility that an attacker could gain control of a computer system that regulates traffic lights, it would likely be best to disable that system, and thus the traffic lights, because drivers would hopefully know to treat the non-working traffic signals like stop signs.

Such a decision would also depend on the security and availability controls implemented, including if there were controls in place that limited the compromise from spreading to the complete system versus just a compromised account.

In a system that contains no sensitive data and only has availability requirements, the security team could just do a basic calculation of the cost incurred from the downtime versus the recovery cost from containing and remediating the compromised system, and then make a decision based on the numbers.

This will lead into developing a business continuity and disaster recovery plan (BCDRP), which is similar to an incident response plan in that they both need to be developed prior to an incident and periodically tested so if a shutdown becomes necessary, a playbook for dealing with the situation is on hand.

In developing the BCDRP or incident response plan, establish a channel of communication with the necessary people, including the chief information security officer, chief information officer, helpdesk, business owners and marketing so they will be able to quickly make an informed decision about potentially shutting down a system.

For example, a Web server with a Web application susceptible to an SQL injection vulnerability might be shut down while a patch is being developed, a Web application firewall is set up or the configuration is changed to remove access by the Web server to run commands on the system.

Regardless of which option is the best in a given scenario, ensuring a plan and communication channels are in place prior to an incident is critical to minimizing the impact on your organization.

Link: http://searchsecurity.techtarget.com/tip/Security-incident-response-procedures-When-to-do-a-system-shutdown