[h=1]Virtualization Security[/h]Terry Komperda December 17, 2012 ABSTRACT Virtualization has made a huge impact in a very short time in the IT and networking worlds and has already provided huge cost savings and returns on investments for data centers, enterprises and the Cloud. What seems to be less substantial and lagging is the understanding of virtualization and virtualized environments from a security point of view. Some people think that virtualization is more secure than traditional environments because they’ve heard of isolation between virtual machines (VMs) and because they haven’t heard of any successful attacks on hypervisors. Others think that the new virtualized environment needs security just like traditional physical environments and therefore apply the same long standing approaches to securities that are already in place. The bottom line is that the new environment is more complex, and virtualization approaches added to current networks creates a new network that needs a new approach to security. This should include traditional security as well as additional security for virtualization. This paper attempts to identify the differences, issues, challenges, risks, etc. caused by virtualization, and looks to provide sound recommendations and best practices to make sure that this addition to the network is just as secure as the network before the addition of virtualization. INTRODUCTION Virtualization has taken off and is here to stay. Although it is a concept that goes back some fifty years, the technology will still grow and advance for applications that present themselves now and into the future. In fact, half of all server loads run on VMs today1. IDC predicts that 70% of all workloads will run on VMs by 20142. What needs to keep up with the technology advances and the widespread deployment is the security of virtualization components and virtualized environments. Let’s take a look at some of the security benefits that are present thanks to virtualization. SECURITY BENEFITS DUE TO VIRTUALIZATION The following are some of the benefits to security once virtualization is introduced into the environment: Centralized storage used in virtualized environments prevents a loss of important data if a device is lost, stolen or compromised. When VMs and applications are properly isolated, only one application on one OS is affected by an attack. When configured properly, a virtual environment provides flexibility in that it allows the sharing of systems without necessarily having to share critical information across the systems. If a VM is infected, it can be rolled back to a prior “secure” state that existed before the attack. Hardware reductions that occur due to virtualization improve physical security since there are fewer devices and ultimately fewer data centers. Desktop virtualization can be deployed to better control the user environment. An administrator can create and control a “golden image” that can be sent down to users’ computers. This technology provides better control of the OS to ensure that it meets organizational requirements as well as security policies. Server virtualization can lead to better incident handling since servers can revert back to a previous state in order to examine what occurred before and during an attack. The system and network administration’s access control as well as separation of duties can be improved as certain individuals may be assigned to only control VMs within the network while others only deal with VMs in the DMZ. You can also have certain administrators deal with Windows servers only for example, while others deal with Linux servers. Hypervisor software is small and not really complex and this provides for a smaller attack surface on the hypervisor itself. The smaller the attack surface and things running, the less potential vulnerabilities. Virtual Switches (vswitches) don’t perform the dynamic trunking necessary to conduct Inter-switch link tagging attacks. They also drop double encapsulated packets so double encapsulation attacks aren’t effective. Vswitches also don’t allow packets to leave their assigned broadcast domain so they nullify the multicast brute force attacks that rely on overloading switches to let packets broadcast to other VLAN domains. Notice that I’ve qualified a number of the above benefits with statements like “if configured or set up properly.” Virtualization is very complex so it must be secures properly to gain the above benefits. SECURITY CHALLENGES, RISKS AND ISSUES WITH VIRTUALIZATION Now that we have seen some of the possible security benefits to virtualization, we can look at some of the challenges, risks and issues related to virtualization. 4.1 File Sharing Between Hosts and Guests - When file sharing is used, a compromised guest can access the host file system and modify or change the directories that are used for sharing. - When clipboard sharing and drag and drop are used by the guest and host, or when APIs are used for programming, substantial bugs in these areas can end up compromising the whole infrastructure. 4.2 Snapshots - When snapshots are reverted, any configuration changes that you made are lost. If you changed security policy, things may now be accessible. Audit logs can also be lost, which would eliminate any record of changes that you may have made on the server. These unfortunate results can make it difficult to meet compliance requirements. - Images and snapshots contain proprietary data like personally identifiable information (PII) and passwords, much like a physical hard drive would. Any unnecessary or additional images could really be a cause for concern. Any snapshots that were stored that had undetected malware could be reloaded at a future date and cause havoc. 4.3 Network Storage - Fibre Channel and iSCSI are clear text protocols and could be vulnerable to man-in-the-middle attacks. Sniffing tools could be used to read or record storage traffic and this could be used to do some re-assembly in the future at the attacker’s convenience. - There tends to be a tradeoff between Fibre Channel performance and its security. Encryption can be used on the host bus adapters used in Fibre channel implementations, but many times it’s not used due to the negative performance issues that occur. 4.4 Hypervisor - If the hypervisor is compromised, any attached VMs will also be compromised, and the default configuration on the hypervisor isn’t always the most secure. - The hypervisor controls everything and provides a single point of failure in the virtual environment. A single breach can put the whole environment in jeopardy. - Bare metal hypervisors usually have access control included while hosted virtualization (hypervisor placed onto a physical server OS) doesn’t. Hosted virtualization exposes the system to more threats due to the presence of the host OS. - An administrator on the hypervisor can do just about anything (has “all the keys to the kingdom”). Hypervisors typically have password provisions but these can easily be shared among admins so you don’t truly know who did what. - Hypervisors can allow VMs to communicate amongst themselves, and this communication won’t even go onto the physical network. This ends up acting like a private network for the VMs. This traffic can’t always be seen as it’s carried by the hypervisor, and you can’t secure what you don’t know about! 4.5 Virtual Machines - VMs are small enough and easy enough to copy to a remote computer or portable storage device. Loss of the data on the VM would be equivalent to breaking into a data center, bypassing the physical security, and stealing a physical server. - User installed VMs don’t always comply with an organization’s security policy and may not have any security software on them. Product trials and games are now being offered on free VM players and these get installed and enter the corporate network with possible vulnerabilities. - VMs that are created typically start with ports open and numerous protocols available. - Every time a VM is created, another OS is added that needs to be protected, patched, upgraded and maintained. Additional OS with related issues can increase risk. - Inactive VMs or VMs no longer used (Dormant VMs) can still contain important data like credentials and configuration information. - Any clipboard functionality that allows for data to be shared between VMs and the host can be an entrance ramp for malware to be transferred to VMs in different security domains. - VMs that are not isolated can have full access to host resources. Any compromise of the VM can lead to a compromise of the resources. - VMs can be created by users without the knowledge of the IT organization. If these VMs are not noticed, they are not going to be protected. - Infecting a VM can lead to infecting data stores, and other VMs may be using these same data stores. - VMs can grow very quickly, and this can put a strain on the security systems. If not effectively automated, the admin burden can increase in relation to upgrades, patches, etc. - Infected VMs can appear, infect other VMs then disappear before they’re noticed. 4.6 Separation of Duties and Administrator Access - In typical physical networks, server admins handle management of servers, while network admins handle network management. Security personnel typically work with both of these admins. In virtualized environments, server and network management can occur on the same management console and this presents new challenges for effective separation of duties. - By default, many virtualization systems give full access to all virtual infrastructure activity. These defaults don’t always get changed, and a breach of this admin access can provide full control of the virtual infrastructure. 4.7 Time Synchronization - VM clocks can drift, and when this is combined with other normal clock drift, tasks can run early or late that would cause logs to lose any semblance of accuracy. Inaccurate time tracking will provide insufficient data for any future forensic investigations. 4.8 VLANs - Using VLANs requires routing VM traffic out of the host to a firewall, for example. This can lead to latency and complex networking that can cause problems with performance. - Inter-VM communication isn’t secured or inspected on a VLAN. Also, when many VMs are on the same VLAN, the spread of malware from one VM to the others can’t be stopped. 4.9 Partitions - It’s perceived that when multiple VMs are running on the same host, they are isolated and can’t be used to attack other VMs. Technically, the VMs may be separated, but the partitions on the VMs share resources like memory, CPU and bandwidth. If a partition consumes an inordinate amount of one of these resources, because of a virus for example, a denial of service can occur on the other partitions3. 4.10 Other Issues - At times, security is kept in the heads of security personnel or in checklists, and if this is the prevalent approach, it will be hard to keep up with virtualization security due to the speed of VM creation, moves, etc. - Virtualization is heavily software based, and this provides more potential software vulnerabilities and attack surfaces for attackers to prey on. - Virtual disks are typically stored as unencrypted files on a host and gaining access to them is just like having legitimate access to them. - Workloads with different trust levels may be placed on the same server or vswitch and the security of these workloads will only be as secure as the least secure workload. If sensitive data resides on this server, it may not be very secure. Despite the myriad issues identified above, virtualization isn’t inherently unsecure, but the way it’s being deployed may be through an unsecure nature. Immature security policies and processes, as well as lack of training, may be the bigger cause of issues and vulnerabilities which may lead to greater risk. Now that we know something about security issues related to virtualization, we can look at some of the common attacks. COMMON VIRTUALIZATION ATTACKS The following are some of the common, known attacks with virtualization: 5.1 Denial of Service (DoS) A successful DoS attack here can lead to a shutdown of the hypervisor. This can lead to the ability to add a backdoor to allow access to the VMs underneath the hypervisor. 5.2 VM Jumping If a security hole in the hypervisor occurs and is found, a user logged into one VM can hop over to another VM and gain access to it to look at information or acquire it. 5.3 Host Traffic Interception Vulnerabilities in the hypervisor can allow for tracking of system calls, paging files, and monitoring of memory and disk activity. APPLYING TRADITIONAL PHYSICAL ENVIRONMENT SECURITY APPROACHES TO VIRTUALIZATION Many of the issues and attacks encountered in virtualization can be addressed by employing existing people, processes and technology. But, what can’t be protected with existing solutions is the virtual fabric composed of hypervisors, management systems and virtual switches. The following are some of the traditional approaches applied to virtualization and their related shortcomings: 6.1 Firewalls Some IT groups send traffic between VMs to standard firewalls that will inspect the traffic and send it back to the VMs. Traditional firewalls were designed before virtualization was deployed in data centers and enterprises, and are therefore not necessarily tailored to the virtual infrastructure and related management systems. This can lead to manual deployment and administration which can then lead to errors. These standard firewalls also won’t provide protection if or when VMs move. 6.2 Network Based Intrusion Detection/Intrusion Prevention Systems These devices don’t work well when multiple VMs reside on a host. It’s mainly because the IDS/IPS systems can’t monitor the traffic between the VMs. They also can’t access any data when applications are moved. 6.3 Limiting the Number of VMs per Host/Assigned to Physical NICs This approach not only limits the number of VMs to be placed on a host, but also assigns a physical NIC to each VM. Although this may end up being a secure approach and has the right security intent in mind, it doesn’t allow the firm to gain all of the cost benefits and ROI related to virtualization. 6.4 VLANs VLANs are used extensively whether you’re talking non-virtualized environments or environments with a good degree of virtualization. The problem here is that as the number of VLANs grow, it gets harder to manage complexities related to access control lists, and the compatibility of the network security policy between the non-virtualized and virtualized aspects of the environment. 6.5 Agent Based Anti-Virus Approaches This entails loading a complete copy of anti-virus software on each VM. This approach can provide good protection, but at an enormous cost for all of the anti-virus copies across all of the VMs in the environment. This fully featured software can also impact memory, storage and the CPU in a negative manner, as it increases hardware utilization which therefore leads to a decrease in performance. Despite the above mentioned drawbacks to applying traditional security, 60% of respondents indicated that they use traditional security solutions to secure virtual environments4. Virtualized environments are dynamic and change quickly, and it’s hard for traditional security approaches alone to keep up, move and change accordingly. A better approach is to keep the good aspects of current security approaches while looking at the following additional best practices and recommendations for virtualization. 7. RECOMMENDATIONS AND BEST PRACTICES FOR SECURE VIRTUALIZATION 7.1 Administrator Access and Separation of Duties - Provide server admins with on/off rights for their servers only and no others. - You may want to give admins the right to deploy new VMs but not modify existing VMs. Other admins can then be able to modify existing VMs but not create new ones. - Separate authentication should be in place for each guest OS unless there’s a good reason for two or more guest OS to share credentials. - It may seem contrary to common thought, but the larger the environment, the easier it is to separate duties across functions. One admin can’t manage storage, domains, the virtualized infrastructure and the network all at once. 7.2 Desktop Virtualization and Security The following are five effective measures for making sure that unauthorized and unsecured virtualization doesn’t exist in the environment5: Update Acceptable Use Policy Spell out the exact conditions under which virtualization software can be installed and define what approvals are required. State what software can be run and how it should be protected. Spell out the repercussions that employees can expect if they don’t follow the rules. Limit the Use of VMs to the Users That Need Them Most users won’t need VMs on their desktops. Forbid the installation of freely downloadable software on corporate desktops and laptops. Limit permissions to a small group of developers and testers for virtual tools and VMs, and help them understand that they still have to conform to corporate security policies. Keep Virtualization and Security Software Up to Date Ensure all of the VMs contain the same firewalls, anti-virus and IDS/IPS as the physical desktops and laptops. Choose Security Policies That Support Virtualization Make sure that there aren’t any known security policy conflicts with existing virtualization platforms. Create and Maintain a Library of Secure VM Builds Maintain a repository of VM builds containing all of the configuration settings, security software and patches that users can download, use and re-use. 7.3 Network Security - Disconnect any unused NICs so that there isn’t an easy way to get onto the network. - Make sure that the host platform that connects the hypervisor and guests to the physical network is secure by setting file permissions, putting things in place to control users and groups, and setting up logging and time synchronization. - Encrypt all traffic between clients and hosts, between management systems and the hypervisor, and between the hypervisor and hosts using SSL. - Secure IP communications between two hosts by using authentication and encryption on each IP packet. - Do not use default self-signed certificates as they’re vulnerable to man-in-the-middle attacks. - Place virtual switches into promiscuous mode for monitoring purposes and enable MAC address filtering to prevent MAC spoofing attacks. 7.4 Storage Networks - iSCSI and NFS should be placed on dedicated storage networks or non-routable VLANs. - Use IPSec to encrypt iSCSI traffic to prevent snooping. - iSCSI supports Challenge Handshake Authentication Protocol (CHAP) and this should be used to force authentication prior to granting access. - When using iSCSI or NFS, use physical switches to detect and disallow IP or MAC address spoofing. - NFS is easy to set up but is the least secure storage choice. Configure the NFS server to restrict access to specific IP addresses related to your hypervisors or use a firewall to restrict traffic to specific hosts. If the NFS server supports IPSec, use it to secure traffic between the NFS server and the hypervisors. - All traffic to and from storage repositories needs to be isolated from non-storage traffic. - Do not send Fibre Channel traffic over Ethernet (FCOE) as this combines data storage traffic with other data types. - Security for Fibre Channel uses zoning, which is basically access control at the switch level and is similar to VLANs. Although numerous topologies are available, its simplest secure form is single initiator zoning. This involves a host bus adapter in its own zone with a target device to prevent initiators from trying to communicate with each other. 7.5 Disaster Recovery - Maintain your production firewall, security posture and IPS/IDS at your disaster recovery (DR) site. If your firewall is disabled at the DR site, until a disaster occurs or if the rules on the firewall are different from the main site, audit the firewall regularly. - Implement proper change control so that your backup site and main site are kept as identical as possible. - Any logging and monitoring at the DR site should be treated as if it is at your primary site. - Audit and PEN test your DR site separate from your main site with the same frequency and importance. - Any replications to your backup site should be encrypted. - Place a copy of your business recovery plan at your offsite location. - Rotate your backup media and keep it in offsite storage. 7.6 Auditing and Logging - Use centralized logging to determine whether guests have gone offline. These guests can get out of sync in regards to patches and updates. Log any VM power events (such as On, Off, Suspended or Resumed), changes in hardware configurations or any login events related to those with elevated privileges. VMs that are copied, moved or deleted should also be logged. - Audit files should be read only and should only be read by those in an auditing role to ensure forensic integrity. Unauthorized and authorized login attempts to the audit files and other virtual resources should be logged. - Conduct regular audits of the environment including the virtual network, storage, the hypervisor, the VMs and the management systems. - Send log files securely to a remote log server. 7.7 Virtual Machine Security - VMs shouldn’t be placed on storage, backup or management networks that are connected to the hypervisor. - Screensavers don’t serve a purpose on VMs. Also, don’t use processor intensive screensavers on physical servers as they can overwhelm the processor that’s needed to serve the VMs. - VMs shouldn’t be able to access or view the resources used by the kernel or host. These resources include storage networks and networking responsible for moving VMs. - Don’t create more VMs than is necessary. Keep track of all of your running VMs to track potential entry points for attacks. Limit use of VMs to critical staff only. - Turn off any unused VMs. - Unused hardware ports like USB on VMs should be disabled. - Use IPSec or other forms of encryption between the host and VM. - Set a comprehensive preparation in place to plan, deploy, patch and backup your VMs. - Physical devices like CD-ROM and floppy drives can be controlled by VMs indirectly or directly on the host. Configure this capability on a per VM basis and disable this connection to hosts by default on all VMs. If this is not done, a VM can request access to the host during boot and other VMs can be blocked until devices are released, thus delaying the boot up process. - You may want to consider employing VLANs within a single vswitch to segment traffic. - When VMs move, active memory and state are sent over the network to the new host in clear text. Isolate this motion traffic from the production network on an isolated segment that is non-routable and configured with a separate vswitch or VLAN. - Any suspended VMs should be started up in a test or lab environment so that any configuration changes are tested to prevent breaking a guest in the production environment. - VMs should not directly access a VM data store or repository. - Consider using a virtual appliance to provide anti-virus protection for your VMs. The appliance provides an agent-less approach. Performance is improved since the processing doesn’t burden the individual VMs. The drawback to some of these appliances is that they only provide anti-virus protection and not the additional application control, IDS/IPS, firewalls and web filtering contained in more traditional appliances. - Consider placing a virtual appliance on the host connecting the VMs with a small driver that takes the scanning and updating processes off the individual VMs. A central signature database makes sure that protection is always up to date even if a VM was previously offline. Security also follows the workload as it moves from host to host. This approach can also apply protection to certain VM groups or perform deep scanning on certain select VMs. - Security policy can be used to make sure that a new VM is not allowed to join a VM group or cluster unless it has a specific configuration and has related updates installed. - Do not place workloads with different trust levels in the same security domain or on the same physical server. The chance of mixing trust levels is great when users can create and deploy their own VMs. - Some organizations limit the number of VMs per physical server or assign physical NICs to each VM for isolation purposes. Other firms also don’t allow VMs to move to other hosts. Although secure, make sure you realize that you will not be reaping all of the benefits of virtualization with these strategies. - Be careful in taking one VM or a small group of VMs and assigning them to a VLAN for separation and isolation. This can lead to VLAN growth and complexity and can create a major admin burden. - Restrict access to dormant VMs. - Any VMs placed in the DMZ are exposed to the Internet and are open to attack. Do not allow a VM in the DMZ to access the storage system or networks. - When two or more VMs are on the same VLAN and vswitch, the traffic between the VMs is not protected. Consider placing virtual firewalls on these VMs for protection. - Place a CPU limit on any VMs that can access the Internet. This is so that if a VM is compromised, the resources are limited to launch attacks on other hosts. - If users are allowed to create VMs, consider allowing them to create VMs from an authorized template. - Consider deploying a security VM to eliminate an agent on each VM. This can eliminate anti-virus storms and any bottlenecks that would occur when all hosts and VMs start their malware scans simultaneously. - Check the OS on VMs with a script and a user login to make sure that the VMs have been updated. If the VM is not compliant with the updates, the script can log the user off and alert the help desk. Or, a non-compliant VM can be kept in the DMZ or test environment and not allowed to access the network until it’s properly updated. - Disable any copy- paste functionality to protect the confidentiality of the data and the integrity of the hypervisor and VMs. - A virtual firewall attached to a VM travels with it at all times to ensure that security policy is enforced before, during and after any moves. - A security gateway (firewall and IDS/IPS) can be employed to inspect traffic between VMs. - Make sure that any VMs that process protected information are isolated from other VMs so that the data isn’t combined with other data or is accessible through other VMs. 7.8 Management Systems - Secure your communications between management systems and the hosts to prevent data loss, eavesdropping and any chance for man-in-the-middle attacks. Enable one or more of the available SSH, IPSec and SSL protocols for this purpose. - Employ a single management system and security policy to cover both physical and virtual environments. Not implementing this approach will mean double the work for generating reports and conducting analysis for any issues that present themselves. - Do not allow a management server to be accessible from all workstations. Compromising this server could affect VMs and data stores. To prevent this, place the management server on a separate VLAN from the user computers’ subnet and then place behind a firewall. These are two completely different security zones. Define access control lists on the network switches and set appropriate rules on the firewall. Change the default permissions on these servers so that the admin doesn’t have access to the entire environment. - Separate management servers from database servers. 7.9 Hypervisor Security - Install vendor supplied patches and updates to the hypervisor as they’re released. Support this with a sound patch management process to mitigate the risk of hypervisor vulnerabilities. Place the latest service packs on guests and hosts and remove any applications with a history of vulnerabilities. - Disable any unused virtual hardware that connects to the hypervisor. - Disable unneeded services like clipboard or file sharing. - Perform constant monitoring of the hypervisor for any potential signs of compromise. Monitor and analyze the hypervisor logs on a consistent basis. - Do not expose the management interface to the hypervisor to your LAN. - Disable all local administration of the hypervisor and require use of a centralized management application. - Require multi-factor authentication for any admin functions on the hypervisor. 7.10 Snapshots and Images - No guest OS images should have write access. - Protect VMs by the snapshot capability of the hypervisor as the snapshot captures the current state of the VM. The snapshot captures the OS, configuration settings, data and application state contained in the VM at that point in time. 7.11 Time Synchronization - Network Time Protocol (NTP) should be enabled and configured to synchronize with a time server close to your network and NTP should run on a host. Guest VMs should either use the same server as the host or use the host itself as the NTP server. If the VM layer allows a guest OS to sync time directly from the host, then this should be used as this is the simplest to implement. - Hashing authentication should be used between NTP peers to prevent tampering. 7.12 Remote Access - Some firms use Virtual Network Computing (VNC) as a cross platform remote desktop function. Communications aren’t always encrypted when using this. Encryption may be provided in the vendor’s settings or through a third party plug-in. Don’t expose these VNC connections to the Internet whether they’re encrypted or not. Control these connections through a VPN or SSH tunneling. - Remote access management should be limited to a small set of authorized management system IP addresses. - Any remote access should ask for a username as well as a password backed up with a strong password policy. For strong security environments, use two factor authentication or one time use passwords. - Remote communication to any management tools should be encrypted and authenticated. - When using SSH, disable the version 1 protocol, disable the admin or root SSH login and require users to use role-based access control or their individual user accounts. Use a tool like Sudo as it allows activity to be written to a log that indicates what was done, when it was done and by whom?. - Do not allow any remote access to the host or hypervisor. 7.13 Backups - Encrypt any backup data streams in case a server image is stolen. Data at rest should have access control lists to control copying or mounting of images. - Network level protections like VLANs and access control lists should be in place to protect backup data whether at rest or in transit. - Do not allow root accounts to be used for backup. - Any backups that are sent to a disaster recovery site over the network should be securely encrypted. - Backup the OS and data on a daily basis and perform a full backup once a week. Complement these backups with remote storage solutions and offsite storage of backup media. - With virtual computing, disk backups are just as important as in traditional environments. Backups of virtual storage should be included in your backup policies. 7.14 Configuration and Change Management - Make sure that any physical or virtual servers are hardened before putting them into deployment. Monitor any configuration changes to detect any unauthorized changes or deviations from compliance in regards to updates and patches. - Harden physical and virtual switches and virtual appliances and gateways before deployment. - Do not allow changes to the infrastructure without documentation and testing in a lab environment that is as identical to the production environment as possible. Answer these questions before making any changes7: - What are the implications of the change? - Who and what will be affected? - How much of a risk does the change represent? - Can the change be reversed if necessary? - How long will it take to roll back a change? - Track VM configurations and issue alerts for any changes to a desired configuration. - Make sure that any existing patch management products support virtual offerings and platforms. 7.15 Server Pools and Virtual Service Offerings - Segment server pools in case they contain different server tiers like web servers that are public facing and database servers that contain personally identifiable information (PII). Put protections in place so that servers are protected from the Internet and from themselves. Not implementing segmentation in the server pools could mean that a single compromised server can affect the whole server pool. - For Virtual Service Offerings (VSOs), backup any user data, organizational data, documents , databases, state information on virtual servers and any Active Directory data using standard backup strategy and policies. - Separate server pools from VSOs from a security perspective. Users that interact with VSOs should not have access to the physical servers which are under the control of the admins. The above best practices and recommendations can be effective when used in addition to the standard traditional security already deployed and are not a substitute or replacement for effective existing security. However, virtualization is different enough in that if these suggestions are not employed, you will still not have a totally secure hybrid (physical and virtual) environment. 8. ADDITIONAL ISSUES, RECOMMENDATIONS AND BEST PRACTICES FOR THE VIRTUALIZED CLOUD Many of the previously mentioned recommendations and best practices are effective for data center, enterprise and cloud environments alike, but the cloud is different enough from the other two environments to require other protections due to scale, multi-tenancy and the fact that VMs don’t always stay within the cozy physical perimeter that you can design security around. The following are some of the important items to take note of: - Hypervisor security is even more important in the cloud due to the magnitude of a potential breach. - VMs need to be tracked to their owners throughout the VM lifecycle. They should only be collocated on servers that meet the collocation requirements of other VMs and should use VM tagging for tracking purposes. - VLANs should be used to isolate traffic from one customer VM to another customer VM. This requires VLANs to be extended beyond the core switching infrastructure. There could be an issue with scaling VLAN capabilities to support very large clouds. - Automation is required for security in the cloud due to its sheer scale. Security must be better planned and managed in the cloud. - Recycling of IP addresses and IDs could be a problem if it’s possible for a user to gain access to another customer’s data. There must be a strong process in place to implement allocation and re-allocation of VMs. - Central storage is an attractive target in the cloud. Data protection and encryption must be properly implemented everywhere when data is at rest, in transit or being processed. - Standards will need to be in place if applications are going to be moved across different Cloud Service Providers (CSPs). This applies to data, firewalls, VMs and virtual network configurations. - Customers in the cloud need assurance that their data is kept separated from other customers within shared storage. - Automated lifecycle management tools should be used to track new deployments. CSPs also need to instruct customers to limit the number of users that can provision VMs. - Standard VM images need to be used to maintain the integrity of the environment. - A dedicated scanning VM cannot be used in the cloud to protect other VMs as they don’t control the hypervisor. An agent-based approach must be used in a multi-tenant environment. - Encryption keys for data stores must be protected. When the keys are protected properly, rogue VMs that may reach data stores become unmountable and unreadable. - Security policies tied to physical attributes like the physical server, IP address, or the physical host separation used for isolation or MAC address, don’t make much sense in the cloud. Security policies need to be tied to logical attributes as opposed to physical ones. Identity, group or role of the application users and sensitivity of the workload become important. Policies need to be context-aware and adaptive. - Standards are needed to tie all of the security together in the cloud. Customers and CSPs also need to delineate the security responsibilities between them. - In Infrastructure such as a Service environment, the client is responsible for maintaining patch levels for any provisioned VMs as well as having responsibility for properly configuring a VPN after initial installation. - The old access control model is machine based and IP focused. The model in the cloud needs to be person and user based. Network Access Control (NAC) determines who you are and what you get access to. Access control also needs to be dynamic as users come from anywhere, at anytime, on any device, and can access from multiple devices at one time8. - Data Loss Prevention (DLP) monitoring becomes more important and fingerprinting needs to be used so that DLP monitoring tools can recognize data. When a policy violation occurs, quarantine and response measures need to kick in. - Protection and scanning of dormant VMs remains with the CSP. - Full system scans in the cloud should not be used as they degrade performance. - If offered by the CSP, customers should use dedicated resources as they’re more secure. The cloud expands the security tasks necessary to provide protection of resources and customer data. The attack surface is much greater due to scale and a breach can have an effect on various customers and the related data that they’ve entrusted to the cloud service provider. 9. CONCLUSION Virtualization provides new security challenges for firms. The virtual components and environment cannot be protected by existing security mechanisms and processes alone. Virtualization creates a different network that is a hybrid between the established physically centered network and the new virtual or logical environment. Additional considerations and protections must be put into place to ensure a strong security posture, and much planning and preparation as well as training needs to be implemented in advance. Virtualization security must not become an afterthought after the new virtual infrastructure and components are put into place. Security in this area will improve as virtualization technology advances, and standards will need to be put into place so that firms have guidelines to follow to secure their new environments. ENDNOTES 1Amy Larsen DeCarlo, Myth vs. Reality: Controlling VM Sprawl in the Cloud, http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. 2Amy Larsen DeCarlo, Myth vs. Reality: Controlling VM Sprawl in the Cloud, http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. 3?Managing Access in a Virtualized Environment,” CA White Paper, October 2006. Page 4. 4?2010 State of Virtualization Security Survey,” Prism Microsystems, April 2010. Page 5. 5 “Is Virtualization a Black Hole in Your Security? 5 Ways to Ensure it Isn’t,” A Sophos White Paper, November 2008. Pages 3-4. 6 Forbes Guthrie, Scott Lowe, Maish Saidel-Keesing, VMware vSphere Design. (Wiley Publishing, Inc., 2011), Page 283. 7 Forbes Guthrie, Scott Lowe, Maish Saidel-Keesing, VMware vSphere Design. (Wiley Publishing, Inc., 2011), Page 295. 8 “Is Your Network Ready For Cloud Computing?,” Cisco, David Newman, 2012. SOURCES Ruest, Danielle and Nelson Ruest. (2009). Virtualization: A Beginner’s Guide. McGraw Hill Books. Campbell, Sean and Michael Jeronimo. (2006). Applied Virtualization Technology: Usage Models for IT Professionals and Software Developers. Intel Press. Haletky, Edward L. (2009) VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment. Pearson Education. EC-Council Press. (2011). Virtualization Security. Winkler, Vic (J.R.). (2011). Securing the Cloud: Cloud Computer Security Techniques and Tactics. Elsevier. Golden, Bernard. (2008). Virtualization for Dummies. Wiley Publishing, Inc. Guthrie, Forbes, Scott Lowe, and Maish Saidel-Keesing. (2011). VMware vSphere Design. Wiley Publishing, Inc. Mishchenko, Dave. (2011). VMware ESXi: Planning, Implementation and Security. Cengage Learning. Security and High Availability in Cloud Computing Environments. (June 2011). IBM Global Technology Services Technical White Paper. Newman, David. (2012). Is Your Network Ready For Cloud Computing? Cisco. Managing Access in a Virtualized Environment. (October 2006). CA White Paper. MacDonald, Neil and Thomas J. Bittman. (October 13, 2010). From Secure Virtualization to Secure Private Clouds. Gartner Research. Virtualization and Cloud Computing: Security Best Practices. Trend Micro. Executive Brief: The Building Blocks for a Secure Virtualized Environment. IDG Global Solutions. Alternatives for Securing Virtual Networks. (2008). Altor Networks White Paper. Is Virtualization a Black Hole in Your Security? 5 Ways to Ensure it Isn’t. (November 2008). A Sophos White Paper. Antonopoulos, Andreas. (2007). Securing Virtualized Infrastructure: From Static Security to Virtual Shields. Nemertes Research. Garfinkel, Tal and Mendel Rosenblum. When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments. Stanford University Department of Computer Science. Ritter, Ted. (Summer 2009). Virtualization Security: Achieving Compliance for the Virtual Infrastructure. Nemertes Research. 5 Best Practices to Protect Your Virtual Environment. Altor Networks White Paper. The CIO Guide to Virtual Server Data Protection. A CommVault White Paper. 2010 State of Virtualization Security Survey. (April, 2010). Prism Microsystems. Server Security, Patching and Virtualization. BlueLane White Paper. Securing the Virtual World. (October, 2011). WatchGuard Technologies White Paper. Garber, Lee. (January 2012). The Challenges of Securing the Virtualized Environment. IEEE Computer Society Publishing. A Comprehensive Framework for Securing Virtualized Data Centers. (July 2010). HP Business White Paper. Vax, Nimrod. (May 2010). Securing Virtualized Environments and Accelerating Cloud Computing. CA White Paper. Securing Virtualization in Real-World Environments. (June 2009). IBM Internet Security Systems Virtualization White Paper. Making Virtual Machines Cloud-Ready. (May 2010). A Trend Micro White Paper. Securing the Virtual Information Infrastructure: Technology Concepts and Business Considerations. (February 2010). EMC Global Solutions. Essential Guide to Cloud and Virtualization Security. Information Security Magazine. Scarfone, Karen, Murugiah Souppaya, Paul Hoffman. Guide to Security for Full Virtualization Technologies. National Institute of Standards and Technology. U.S. Department of Commerce. Special Publication 800-125. Information Supplement: PCI DSS Virtualization Guidelines. PCI Data Security Standard. Version 2.0. (June 2011). Butler, J. Michael and Rob Vandenbrink. (September 2009). IT Audit for the Virtual Environment. A SANS White Paper. Database Security in Virtualization and Cloud Computing Environments. (2011). A McAfee White Paper. Sunderland, Bill and Ajay Chandramouly. (November 2011). Overcoming Security Challenges to Virtualize Internet-facing Applications. An Intel White Paper. IBM Point of View: Security and Cloud Computing. A Cloud Computing White Paper. (November 2009). Girola, Michele, Alessio M. Tarenzio, Mark Lewis, Marian Friedman. (February 2011). IBM Data Center Networking: Planning for Virtualization and Cloud Computing. IBM Redbooks. Hartman, Bret, Dr. Stephen Herrod, Dave Shackleford, Charu Chaubal, Nirav Mehta. (2009). Security Compliance in a Virtual World: Best Practices to Build a Solid Foundation. An RSA Security Brief. An Integrated Security Solution for the Virtual Data Center and Cloud: Protecting Physical and Virtual Workloads. Juniper Networks White Paper. (2011). Alternatives for Securing Virtual Networks: A different Network Requires a Different Approach – Extending Security to the Virtual World. Juniper Networks. (2011). NIST Guidance Cites Cloud Security Gaps, Need for Standards. http://searchcloudsecurity.techtarget.com/tip/NIST-guidance-cites-cloud-security-gaps-need-for-standards. Lowe, Scott. (March 1, 2012). How iSCSI Packets Are Encapsulatedand How to Protect iSCSI Data Traffic. http://www.techrepublic.com/blog/networking/how-iscsi-packets-are-encapsulated-and-how-to-protect-iscsi-data-traffic/5398 Application Brief: Multi-Tenant Cloud Security. www.vyatta.com/sites/vyatta.com/files/pdfs/vyatta_app_multitenantcloud.pdf. DeCarlo, Amy Larsen. (January 20, 2012). Myth vs. Reality: Controlling VM Sprawl in the Cloud. http://searchcloudprovider.techtarget.com/tip/myth-vs-reality-controlling-vm-sprawl-in-the-cloud. Shackleford, Dave. (March 9, 2010). An Introduction to Virtualization Security. SANS.http://net-security.org/article.php?id=1397. Chickowski, Ericka. (9/3/2009). Five Fundamentals to Secure Virtualization. http://www.channelinsider.com/c/a/virtualization/five-fundamentals-to-secure- Virtualization-565563/. Haletky, Edward L., Contributor. Securing Virtual Environments: Three Considerations. http://secureservervirtualization.techtarget.com/tip/securing-virtual-environments-three-considerations. Peterson, John. Virtual Environments Will be More Secure than Their Physical Counter Parts by 2010. Montego Networks. http://vmwaresecurity.typepad.com/security_in_the_virtual_w/2008/03/virtual-environ.html. featurevisualization security [h=5]About the Author[/h] Terry Komperda is a Chicago-based security enthusiast and researcher who likes to write about technology subjects from both a business and technical perspective. His current interests are data centers, the Cloud, virtualization and all aspects of security. He currently works in product management and new product development and develops DCIM software for data centers. Sursa: http://resources.infosecinstitute.com/virtualization-security-2/
[h=1]WordPress Pingback Vulnerability Can Be Abused for DDOS Attacks[/h]December 18th, 2012, 14:15 GMT · By Eduard Kovacs A security hole in WordPress’ Pingback system – a mechanism utilized by web authors to know when someone links to one of their documents – can be leveraged by cybercriminals to launch distributed denial-of-service (DDOS) attacks. According to Bogdan Calin of Acunetix, the WordPress XMLRPC API, which can be accessed via the xmlrpc.php file, can be abused not only for DDOS attacks, but also to find out if a host exists on the internal network, to port scan hosts inside the network, and even to reconfigure an internal router. The expert reveals that users can only protect themselves by renaming or deleting the xmlrpc.php file. The vulnerability was reported to Automattic, the developers of WordPress, around 6 years ago, but the ticket was closed at the time after someone argued that “there are so many ways to orchestrate a DDOS attack.” Five days ago, the ticket was re-opened after a script that took advantage of the Pingback API was released. Sursa: http://news.softpedia.com/news/WordPress-Pingback-Vulnerability-Can-be-Abused-for-DDOS-Attacks-315722.shtml