Security automation in virtual and cloud environments v2

Editor's Notes

• #5: I wanted to also share this quote from the Accenture Technology Vision report of 2011. This report addresses some of the big trends in technology such as big data and cloud computing. About IT security, the report makes the point that there needs to be a shift in how security professionals think. Security used to be about setting up a secure perimeter and if this perimeter were breached then the entire organization is at risk. But the reality is a lot more complex. Organizations are getting compromised all the time, and some attacks are really successful and some are not. But no organization has the resources to adequately investigate every single compromise and figure out what happened. This is why automation is so important.
• #6: So with that said, let’s go into the main outline of this presentation. I’ll break it into 4 major parts. The first will be about why we’ve seen so many challenges in properly implementing security in virtual environments, and why we are hopefully seeing changes. The second part will give a brief overview of the vShield vision and how its API works. The third part will go through some use cases of how to use this API for security integration and automation. We’ll also talk about how APIs from other security products can also be used to help. And then we’ll end with some practical steps for how one can start implementing more security automation solutions.
• #7: How much are we seeing security in virtual environments? Unfortunately, not as much as we would like.One of the big issues I’ve seen in customer environments is the existence of silos. This has been the nature of enterprise IT – each group runs its own separate hardware and software. Networking, virtual, and security teams have traditionally owned and run their own gear.In many situations, the VMware group needs to focus on critical factors such as hardware consolidation, ROI, and speed of deployment. So security tends to fall lower on the priority list. And because security is a separate silo with its own concerns, it hasn’t gotten too involved in that virtual environment.
• #8: Another challenge with security is its static natureMany security tools make the assumption that the environment is static and policies don’t have to change very often. As one example, look at how long it takes to make a firewall rule change. It could take a few days.
• #9: But we don’t live in a static world, especially given the dynamic nature of virtual environmentsThink about how many VMs are being created, or moved around between locations, or changing because of snapshot reversions.I think the recently announced VXLAN will help to ease migration of VMs between private and public clouds but there’s still the open question of how you update all of your security devices in different clouds as you are moving these VMs.What all this means, is that the static nature of security is another hindrance. Security devices may fragment the virtual network and create overly rigid topologies. This keeps the virtual environment from being as dynamic as it should be so it can’t provide the appropriate business benefits. Or the security tools may not even work properly because they can’t see inside the virtual environment or their policies are obsolete. If any of this happens then the security just won’t be put in because it gets in the way or it isn’t worth it.(Devices are chokepoints and fragment the virtual architecture; capacity is never right-sized, no intra-VM visibility, rigid topologies)You also may need lots of different boxes that each perform different functions. Integrating together is challengingLastly, vendors may not even have virtual-specific solutions that you can use
• #10: But I think we’re seeing some positive trends now. One key driver is the new PCI virtualizationguideilnes, released this past June. And they really try to clarify how PCI applies to virtual environments. If you deal with PCI at all, I highly recommend you download this document from the PCI Web site and take a look. Here is a high level summary of what’s in the document:You need to implement some type of network security to monitor and protect virtual assetsYou need to enforce segregation of duties and least privilege in a virtual environment – which means that no one group can no longer have root access over everything.Mixed mode virtual environments are possible but you need to put in extensive security controls to show your auditor that isolation between trust zones is properly enforced.Finally, In-scope virtual systems and the hypervisor are subject to hardening and monitoring requirementsThe bottom line is that we should see greater collaboration between virtual and security teams because they need to work together to ensure their environment complies with the PCI requirements.
• #11: Here’s another driver for security, which is the steadily increasing percentage of virtualized assets in the enterprise. This graphic here from this past year’s Partner Exchange last February and shows that we have hit a crucial milestone at 30% virtualization. So the easy stuff has been virtualized and enterprises are now looking to virtualize their mission critical apps such as their database and SAP servers. I know that many of you would argue that you’ve already done this in your environments but we’re talking about doing this across the board in general.So to get to the point where 40-50% of applications are virtualized, and this is one of VMware’s big goals for this year, security becomes a much bigger deal. It’s not as critical for some of these easy apps, but it needs to be addressed or at least discussed for the mission critical apps.
• #12: And this brings us to how security products themselves need to change to be more dynamic.And this is where the vShield vision comes in. vShield is promoting a vision of integration between different security devices to protect the environment and adhere to regulations. It becomes the “security middleware” so products can work more seamlessly.vShield is not intended to be a manager of managers, but it enables multiple security products to work together to understand the virtual environment and adjust to changes. Policy violations is just one example.
• #13: vShield is NOT a silver bullet for security or compliance in virtual environments because this doesn’t exist. It’s too complex of a problem. But I think this vision of vShield as security middleware is realistic and I hope it will bring multiple security vendors together.
• #14: Which brings me to this phrase here that “code is law”. Lawrence Lessig is a lawyer who used this phrase to basically say that source code determines what is real and what is not. This phrase applies here too. vShield isn’t just fluffy vaporware. We have a documented API and source code samples. And we can see what this API can and can’t do. So let’s explore the API in more detail and see what’s possible.
• #15: Here’s a quick overview of the main components of vShield. They’ve been well discussed by now. We’ll mainly focus on vShield App and Edge and their network security functions.Edge is a virtual router supporting firewall and various other functionsApp is primarily a NIC-level firewall for VMs – each virtual NIC can have its own separate firewall rules
• #16: So here’s a specific example of vShield and policy enforcement. So as a third party security vendors sees behavior in a virtual environment that violates policy, it uses the vShield API to change the environment’s security configuration. The API changes firewall rules or security groups so you can block traffic or quarantine an entire VM.This specific diagram is showing App but the same principle applies to Edge, where the firewall sits at the edge of the virtual datacenter.
• #17: The API is very simple. A REST API is based on HTTP URLs. The URL determines the command. You do a GET to retrieve data, and you do a POST to send data back. So in this case we want to look at all the firewall rules for a virtual datacenter. You do an HTTP GET to this URL while submitting your username and password with HTTP authentication, and vShield Manager sends back the ruleset in XML format. This is for a datacenter object but you could get rules at different levels of granularity: clusters, resource pools, vApps, or port groups.This means that you can have rulesets down to the individual port group. So as VMs are migrated between physical ESX hosts, if they are connected to a distributed switch then their port group configuration remains the same. This means that rulesets can essentially “follow” VMs as they are migrated between hosts.
• #18: Now that you have your rules, you make a change such as adding a new rule. And then you call the same URL with an HTTP POST command and submit the new XML ruleset.That’s how you would see and change firewall rules. The most important principle is that it is very straightforward to use these URLs to access security configurations, make changes to them, then push them back to activate them.
• #19: I’ve included other examples of REST commands. Hopefully they are self-explanatory. The first URL enables you to get or edit the NAT configuration, the second will start the load balancers, and the third will enable you to get or edit a list of syslog servers to send data to
• #20: Now that we understand some more about vShield and its API, let’s see how they fit into the bigger picture of security automation. In this specific example, you want to automate security for the provisioning process of a new VM. Here I’m talking about a private cloud. But this concept can also apply to non-cloud virtual environments too.Here’s a 4 step process: Request a new VM. Then provision the instance. Then provision its security policy in the form of a firewall. And finally, maintain this policy over time by making the appropriate changes. So the security automation is in the provisioning and ongoing maintenance stages.
• #21: To provide even more detail, let’s go through an actual use case. I know this is highly simplified and there are a lot more details I could have included but I wanted to just get the main points across. An enterprise has built a private cloud for virtual server deployment. This example is also well suited for virtual desktop deployment and you can substitute virtual desktop as we go through this. But integration between vCloud Director and VMware View is still down the road.In any case, this enterprise has built a portal so multiple groups worldwide can request a server VM to be created. And the Server Type such as Web server, LDAP server, etc. determines the server’s function and its security policy as well. LDAP servers should only have ports 389 and 636 open, along with a few other management ports. Instead of individual servers, you could also request entire applications because we’ll be provisioning vApps on the back end.
• #22: The next step is for a vApp to be created from the appropriate Org datacenter with the appropriate resources. The vApp consists of a single VM. There are different ways of assigning the IP address but once it’s obtained, it is then registered for that VM.Internal database: register IP, MACvCloud Director: provision cloudWeb PortalFront End displaying information regarding the service and form to request a systemMicrosoft SharePointWorkflow Engine including Lifecycle ManagementIntegration Point for internal systems including Chargeback and Hostmaster Registration SystemVMware vCloud DirectorWeb Based User Interface to consume cloud resourcesEnables the Private CloudVMware vShield Application / EdgeVirtual Appliance to implement, manage and maintain security policySecurity in the Private Cloud
• #23: Step 3: vShield App is deployed and configured [does any part of this happen before new VMs are added?]each VM is automatically put into the required Security Group (determined by what user requested in portal) Deploy vShield App on all hosts which will have VMs in this vDC/private cloud Configure vShield App for datacenter level rules (L2/L3 ICMP, ARP DENY, etc. - get from slides] Configure vSheild App for SG level rules (VDI can’t talk to each other, etc. - get from slides]
• #24: Firewall changes can be permanent or temporary
• #25: Step 4 (optional): vShield App can also quarantine the VM if it is considered to violate a security or policy thresholdQuarantine can be temporary or permanent, i.e. requiring operator intervention to restoreSo that ends the first example of how you would security automation to apply a security policy for provisioning and then enforce that policy over time.
• #27: Now I’ll go through a public cloud example with a multitenant environment. Automation is similar in that you’re using it in the provisioning and ongoing operations stages, but the architecture is different. And you may make different kinds of security policy changes, which I’ll show in a bit.
• #29: In that org datacenter, you deploy an Edge security appliance is provisioned via vShield API with the appropriate firewall, NAT, load balancing servicesYou would also use the API to assign internal and external IP addressDefine NAT rulesDefine firewall rules for that Edge device.
• #30: And the final stage is that you would update the tenant’s firewall configuration as required. In this example, the tenant has subscribed for a protection service where they want the firewall to block additional IP addresses that could be members of botnets. So an ongoing basis, the firewall configuration is updated with addresses from a variety of third party security sources to provide additional protection.So here is another example of security automation, this time in a multitenant environment. You’re once again using the vShield APIs for security provisioning and then you also them to provide additional security services.
• #31: So at this point I want to do a reality check and ask you, do you think all of this is really practical? I’m sure for some of you, you’re wondering if you ever want to allow these type of dynamic firewall rule updates? After all, change control processes exist for a reason. Lack of change control helped to create this kind of environment shown here. You need some sort of order to hold back the chaos that will result. And you may also need processes for compliance or regulatory reasons.
• #32: I don’t claim to have all of these answers, and I think we collectively as a security industry will have to figure this out over time. But I do know that we don’t live in a static world. And we can’t assume anymore that static security will adequately protect us.I touched on the highly dynamic nature of virtual environments previously. No one can manually keep track of what is going on. Static security policies will constantly be out of date. And these obsolete security policies not only don’t adequately protect the environment, they get in the way of the business. Legitimate applications get blocked, and this just lends ammunition to NOT putting security into a virtual environment.
• #33: And we can never forget that there is an adversary out there that is constantly changing, getting smarter, always looking for new ways of breaking into systems and stealing data. That’s ultimately why the security industry exists. Many of you may have heard of Operation Shady RAT, where multiple governments and defense contractors were compromised in a 5-year hacking campaign. Targets were found in 14 different countries. There are other examples of compromises that we know about, such as Sony, RSA, Epsilon, and Citibank. There are many others that we don’t know about, and it’s not clear that the organizations who have been hacked are even aware of this.The bottom line is that we as a security industry – both vendors and enterprises – need to think beyond what we’ve been doing and look at new tactics. Automation has transformed the IT industry in general and there’s every reason to think that it can transform our industry as well.
• #34: I just wanted to mention another quote from the Accenture report underscoring this point. We can’t keep the hackers out 100% of the time. Watertight IT security doesn’t exist, as the quote says. This isn’t realistic. Instead we build automation to detect attacks and to respond to them as the first line of defense. What we’ve talked about today, about automating the provisioning process and policy enforcement, are just first steps. There’s so much more that we need to do.
• #35: Put another way: let’s not do manually what we should be doing automatically.
• #36: Before we end, I want to shift gears a bit and go beyond just vShield automation and talk about how security products can become more tightly integrated with one another to automate the analyst’s job.What is the value of integrating security products together? From what I can tell by talking with lots of customers out there, it’s all about the data. Each security product generates its own dataset, and what security analysts really need is a way of taking multiple security datasets and intelligently combining it together. Security products shouldn’t be focused on keeping the data locked up in its own product but the data should be freely available via APIs and database queries so it can be used for analysis.
• #37: And this is where contextual data about the virtual environment can be helpful too. Security products can use this data to determine some really useful things:Which VMs are located on an ESX hostWhen a migration takes place and where toHow security policies may change or break because of a migration Whether a VM is online or offline and available for scanning or patchingAll this data is accessible via the vSphere SDK.One of the signs of a security vendor who understands the virtual environment is one who is pulling this data and doing something useful with it.
• #38: So as I talk about combining security datasets for useful analysis, I’m not just talking about what SIMs do, where they aggregate the data in one place and then use correlation rules.I’m talking about selecting combining data to make intelligent decisions. This is what security analysts do today. If they see something strange in one security console, they will jump from product to product manually to figure out if this represents an actual compromise. This manual process is what we need to automate so the security person can focus on more important tasks, such as defining the architecture.Many of you may have heard the term “big data”. It’s becoming somewhat of a fad but it’s the idea of taking massive datasets and utilizing automated analysis techniques such as machine learning to figure out useful trends. Machine learning recommends new books for us to buy, or it identifies spam. We need these tools to identify anomalies in security data or mutations in existing malware because humans can’t look through all the data themselves.
• #39: So this vision of security automation may appeal but you’re not sure where to begin. You don’t know how to use these APIs, and you don’t have to time to build integrations.
• #40: We’re at the beginning of this transition to automation so it will take time and we have to go one step at a time. Step 1 is to make security a priority for your virtual environment. Create a specific security policy for VMs as they are provisioned or migrated. Are you going to scan them? What do you do about offline VMs? Think about how you should segment your VMs, either on the same host or between hosts. Think about where vShield will fit in.Step 2 should be a result of step 1 but it’s really about working together on a shared goal. It really will take a bridging of the silos to implement proper security.Step 3: Talk to your vendors and ask them about their plans for vShield integration. What is their vision for understanding the virtual environment and dynamically adjusting to changes? How can they make their data available for analysis by other products?Step 4: This may be a bit controversial but some integrations between vendors may still be open source and not “officially” supported. But take a look at them and see if they add value. If they do then consider pushing a vendor to officially support them.
• #41: This is my conclusion. My biggest point is that we need security automation in a dynamic environment because security people just don’t have time to find and react to all of the malicious activity out there. Automation should be our first line of defense.
• #42: If you haven’t already, take a closer look at vShield. It has a vision of dynamic security that is provisioned “at birth” and hooks into other security products. I’ll be the first to say that there are many other improvements that could be made to vShield. I have a whole list of feature requests. But at least they have a vision for security automation and they are on the right path.
• #43: Finally, we as vendors need to do a better job with automation in general. We also need to more fully plug into the virtual environment, being aware of what’s going on and responding to changes dynamically.