Chapter 1: What Is a Security Threat?

Before we can begin our discourse on virtualization security, we need to first understand a few common terms and ideas. Specifically, we need to know how the virtual infrastructure fits into the entire picture of the data center, the virtual ecosystem, or as we will use within this book, virtual environment. We will define the boundaries of the virtual environment and how it changes the data center from a 10,000 foot view. In addition to this basic definition, we need to specifically define threat, vulnerability, and failure in terms of virtualization security. These key terms will be used throughout this book, and many definitions exist for each one. We will create specific definitions and follow up with some common examples that professional penetration testers use. It is also important to understand how the virtual environment can possibly be attacked, as well as the source for the threats. There are many Web sites and books mentioned within Appendix D for further reading on penetration testing.

The following chapters will present the threats in such a way that you can manage the risk within your virtual environments. Wherever possible, the risks will be followed by possible ways to mitigate them. Unfortunately this book cannot address all possible risks, so we are covering only those areas previously mentioned in the preface with as much information as possible so that the reader can extrapolate future threats as well as determine places to monitor on the Web to uncover new vulnerabilities and learn how to protect against them.

Because this and the following chapters will be presenting security issues, it may seem at times that I and my contributing authors are just a little bit paranoid. Okay, perhaps quite a bit paranoid; however, a healthy dose of paranoia will aid you in risk analysis and consideration of all the possibly outcomes of breaches to your virtual environment. If you dislike the term paranoid, I would substitute security conscious, because that is the main thrust of this and other chapters: to raise your awareness of all the myriad threats. The following chapters provide concrete suggestions that those looking for security solutions can implement and contribute to their virtualization success.

Although this chapter deals with the entire virtual environment per Figure P.1 from the preface, starting with Chapter 3, “Understanding VMware Virtual Infrastructure Security,” each chapter addresses a subset of the entire environment.

The 10,000 Foot View without Virtualization

We can describe the security model for existing systems by using the following list of elements or aspects of security. Each element is generally performed by different groups of people, each using different methods, protocols, and documentation to enact or assure their separate aspects of security. Corporations may have one document to handle security, but different organizations end up implementing different bits of it with exceptions specific to their group, organization, and business unit. This all starts with a written security policy that covers every aspect of security from physical to virtualization security. The security policy not only defines security roles but also how to respond to specific physical and virtual threats. Sometimes these documents have teeth (as in someone’s job is on the line) and other times they do not. But, in general, they all cover or should cover the following physical threats:

Information classification, definitions, and document-marking strategies
Disposal of confidential and other documents
Physical threats to the building or campus, such as bomb and biochemical threats
Response to fires and medical emergencies
Monitoring of entrance ways, parking garages, and so on
Monitoring of entrance to and from secured areas
Response to cyber attacks and generally a statement on the protections to use

In addition to the preceding list, the security policy covers many more security threats and concerns, as well as the preventative steps to protect the entity (organizations, businesses, and enterprises) from any known issues. Although the security policy is important, implementation is imperative. Key is the implementation of the security policy and the documentation of these steps. When we look at just the data center, the following steps are usually taken:

Secure the Data Center.
Securing the datacenter entails the use of physical controls and monitoring tools to monitor access (card keys, video camera), power provisioning and control, cooling, and change control protocols.
Secure the Network.
Securing the network implies a secure network architecture that includes at least the use of firewalls, routers, gateways, intrusion detection and prevention systems, and perhaps compliance auditing and monitoring systems.
Secure the Servers.
Securing a server entails securing the server operating system with improved authentication, logging, and hardening. This step also includes most vulnerability prevention tools, such as antivirus, spyware/malware detectors, spam filters, some firewalls, and worm protection mechanisms. This step could include the placement of the server within the data center, perhaps behind further physical aspects of security such as doors, keyboard monitoring, card key access, removal of unused software, and the like.
Secure the Application.
Securing the application entails application integration into authentication tools, application hardening, compartmentalizing, and other secure coding tools as well as regular patching and updates to the application.
Secure the User.
Securing the user entails knowing more about the user for authentication, tracking, and monitoring. This is not only a password (what the user knows), but perhaps a retinal or fingerprint scan (what the user is), and other tools such as common access cards (CAC) and RSA Keys (what the user has). User training to spot social engineering and other security concepts is also important.

If we are lucky, security of data centers, networks, servers, applications, and users are part of a single organization and everything is integrated fully and not disjointed. However, this model changes when virtualization is introduced. Virtualization adds complexity, changes points of control, and introduces new security problems and threats.

The 10,000 Foot View with Virtualization

The security model for virtualization systems can be described using the following list of definitions; these differ from the steps in the previous section in that generally only the virtualization administrator is involved after the physical aspects of security are covered. The virtualization administrator is most likely not a security administrator and should work with the security administrators to properly secure the system. Each of the following steps adds to the previously described steps within “The 10,000 Foot View without Virtualization” section.

Secure the Data Center.
Securing the data center additionally entails ensuring that the physical console has some means to monitor the virtualization server for system crashes via either a dedicated monitor or some form of remote means. This is the only means by which to access crash data. Note that when a virtualization host crashes, all the virtual machines running within the virtualization host crash.
Secure the Virtualization Server.
Securing the virtualization server entails server hardening, setting up monitoring and auditing, and proper authentication protections. In effect, the virtualization server should be considered a data center within a data center. Protect the virtualization server as well as you would your data center.
Secure the Virtual Network.
Securing the virtual network entails creating a secure virtual network architecture that works hand in hand with the physical network security. Included in this is the possibility of intrusion detection and prevention systems, virtual machine vulnerability management tools, or even virtual network compliancy auditing tools. The virtual network includes all networking for virtual machines (including the use of virtual firewalls and other protections mechanisms), virtualization server administration, virtual machine migration, and access to storage devices.
Secure the Physical Network.
Securing the physical network entails a secure architecture per normal means described previously. The interfaces to the virtual network should be further secured, including storage interfaces by using firewalls and network segregation.
Secure the Virtual Machine.
Securing the virtual machine is important to ensure that the virtualization layer is not exposed to attack. This is in addition to the normal steps taken under “Secure the Servers” in the previous list within the section “The 10,000 Foot View without Virtualization.”
Secure the Application.
Securing the application entails ensuring that the application does not expose the virtualization layer to performance and other issues. For example, running full disk antivirus scans simultaneously on all virtual machines would create a performance problem.
Secure the User.
Securing the user additionally entails restricting access to virtualization servers and direct console access to virtual machines while maintaining all authentication protocols.

The 10,000 foot view of virtualization introduces new elements and aspects of security, as stated previously. These are generally handled by the new role called the Virtualization Administrator and are separate from the total security picture. Most corporate security documents and protocols are just now starting to consider virtualization servers, as they deal with the increase in virtual machines. But looking at security only from a virtual machine perspective is a bit narrow.

A comprehensive security architecture is required that will include all the aspects of virtualization, as well as the traditional physical roles. Security architects, administrators, and managers now have to deal with the virtualization server. What is needed is education of the security architect, designer, and manager so that a comprehensive view of security exists whether virtualization is used or not. The old methods are not completely applicable, and new ones must be developed. Those new security concerns and protection methodologies are what this book delves into.

Applying Virtualization Security

The two 10,000 foot views look at the data center from two distinct views: the old school and the new school. Figure 1.1 shows the clear demarcation between the two schools. After your network passes into the realm of the virtual infrastructure represented by the thick polygon, you need to combine security approaches to secure the entire environment.

Figure 1.1
Where the Virtual Infrastructure touches the physical world

The content of the outer, thick-lined demarcation in Figure 1.1 includes some aspects of the physical world, the cables that go between the systems, the separate servers used to manage the environment, and the remote storage used. The rest of the environment falls into the realm of securing the virtual infrastructure. The demarcation bisects the IDS/IPS Server, among others, and that is on purpose, because you need to understand that a physical IDS/IPS may not work within the environment unless it is placed appropriately on an interface into the virtual infrastructure. It is also interesting to note that you may have multiple IDS/IPS systems involved in that particular aspect of security. The other bisections relate to systems that can serve multiple duties and may act upon systems outside the virtual environment as well as within the virtual environment.

The big issue with implementing virtualization security is that there may appear to be duplication of effort from the physical world. So why not just apply what you normally do for the physical machines to the virtual machines? Unfortunately, this cannot be done yet—not until there are changes to the virtualization servers in use. Specifically, many of the BIOS security measures and much of the security hardware in use today cannot be applied to a virtual machine, whereas any hardening technique that can be applied to the OS within the physical machine can be applied to the guest OS within the virtual machine. Therefore, we have to apply security in two distinct and different environments. The VMsafe and vNetwork APIs (covered in Chapter 3) will do quite a bit to alleviate these problems when used with VMware vSphere4.0. In essence, what used to require a physical element may now require a software element.

The main point to take from this is that the virtual infrastructure is a data center within your physical data center. With the advent of even more powerful laptops, your virtual infrastructure may become mobile, which implies a limited but mobile data center. This was an almost unheard of concept in the past, yet now it is possible.

This is why securing the virtualization server figures so prominently within the new structure of the data center. While you apply your physical security to determine who has accessed the data center, including thermal sensors and video cameras, you need to also apply instrumentation to the virtual infrastructure.

Virtualization Security Consideration- If the virtualization server is insecure, can the entire virtual infrastructure be secure?

After the virtualization server is secure, designing a secure virtual network is required. This differs from the physical network in that wires do not need to be run, and everything needs to be done within software. This is where most networking security specialists stop considering the problem of securing the network. They consider everything on the other side of the wire to be secure, so everything must be secure.

TCP Vulnerability - In 1996 14,000,000 computers were connected to the Internet. On September 1, Phrack (e-zine) published a network attack tool. Now 14 million computers were at risk. Within days various companies were attacked, with horrible results. By the time an effective defense was implemented, tens of thousands of systems were affected.

This was the first widespread DoS attack.

How was this possible? Next we’ll look at the flow of TCP data as described in Figure 1.2.

Figure 1.2
TCP session startup

Source requests communication by sending a SYN request to dest.

Destination responds, accepting the communication, sending a SYN ACK packet to source.

Source acknowledges with an ACK packet.

The session starts.

Notice that the startup sequence does not require authentication. This simple fact, which is by design, is what allowed the attack to be successful. The attacker continually sent SYN requests without waiting for the SYN ACK; this is not a code fault, but poor architecture.¹ This attack was similar to dialing a phone number, hanging up, then redialing a phone back. In effect, it would tie up the phone line until the phone could disconnect from the line. The other major failing of the normal TCP packet is that it is unencrypted, which means that the startup is a clear text protocol and is easily intercepted. Last, this vulnerability demonstrates an issue created when someone, usually a hacker, does something unexpected.

Given that TCP, the normal networking mechanism, is inherently insecure (see the sidebar “TCP Vulnerability”) should the network security aspect of virtualization end at the interface to the physical network? Should not there be further security constraints on the virtual network?

Virtualization Security Consideration- The security of the entire network depends on the security of the virtual network plus the physical network.

After the virtual network is secure (covered in Chapter 9, “Virtual Networking Security,” we turn our view to the virtual machines (VM) to run within the virtualization server. The main concern here is to not expose more than we have to in order to achieve security. The end users, and therefore hackers, should not even know that the system they are accessing is a virtual machine. Everything should behave as expected. But because it is a virtual machine—and as of yet, there is no way to hide this fact—the virtual machine should protect against data leakage about the virtual environment. This is governed by what the VM accesses and not necessarily where it is running. The operating system running within the VM has its own security hardening considerations, and that still needs to be applied. This is separate from the hardening virtualization environment and should be done as part of service design. This is covered further in Chapter 8, “Virtual Machines and Security.”

Virtualization Security Consideration- The Virtual Machine is only as secure as the guest operating system running within it. Adding virtualization does not add security.

Now we come to the next level of security, securing the application or applications. This additional layer of security should not impact the virtualization host. Included in this layer are additional logging, spyware, and antivirus scanners that are accessed from within applications. Other classes of spyware and antivirus scanners work in a standalone fashion. They are geared toward protecting the guest operating system as a whole, not just the data pulled into one application. Consider that more than one VM within the virtual environment may be doing the exact same action at the same time. Any major disk IO can affect a virtualization server adversely, so your security measures need to be considered as a whole, looking at the entire virtual infrastructure and not just a VM, which is covered in Chapter 7, “Operations and Security.”

Virtualization Security Consideration- Application and operational security should consider the entire virtual infrastructure and not just the individual virtual machine.

Last, the user must be secured, but because the virtual machine does not have direct access to hardware, a true two-layer authentication scheme may not be possible. Given this, we must consider where and how authentication takes place.

Virtualization Security Consideration- VMs do not have direct access to hardware, so some two-factor authentication schemes may not be applicable.

Definitions

Now that we know the additions to the previrtualization security thinking of security, we need to define security fault, threat, and vulnerability. Virtualization may also change how we think of confidentiality, availability, and integrity. Before we define them, we’ll look at the results of each. The consequences could imply any or all of the following:

Failure of a virtual machine
Failure of a specific service
Failure to access the attached network
Failure to reach storage or even a failure in the storage fabric in use
Failure of the virtualization server
Increased information leakage
Loss of data
Loss of revenue
Imprisonment
Identity theft
Loss of jobs (specifically your own)

This list, although not complete, does bring to light some serious consequences of security faults, threats, and vulnerabilities. Today we hear about loss of data to criminals all the time in the news. You really do not want that to happen to your company or entity.

So what are the definitions? First, we start with the term threat.

Threat

A security threat is a theoretical happening that may not occur but should be considered as part of your virtualization security architecture and design. For example, the threat always exists that your systems will become the target of a denial of service attack. A threat may or may not have a method to mitigate the possibility of attack. Within virtualization security is a constant threat of information leakage about the virtual environment. Information leakage is defined as the information an unprivileged user can see or access that the user should not be able to view or otherwise access. Information leakage could potentially lead to discovering otherwise classified or important information about the security, configuration, use, or any other information about the host in question. This information can also possibly be used to craft attacks specific to the host.

Vulnerability

A security vulnerability is either an implementation, design, or architecture failure by which a hacker may cause a system to crash or hang, gain access to private data, or use as a way to gain further access into the virtual network. Unlike a threat, which is theoretical, a vulnerability exists, and so do the exploits, yet a fix may or may not exist. This implies a real possibility of vulnerability exploitation. In the case of TCP version 4, no fix exists to solve this basic problem because it is architectural, but there are ways to mitigate attacks.

Fault

A security fault is a threat or vulnerability that has been exploited; the system has either been successfully attacked, a security subsystem has been bypassed, or your mitigation steps have come into play. This is also the time to apply digital forensics to determine the cause of the fault. Other people consider this to be a defect, incident, or compromise.

The Beginning of the Journey

Now that we have defined the extent of the virtual infrastructure, the additional security steps needed to implement virtualization security, and have defined our terms, we are ready to dive into the world of virtualization security. In the next chapter, we discuss specific threats and vulnerabilities to the virtual infrastructure as determined by the application of the science of penetration testing. But before we do that, we should discuss how this affects your security policy. The security policy, as stated previously in this chapter, is the document that points to other documents that hold all the information about the security, physical and virtual; the deterrents and penalties with respect to mitigating security threats and vulnerabilities; and the actions to take place after a security fault. Given this, it is logical to assume that the security policy is affected by virtualization security and that the security policy should further direct virtualization security configuration and usage.

Before beginning your journey into virtualization security, give your security policy a very good read through. Determine if things come to the fore that need to be changed to be able to run virtualization servers, or that need to be changed to mitigate already known problems. Some examples of security policies statements that affect the implementation of a secure virtualization server include the following:

“No multihomed machines are allowed.” Then you cannot even start a virtualization server, because they are intrinsically multihomed. Best practices for implementation, regardless of security level, dictate that several physical NICs be placed in use. Each NIC is assigned to different networks, and that is by default a multihomed system.
“All servers must pass a specific assessment.” The assessment may not be designed specifically for the virtual infrastructure, and the virtual infrastructure will not pass the assessment. All assessment tools must be specifically designed for the virtual infrastructure.
“Full antivirus checks will be made on every system at 1AM every night.” You will also be in trouble because you will need to violate the security policy to disable antivirus scanning on virtualization servers, because the results will be a multitude of false positives, serious disk IO issues that will lead to another multitude of errors, and possibly even failed machines.

This list presents just three examples on how a security policy can affect the virtual infrastructure. These are very detailed items, but they can be made quite general, as well. For example, the policy could just state “virus scanning will be performed” in a high-level document but leave the details to be outlined in a subsequent document. Please reread your security policy documents and start jotting down notes as to what needs to change in order for the virtual infrastructure to be used and implemented. Start your first document on virtualization security as it applies to your company or entity.

Footnote

Mark G. Graff, Kenneth R. Van Wyk. Secure Coding: Principles and Practices. Sebastopol, CA. O'Reilly Media, Inc., 2003.

Skip Links

Chapter 1: What Is a Security Threat?

Excerpt from 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment'

The 10,000 Foot View without Virtualization

The 10,000 Foot View with Virtualization

Applying Virtualization Security