The most elegant solutions are the ones that take complicated

Transcription

1 ISSA PREEMINENT TRUSTED GLOBAL INFORMATION SECURITY COMMUNITY Virtualization - The Missing Element of the Cloud By Tom McAndrew and Mike McGee ISSA members, Puget Sound, USA Chapter This article discusses six major challenges of virtual environments and provides tips on how to protect and secure a virtual infrastructure. Abstract Virtualization is the critical element which enables cloud computing. This article discusses six major challenges of virtual environments and provides tips on how to protect and secure a virtual infrastructure. The most elegant solutions are the ones that take complicated subjects and break them down into basic rules and elements that anyone can understand. For example, Physics is the science that attempts to understand and explain how the world around us works. There are fundamental rules that explain energy (E=mc 2 ), force (F=MA), and the basic building blocks of all matter (atoms). The complexities of the world could be broken down into simple concepts that almost anyone can grasp. A simple core set of rules and definitions that are broadly adopted ensure consistency and evolution in the scientific community. This same scientific approach is currently being taken in cloud computing today. We are defining the basic rules and fundamental elements of cloud computing. Some have taken very scientific approaches in defining the cloud, and others have taken a more practical approach built on business uses. For example, one way to define the cloud is by identifying one of the four ways it is deployed (in a private data center, public data center, community data center, or hybrid model). Another is to define it by the type of service that is offered; Infrastructure as a service (IaaS), Software as a Service (Saas), or Platform as a Service (PaaS). Yet another way is to define essential characteristics of cloud services (elasticity, on demand, etc.). All of these are each appropriate ways of getting the information security community to speak in a common language. However, there is relatively very little around the explanation of the three common building blocks of all cloud environments. Just as an atom is made of three basic elements (electrons, protons, and neutrons), cloud environments consistent of three basic elements: hardware, software, and virtualized components (HSV). Despite all the marketing hype about data living in the cloud, you can be assured that your data is living right here on earth on a piece of hardware, software, or a virtual component. So if all clouds are made up of fundamental elements, how do we go about assessing the risk for these environments and ensuring that they are secure? The good news is that we have already been practicing how to secure hardware and software for several years. We are still improving our processes, but there is a lot of guidance out there on business continuity, software development, secure coding, etc. However, when it comes to the world of virtual components, we have only a handful of generally accepted security practices. Without having generally accepted practices around virtualization, we are missing one of the three fundamental elements of all clouds. This lack of guidance has evolved primarily be of the vendor neutral approaches of the virtualization papers and industry guidance. Most organizations that publish cloud guidance are careful to ensure that they are not endorsing or highlighting any particular product. They also want to ensure that their guidance is relevant and not outdated by the time it get published. They shy away from the strengths and weaknesses of different virtual environments and security considerations and tend to focus on the big picture. For example, one of the leading industry papers on cloud in the United States is the National Institute for Standards and Technology (NIST) special publication , Draft Guidelines on Security and Privacy in Public Cloud Computing. Throughout the 38-page body of the document there is not a single chapter, paragraph, or sentence that speaks to the unique risks of different virtual environments from different vendors. By attempting to be vendor neutral, NIST has omitted the most critical guidance 25

2 for IT security experts seeking standardization what to do with the virtual platforms. They published another document, SP , around virtualization, but Microsoft is mentioned only once, and VMware is not any where at all. But for those of us on the ground, we have to face the reality that most cloud environments are built on well-known virtualization IT security is great because no one knows everything, but anyone can have an opinion. products (VMware, Microsoft Hyper- V, Xen, Citrix, Parallels, etc.). These vendors make up the virtualization in the three basic elements, and failing to address them and their current risks explicitly when defining the cloud is slowing down the standardization and adoption of the cloud. Each vendor solution was designed to address a specific industry need, and each has different benefits and drawbacks from a security perspective. Without tackling the risks and security mitigations of each vendor s approach, we are missing the most critical element of cloud computing. In 2010 Gartner estimated that more than 60% of virtual environments will be less secure than their physical counterparts through VMware states that 96% of Fortune 1,000 are using virtualization. 2 Microsoft has stated the primary vehicle for cloud infrastructure is virtualization. 3 When you add all these statements up, what do you get? Everyone is moving to the cloud; the cloud is built on virtualization; and virtualized environments are less secure than their physical counterparts. Sounds like a CISO s worst nightmare! The good news is that armed with this basic knowledge, you can follow these simple steps to ensure that you are addressing the new risks of virtualization in your environment. Tip #1 Read the vendor s documents IT security is great because no one knows everything, but anyone can have an opinion. You d think that this tip would go without saying, but I m amazed at the number of people giving security advice on virtualization that have no knowledge of how their specific instance of virtualization actually works. We have been so accustomed to believing that anything from a vendor is marketing hype, but the reality is that these vendors have invested a tremendous amount of time and resources in describing the security architecture of their environments. And as a security expert you can be discredited quickly if you have not taken the time to understand the specific virtual solution. Just last month I had a call with a client on virtualization and its impact to the Payment Card Industry (PCI) compliance. The company set me up on a conference call with Bob, their virtualization expert who had been maintaining their VMware environment for the past three years. He was prepared to go into great technical detail on why their rather complicated environment should be acceptable for PCI. The conversation went something like this: Me: What type of virtualization are you using? Bob: We are running VMware Me: ESX or ESXi? Bob: We are running ESX Me: Oh, can you explain why you are using a product which is end of life? VMware announced over a year ago that they were no longer going to be supporting ESX and that all customers should migrate to ESXi, which has several security benefits. vsphere 4.1 will be the last release to support the old ESX architecture, and you should be on ESXi as soon as possible. Bob: I wasn t aware of that. What does that mean? I then went into detail of the security benefits of ESXi and why as a security practitioner I recommend that they migrate their architecture not just for PCI compliance, but for a variety of other security issues. It turned out that Bob s organization had not made a choice of what type of virtualization they were using. They were not aware of the differences between ESX and ESXi. Instead they mistakenly believed that all VMware environments were the same. They were simply unaware of the risks and virtual architecture they were running. Within three weeks they had followed most of published guidance and our recommendations; the rest of the assessment was completed quickly, and the customer was significantly more secure. It sounds simple, but it is hard for us as security practitioners to admit that we have limitations. Security and information technology is a large, complicated industry that changes rapidly. Know your limits and have the courage to say I do not know if you are getting beyond your skill set. Very few individuals are able to keep up with the latest and greatest in technology and security on a daily basis. If you are using a specific vendor, read their documentation. All of them have created great knowledge bases for customers and prospects. While some of the documentation is going to be self-serving for the vendor, it is the first place to start. In addition, more and more companies are having their architecture and services reviewed by an independent third party. These assessments take a variety of forms, from SSAE 16 reports (formerly SAS 70s), letters from auditors, or technical whitepaper or publications. These third-party assessments are great reads for getting up to speed on the critical risks and mitigation recommendations. Tip #2 Provide a narrative of your environment Most organizations have some documentation, which describes what they do in words. There is usually some promotional literature that is designed for marketing or sales to 26

3 share with potential clients. There is also usually another set of documentation which is shared among auditors or existing clients under NDA, which goes into more detail. Unfortunately, I see that many of these narratives are lacking even basic information on virtual environments, and many of them do not describe virtualization at all. Virtualization is not simply another piece of software to be noted in the narrative. Virtualization is a fundamental architectural change that drastically affects the security, configuration requirements, and system boundaries of an IT environment. If virtualization is used, organizations should ensure they have an accurate narrative explaining the scope of virtualization, why it was implemented, and what systems are affected. Most IT administrators are the only ones that really know the details, but unfortunately documentation is not their strengths. They do not get up in the morning hoping to spend their day writing a Word document. In order to get a good narrative, you will have to work collaboratively with business owners, administrators, IT technicians, and your audit team to get a comprehensive narrative. The narrative should include Why, What, and How: why you are using virtualization? what is the architecture that you have deployed? and how is the organization using the virtual environment to support business needs? The best way to get ahead of this is to ensure that you embrace and document your virtual environment up front. If you have a SSAE 16, PCI assessment, bank assessment, vendor due diligence document, or any document that may be externally facing, make sure that you are clear about virtualization within the environment. Start with the why, why are you using virtualization? does it save money? does it ensure greater consistency? or does it help your business continuity plan? There is likely a compelling business reason or security driver that was critical to your decision. State how and why you are using virtualization up front, and it will significantly improve your dialogue with vendors, assessors, and business owners. Tip #3 Keep three separate network diagrams Three times in the past year I was more than two weeks into an assessment only to find that virtualization existed midway through the assessment. Why did I not know about it earlier? It was because there was not a single document, diagram, or interview which mentioned virtualization at all. I only found out when I went through the data centers to visually look at the servers. The diagrams would show 10 windows servers, and the server room would have only two servers and a SAN. When I asked were the other eight were, then the topic of virtualization would pop up. Unfortunately this changes the entire assessment because virtualization affects the flow and security of all network traffic in the virtual environment. It is not simply another piece of software to be added to an inventory list (although it should definitely be included). Security controls deemed appropriate in a physical-only environment are not the only controls necessary for a virtual environment. The primary issue here is that many times network drawings are not updated to reflect the true placement and network flow of virtualized systems. My recommendation: create and maintain three network diagrams. Network diagram #1 Physical network topology The first network drawing should be a Layer-3 drawing. This should include all the physical hardware, network interface cards, routers, switches, firewalls, and other components that are used to router bits from point A to point B. Focus on the physical connections. One of the biggest mistakes I find is that virtual systems look like they are physically connected to routers, when it is actually the virtual hypervisor that connects to a physical network interface card (NIC) on a piece of hardware. My advice is to keep the physical world on a physical drawing. If you are running a Dell Server with three NICs, then show that server with three NICs and how they are connected. If you are an IT security assessor evaluating the systems, compare the network diagram to the system components that you actually see with your eyes. Trust but verify continues to be timeless advice. If you see five servers, look for five servers. If you see one NIC, look to ensure that that system only has one NIC. I always start by looking at the network diagram physically counting the number of servers, routers, and firewalls and comparing that to my walkthrough. While this is not practical in very large environments, usually you can tell in a matter of minutes if the network diagram you are looking at matches the physical hardware you are seeing. Network diagram #2 - Data flow diagram IT systems do not exist for the sake of existing. All systems serve a function and are designed to meet a critical business need. Most organizations map this out in a data flow diagram. These diagrams are usually built on three general concepts: input, process, and output. This diagram helps provide the business owners with views of how IT supports their functions. Many organizations maintain dozens of data flow diagrams, covering the flow of health care information, credit card data, personally identifiable information, financial data, marketing data, etc. Ensure that you capture all the system components that can affect the security of that data as it flows through an organization. This usually requires some creativity, since not every system will fit into a network diagram, so my advice is to choose the most important systems that affect the flow of data. In small, controlled environments you can likely fit all components into a diagram. In larger environments, you may want to split it up into different views (networking, servers, databases, etc.). The key element is that you should be able to match your list of components to a visual network diagram. 28

4 # H,S, V Quantity Type Brand Version Dynamic? Comments 1 Hardware 2 Firewall Cisco ASA IOS 8.4(1) with ASDM 6.4(1) No Internal Firewall 2 Hardware 2 Firewall Juniper SSG 140 No VPN 3 Software 100 Adobe Acrobat Reader No Authorized PDF reader 4 Software 4 Hypervisor VMware ESXi ESXi 5.0 No Running on four separate physical servers 5 Virtual Componenent Web Server Windows 2008 R2 Yes Scales to meet customer needs 6 Virtual Componenent Swtich VMware N/A Yes Scales to meet customer needs Figure 1 Sample inventory Network diagram #3 Virtual diagram Once you have captured your physical layout and data flows, it is important to document all the virtual components and their relationships to hardware and critical data. When updating your virtual diagram, ensure that you include all critical components, such as virtual switches, operating systems, databases, storage, servers, virtual firewalls, etc. Also, be sure to discuss whether they are dynamic or static virtual components. A large public cloud provider such as Amazon is not going to be able to track every single virtual instance that is running, but they can provide an explanation of how they deploy a virtual switch and ensure that it is managed and configured correctly. Remember, most software was not written with virtualization in mind, and may be prone to different attacks and security flaws when running in a virtual environment. For example, a piece of software may encrypt data and keep the encryption key only in volatile memory, which is relatively lower risk. But if you allow dirty snapshots (which is essentially when you copy a running virtual machine and store it exactly as it existed), then that encryption key could be written to a hard drive, stored in a SAN, and duplicated in your backup systems? The same software has different security risks depending on your virtual environment. These sorts of items need to be considered with the virtual diagram. Tip #4 Update your inventory In the beginning of this article, I mentioned that there are three critical elements to any cloud environment: hardware, software, and virtual components. Maintaining an inventory of all IT systems can be an overwhelming task, particularly in large environments. Hardware is relatively easy to track; software is a little more complicated, but there are a variety of tools that make tracking software much easier. However, tracking virtual components is still largely a manual process today, and there are few automated reports that can be run to show all the virtual systems running. Since virtual components are critical elements, you need to have some way of tracking how they are deployed, retired, configured, and maintained. Today this primarily done through change control tickets and the sys- Hypervisor Hardware Bare Metal tem development life cycle (SDLC). However, more and more vendors are creating tools for tracking these components and reporting on them. For example, Trend Micro has an agentless anti-virus solution that has visibility at the hypervisor level. 4 As you review and update your system inventory, make sure to include all the software and versions that you are using, including your virtual systems (see Figure 1). Remember that virtual systems are not limited to servers. There are virtual workstations, virtual switches, virtual firewalls, etc. Additionally, make sure you take the time to review your software and see if there are known security vulnerabilities, or if the software is nearing its end of life. Tip #5 Go bare metal A hypervisor (also known as a virtual machine monitor) is the software that allows multiple operating systems and virtual components to run on shared hardware. However, not all hypervisors are created equal. There are two types of hypervisors. Type 1 hypervisors are bare metal, meaning they are installed directly on top of the hardware they run on; there is no operating system (see Figure 2). They are the direct interface between the hardware and the virtual world. The security community believes this is the best type of deployment and it is recommended in nearly all security guidance on virtualization such as NIST for one. Host OS Hardware Hosted Hypervisor Figure 2 Bare metal vs. hosted hypervisor 29

5 A Type 2 hypervisor is one that is installed on top of another operating system. This deployment is common for small environments that are looking to test out virtualization. Many small organizations using Microsoft get a trial of their virtualization software and run it on a server that is primarily tasked with other functions. A type 2 hypervisor is also common for laptops that are running different operating systems such as VMware Fusion or Parallels. Tip #6 Clearly define the system boundaries I saved this tip for last, because it is one of the hardest things to do in a virtual environment. It was not too long ago that all networks were essentially flat, meaning that anything on the network could talk to anything else on the network. As much as we would like everything to be secure, different systems need to meet different levels of security, so we segment our IT infrastructure into different zones. The traditional thinking of network segmentation has historically been physical separation or the use of firewall rules (Layer-3 segmentation). But virtualization and cloud computing are forcing us to consider alternative ways of meeting acceptable segmentation. The term segmentation is interesting because no IT environments are truly segmented unless they are physically disconnected from each other (and even then, there are still ways to breach that segmentation such as wireless and sniffing electrical transmissions). Most organizations are comfortable with defining system boundaries at the network layer. As technology evolved, we began considering other ways of enforcing segmentation, such as using VLANs, IPSEC, applications, and other technology. Take a webserver that communicates to a backend database and the Internet. Traditionally, we would put the webserver in its own DMZ and segment it from the Internet and back- end database by installing a firewall. But a Layer-3 firewall alone will not prevent an attacker from exploiting a software flaw and executing a SQL injection attack to gain access to the back end system. Virtual environments are no different in that they can create segments, but those segments are only as good as their configuration and threats that test them. However, one of the biggest risks is that subtle configurations and vulnerabilities in the virtual environment have the ability to affect everything on the host. To put it simply, if you do not securely configure your virtual settings on your hypervisor, you are putting your entire environment at risk! In summary Cloud computing is upon us and becoming more common as companies continually look to improve their operational efficiencies. However, before we can understand the risks of moving into a cloud, we have to understand the fundamental elements that make up a cloud environment. There are several theoretical deployment models, but the risks around virtualization and security best practices are still emerging. If you are using virtualization or a cloud environment, start with these six tips and you will be off to a better start than most! About the Authors Tom McAndrew and Mike McGee are security practitioners living in the Seattle area and members of the Puget Sound Chapter of the ISSA. Both have worked in a variety of setting including the banking, retail, service providers, utility providers, military, and healthcare organizations. Tom is also the current President of the Puget Sound chapter of ISACA. They can be reached at thecloudguys@gmail. com. 30