Hello, everyone, my name is Warby Warburton, I'm a senior tech marketing engineer at Palo Alto Networks. This is video two of the "Virtualized data center and how to secure a software defined data center". In this example, I'm going to show how to secure the east-west traffic. In the first video we concentrated on the North-South, how to do security at the edge of the perimeter using physical firewalls that could keep state with a dynamic data center. In this example, we're going to talk about specifically the East-West traffic, how to protect different application tiers within the data center. As before, we're going to start with our virtualized data center; and in a traditional data center, we have lots and lots of racks of servers. Ideally, we want to be able to run any virtual machine, any guest server on any available compute and not be tied to physical architecture in any way. It makes it easier to scale and it makes it easier to automate. We might have a Web server running here. Another web server of the same tier running over here. Maybe a couple of database servers running over here. The challenge here is to secure this environment where we're getting the maximum use of our compute resources without compromising security. You don't want a situation where an attacker comes in; maybe you have really good perimeter security, but you have a badly formed website that inadvertently allows access to using a web form to attack a back end server. An attacker compromises this using, because it was badly built or badly formed website and now they're trying to propagate over to this database. This attack is launched from within the data center. The view of the physical firewall is legitimate Web browsing traffic. The actual attack is happening from here to another server. We need to be able to see that, we need to be able to stop it. What we're going to do is, rather the entire cells to physical architecture. We're going to change the view and look at, logically, how to best secure this environment. Now rather than focus on the physical layout, let's look logically at the best way to secure this environment. I'm going to draw a typical three-tiered application in the data center. I might have a couple of Web servers, a couple of database servers with the middle app tier. Let's group these logically the way it makes sense to secure them. We're going to create a Web tier, an app tier, and a database tier. What we want to do is, we want to actually focus on steering traffic that we care about between these tiers to our virtual firewall. In this case, we're going to use VMware's NSX to get the maximum advantage of the software defined networking, and we're going to integrate our Palo Alto network's virtual firewalls with NSX. What that allows us to do is register as a service and actually launch as a service to a cluster of hosts, and we would actually be installed as a virtual firewall on every host, that way we can inspect the traffic locally. Logically, what it would look like is, there would be a virtual firewall running on each host that can inspect traffic. For example, if this Web server needed to talk to this database server, we can see that traffic. Within a tier, things like database is doing a synchronization. That's a lot of volume and it's not as risky because that's deep in the environment and once the database has been secured from these other tiers, we can trust it to talk to another database. What we'll do there is, we'll leverage the distributed firewall that comes with NSX. By using the two together, we get the maximum balance of performance and functionality. For example, in this case, this Web server, Lets say the form was bad, an attacker is using that to launch it. We can see the traffic, and we can use threat profiles, we can use Wildfire, we can use safe application enablement by whitelisting applications to prevent that traffic from propagating if it is indeed compromised, so we have East-West protection. The way we integrate with NSX, is we use Panorama. To manage the virtual firewalls, we use NSX Manager from VMware, and we use vCenter. These three worked together to create the solution. They also have the advantage of using the state. NSX Manager learns from the environment. It can share that to Panorama. Just as before, with the North-South firewalls using dynamic address groups, we can also use dynamic address groups in the East-West, virtual firewalls, so that as these tiers grow from one or two to dozens or even hundreds, the policy doesn't have to change. There's no comment required on the firewall because we're referencing dynamic address groups. New web servers come on board. The IP is automatically shared from NSX Manager to Panorama. Panorama pushes that update to all the virtual firewalls, and they automatically apply the correct policy so that only the correct traffic can flow. In our case, let's say the database is an MS SQL Cluster, and we have IIS web front-end servers. Whenever that web server needs to talk to the database server, "I'm going to check to see, is that really MS SQL traffic? If it is, I'm going to allow it. If it's not, I'm going to block it, and I'm going to log it. But even the traffic that I allow, I'm still using my threat protection, my vulnerability profiles, and even wildfire to make sure that there's no malware piggybacking on that traffic." So next, I'm going to show a video of how this actually looks in a live demo. I'm going to go through to show you how this actually integrates with NSX, how we have a shared policy using dynamic address groups, and how we can track state in the firewall. Next up, we're actually going to run through the demo of the East-West integration using our VM-Series firewall, Panorama, and NSX from VMware. In this particular demo, I decided to use a SharePoint deployment. It's a common application, and it's a three-tiered deployment in this case. It also has a domain controller, and there are one or more servers in each tier. We can look at inter-tier versus intra-tier traffic steering and inspection. To show the power of the software-defined networking that we get through NSX, I'm actually going to run all of these servers in a common virtual switch, a common distributed port group, a common VLAN, and a common subnet. Normally, in a traditional firewall, each tier would be in a different VLAN and a different distributor switch, or at least a different port group. But because we can make steering decisions and security enforcement decisions independent of the infrastructure, it could be as simple as one entire flat network. This may not be common because we may be integrating in an existing environment. And that's fine. We can run in any example. I just wanted to show you the extreme case. This is, logically, showing how the virtual machines are deployed without, yet, showing the virtual firewall. Again, there are the three tiers, the web tier, the application tier, and the database tier, and there's also a domain controller. There's the Edge Firewall that we talked about in the first video, which is integrated with NSX for learning things, like dynamic address groups. But the focus on this demo will be the virtual firewalls in between. Here, I have a physical view. I have three ESXi hosts in a cluster, and because Panorama has registered to NSX as a service, every host automatically gets a firewall deployed. That entire process is automated, which is part of the power of the solution, including the licensing of those firewalls. Panorama is an integral part of the solution. The way Panorama registers to NSX is using this new menu called the VMware Service Manager. This was introduced in PAN-OS 6.0. In this screen, we configure the location of NSX, as well as the credentials to log into NSX. We also show the location of the OVF. This is the download site for the virtual VM-Series firewall [inaudible] , the actual OVF location. This is something you hosted in your data center, and there's a multi-use off code. This code will be used each time a new firewall's deployed, whether you're going into a new cluster in your vCenter, or you're expanding an existing cluster. When the new firewall comes up, it'll reach out to Panorama, and Panorama will use this off code and our update server to generate a unique license for that new firewall. We can also use optionally a template for common configuration elements and a device group for the shared policy, and other elements as well. As I talked about in the first video, we have the notified device groups where we can tell our perimeter firewall, our physical perimeter firewall about new servers. This data shows that Panorama successfully registered. The way that looks on the vCenter side is if I go in Networking and Security, where all the NSX configuration is done. Under Service Definitions, I can see a new service called Palo Alto Networks, Next-Generation Firewall. Under Installation, I can show the status of the Palo Alto Networks firewall service deployment and in this case, my SharePoint cluster. On my SharePoint cluster, I have the three hosts that I showed in the diagram, 181, 182, 183, I have my domain controller and my web front end servers, my SharePoint server, and my database. It doesn't matter with the power of the solution, a combination of NSX and Panorama, it doesn't matter which host these machines are running on, they won't be enforced from a security perspective based on the tier they are in, not the host they're sitting on, not the switch they're connected to, not to the distributed port group. Again, it's software-defined networking, we're independent of that virtual and physical infrastructure. Once I have deployed, what I need to do is tell NSX what traffic to steer to the firewalls. In NSX 6.0, I do this in service composer, in 6,1, I do it in firewall on this menu. Since I'm running 6,0 in this demo, I'll show you the service composer option. We create these security groups and there are some that are built-in and there are the new ones that I created. For example, web servers. To get the full advantage of the power of the solution, I'm using security tags. These are tags that are created with NSX and then are assigned to individual host or rather guest machines. Whenever a new VM comes up with the tag web server, it will automatically be sent to Panorama, and those are going to show up in dynamic address groups. I have a dynamic address group in Panorama called Web Front End Servers and it nurtures. These are all the match criteria that I learned from NSX in this case it matches the NSX security group web servers, dash security group dash 10. There are some static groups that I created and these are the dynamic groups that I created in NSX. I can see the value, the currently registered IP addresses of these servers. In this case, I have two IP addresses because I have two interfaces on each server. I have a management interface and a production data interface. This 1500202 is where I'm actually steering my traffic. I have my policy for East-West traffic in my NSX device group and the other video I was looking at the Edge firewall. These are the firewalls that are for the East-West traffic, the virtual firewalls. This is my entire policy for my three-tiered SharePoint application plus my domain controller, because I'm using dynamic address groups and member IPs are automatically mapped to these dynamic address groups as they come up from NSX, I don't have to track individual IPs. My demo has five servers. If this was a production environment with 500 servers, it would look exactly the same. My policy would not get any more complicated. It would be simple to implement. I wouldn't have to make production changes and schedule outage windows and it would be easy to maintain. For example, we have customers that can spin up virtual machines in a matter of a few minutes, but they have to wait two to sometimes three weeks for an outage window for somebody in the IT to change the firewall to allow that new virtual machine to talk on the network. In this case, we can get that from two to three weeks down to two to three minutes or less. It's a very powerful solution. Also, when a virtual machine goes away, let's say I scale my web front-end server firm for a peak usage, and after my peak usage requirements have gone down, I don't need many web front-end servers. I can shrink that firm down and the IPs will automatically be unregistered. I don't have the issue of a year from now seeing an IP address and a policy not sure why it's there. Unclear if I can delete it without breaking something and ending up with years and years of hundreds and hundreds of lines of access control list in this new model with the next-generation firewall. All that problem goes away. In this case, I have my two web front-end servers, but one of them is not showing up in my dynamic address group. If I click on "More" I can see these are the two IPs associated with one of the servers. If I come here to Host and Clusters, Web frontend 1, I can see from VMware tools, these are two IPs that I've learned. But Web frontend 2, its two IPs are not showing up. If I come over here to the security group that Palo Alto Networks is learning IPs from, WebServers and I click on "Virtual machines" I see only Web frontend is listed. The reason is, Web frontend 2 does not have a correct security tag, the security tag list is empty. I'm going to click on "Manage" this is similar to the North-South demo, but now it's also being used for East-West traffic. I'm going to correctly assign this to a Web server. When I go to my NSX security group and I click on the "Virtual machine" list as before, I now see them both, and I come to the dynamic address group, and they're both there, two IPs per server. Now traffic can flow according to this policy, for example, a Web frontend server to a SharePoint server, if it's any of these applications that traffic can now flow. Just like in the North-South demo where the edge firewall was dynamically learning IPs for the edge policy, my East-West traffic is also learning. For the East-West traffic, I also need to create steering rules. This is how I let NSX know which traffic is going between tiers that I want to inspect with the firewall. I don't want to overwhelm the virtual firewall with something like backup traffic or two databases synchronizing. But if a web front end server is reaching out to the database or an application service reaching out to the database, that's a critical part of the infrastructure. I want to see that, I want to make sure that it really is MSSQL traffic, I want to make sure that someone's not trying to guess the MSSQL route password. In this example, any traffic in a SharePoint, NSX security group reaching out to an MSSQL security group steer that to the service, in this case, the local virtual firewall. Once I've done that, then I can see the traffic flowing between the tiers. In this case, for example, one of my SQL servers is talking to the domain controller, I can see that traffic, and I can make the correct decision, for example, allow it to pass because it's the Microsoft SMB protocol. This is the power of the combination of using NSX to steer the traffic and Palo Alto Networks firewalls to safely enable the traffic. In addition, I can also enable my other protection, including threat protection, I can do my zero-day sandboxing technology with wildfire. You can have a situation where you have what looks like legitimate web browsing traffic hitting your web front end server, but because that Web server is already compromised or misconfigured, it might be being used as a launchpad to attack the database. Because that traffic for that attack is sourcing from the Web server that's already in your data center, you need visibility of that traffic going to the database to make sure that, for example, a zero-day exploit isn't being uploaded to the database so that it can propagate in the data center. This visibility with the dynamic steering of traffic and our next-generation firewall features, we can see that traffic, we can block it and we can create dynamic policy to block in the future as well. This is the power of the entire solution. Thank you very much.
