Chapter 1: What Is a Security Threat?

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

1 2 Page 2
Page 2 of 2

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

  1. Source requests communication by sending a SYN request to dest.

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

  3. Source acknowledges with an ACK packet.

  4. 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.1 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

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

© Copyright Pearson Education. All rights reserved.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
1 2 Page 2
Page 2 of 2
Take IDG’s 2020 IT Salary Survey: You’ll provide important data and have a chance to win $500.