VMware NSX for Security

so my name is Jeff Wilmington I'm a technical product manager with the networking security business unit I focus on the security aspects of the nsx product so distributed firewall edge firewall our guests introspection services service assertion and so forth for our layer seven partners and so forth a little bit today is just a little bit of an intro to to nsx how many folks have I mean I know some folks of familiar with in a sects how many they have actually used it on a you know in a workload environment know a little bit about it maybe don't know a little bit about it ok ok cool I want to make sure that that I that I get through the introduction so we kind of level set kind of the the expectation of what we're going through and so forth and we're going to talk about nsx datacenter in a sex cloud is my mic is everything okay you guys look a little ok coach ok ok awesome so in a sex datacenter is functionally what we've what we've been doing is is if you think about virtualization and what we've done with like the ESXi hypervisor right we basically said bring your bring your commodity Hardware your HP or Dell your whatever kind of hardware and basically run our software on top of that and basically virtualized those those physical infrastructure types of services and so from an sx perspective we've taken that same concept and we've said the physical infrastructure to us it were agnostic to that infrastructure right there are certain things that we need from that infrastructure to run things like MTU highly resilient and basically let's move some packets right that type of that type of equipment that we have that physical infrastructure and we're going to take those data services that we would typically use the way that we typically buy products for us or routers and switching and so forth things that have been generally distributed around our data centers and bring them closer to our applications so we do that by providing the NSX platform inside the virtualization layer inside the hypervisor of the ESXi host so we're taking things like routing switching firewalling and things like load balancing and we're putting them directly into the sxi hypervisor and as we do that we're taking these cons and moving these services that we would typically have to either you know provide routing for or send traffic to an external firewall and we're bringing them closer to the actual applications themselves so that we can take those we could take those services and provide them right to the application regardless of workload type so we have virtual machines NSX supports virtual machines supports bare metal systems supports container based workloads and then we layer in the NSX cloud portion of this and NSX cloud what that has done is it come it's a it's a piece that interacts with the nsx manager on-premises and helps provide the same networking and security services for the workloads on-premises to our native to our cloud providers so that would be VMware cloud providers or native public clouds like Asscher or AWS so what we are functionally doing here is we're saying much like Tom was saying we wanted to provide that ubiquitous and consistent networking and security enforcement regardless of where that workload lives whether it's on-premises or off premises so make sense ok so a little bit into what we're doing from NSX in terms of security so from a from a use case perspective these are the types of use cases that we typically see with our customers in terms of how we provide security to those for those different use cases our first one being around micro segmentation and that's our ability to provide security services as close to the application as possible and create isolated zones around those around those applications so that we can control traffic oops at the button to fast we can control traffic between the systems secure end-user desktop and computing is a very similar concept where VDI desktop infrastructures have lots of desktop pools and so forth and our ability to control traffic between those desktop pools lastly being around DMZ and software so our ability to say that from a security perspective lots of organizations have built you know air-gapped DMZ s they have specific hardware and equipment that does that's specific function where they have sandwich firewalls between those systems I don't know why this thing keeps moving maybe I keep hitting the button but from a dmg perspective if we put a firewall at all of our virtual workloads functionally we're creating dmz s within software right because we're creating that firewall at that at that virtual machine level if we can control traffic from one virtual machine to another dmz s are actually be easy for us to actually create security policies to actually make that happen I'll go into that in just a little bit so very similar to what tom was talking about and all kind of speed through this since he covered a lot of this but basically what we've done from a security perspective or what customers have what we've seen with customers is is that getting into the environment is very pretty difficult right we put don't large firewall services at the perimeter but if someone were to get through those systems either through some legitimate method or through some illegitimate method then their ability to move freely with around the datacenter becomes very very easy and that's generally because we don't have security services between our systems and if you think about this from a north-south or an east-west perspective most of the traffic we've talked about in the past has been like north-south is eighty percent of our traffic and twenty percent is more east-west but actually if you think about it as our applications have grown and have expanded with inside the data center that the majority of our traffic now is actually east-west and we don't provide security services for a lot of applications or its fees operationally infeasible because if you have to put physical firewalls here then I have to do lots of going back and forth and trying to figure these things out as applications need to talk to each other so what we what we do is you know what if we could take that zero trust model that Forrester was talking about from you know assuming that everything is a threat and then acting accordingly and take all of our virtual machines and place firewalls at the v-neck of every one of those virtual machines what does that mean to us that means that means thanks Jeff you just gave me a thousand firewalls for every one of my virtual machines in my environment I appreciate you putting a firewall at every one of my virtual machines but what that really means is is that is that now we have some very very fine-grained ability to control security between these virtual machines right we can say that these virtual machines or one virtual machine can talk to another but not necessarily another and that we can individualize all of the security so what we've seen with a lot of our customers is is that when they start with down the NSX path for security it's not it's not some they want to secure the entire data center as they start out it's generally they have a specific use case something like say PCI compliance right where they have some workloads that they want to place the security posture around that's different than other environments having a firewall at every one of our my VMs and having the ability to provide individual security policies for each one of those different systems or logically group constructs so saying these are my PCI systems maybe I want a different kind of security posture and creating a security policy that's enforced at every one of those VMs consistently regardless of location what sure but most of these VMs probably have host-based firewalls already sure so what's your value compared to that why couldn't I just configure my own space firewall so okay so host-based firewall let's take a Windows example right so configuring a Windows based firewall means that I would need to use Active Directory group policy to enforce those things right how fast does it how long does it take to push a group policy down to a system they could take less than 10 minutes it could take less than 10 minutes I can do it in less than less than a second but it's a one-time click either way right so when a when so what we what I'm saying is is that what we're doing that's different than say a host-based firewall is that our firewall is at the v-neck of every one of our virtual machines so let me explain kind of what that means take a take a physical server for example right we have a physical server we take a cable and we patch it into a switch ok it what if I was a what if I put a firewall right in the middle of that cable that's what we're doing and don't weigh that we're saying that so I can control traffic in and out of that system that's not host-based it's within the kernel of the ESXi hypervisor and it's not disabled is it part of the distributed V switch or is it on the V Nick on the on the it's between it's between the distributor switch in the v neck so it's right in the middle of that so I'll kind of show a little bit a show slide to come so do you I think any kind of hit or is there CPU cycle loss for this because again and whenever you put a firewall in your traffic general absolutely right so there's there's always going to be some there's always going to be some some hit what we've seen at scale is is three to five percent where the CPU overhead okay that's so and I'll explain this a little bit further it could be a lot if you have a lot of you get big quick yeah but let me let me let me kind of it let me kind of break that out for you and just just uh just a second here so we hit this whiteboard real quick so if I have a vSphere host with VMs on it and each one of these VMs has a firewall before it goes outside to the logical network think about this as we put we're time saying that we're putting the firewall in capabilities with inside the ESXi host okay how many hosts to do certain customers have maybe tens maybe hundreds maybe thousands right this putting that firewalling service in the host itself scales horizontally so technically as you add more hosts to your environment this firewall gets bigger and we think take things like consolidation ratios twenty to one thirty to one right if I had a thousand virtual machines and I need to provide security between all thousand of those virtual machines if I did it with a physical firewall I would need a very large firewall to accomplish that right from the hosts perspective if I'm running the security software in my kernel I get kernel speeds or near line near line rate speeds so if you had two ten gig Nick's coming out the back of this I could push around nineteen gigabits a second worth of firewall throughput okay I couldn't push that much capability at the three to five percent overhead of what I'm talking about but I don't have to always push that amount right because think about it my virtual hosts have a consolidation ratio of say twenty to one or thirty to one if you use the physical firewall I need a firewall that supports all thousand of my virtual machines right if I use the NSX firewall that's in the kernel itself I only need to provide firewalling services for the consolidation ratio that sits on that host itself because all of that firewalling takes place in the host does that make sense so as I scale and I add new workloads I add more firewall incapability I add more routing capability and I have more and I have more switching capability back to your question on the host base side of things since we're running in kernel the only even if you were to disable the firewall it fails closed okay so if you even if you you would have to compromise the hypervisor to be able to do that if you were an attacker what's generally the first thing that you do when you attack a system I shut the AV off I shut the host-based firewall off right I shut those things down those are things that are easily compromisable on a sana system basis if I have a firewall that cannot be shut down from the guest because it's running in my hosts that is a much better and it in a reacts in a sub-millisecond sub-second type of response time in terms of being able to apply a security policy that's that's a great point let me just counter with this question Moser most traffic these days is over port 443 okay HTTP is I saw the well I saw the tweets and I know somebody hates at a station yes I think I'm sorry huh your firewalls not gonna be able to have any insight into that unless you intercepted and decrypted is there any thought about that sure and your firewall side sure so from our firewall side as I'm gonna kind of move over here we do have some layer seven capabilities within our firewall okay so we we have we have a roughly around 70 or so application IDs for for taking a look at traffic now we look at the packet we're not actually so you talk about HTTP right so we are not an SSL proxy are so we're not going to decrypt we're not going to Deepak and inspect and go from there what we because that's a very CPU intensive process we have partners that do those things so Palo Alto Xand checkpoints the nice thing about nsx from that perspective is if we need to send if you want to send for deeper packet inspection that's past our firewall level you can send you can redirect those services to a third party service a third party SVM that can actually do those things so if you wanted to look at HTTP traffic and you wanted to do actual inspection of what's inside that there are partners that we partner with checkpoint and firewall you know and fortinet and Palo Alto that have been doing this for a lot longer than we have and have a more robust threat prevention right so we don't have IP s we do we don't do deep packet in that regard so what we can do though is from our firewall we can say if it's coming across the HTTPS I can take a look at the sub at the sub at the sub data within the packet header and say what version of TLS is it actually coming across so I can actually still I can actually still control from a layer seven perspective I can say you can run HTTP to HTTPS but it's got to be TLS version 1.2 right so we're not gonna allow 1.1 to run in our environment or anything along those lines so we can get that granular from that perspective I know kind of where you're going that's where we have our third party heather gray says well Chris just challenged me on Twitter and he said he would challenge the idea that most traffic east west is 443 and you're probably right it's more than 389 it's 1430 3306 33 people traffic that's right but your um I mean yeah I would I would agree with you on that but it still begs a question where's the real value here is it that was perfect for me and only tag this to equation so you saying oh hey I can stand for group policy and establish you know uh policies machines and then write some scripts and push out each of my learning machines sure I bring up a new domain new IP address now I've to go do a whole bunch of busy work to allow east-west traffic for each of those verses he can establish a policy and says I allow this traffic because I trusted my establishment and it pushed us to everything instant that's what good wear this for wear wear this wins is in the DevOps model where you're out of bounds where a security team can still be a security team and make sure that the firewall rules are gonna be the same across everything and just say here you want to deploy a VM do whatever you want but we control the firewall so and it's more than just the compliance check you went at the DevOps layer because now the admin can't disable that yeah but you also want it to compromise host level because now the attacker can't disable it and you can then quarantine the host independent of the individual machine because it's being controlled by an outside control that's out of bounds yes yes and so and there's our performance is better than host base yeah so if you've seen if you've seen some things like agentless offload for you know agentless antivirus right generally the performance is much better than running full agents with inside the actual system if you think about it in terms of like windows-based firewalling or IP tables or whatever you have to know a lot of information to be able to write those rules and every time that you need to either add another application or that application changes or something I've got to go back to that policy I've got to redo it and it takes it's a lot of operational overhead to run it in that regard what we can do is is we take the inventory information from things like V Center and so forth and we can write our security policies based on objects from like say V Center right so I can say that V m1 is my web app in V m2 is my is my database or my application server and I can and anytime I decided to spin up another web server it would immediately be pushed into the same security group and then the security would immediately take place if you were to do that via group policy you would have to build the machine then I would have to add it to the I'd have to add it to the group policy I have to do a lot of extra overhead to kind of do that especially for especially for something that could be easily compromised by just shutting down the firewall so from our perspective the VM admins or any person that's actually using the server itself could not disable the firewall they could they would have to be that that's a great point I would suggest the other thing you could say is that the your your product that your firewall product probably has central logging it's very difficult to do central logging with yeah I'm just firewall yeah and I don't even know where I would start with it on a host-based firewall on Linux yeah or even Event Viewer generating five million transactions per millisecond yeah and I could and I'll show some of that and I could show kind of where we're doing from a logging perspective I think I think one of the previous points that we were talking about of the east-west traffic so if you think about nsx layer seven firewalling it's actually tailor-made for layers east-west so there are parties that we give is really Active Directory DNS traffic sequel traffic these kind of app IDs we're not really looking at URLs or facebook chat or something like that yeah those are more that's more north there's more north-south types of scenarios right so so from in a sexist perspective the the value add if you will is our ability to help with remember help secure those latter that lateral movement so from VM VM blue to VM green most environments have unrestricted or unnecessary traffic that could either be instantiated could come up between these systems you know one system could actually talk to another there's there's you know 65,000 open TCP ports so any port or protocol could be used and not only that but there's no real context awareness really of what those applications of what that application actually is not without some kind of third party type of service but within a sex okay sorry go yeah just a question I didn't get what is done by the nsx vital and what is done by your ecosystem partner sure so from our firewall perspective I'm getting ready to get to kind of get to that just a second so from our firewall perspective we put the V put the firewall at the v-neck of every one of our virtual machines and that is a stateful layer two through layer four plus a little bit of layer seven firewall and capability okay so this isn't ACLs or anything like that this is a stateful we have a cont we have a connection tracker that's actually with inside the actual EXI hypervisor so we are keeping track of those counter of those conversations and so forth so that when the virtual machines establish a communication there's no need to write bi-directional rule sets for those systems it is a stateful system so pervy NIC stateful services if you need to go outside of the services like cowson was saying if you need to go outside of the IDS that we have or you want something like you know an SSL proxy where you want to dig in to 443 that's where you would do some kind of cert we would do service assertion so what we what that means is we can have the ability to write our rules and we can redirect traffic to a third-party system because there the nsx solution is based on the group based policy and the contracts right it's like of a stack yeah so if I say this machine talks to this machine and it talks maybe it talks to over a couple of different services right but I want to actually take a look inside HTTP and I want to do deep packet inspection I don't have to send all my traffic like you would have to send in a physical world I would have to send everything over to the DPI engine and everything would be would be sent if I knew that I didn't want to I didn't need to look inside HTTP or anything else but I wanted to look inside HTTP I could only I could send just HTTP traffic to those GPI three partners and have them actually do then do the detection that way what we say is is let the VMware it let the V the nsx firewall the distributed firewall do the bulk of the east-west firewalling as much as possible for these types of services right so let it do the bulk of that if you need to send it somewhere else send specific traffic and we have that ability to redirect specific types of traffic to the third-party system to do that that can be physical close yes so as you come in if you had traffic coming from a physical environment if this was a physical server right and it was coming in I could send any traffic that's coming from this destination to the third-party system if I wanted to do that okay so we get down to that fine-grained fine-grained security and like Tom was saying it's about shrinking that attack surface right so if blue needs to talk to green we only know that it needs to talk over a specific port and protocol and we only know that blue needs to instantiate the conversations agree Web the app right app can respond but apps should never necessarily instantiate a communication back to the web server or database or something like that so we can control that east-west traffic by specifically writing a policy that says these two systems talk over these ports and that's it that means all of the other unused ports that are normally open in this type of scenario are now closed and the only way for someone to cut the compromises system it's not silver bullet but we bring down that attack service right so we limit the options of someone being able to traverse laterally in the environment the other thing is go ahead so I work with a lot of different organizations I'm almost always saying segment your data erasure signature network segments your system the pushback I always get is well we don't necessarily understand our workloads we don't necessarily understand what the traffic is yep if we do it's going to take too long to implement if we do it something might break and that's just segmenting let's say a DMZ or a manufacturing plant yep let alone doing micro segmentation what tools you keep saying you know this you know this and if it was gonna get two VMs great what tools do you guys offer on an enterprise side so there I can counter that well ok I know you don't know but here let me help you figure that out sure and so I'm gonna get to that part and the operationalizing piece we're going to talk about writing security policy and the tools that are associated with rocking sense so this is this is what we just speed up a little bit this is what we're basically able to do right we're to able to take the VM concepts of all the virtual types of workloads that exist in your environment create logical constructs around those systems we can create security groupings around that application itself and then now every VM can be its own perimeter so we can start saying that this system can talk to this system and this system can talk to this system but this systems cannot talk to any other applications in our environment so going back to kind of the dmz use case or something similar you could technically have a web application that sits in your data center sitting right next to your HR database but you have not allowed those systems to talk to each other so there's no way for someone laterally traverse to that other application because you have a different security posture for your HR application that is different than say your web facing at your web hosting types of system and one thing that I would often jump up in some of these things whether you're doing some type of firewalling is since it's at the v-neck level it doesn't matter what your MAC address or your IP address absolutely it follows the Machine right yeah absolutely so the magic that we do when I say that we talk about we do things that layer to right so what we do is we still at the data plane layers still translate those systems IP addresses right that we still translate those things to MAC addresses and so forth but we do all that we do all that on our side so when you write your rule set you just say web to app or virtual machine named a virtual machine name and then we do the translation at the data plane Wow so that means like at fqdn with that you couldn't just put it in it's more like a gooood at that point okay good one can talk - go ahead - so when I firewall my systems my VMs I think about fqt ends mostly fqdn inside here we write our apps - fqt ins yep but I can spoof that this you could if you if you attack with DNS server so we're working on things like that so fqdn based firewalling we're gonna be doing some things like that okay where we're gonna be able to have those things especially for things like URL filtering and so forth those kinds of things are gonna be are gonna be coming but like you said this makes it network topology agnostic meaning that it doesn't matter whether or not these systems are on a flat layer 2 network or multi layer 3 networks it doesn't matter to us we can still provide the same kind of firewall and capability even if you have one large layer to segment so we have there is a customer that I know of that puts all of their virtual machines on one giant network how do you do security in the physical world to that it's very very difficult right so if I have all my virtual machines sitting on one network I could use the NSX firewall to still control traffic between those systems regardless of what the topology of the underlying physical network actually looks like ok talk a little bit about how we do some of these things so from a context perspective you know layer two through layer four four five tuple I mean that's pretty pretty straightforward layer seven application ID network context being things like logical switches so the nice thing is is that from a nexus perspective you can select different types of objects to create your security policy you don't have to use you don't have to use VMs you can still use IP addresses if you want to use those so for things for the from the physical world that are accessing your applications you can still control traffic using an IP address as necessary you could have logical networking from an NSX perspective so if you're building logical networks logical layer 2 networks in NSX that's that right on top of your underlay the logical switch you could use the logical switch construct that says all my virtual machines that live on that logical switch I can control traffic for those systems as well workload context being things like security tagging operating system VM names and security posture so one of the one of the one of the use cases we had for some of our customers is around operating system type so customers that we're leveraging or using I use the word leverage wrong Windows Server 2003 systems they had a lot of Windows Server 2003 systems they'd they were trying to figure out which those systems were you can actually create a security group that says that the OS type if the OS name equals Windows Server 2003 I want to group all these constructs immediately so I can immediately group those constructs right into one security group right away and immediately start looking at how I want to secure those systems security tagging being our ability to basically tag a system and say that maybe it's part of the application tier maybe it's part of the production as part of the production application and so forth as you build systems the nice thing about this is is you can create a security group and if you tag it with a specific security tag it can be placed automatically into that security group I'm going to talk a little bit about to have the security group concepts work in just a few minutes the other thing is I kind of glanced over this a little bit is around user context and our ability to do identity based firewalling so that is our ability to use a context engine that we have within the vizor itself that actually does a lookup against an Active Directory s ID and it what it can do is it can it can place that user and say these users have access to this application and the way you write your security rule is you say this Active Directory group what regardless of where they regardless of where they live is accessing this application and only those users can access the like in a Kerberos ticket you could look at this SID yeah so when we do a TCP connection between it has to be TCP base right now we're look we're doing things like ICMP and UDP and so forth okay but is if the user instantiates a TCP connection to another server the identity firewall immediately checks the user against the actual after directory s ID group that they belong to and if they don't belong in that group it won't allow communication that makes sense user session based being things around RDS H so folks familiar with RDS H Remote Desktop session host right so so I said that our firewall translates things that IP address Rd SH space systems if you write firewall rules for re SH based system what's wrong with that fqdn base got a broker well it's broken because there could be 50 users logged into that system all doing different things right so what we've done from RDS Atrus perspective is is we've used that user context like I was discussing before and as users log in to the to the actual Rd SH system we can write granular based policies based on each one of the different user groups so a you so 50 people from 50 different groups could be logged into one RDS HS and I can control all 50 of those users and where they go but tcp only tcp only run okay yep so security groups are the what you want to protect right so this is our ability to basically group the logical groupings between the systems right so dynamic inclusion static inclusion and static exclusion let's go back to let's go back to sixth grade math please excuse my dear Aunt Sally everybody remember that so the way that this works is dynamic inclusion plus static inclusion - static exclusion equals what groups mean okay do the parentheses first go from there and that's how your groups get built the nice thing about this is is that we can use all the different types of membership criteria so we have computer names entity DM names and so forth that can actually be used to create these security groups so they don't have to be IP addresses they can be a logical constructs from things something like V Center and there's a security policy is the how that's the how you want to protect these systems right so do I want to I want to create you know you know create a policy and then apply it as many times as I want to create that so things like anti-malware vulnerability management for things like guests introspection so if I want to redirect traffic for antivirus systems and so forth I would use guest introspection for natural work introspection that's where I would do things like ids/ips services or third party layer seven deep packet inspection is how I would do those things okay it's like a little bit about operationalizing and I'm going to get to the demo so zero trust we're gonna kind of go through this right this is real quick basically the starting assumption retreat everything like a like a threat and then we act accordingly the design principles around isolation and segmentation basically saying that we're going to isolate the applications and then segment them right so we can either do isolation through network virtualization by creating logical logical networks with nsx and isolate those systems from one another and then we could do segmentation is by saying that that virtual machines that sit on those logical networks can't talk to each other or can talk to each other over specific types of ports and protocol the basic being around least privileged right again network least privilege of saying that this system can only talk to the system over this port and protocol or this context and last oh go ahead in reality outside of greenfield opportunities do you see people actually adopting a zero trust model or are they going the it's zero trust except we trust everything and then we build policies around it but even then we still can't pull that trigger yeah so so that's where things like the tools have come into place to kind of help which are great tools to help get those things kind of moving right and get those and get those projects moving because everybody knows that every Apple doner has documented fully every one of their applications right exactly they know how the applications talk etc so we have to rely on tools you don't know what you don't know but the nice thing about this is is as you go through that process of app rationalization and and going through the process of monitoring your applications you learn a whole lot more about your environment the nice thing about that is is then that can be actually poured it over to say disaster recovery from books and things like that so it's actually and some people think it's an exercise in futility in futility but to be fair it actually Nets a lot more rewards by doing it than it does not doing it because if you tied significant the moment they run log in site they start to see the action absolutely yeah all the audience absolutely absolutely so where we see most customers from greenfield perspective sure we can immediately start with that kind of whitelist zero trust model where we want to start everything out right away in brownfield types of environments you know a lot of customers start with one simple application their specific use case that they want to accomplish for things like health care like they want to you know one of my customers wanted to do you know secure like care fusion which is like their their application for you know Schedule one drug monitoring right and so forth so that's what they started with the start and then what they did was they started building these more secure types of clusters where these applications already had these security postures in place and then they slowly started migrating the other applications over to those environments but you have to know how those other applications interact with everything else otherwise it becomes kind of difficult to do that that's where the tooling kind of comes in from that perspective from ubiquity and centralized control our ability to do the security policy again public cloud on-premises from one from one nsx manager our ability to write those policies regardless of where they live so just to follow up in a public cloud so we could apply these same principles to an AWS absolutely AWS or an azure workload so and I'll show and I'm gonna show how we do it for an EMR application here in just a second I'll show kind of how that works thank you yep promise we're almost done here so from a slide perspective didn't mean I am beating people up with slides normally I would have done this on the whiteboard but from a Apple so from that we see customers basically building their their security policies based on one of these three kind of different aspects right so network based policies are kind of more physical firewall right and then an IP address you know those kinds of things but policies are very network centric meaning that I need to know the IP addresses to write my write my policies infrastructure base are very similar to like what Tom was saying where you know infrastructure centric types of things are I'm using a logical construct it's a logical switch or it's this data center or it's this cluster or those types of things and as we kind of move up the pyramid to the very top are where most of our customers kind of start with and that's our ability to do micro segmentation around a specific type of application where the data center environments are dynamic the vet work the workloads move around the nice thing about this is is that as workloads move around the firewall and policy all the security policy moves with the application so as our if if our systems are working on one host and move to another things like DRS are shuffling things around due to resource scheduling it doesn't matter from NSX's perspective the same security policy is enforced even under the emotion okay this is what we've this is what we've seen for most of our from our most commonly deployed model for how we write our firewall and rules and breaking down the rule sets into specific types of groups right so the top ones being around emergency rules those would be things for like quarantine or you know I need to do a quick allow rule based on something I'm doing some work on quarantine in being I need to stop the bleeding now right I have an I have a workload that is that it's compromised and I need to immediately start blocking traffic to it as much as possible I can put a rule at the very top the firewall works in a very similar fashion to any other firewall top-down and go from there infrastructure based rules for things like shared services so a DD and SMTP we all know that we're trying to secure applications from you know talking to themselves or other applications but we always forget or sometimes always you know sometimes forget that these systems actually all still talk to all these shared kind of services right so they still need kind of these care and feeding for being able to do that environment rules based on things like our ability to provide security and say that these are development workloads and these are production workloads so from a customer perspective you could have prod and dev running on the same hosts you can give them more priority through other other things with vSphere for like resource groups and so forth but you can also have the same security posture for your development environment and your production environment at the same time so when your cut when your application developers test their code they're actually testing against real production based rules and all they do is they move that code over to the production environment that has the same rule sets in place right so our ability to make that easier for folks to because as we tip we did so we test it in tests and it worked just fine then we move it to prod now all of a sudden we can't figure out why it doesn't work go ahead I don't know if you're gonna cover it in this at all or if you can speak to it but when you're wanting to provide protections or you know firewall in an apk s docker kubernetes type instances in context yeah so we handle we handle that from a from a kubernetes or a PKS perspective there is a plugin called the the NSX container plugin for kubernetes and Cloud Foundry functionally what that is is that's a that's a plugin that runs that translates things like Network policy and it translates them to the NSX firewall to create firewall rules I could show you I have I have a it's not fully it's not fully fleshed out but I can kind of show you what that looks like in the firewall but basically as you write your container based workloads you write a network policy for kubernetes right and you apply that network policy for how those containers talk to each other when you apply that through something like PKS NCP intercepts that and translates those into NSX firewall rules so we actually translate all the container based network policy over to a firewall rule which also means that I can now allow my VM workloads to talk to my containers through the NSX firewall the same way that we would do a VM to VM type of communication that answer Chris okay thank you just quickly rules rules between our application right so we know that our applications still talk to other applications and then obviously our rules between our app tiers or our web tiers and so forth and then lastly is a deny rule depending upon if you're doing a white listing type of model the nice thing about from a from a from in a sexist perspective is if you think about it I put a firewall at every one of the v-necks but my firewall is actually default allow does anyone know why does that make sense why you would be a default allow because if it's not default allow you just denial of service to your entire infrastructure by doing it right by putting the firewalls in place so it is default open to start so that you can on board the applications quickly the default rule here is set for deny that's typically in a greenfield environment the nice thing is you can write application base blocks as you see fit up further up in the firewall so that kind of to the question about how you operationalize these things and how you actually get to this process all we need to do is we need to prepare the host for NSX we need to install the NSX bits the last thing is is we need to identify the applications and start monitoring the flows between the applications so from our application perspective we have arm we have the application rule manager which actually goes through and can take a look at the flows in real time and actually create recommendations for firewall rules the next tool is around the realized Network insight so if you realize network insight is the it was the Arkin acquisition so that has the ability to it's kind of more robust in terms of being able to see the entire infrastructure it does more than just security planning it's more it has a more holistic view if you will of the entire network infrastructure you can see things down to switch level also into the virtual switch level and the firewall and capabilities of Palo Alto and checkpoints firewalls and flows and flows yeah so the nice thing about this is is that these two tools here provide you recommendations based on how the application actually functions for how to write your firewall rules huh dar lured the arm rules automated like if it's useless the arm is the arm is actually the arm is actually automated the VR ni provides you the recommendations and then you go in and actually take a look at the rules the nice thing about the nice thing is is that these systems will actually let you know whether or not there's actually a rule already in place right so it gives you a recommendation that will actually show you the firewall rule that's coming from the NSX distributed firewall and tells you which rule is already being applied for that flow if that's not the rule that you want then you can move up you can change the rule around or rewrite a new rule based on the flow and then it will it will it will show that rule instead its arm has anomaly detection built-in it does not have anomaly detection in terms of like like the allocation is behaving someone that laid down loaded three gigs from a sequel database will Sharon Lily get 200 makes a day absolutely right so it doesn't it doesn't do things like that from an anomaly detection perspective what we what the what these tools do and I want to say do again but what they do is that they provide you the flows so that you can actually start taking them back to your application owners and saying this is what I see your application actually doing we need to start actually taking a look at those flows and determining whether or not those flows are the actual flows of the application or not once we have analyzed the application profile and understood the flows and rationalize all of the different all of the all the flow information then we're going to write our security policy and put it in place pretty pretty simple concept the the question that usually comes up is how long do I monitor my applications and my answer to that is don't is it depends the typical IT answer right depends on the application so understand the application don't monitor a payroll application that runs a batch job every two weeks and only monitor for two days right it's mostly just common sense in terms of you know what the how long you need to monitor the nice thing is is that most of these tools can monitor up the application for well over 30 days well into you know 90 and 180 so forth so from there

Channel: Tech Field Day

Views: 1,350

Rating: 5 out of 5

Keywords: Tech Field Day, TFD, Security Field Day, XFD, XFD1, VMware

Id: T2aPudOcLNE

Length: 44min 23sec (2663 seconds)

Published: Fri Dec 14 2018