Auditing Security Risks in Virtual IT Systems 

 
Download Article Article in Digital Form

Virtualisation of IT systems has gained popularity and relevance in recent years, but its roots can be traced back to 1972 when IBM introduced virtualisation technology in mainframes. Traditional servers have long been accepted by chief executive officers (CEOs) and chief information officers (CIOs) to run day-to-day business; however, studies show that this methodology is responsible for wasting processing power and hardware resources because no servers are utilised to their fullest capacity. Recent trends indicate an urgency amongst IT leaders towards cost savings in IT investments and ‘green IT’. Virtualisation of IT systems is playing a significant role in realising these savings.

Virtualisation provides significant cost savings by sharing storage space and central processing unit (CPU) capacity. As with any technology, though, virtual IT systems are not risk-proof. A proper risk mitigation strategy needs to be developed and followed if organisations are to harness the benefits of virtualisation technology. Information security auditors have an important role to play in auditing the risks of virtual IT systems. This article discusses virtual IT systems and the inherent risks that need to be audited for proper risk mitigation and provides guidelines for security audits of virtual IT systems that can be referenced during information security audits and the application of security to virtual IT systems.

What is Virtualisation?

Virtualisation is a software technology that divides a physical resource, such as a server, into virtual resources called virtual machines (VMs) (see figure 1). Virtualisation helps to consolidate physical resources, simplify deployment and administration, and reduce power and cooling requirements.

Virtualisation in a computing system adds a layer of abstraction between two layers in that computer system. The layer of abstraction is a software layer between the hardware and the guest operating systems. The layer acts as a resource manager to enable the sharing of processing power and memory. This software is called a virtual machine monitor (VMM) or hypervisor. VMMs virtualise the hardware of a physical machine and partition it into multiple, logically separated VMs. The VMM monitors everything that happens inside a VM, and it enforces resource management policies on the VM. Multiple operating systems (OSs) can coexist on the same virtual machine in isolation from one another and can operate simultaneously on a single server. Virtualisation allows companies to eliminate dedicated hardware-based servers—saving acquisition, maintenance and electricity costs.

Types of Virtualisation

Although server virtualisation technology is the most popular technology, virtualisation is not limited to servers. Virtualisation can be applied to OSs, desktops, applications, storage and networks. VM technology is also being used in data storage, such as storage area networks, and inside OSs, such as Windows Server 2008 with Hyper-V. Virtualisation in a distributed environment is the basis for grid computing and cloud computing—supplying a computing infrastructure as a utility, on-demand service.

Virtualisation can be categorised into three areas:

  1. Storage virtualisation—Virtualises the physical storage from multiple network storage devices so that they appear to be a single storage device. In general, ‘virtualisation’ refers to server virtualisation.
  2. Network virtualisation—Combines computing resources in a network by splitting the available bandwidth into independent channels that can be assigned to a particular server or device in real time
  3. Server virtualisation—Hides the physical nature of server resources, including the number and identity of individual servers, processors and OSs from the software running on them

Architectural Overview of Server Virtualisation Technology

Server virtualisation allows multiple operating systems and applications to run concurrently on a single hardware. The OSs run independent of each other in isolated environments (the VMs). A virtualisation layer is required to run on the computer’s OSs as an application or service to create multiple VM environments. OSs and applications running in a VM can access the CPU, memory, and disk and network resources that are similar to a physical computer.

Figure 2 depicts the architectural overview of server virtualisation technology.

The components of a virtual server are:

  • Physical hardware or virtualisation host—Physical machine on which the VM environments reside. The number of VMs that can be supported on a single physical machine depends on the hardware configuration and specifications.
  • Host operating system—Primary OS on the physical machine. The virtualisation layer resides on this OS.
  • Virtualisation layer—Virtualisation software that co-ordinates with the host OSs for requests from VMs regarding CPU time, physical memory, disk read and write, network input/output (I/O), etc. The virtualisation software is called hypervisor (see figure 3), and it plays an important role in virtualisation technology. It intercepts the hardware resource requests from the virtual machines that reside on it and translates the requests to a format that can be understood by the physical hardware. Similarly, the requests from the physical hardware are translated by the hypervisor so that the virtual machines can understand. The hypervisor decouples the VMs from the physical hosts by introducing a layer of abstraction between the VMs and the physical hardware layer.



    Not all virtualisation solutions leverage a hypervisor. Some of the virtualisation products that make use of a hypervisor are VMware ESX and Virtual Infrastructure, Microsoft Hyper-V, and Citrix XenSource.
  • Virtual machine—Independent and isolated environment created by the virtualisation software. OSs can run VMs independent of each other.
  • Guest operating systems—The OSs installed on VMs. These run on the host OS. Virtualisation technology allows multiple VMs with heterogeneous guest OSs to run in isolation, side by side on the same physical machine. The VMs have their own virtual hardware (e.g., CPU, RAM, disks, network cards) on which the guest OSs and applications are loaded. The guest OSs perform consistently, irrespective of the physical components.

Benefits of Virtualisation

Virtualisation of IT systems has many advantages, which is why it has become so popular. Apart from improving IT service agility, virtualisation reduces the infrastructure cost of ownership by decreasing the total number of physical servers; therefore, operating expenses go down dramatically.

Virtualisation expedites the server provisioning procedure and also improves capacity management. IT efficiency is increased due to shared CPU processing capacity and effective storage utilisation. VMs are capable of running different OSs and have several benefits such as encapsulation, isolation and partitioning.

VMs are encapsulated into files, which make it possible to rapidly save, copy and provision the VM. Fully configured systems, applications, OSs and virtual hardware may be moved within seconds from one physical server to another, for zero-downtime maintenance and continuous workload consolidation.

VMs are completely isolated from the host machine and other VMs. If a VM crashes, all others are unaffected. Data do not leak across VMs, and applications can communicate over configured network connections only.

Virtualisation allows for partitioning multiple applications and supporting multiple OSs within a single physical system. Servers can be consolidated into VMs on either a scale-up or scale-out architecture, and computing resources can be treated as a uniform pool that is allocated to VMs in a controlled manner.

Other significant benefits of virtualisation include effective segregation of duties, simulation support with multiple versions of the same or different OSs, more continuity options and expansion of the test environment. Some big organisations have embraced virtualisation to increase business resiliency to support disaster recovery (DR) and business continuity.

From a security point of view, the advantages of virtualisation are:

  • Better forensic capabilities
  • Faster recovery after an attack
  • Safer and more effective patching
  • Better control over desktop resources
  • More cost-effective security devices

Security Risks in Virtual IT Systems

Even though they have many advantages, virtual IT systems are not risk-free or completely secure. Organisations need to take care of the security risks when using virtual IT systems. ‘Like their physical counterparts, most security vulnerabilities will be introduced through misconfiguration and mismanagement. Compromise of the virtualization foundation is a worst-case scenario’.1 According to Gartner, 60 percent of virtualized servers will be less secure than the physical servers they replaced through 2012.2

The security risks in virtual IT systems can be broadly classified into three types:

  1. Architectural vulnerability—The layer of abstraction between the physical hardware and the virtualised systems running the IT services is a potential target of attack. Just as the guest OS is subjected to the same security risks as a physical system, security measures (e.g., antivirus agents, spyware filters, IDs) should be installed on all VMs.

    Architectural vulnerabilities can be addressed in the following ways:
    • Vulnerability analysis—An architectural vulnerability analysis can be conducted by comparing current system attributes to a reference set that consists of valid system samples and noting the differences between the two sets. Immediate follow-up on the differences helps to make the architecture more robust and secure.
    • Regular updates of security features on VMs—All security measures should be kept up to date.
    • Proper patch management on VMs—VMs should be properly patched and monitored by the IT staff. Proper patch management should be performed regularly for all VMs including those in suspended or off status.
    • Implementation of network best practices—A VM or a group of VMs connected to the same network can be the target of network attacks from other VMs on the network. Network best practices should be applied to harden the network interfaces of the virtual machines. Network segmenting of VMs can be performed to mitigate the risks of various types of network attacks. The trust zones can be separated by using physical security devices.
  2. Software vulnerability—The most important software in a virtual IT system is the hypervisor. Any security vulnerability in the hypervisor software will put VMs at risk of failure. The following steps are necessary as precautionary measures against software vulnerabilities:
    • Prevention of single point of failure—The pervasive attribute of the hypervisor across all virtual hosts will be a cause of concern if a malicious code compromises one hypervisor instance. A single instance of replicating malware can rapidly exploit all hypervisors in the networked IT environment, thus causing a single point of failure.
    • Hypervisor updates—The hypervisor software should be regularly updated with available patches to get rid of security weaknesses.
    • Controlled access to VMs—Proper lockdown of privileges should be performed, and controlled access to virtual environments should be ensured to reduce code exploitation through malicious software.
    • Security of the host OS—The virtualisation layer resides on the host OS, so the utmost care should be taken to ensure that the host OS is not compromised by virus attacks.
    • Organisational policy for VM security—A policy-based security model for hypervisors and the host OS should be applied from an organisational level.
  3. Configuration risks—Due to the ease of cloning and copying images, a new infrastructure can be deployed very easily in a virtual environment. This introduces configuration drift; as a result, controlling and accounting for the rapidly deployed environments becomes a critical task.

    Configuration risks can be mitigated with the help of the following steps:
    • Configuration assessment—A periodic configuration assessment should be performed to achieve a known and trusted state of the virtual environment.
    • Hypervisor configuration checks—The integrity of the hypervisor configuration should be checked periodically to mitigate risk and to increase operational efficiency of the virtual IT system.
    • Authorisation and proper documentation of change— Changes to the VMs can be done instantly per need, but all such changes should be authorised and properly documented. Undetected and unauthorised changes to the VM configuration can introduce security breaches and can make the system noncompliant to organisational and regulatory standards.
    • Configuration audit and control—Implementing a proper configuration audit and control solution to the VMs can ensure environmental stability and prevent unexpected threats to the virtual IT system and the business. Configuration risks can be mitigated by regularly checking the configuration of components against defined standards.
    • Approved templates for VM deployments—There should be templates for VM deployments, and any change to the standards should be studied and approved before implementation.
    • Event monitoring—All events on VMs should be monitored using server host logs. Active-state monitoring of configuration changes to hosts, VMs, clusters, resource pools, data stores and virtual networks should be implemented.
    • Configuration management database (CMDB)—A CMDB should be maintained with the proper description of the infrastructure. The CMDB should have information about the location of the images of suspended VMs and the physical-to-virtual mapping.

Security of Virtual IT Systems—Organisational Responsibility

Establishing policies and procedures for virtual IT systems is the responsibility of the organisation. When a process is being defined for VM deployment, IT managers need to work with business managers to identify the steps and time frame. By comparing system configurations with a well-defined security policy based on the benchmarks proposed by the Center for Internet Security (CIS) and the US Defense Information Systems Agency (DISA), the IT team can be assured that new deployments adhere to the organisation’s best practices. Ensuring that only approved configuration changes are implemented as part of a well-engineered process can minimise risks related to changes in a virtual environment.

The roles and responsibilities in a virtual IT environment should be clearly defined and documented. Even system administrators should not have more access authority than is necessary. Proper virtualisation management requires a deployment process to ensure that the new VMs meet the organisation’s standards. Licence agreements and policies should be regularly updated for regulatory compliance. Training the staff on virtualisation technology and security features in a virtual IT system is the responsibility of the organisation.

For the recovery of important information and virtual IT systems, organisational-level initiatives are required to establish data protection policies. Disaster recovery and backup policies should be clearly defined and should mention critical factors such as acceptable data loss, acceptable downtime, guest-level backups and host-level backups. If the host computer is compromised, it can provide direct access to all VMs on the server. An intruder can reconfigure, move and copy the VMs, putting sensitive data at risk. If any malware intrudes the virtualisation layer, it can gain access to all VMs on the host computer, including the production VMs, causing increased security risk.

The existing security policies for the physical IT system cannot be copied blindly for the virtual IT framework. The technical team should work with the functional team to map the existing security policies to the virtual IT system. An internal audit program should be developed, specifically for the virtual IT system. Proper security information management should be set up to secure the virtualised system. While drafting security policies, special attention should be given to secure the management console, VM operating system, VM networks, VM kernel, VM server traffic, VM kernel traffic, VM backup, VM data and VM deployment. Management should provide directives for preventive and detective measures via well-defined monitoring and auditing policies and their execution with proper follow-up action.

Audit of Virtual IT Systems

Virtualisation is different from working with IT systems that use physical servers. The IT auditor needs to know every aspect of VM technology and the risks associated with VMs. To perform a successful audit of a virtual IT system, the information security auditor should have an adequate understanding of the VM infrastructure, access points, used and unused ports, embedded or overlaid controls, and server partitions.

The IT auditor should assess the business need for moving from physical to virtual and whether doing so would provide any real benefit to the organisation. The principles, best practices and audit approach that are used for auditing a physical IT system should be used during the audit of virtual systems, along with the technology-specific audit points for virtualisation. While auditing a virtual IT system, the information security auditor should evaluate the precautionary measures that have been put in place based on situational awareness and the validity of these measures. There should not be any security policy shortcomings, and the policies and procedures should be backed by proper authentication, authorisation and accounting procedures to mitigate any risk associated with the virtual IT system. Both physical and logical access controls should be enforced by the organisation, and the auditor should check the validity of all the controls.

The management console is required to be secured by tight access controls and should be locked down to specific users only. Logical access controls such as application security and segregation of duties should be applied for all levels of users.

The information security auditor should evaluate the process of creation, deployment and change management of the VMs. The security of the hypervisor is of the utmost importance; therefore, the auditor should evaluate all security measures enforced by the organisation for hypervisor security. An important point of consideration is the state of VMs. As VMs can be in three states—on, off or suspended—the auditor should check for any security negligence in VMs that are in off or suspended states. The auditor should study the virtual configuration standards and the configuration control procedures adopted by the organisation for maintaining virtual systems. Any discrepancy in the standards or control procedures should be considered a material weakness and should be reported to management for rectification.

An organisation relying on a virtual IT system should have a proper support system in times of production server failure or disaster. The auditor should check the DR plan for the virtual IT system and should evaluate the test results. The auditor needs to evaluate the sufficiency of existing controls, such as firewalls, intrusion detection systems, intrusion prevention systems and network port security, so that the virtual system does not fall prey to external malicious attacks. The information security auditor should be aware of the best practices in VMs, specifically the benchmarks proposed by CIS and DISA. Based on the unique aspects of VM technology, the information security auditor should gather evidence and assurance of the controls in a virtual IT system.

Audit Points for the Security of Virtual IT Systems

This section provides guidelines for auditing virtual IT systems and can be used as a reference. The guidelines consist of the significant audit points relevant to virtual IT systems— as mentioned in the benchmarks and best practices proposed by CIS, DISA and virtualisation product vendor VMware.

Purpose of Moving From Physical to Virtual
1. Is there a business need for moving from physical to virtual?
2. Does the virtual IT system impact Payment Card Industry Data Security Standard (PCI DSS) and other compliance requirements?
3. Are business goals met by utilising virtualisation?

Risk Assessment
4. Is there sufficient expertise to support the new environment?
5. Has there been sufficient training of the team for working and maintaining the virtual environment?
6. Are the operational procedures regularly updated?
7. Is there a single point of failure?
8. Are the security zones separated or combined?
9. How are the IT resources separated and aggregated in the VM environment?
10. How is the VM environment security managed?
11. Is there administrative access to the host machine?
12. Does the management console have tight access controls, locked down to specific users and specific partitions or machines?

Understanding the Infrastructure and the Controls
13. Are the partitions on different OSs?
14. Are the partitions on a single server or across servers?
15. What partitions exist—for which environments on which boxes (i.e., a network map)?
16. Are there controls over each partition, similar to those expected for a server?
17. Are there controls for specific users that limit access and read/write capabilities?
18. Does a standard naming convention exist for server, partition and library/folder names?
19. What controls are in place for deploying multiple copies of software?

Network Map of the VM Environment
20. Where are the following types of systems located?
  – Systems development
  – Systems testing
  – Production systems
  – Business unit servers
21. Are the virtual environments separated by sensitivity?

Evaluation of Policies, Procedures and Documentation
22. Evaluate the standards prepared by the organisation for system and security administration of the virtual IT systems.
23. Evaluate the procedure of creating, deploying, managing and making changes to virtual machines.
24. Evaluate the lock-down and hardening policies.
25. Evaluate the completeness and accuracy of VM documentation.

Evaluation of Controls
26. Do the documents for change control refer to the correct partition on the correct server?
27. Evaluate backup capabilities.
28. Evaluate DR options.
29. Are the software licences up to date?
30. Evaluate contracts and vendor licence options.
31. How frequently are the security audits performed?
32. Evaluate the third-party solutions being used to enhance the security of the virtual environment and their compatibility with the virtual IT system.
33. Evaluate the control standards prepared by the organisation for the virtual IT systems.
34. Are there appropriate resource usage and cost allocations amongst applications across a shared infrastructure?
35. Is there image sprawl/virtual sprawl due to system mismanagement?
36. Does the system have orphaned images?
37. Is there a provision for hypervisor security?
38. Evaluate the business continuity and capacity management strategies for the virtual IT systems.
39. Evaluate the existing configuration management infrastructure to determine the scalability and efficiency of the virtual IT system.
40. Evaluate the patch management procedure of the VMs.
41. Do the VMs have any services such as desktop clocks or screensavers (downloaded from unknown sources) installed on them?
42. Is there any software without a defined business need?
43. Is the system locked down to eliminate unnecessary services?
44. Are the host firewalls capable of detecting intrusions?
45. Is there a procedure for periodic malware analysis?
46. Is the physical host used for other purposes?
47. Is there a provision to monitor the physical host with host-based intrusion detection software, such as a file-integrity checker?
48. Is there a provision to periodically re-image the physical host using cloning software?
49. Are there any security shortcomings of the existing virtual IT system?
50. What compensating controls have been applied for the virtual IT system?
51. Evaluate the deployment procedure in practice for virtual IT systems.
52. Evaluate the management, operational and technical controls in practice for the virtual IT systems, and evaluate whether there are any loopholes.
53. Are policies and procedures for virtual IT systems updated periodically?
54. Evaluate the hardware requirements, and plan for additional processing power and memory to cover the VM platform overhead to identify the threshold limits of the virtual IT systems.
55. Evaluate the boot-time disk requirements so that most critical VMs are loaded first.
56. Does each VM have its own dedicated physical disk?
57. Is physical access to the host hardware and OS limited, as required?
58. Is there a provision to prevent file stealing using external media (e.g., floppy, CD/DVDRW, USB/flash drives)?
59. Is there a provision to capture traffic coming into or out of the network interfaces?
60. Is there a provision to secure access to the room(s) that houses the physical machines?
61. Is there a provision to lock the hard drive cases to prevent removal of the hard drives?
62. Is there a provision for booting from any device except the primary hard drive?
63. Is the basic input/output system (BIOS) password protected so that the boot choice cannot be changed?
64. Is there a provision to control all external ports through host- and guest-system configuration or third-party applications?
65. Is the base OS hardened against security vulnerability?
66. Does the host have only as many accounts as needed to manage the VMs?
67. Is there a password management policy so that passwords are long, hard to guess, changed frequently and provided only to staff that must have access?
68. Does the host have any network accessible services?
69. Is there a policy to authenticate the services that need to run and to disable, or to remove entirely, unneeded programs and services?
70. Is the host patched regularly?
71. Are the patches destined for the host first tested on a non-production test machine before being applied to production systems?
72. Are the VMs configured properly so that no single VM can monopolise the resources on the system?

Network Security
73. Is there a provision to establish a firewall for the VM layer service ports?
74. Is there a provision to permit remote access to the host or hypervisor?
75. Is a physically separated administrative infrastructure used for management functions, such as creating new VMs or changing existing images?

Encryption for Communication
76. Is there a provision for encryption to secure communications?
77. Does the organisation use Secured Hypertext Transmission Protocol (HTTPS), Transport Layer Security (TLS), Secure Shell (SSH) or encrypted virtual private networks (VPNs) from guest to host or from management devices to hosts?
78. Are there management-approved initiatives to prevent spoofed source address attacks, connection hijacking, route hijacking and man-in-the-middle attacks?

Logical Access Controls
79. Is there a provision for logical access controls on the virtualisation servers?

Services and Configuration
80. For limited resource hosts, is there a provision to run low-priority tasks during off-hours or when the system is idle?
81. Are features such as screen savers and defragmenters disabled on the virtual desktops?

File Sharing Between Host and Guests
82. Do the VM environments support file sharing amongst host and guests, and if so, is that justified by a business need?

Time Synchronisation
83. Is there VM clock drift?

Disconnecting Unused Devices
84. Are all unused devices disconnected from the VM?

Remote Management Approaches
85. Are remote management tools encrypted and authenticated?

Patching and Vulnerabilities
86. Are the guest and host OSs maintaining the latest security patches?
87. Are the patches tested before being applied to a production environment?

Logs
88. Is the host configured to log changes to the VMs including incidents of copying, moving or deleting from the host?

Backups
89. Are image backups taken for all VMs?
90. Is the data stream of the backup encrypted to prevent theft of the server image?

Security From External Modification
91. Is the hypervisor secured from unauthorised modification?
92. Is the VM secured from unauthorised modification?

Denial of Service (DoS)
93. Is there a provision for preventing a DoS attack?
94. How is network traffic on a VM authenticated?

Miscellaneous
95. Are all VMs in power states of suspend or off configured with up-to-date antivirus software and signatures?
96. Are all off and suspended guest VMs configured with the latest patches and updates for the guest OS?
97. Are all necessary permissions configured on the configuration files and virtual disk files for all VMs?
98. Is all network traffic managed on a dedicated virtual local area network (VLAN) or network segment? Are the service console and VMs configured on separate VLANs or network segments?
99. Are all port groups configured with a network label that identifies the port group function?
100. Have all unused port groups been removed?
101. Have log file permissions been configured to restrict unauthorised users?
102. Are all logs sent to a syslog server?
103. Are server vendor security, patches and update notifications subscribed regularly?
104. Has the server software version been configured with the latest patches and updates?
105. Are all server updates tested in a development environment before being installed on the production servers?
106. Are all VMs and third-party applications in use documented?
107. Does the organisation have procedures for the backup and recovery of all servers and VMs?
108. Does the disaster recovery plan include all VM servers, VMs and necessary peripherals associated with the system?
109. Are the backup files stored on a separate logical partition so that restoration is possible in case of hardware failures on the production physical servers?
110. Are VM CPU and memory configured with a minimum CPU cycle time to guarantee that the VM is available for use?
111. Is there a provision to notify the virtualisation system administrator if VM CPU or memory usage exceeds 90 percent?
112. Do only authorised users have access to specific actions on the VM, and are the names/profiles of authorised users properly documented for ready reference?
113. Does the administrator change or modify the VM’s default permissions and attributes without authorised approval?
114. Is a documented configuration management (CM) process utilised for all VM additions, changes or deletions of users, groups, roles and permissions?
115. Is the baseline configuration documented for all VMs, users, groups, permissions and roles?
116. Are all VM user, group, permission and role changes logged for review/tracking?
117. Are VM logs reviewed on a daily basis for suspicious/ unusual activity?
118. Is the VM server configured in lockdown mode to disable all remote root access?
119. Are all documents of the virtualisation infrastructure up to date?
120. Is all access to OS images restricted to authorised users only?
121. Are all master templates stored on a separate partition?
122. Are all master templates restricted to authorised users only?
123. Is there a policy in place to identify and assign VMs to the appropriate personnel?
124. Have clipboard capabilities (copy and paste) and drag-and-drop capabilities been disabled for all VMs?
125. Have all VMs been time synchronised by an authoritative time server?
126. Is there a change control board to document and approve all production VM renames?
127. Are all test and development VMs logically separated from production VMs?
128. Is there a policy in place to restrict copying or sharing VM files over networks and removable media?
129. Are all VM moves from one physical server to another logged regularly?
130. Are all VM moves to removable media (e.g., DVD, CD, USB drives) documented?
131. Are VMs removed from the site only if approved and documented?
132. Are all production VMs kept in a controlled access area?
133. Are VM rollbacks performed only when the VM is disconnected from the network?
134. Are all virtual machine OS log files saved for auditing purposes before any VM rollback occurs?
135. Are all VM log files configured with a maximum size limit (500 kilobyte [KB] is the recommended size)?
136. Are all VM log files archived for a minimum of one year?
137. Is the backup of all VMs done in accordance with the Media Access Control (MAC) level of the VM?
138. Are all VMs properly registered in the vulnerability management system (VMS)?
139. Are the VM requirements documented before creating VMs within the virtualisation server environment?
140. Are unused hardware on VMs either removed or disabled?
141. Is the host OS compatible with the VM’s guest OS selection?

Conclusion

The pace at which virtualisation technology is being embraced by organisations can be a cause of concern if robust security features are not applied to the virtual IT systems. A Gartner study indicates that by 2012, almost 50 percent of servers will be virtualised throughout the world.3 To make virtual IT environments more secure and robust, adequate knowledge of virtualisation technology is mandatory for the installation and audit of virtual systems. Basic audit techniques coupled with proper control over the unique aspects of virtualisation technology can help mitigate the security risks of virtual IT systems. The audit guideline provided can assist in identifying and fixing the weaknesses of virtual IT systems and can help improve the operational efficiency of VMs so that organisations benefit from virtualisation technology.

References

Endnotes

1 SANS, www.sans.org/thought-leaders/kim_thought_leader
2 Gartner Inc., ‘Gartner Says 60 percent of Virtualized Servers…’, press release, March 2010
3 Baker, Adrienne; ‘Gartner: Top Virtualization Security Risks and How to Combat Them’, Information Management, www.information-management.com/news/virtualization_security_risks-10017445-1.html

Abhik Chaudhuri, MCA, PMP
is an IBM-accredited senior IT specialist with experience as an IT security administrator and project manager. He can be reached at abhik.chaudhuri@gmail.com.

SH (Basie) von Solms
is a research professor at the Academy for Information Technology at the University of Johannesburg, South Africa. He specialises in research and consultancy in the area of information security and has acted as an information security consultant for the last 15 years. He also is a fellow of the Computer Society of South Africa and of the British Computer Society.

Dipanwita Chaudhuri, ACA (ICAI), MIIA
is manager of the management consultancy services at a reputed Chartered Accountants (CAs) firm in Kolkata, India, and is a registered consultant with Asian Development Bank. She can be reached at banerjee.dipanwita@gmail.com.


Enjoying this article? To read the most current ISACA® Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2011 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.