Unlocking Cisco TrustSec: Dynamic Segmentation and Security Group Tagging with ISE

Good morning, good afternoon, good evening, everyone. Welcome to today's security expert insight series session covering Cisco identity services Engine segmentation.00:08My name is Tim Bbby and I'll be the host for today. Before we begin, we're gonna jump through just a few key notes. 1st off, our series overview. This is session number two. Last week we had our foundations of network segmentation talking about VLANs, ACLs, and how I.00:20This uses those to segment out your networks. Today we're moving into segmentation and security group tagging with ICE, and next week we'll be finishing up with integrations using the segmentation and security group.00:40Policy taggings, quick note today we'll be using Slido throughout the session for Q and A please don't use the chat for Q and A if you can use the QR code on the screen as well as the code and passcode down on the bottom left to.00:53Enter into the slido. That's where we'll be collecting all your questions today as well as running a Q and A here in just a moment.01:13I'll leave this up for a few seconds just so everybody has a chance to get in.01:21Alright, and with that we will go ahead and.01:41Stop this for a moment and log back in.01:49Okay, running our, this will be the only Slido question for the day, just asking in general what other ICE related topics you would like to review in future expert insight series sessions. So I'll leave this one up for a few moments to allow folks to get in and answer that one beforehanding.02:09Thing off to Eric.02:29I think cert automation is going to be a big topic upcoming future releases, there will be some additional functionality within ICE that we'll probably demo out in the next few months as soon as it's available in product for that.02:50Nice API is another good one that we will definitely get on the list and we'll give this one like another 30.03:25Seconds or so before handing off to Eric because I know we have a a lot of content to get through and not a ton of time to do it.03:44Alright, Eric, if you want to go ahead and take control, we'll pass it on to you and I'll be back in a little bit to run through some demos for you. Alright, thank you. Okay, so good morning, good afternoon, good, good evening, everyone, and welcome. Thanks for joining.04:07Us for this expert inside session. Today we'll be talking about unlocking the power of trustsec. I'm Eric and I'll be joined by Tim. We're both customer success specialists over the next hour or so, we'll look at why segmentation matters.04:27How trust sec changes the game, walked through the configuration and the three core pillars and then we'll finish off with a live demo. So let's let's get started. The agenda for today, we have a packed agenda, we're gonna start with an introduction to Cisco ICE, we're gonna do a segmentation.04:46Overview, we're gonna jump into the trust sec fundamentals. We'll cover configuration and the three core pillars. This is really the heart of the presentation, and then we're gonna jump into a live demo that Tim prepared for us and we'll see trust sec in action. And then we'll come back to the slides.05:05To wrap it up with a summary.05:25Okay, so before we talk segmentation, let's take a minute here to just cover, ICE and what it does, so added score, ICE is doing three things. 1st, it's collecting attributes about every endpoint that touches the network, who or what it is.05:30From identity and profiling plus building conduct contexts from active directory groups, device types, location, posture. Second, it uses those attributes to authenticate and authorize the endpoints deciding whether it gets on and what it's allowed to do.05:47And 3rd, it shares that context with the rest of the network and security stack through PX grid. So devices like switches or firewalls, could be secure network analytics or cat center catalyst center can all act on the same identity information.06:08So that's the, the, the flow you see here in the slide. We're building the context, summarizing it into one decision and exchanging it so everything downstream can enforce consistently.06:28Okay, so before we go deeper, I want to put segmentation in context. We see a list here of features that ICE provides and just notice that segmentation is not a separate product. You have to go out and buy. It's one capability of the ice.06:44Platform that many many of you already own. So, in terms of licensing, traditional segmentation can be used which are essential licenses, but if you want to unlock the power of trust sec, you need to go towards the advantage licenses.07:03Yeah, sorry about that. Okay, so, let's start by comparing traditional way of segmenting a network versus trustsec. What is segmentation? So last week on our expert inside session, we covered segment.07:22Basics with VLANs and this slide we see we see that approach as well. So.07:41So what is segmentation? Just to quickly come back on it? Simply put it's dividing the network to provide the right level of access to your users and doing so with, you know, the least privileged principles. In this example, on the slide, it's a healthcare example on screen so we see a doc.07:48That needs to have access to confi confidential patient records. We see a lab technician that needs to have access to hospital staff internet but should be denied to confidential confidential patient records and we see visitors.08:09Visiting the hospital that, you know, would only get access to the hospital Wi Fi, and so basically what we're showing here is that it's the same network, but we very different levels of access and will use segmentation to provide that access.08:26The traditional way, you know, using VLANs and also we're showing how this can be done with sgts and this is what we're gonna be focusing on in today's presentation. Okay, so this is one slide that in.08:41Pretty much explain trustsec as a whole like sort of a elevator pitch.09:01So let's go through it. This is gonna give us some good context before we get deeper into these topics. So 1st thing what's the security group? A security group is a set of users or endpoints that share the same access policy. This is defined in ICE.09:07A security group tag is, 16 bit number that ICE assigns to that group. Sorry, and here on the screen we see this the the security group tags expressed as hgts. On the left side you see the employees, they have an SGT four managers SGT 20, and on the right.09:23Side, you have your, your servers who also have their own set of sgts, ok?09:43You have admission endpoint admission control. So this is how the network devices, sorry, this is how your endpoints get on the network and get classified using their authentication methods, whether it's dot one x, map or web auth. And then you have network device admission control or NDAC.09:51And this is how your network devices are gonna authenticate with each other and.10:10You can also enable macsecs or encryption between those those devices. So let's also talk about ingress ingress and egress ports. So the ingress is the point where traffic enters the network on the switch closest to the user and this is where we classify.10:17Find the hgts and the egress port is gonna be the point where traffic exits towards the destination on the device closest to the destination. This is where we want to enforce our sgacls. We're also gonna talk about SXP.10:36SXP is the SGT exchange protocol. It's a TCP control plane protocol that carries IP to HGT bindings from a speaker that could be ICE or a switch to a listener device that can tag inline. So we'll use this when inline tagging is not possible.10:52Okay, so if we look at the flow here on the screen, we basically see that on the left side, we are classifying at the ingress port, the switch closest to the user, this is where we're assigning the tag as the users connect and then.11:14Between the ingress and the egress, we can see that we're doing some inline tagging. So we're propagate, we're propagating the tag from one network device to another. So this is just one propagation method. We're gonna see two of them in this presentation. We're also gonna see SXP, and you can also see actually the S.11:32XP connectivity from ICE down to.11:52Down to the network devices. And then on the far right side, we see the egress port where we're enforcing the sgacls and this is being done by using our egress policy matrix, which we're gonna look into more in details, and this policy matrix is gonna help you define your source and destination.11:57Patient groups and enforce your sgacls.12:17So in one line, if we can sum this up, I would say, classify once at ingress carry the tag and enforce at egress. It's a bit of a simplification, but that's how we can summarize it. And one important thing to note as well is that this is all inde independent of IP subnet or VLAN.12:20And the f the policy is following identity and.12:40That's, that's very important to, to, to remember. Okay, so let's move on here and explain a bit what a security group tag looks like on the wire. This is an ethernet frame.12:45And, we have at the top, we can see the optional macsec header that we talked about for encryption. This gives you your layer two encryption and protects you against men in the middle attacks. Then there's your optional VLAN tag, and then the piece that really matters here that I want to show on the slide is the cisco.13:02So metadata header and the SGT value in there, the 16 bit value.13:22That's the tag that we're gonna, be talking about. A couple of things to note as well is that the frame gets tagged at the ingress port as we just saw in the previous slide, only on trust set capable devices and the tag is added before other layer two services like QoS.13:28And one more note here is that the header adds actually roughly 40 bytes to the frame. Okay, so, let's keep going here and talk about talk about.13:47The the three pillars. So we covered we already covered central policy. We talked about ice, that's our engine, and then the three pillars underneath which we're gonna dive deeper into as the presentation goes. So what's classified here classifying is assigning the tag based on context that.14:04ICE is collecting, then propagating means that, you know, we're gonna carry that tag across the network so that.14:24We can finally get to the enforcement points and so what is enforcement is to forward filter or drop, make those decisions based on the tag that we were able to propagate and the policy matrix that we configured.14:33So, very important to remember these three words classify, propagate and force, we're gonna talk a lot about it during this presentation. Okay, so I wanna show you guys here on this slide what identity based segmentation kind of looks like.14:49Here we can see that we have different endpoints that are grouped by identity and the tags are assigned to each group. ICE authenticates them and drops them into the right security group. And once that's done segmentation gets applied by identity and not by location using IP pools or.15:08Subnets.15:28With VLANs and so in other words, we're shifting here to identity driving segmentation. Okay, so let's look at a side by side comparison to see what network versus identity based segmentation looks like.15:29On the left side here, we see that segmentation is applied using VLANs for different types of traffic or types of users. This method of doing segmentation, is more time consuming when we compare to trust sec, it's more complex to maintain as well as your.15:49Network grows and on the right side.16:09We're showing, the same network, but now using htts to tag the traffic for different security groups. So this is gonna help you simplify management and reduce OpEx and also is gonna provide you the ability to do micro and macro segmentation.16:12And one thing to remember here is that trustsec is gonna help you decouple your access rules from the topology. So this is gonna make you more agile. Alright, so the ACL explosion, here's one of the pains actually that trustsec helps solve.16:32Traditional models, you write ACLs for source and destination. These ACLs can quickly become hard to manage as the network scales. So this slide here shows the table in the worst case scenario where each host has an ACL. So to be honest with you guys here.16:52In modern security, network designs, we're using VLANs, and subnets. So this reduces the ACL explosion. In this case here, e.g., if, we were to use the worst case illustration, if S one wanted to connect to D one it would require for.17:12Four access control entries and then if we wanted S one to connect to all six destinations, this is where we see a total of 24 access control list entries and.17:32I mean if we continue going, four sources, six destinations, four ACL each. So you can see how this starts growing inside your switch. Also, once again, you know, to reiterate is that your policies here are tied to your topology and.17:44This makes it harder to manage as your network keeps growing.18:04If we look at how the same problem is solved with trustsec, in this illustration, once again, we see the ACL explosion and keep in mind here, as you see this is the the worst case illustration, so you do see numbers like 12040 8000 ACL entries, even though in reality in the real.18:09The world, we might not reach those numbers because of, you know.18:29Rules summarization that can be done with subnets and IP pools. However, I just want to kind of reiterate here that traditional ACLs, even though they're well summarized, still reference the IP or a subnet. So your policy once again is tied to your topology and this.18:34This is what makes it harder to manage in the long run.18:53Okay, we're gonna show here, I'm showing here a quick example of how trust sec can block lateral movement attacks using sgacls. And we're gonna dive deeper on the enforcement portion, but here is just to show a use case of.18:56Slowing down the propagation of malware and how trust that can help you do so. We see in the matrix that we are we've configured an SGACL called block malware blocked malware, and this blocked malware SGACL is blocking.19:17Traffic on commonly abused ports because enforcement is identity identity based here using HGACL using hdacls, it blocks traffic at the destination port and doesn't use the IP addresses. So any host in that group that becomes compromised is automatically blocked over those ports.19:37And since the SGACL enforces on the tag regardless of subnet, this even stops intra VLAN exploits. So, this can really help slow down malware propagation and contain ransomware.19:57Which, you know, means that a compromised host won't be able to affect another host on the same subnet. This is something that traditional segmentation actually struggles with. Okay, so why invest in identity based segmentation or trust sec?20:16Here we have four business outcomes, lower OpEx 80 % less operational effort. This is a research done by Forrester. Forrester is a leading global market research firm. Their research.20:35Found that trust sec software defined group based approach cuts the ongoing effort to manage segmentation by up to 80 %. The next benefit.20:55Is faster change in onboarding. You classify once and then you can reuse this enterprise wide. Once again, Forrester found that because classification is tied to endpoint identity, so using sgts or security group tags rather than the network topology admins can implement.21:07Or change network wide policy up to 98 % faster, 3rd benefit compliance and audit.21:26Your policy is now expressed as security group tags, not IP addresses. Just imagine going through all your switches and routers and trying to figure out which IP address is, is mapped to which IP pool or which users, which locations and so on. So.21:34This really helps with, you know, your compliance and your audits. And also your 4th benefit here is the ransomware containment. You shrink the blast radius by restricting east west lateral movement. This is an important advantage over traditional ACLs, not because.21:51Traditional ACLs can drop the packet, but because.22:11It's enforced by a group regardless of IP or subnet, you can really contain the movement within a VLAN, which like we were saying, I was saying, traditional segmentation struggles with. All right, so.22:16Let's look at configuring trustsec. Trustsec has three separate trust relationships. So let's review them. The 1st one here is the relationship between ICE and the network device. This is always required. Every NAT authenticates to ice over radius.22:33With pack or packless and we're gonna review this and what it means, this is how basically ICE trusts the device and how the switch will pull in environment data and sgacls. The other method, the other trust method is a switch to switch. So we have.22:54Ndag, which we talked about earlier on, network device admission control, so this is optional. You don't need it for, for the inline tagging. However, if you do configure NDAC, this will allow you to enable macsec, which is gonna create the encryption between your links.23:14And then you have peer to peer, using SXP and when you can't or don't want to do inline tagging, then this is where SXP is gonna help you carry IP to HGT bindings over a TCP session, ok? And it also uses MB five passwords.23:33This is independent to to independent of NDAC. Bottom line here is that ICE to switch trust is always radius based. NDAC is about device to device link trust and encryption, and SXC SXP is about transporting bindings.23:52When inline tagging is not available. Okay, so let's dive a little deeper here. We just said that the 1st trust relationship ice to switch, ICE to switch is always there and always radius based using pack or pack list.24:12This slide here zooms in, into that relationship and shows the.24:32And shows the three ways the switch opens its connection to ICE, and how you configure them each on on the nat side. So what do I mean by connection is that the link the switch uses to pull two things from ice. Environment data, so the SGT names and numbers and the.24:39SGACL policies for enforcement.24:59Okay, so three ways to build this link. Let's look at pack. 1st. Pack is your classic method of configuring this trust. You set your CTS credentials, you set the CTS authorization list and the switch does eat fast to get a pack.25:02From ICE.25:21The shared key though has a lifetime and this can cause issues as you know that that key expires. One thing to note as well here is that this works on any iOS XE and any ICE version, any ice version, but as I was mentioning, it can break when that.25:23Pack expires. So 2nd method is rest. So you can use HTTPS to, to build that trust relationship. You can point the switch at, at ICE.25:43With a CTS policy server command and try trust ICE using certificates. It pulls the same data but it'll do it over TLS and doesn't have any pack files. This is supported from iOS XE seventeen.X with ICE two.seven and up.25:59So two.seven actually is an older version. We're gonna look at the more recent version of building the stress and this is packless using radius or nopack. You keep the same CTS commands here.26:19And, you're able to download the same, the same data from ICE. It's much more simpler and more scalable. However, it does have some version requirements so you need to have iOS XE seventeen.fifteen and ICE three.four as a minimum version to do the.26:34This method.26:54Okay, so next, just, just wanted to show here a side by side comparison of these of these methods and how they differ so pack once again is.26:59Using a file provision over each fast. Rest is the switch trusting ice using certificates and over an HTTPS connection and pack list is dropping basically the pack file.27:19However, it has some version requirements in order to to use this. Okay, so the nice thing is that when we want once when we want to configure trust sec is that ICE actually walks you to.27:35To the whole rollout under work center trust sec overview inside ICE, it lays the deployment out in three stages. So 1st stage is prepare, you plan your security groups and do the preliminary setup.27:54The triple AAA and trust sec server settings, your network devices and so on. The defined step is the find stage is where you create your components, your security groups, your write your sgacls, you drop them in the in the policy matrix.28:09And you set up your SXP if you need it. And then the go live and monitor is where you're gonna push your policies and you can also start it in monitoring mode to see if you're ready to actually start the enforcement.28:24Okay, so in the next slides what we'll do is we'll go through some of these steps, some of these stages and show you how that configuration is done. Okay, so the 1st phase is prepare. This is where we actually configured that trust between ICE and the switch, and the key point is that.28:42But it's the same step, NO matter which method you saw earlier, so.29:01In ICE, when you go to work center device administration, network resources, network resources, network devices, you pick your device from there and enable advanced trust sec settings, ok? You set a device ID and a password and you make sure that the ID and password that you configure there matches.29:07That's exactly what you put on the switch.29:27With the CTS credentials command. So this is this is the 1st step for the prepare phase. It's not everything you need to configure door nice over the next few slides. We still need to create the security groups, write some sgacls, build the matrix, so let's the.29:29Let's continue and see how that works.29:49All right. So, once we're done with the prepare step, we're moving into the define and creating a group is, it's pretty simple. Again, everything is in work center trust sec, components, this time security groups, and, just simply you click add, you give it a name and.29:54And ICE automatically assigns a unique 16 bit tag. In this example, we see that the tag is has the number 17.30:14You get already 15 predefined groups out of the box and anytime you add or change one, it pushes out to the switches through the environment data. So, this is something you can also verify on the switch side with the show CTS environment data command.30:27One recommendation here is that when you name your groups, make sure that they mean something for your business. E.g., employees contractors, PCI servers, IoT devices, because that name is what your whole team is going to be reading in the policy matrix.30:46So it's important to make sure that you're precise with the naming. Alright, still in the defined step here and here's the the moment where identity becomes an actual tag.31:06This is an authorization policy in ICE. If we look at the rules, we see corporate employees, are getting tagged with SGT four. We see contractors are getting SGT five, we see the IP cameras are in the IoT devices group SGT twelve and we are.31:22By BYOD sorry devices are getting SGT 15, so basically inside our authorization rules, this is where we're assigning our security group tags to our endpoints or groups of devices that are, that we want to connect and assign access to.31:42Okay, next step here, and this is the last piece of the fine is where we're gonna create our sgacls. Once again, work center trust sec components, security group ACLs, we click add. On the slide here we see security SGAC.32:06CL, called malware block. This, is denying some risky ports, so you see two ports there being denied and the permit IP and.32:26Once again, the naming here is important because you want to reuse this same rule across many places, so make sure that the naming is is meaningful to you. Then once that HDACL is created, you need to place it in the egress policy matrix. So the way to make sure.32:38Six works, is that there's a source source group down the side here and there's a destination group up top.32:58Across the top and each intersection you drop in an SJCL here, we see contractors to servers gets the malware block ok so one thing here I want to note as well is that.33:07Writing the rule and putting it on the matrix does not drop does not start drop dropping your packets, Nothing is enforced until you turn enforcement on on the device, which is, the go live step that we're gonna see next.33:26All right, so it's time to deploy and monitor. The job now is simply to go live and, start monitoring and seeing that and seeing if, you know, what we've implemented actually works for us. This is what the production matrix looks like in ice. It's the single source of truth for the policy.33:45When you hit deploy.34:05Sorry, ICE activates and activates it and sends a COA a change of authorization out to the network, which tells each device its policy is still, so the rules aren't pushed. Each switch needs to reach back to ICE actually and pull only the.34:07The GCL it needs for the traffic it's actually seen. So it's not a big blast, we don't blast everything down to the network.34:27We turn it on and we inform the network devices and when the network devices see the traffic, they have the ability to pull the appropriate sgacls for enforcement. There is also a very interesting option here.34:34Which is the monitor all button, so when we turn on enforcement, we don't wanna turn it on right away and start enforcing and blocking traffic. The monitor all button really helps with turning on your policies, but not.34:50Not dropping so your counters will show that the traffic would be blocked but without blocking them. So this really helps you see if what you've implemented is actually what you want. And once you're confident with that, then you can turn monitor mode off and start enforcing for real.35:10There is one thing I want to call out here as well is that within ICE, you can use reports and within those reports section within the reporting section, you can actually monitor the drops and also you can do this on the switch as well with a command like CTS role based counters. You'll have a, one of the counters that.35:31Says monitor and then you can look at that counter and see if it's incrementing or not.35:51Okay, so, we're done configuration and let's jump into the 1st of the three pillars classification. There are two ways to classify and you'll end up using both on the left side here. We're looking at.35:58That dynamic classification.36:18This is the tag that gets assigned at the moment of authentication through your authentication methods, and on the right side, what we're seeing is a static classification. So this is where you map a tag to something fixed on your network, and as you can see here on the slide.36:21But there are different ways.36:41To do the static classification. We're gonna review them next. One rule of thumb here is that dynamic is at the access layer where things are moving and logging in and static is more like a data center where things are fixed unknown.36:44Okay, so, let's look at static classification on the switch itself. There are four forms and, you can see them here on the slide. You can map a physical, you can map an IP or a subnet to a tag with CTS role based HGT map command.37:07You can map a physical port under the interface, you can map, an entire VLAN to a tag.37:27You can also map a layer three interface, so, this method works and it's quick for a handful or fixed resources. However, if you have a big network and you have a lot of, a lot of.37:35Devices that you need to tag statically then this it's it's much more complex to do so. And also you would have to maintain this static classification on all of the different network devices. So.37:54In the next slide, we're gonna see how we can centralize this. Here is the same static mapping, but done centrally in ICE, you go to work centers trust sec components, and there we have a section for IP HGT static mapping.38:12You add your IP or your subnet, map it to a group and push it out to your devices. One thing I want to, you guys to note here, one caveat here on, on this slide is that only IP to HDT and subnet to HDT mappings can be managed centrally in ICE.38:27So the other ones, VLAN port and layer two interface mappings are not available in ICE, so those ones still live on the switch. Okay, let's jump into dynamic classification. The tag is just an authorization result and.38:47Here's here's what it looks like. We saw the authorization rules before on the left is the authorization policy with rules like production users, devs, guests, and so on each returning a security group. And on the right side is the security group table, which is mapping those different.39:08Different groups of endpoints to an SGT. E.g., an employee is four contractor is five and guest is six and so on.39:28Okay, so dynamic classification verification on ICE, this is how you would verify it on the ice side in the live log details for a successful session, you can see the authentication succeeded for user employee one. It's profiled as a windows, workstation.39:43And it matched our contractor rule.40:03Over here, but the line I want to, focus on is, the Cisco AVP pair over here, which is telling us which security group tag it's using. So in this case it's using group tag number seven.40:07Okay, some verifications for dynamic classification done on the switch, three commands that we can use show authentication sessions on the interface with the details, shows the session authorized with its SGT value.40:29Here in this case we see it's it's four. Show IP device tracking confirms the switch has learned the endpoint's IP.40:49Which it needs for the mapping and show CTS role based SGT map all shows that IP mapped to its tag with the source listed as local, meaning that it was learned right here from the authenticated session.40:56Okay, and some of these commands actually we're gonna see them during Tim's demo. So let's move on to propagation. So we've tagged the endpoint, but we we're tag sitting on a on one access which isn't much use by itself. We need to propagate it.41:15So let's get into.41:35The propagation methods, two ways to propagate. We already discussed a bit about inline tagging and SXP. We can see here on the left side that the tag rides in line inside the actual traffic and we've got a list of methods to.41:38To move this tag in line, whether you're using ethernet, macsec, or IPsec. You can see the tag traveling, you know.41:58From one packet, in the packet from one switch to, to, to the router, to the next switch, and this can be validated by doing captures and you which you should see in the capture that, you know, the tag has moved from one device from one hop to another.42:07On the right side is the control plane propagation. Instead of putting the tag in the traffic, as we saw before, you share the IP to tag mapping out of band over a separate protocol, either SXP or even PX grid, but.42:25For today we're gonna be focusing more on SXP. The rule of thumb that we can call out here is that we use inline whenever your hardware supports it and use the control plane method SXP to bridge the gaps where it doesn't.42:42And in real, in the real world, you're almost always gonna need both because of the ecosystem of devices that you have. Some will support inline tagging, some won't, so you don't want to create blind spot blind spots, you'll have to use SXP to fill those gaps.43:00Okay, so quick reality check here on what each device can actually do. So the switching and routing fabric cat nine K nexus, ASR, ISR, CAT8 routers and the catalyst 9800 wireless controller are all fully functional, they classify tagging line and.43:19They they can do inline tagging sgts over internet and and over VPN.43:40And they also enforce with sgacls. Firewalls are are a little different here. So secure firewall FTD can learn sgts over SXP or PX grid, and also tag inline over ethernet. And they can also enforce.43:46However, your classic ASA is SXP only, so this is the one thing I want to call out. And the other thing is older devices like legacy air, OS, wireless controllers, and any non HGT or 3rd party device will support classification and SXP propagation.44:08Only but inline tagging and SJCL enforcements won't be supported.44:27Okay, so, how do we get inline tagging to actually work? You have to tell the switch which links to trust and you can set this up manually with this command here CTS manual on the interface, and then you set a policy static SGT command.44:38With the trusted keyword.44:58The trusted keyword is important here because that keyword is what says trust this link and propagate the tag in line. And, as I was saying, if you take a capture, you should, this is your evidence to show that your inline tagging is.45:01Is working, so.45:20This is how you prove inline propagation. You look at it on the wire and this is a wireshark capture that you see here on the slide. It's a simple ping and by expanding the frame, there it is, you see the Cisco metadata, the HGT three here is your tag being propagated from one switch.45:22To another. Okay, so let's talk about SXP now, the SGT exchange protocol, it runs over TCP port 64000 999 to start the connection. Each end is either.45:42A speaker, which advertises bindings, a listen or a listener which receives them or both for bi directional connection. He needs NO special hardware since the binding just rides over IP and it uses MD five for authentication.46:02So a quick note on SXP versions because we have five of them, one through five here, as you can see on the slide because some of the difference matters. You see here version two, we added IPV six version three, we added subnet bindings so you're not stuck advertising host by host.46:21Version four was a big one, bi directional connections, loop detection capability exchange and built in keepalives, and version five is VRF aware, so single SXP connections can handle all your virtual networks.46:41Okay, so configuring SXP in ICE is straightforward. Once again, we are in work center trust sec, SXP, and, we add a device.47:00You give it a name and an IP, you set its peer role here, we set it to listener, and we pick the PSN, it connects to the SXP domain, the password and the version as well. We need to configure one quick note here, the field SXP domain just tells ICE.47:14To only share bindings among peers in the same domain, by default this value is set is set to default actually. And here is the matching site on the switch. You enable it with the command CTS SXP name.47:34You can actually set a global default password here and the source IP and then define each peer with the CTS SXP connection peer commands specifying the mode, speaker, listener or both.47:55Two things that trip people up here is, the roles has to complement ICE, so if ICE is the speaker, the switch is the listener and the passwords have to match. If that doesn't work, there's NO partial success, the appearing is either up or down.48:12To verify on the CLI, you've got some show commands so show CTS SX SXP connections and, and what you're looking for is, is the the state over here showing on the connection status.48:34And show CTS role based HGT map all shows also the bindings it learned with the source listed as SXP. If you see anything other than on like pending or flapping, it's most it's most likely always that the role or the password has a mismatch.48:56What we just talked about there and the previous slide. ICE also gives you a view of the SXP devices list, so every peer, its status, its role, its version, it's all in one place inside ICE, so instead of logging into every switch and router to.49:14From the show commands, you can just go into ICE and confirm everything is healthy. It's much easier for the operations teams to look at this inside ICE.49:33And this is the SGT bindings view, the actual IP to tag entries ICE has learned and it's the and the ones that it's distributing, you can see here, the IP, the group it's mapped to.49:44Here it's employees tag four and how it was learned. This is the real data that enforcement depends on. Okay so we've seen a bunch of ways a switch can learn the bindings and.50:01And here's the thing, it's that a single switch often learns the same IP from several of these sources at the same time, so which one wins when they disagree? This is what we're actually gonna see in our next slide.50:20This is the order of precedents and honestly this slide is very good for troubleshooting when the same IP shows up from multiple sources, this hierarchy is gonna decide the winner. At the top here, we have inline tagging and in the actual that one wins 1st.50:371st, then a live dynamic binding from.1X or map. Then it's SXP.50:57Then you have your static mappings in order, layer three interface, then it's the IP, the subnet, and the last one that wins is the VLAN to HTT. So knowing this order can really help you speed up your troubleshooting if ever you're stuck troubleshooting SXP.51:04Okay, so last thing here on propagation we talked about, Sorry, we mainly talked about SXP, but we also said PX Grid is also possible. So PX grid extends all of this beyond the Cisco fabric, so ICE takes in context.51:23Including the IP to tag bindings, it learns over SXP and then publishes it over PX Grid to whoever subscribes and you have a broad list there, could be a secure firewall, a catalyst center, and any, and really like any PX grid subscriber, so what this gives you.51:41Two is very powerful because now.52:01Your firewall can write rules using the exact same security groups as your switches. Everybody every device basically is working from the same segmentation context. Next week in our EIS we'll be covering integrations more in detail.52:03Okay, so we've classified, we've propagated now, time to review enforcement. This is where segmentation with becomes becomes real. So, this is the enforcement policy we saw before, we.52:25About the matrix, it's one of the most important things you'll see in trustsec. On the left, we saw the creation of the hgacls earlier on. Here's one called malware block denying the risky ports. And then on the right is the egress policy matrix.52:44Where once again you have the source groups down on the one side and the destination groups across the top, and at each intersection is where you drop your HDACL, so that's where your access rules goes.53:03One important thing to note here is that you have to actually turn enforcement on on the switch with the CTS role based enforcement command to start blocking traffic if you don't, if you don't, nothing, nothing will get enforced, and also keep in mind that if you have monitor mode turned on.53:19On then enforcement doesn't, doesn't doesn't work basically, it takes in consideration what you have in your.53:39Policy matrix, but the traffic is not dropped until monitor mode is lifted. Okay, let's talk about how the switch actually gets those policies, those sjcls. Let's review this in.53:48In five steps. So, you see here the highlighted column, this column here represents the destination group. So, number one, the switch learns it has traffic going to that destination. And then, 2nd step is that it asks ice over over radius for.54:07That whole column, ICE will send back the HDACL names for every cell in it and then the switch will download those hgacls. Once it has them, it program programs them into hardware, into the TCAM. So those are your five steps. One thing to note here.54:26Here is that if any of your hdacls have a syntax issue, the HDACL download will fail so you don't have half applied policies on your nets.54:46Okay, so let's review the phased enforcement using monitoring mode. You see here on the matrix, every cell is in one of the three states. Green is enabled, meaning the HDACL is live and matching traffic and the traffic is.55:01Actually being dropped. The amber is in monitor mode. It logs what it would drop, but the traffic still flows and gray is disabled, so the cell is off.55:21And we see once again here that there is the monitor all button with one click it puts the whole matrix into monitor mode and it's completely non destructive, and if you uncheck it, it restores every cell exactly as it was. This ties back to what.55:37What we were seeing in the go live and monitor stage from one of the earlier slides.55:55Okay, so, where does enforcement happen? We talked about the egress earlier on. There are four conditions and all have to be true. The switch needs the source IP to tag binding. It needs the destination binding, the platform and VLAN.56:03Have to have enforcement enabled as well and the policy has to be downloaded from ice. Now if you look at the diagram.56:22Enforcement happens at egress, at the data center switch closest to the servers. Okay, what if now we want enforcement but we're using SXP?56:30So the answer is, is that it still enforces. It just takes the source IP from the packet, looks up the tag from the SXP binding, it received and applies the exact same HGCL it would have applied from inline tagging frame.56:47So basically, the enforcement logic doesn't really care how the tag was learned and this is exactly how SXP bridges the gaps where inline tagging isn't end to end.57:06Okay, so how do we verify, and there are really two steps here. The 1st one is did the policy actually make it to the device? There are a few commands here that we will see in our demo. So the show CTS role based permission shows the SGACL install installed for a given.57:22Source to destination pair here you can see malware block zero one, downloaded and installed, show access list for that SGL shows.57:42View the actual rules inside it and the the platform resources command shows how much TCAM you're using, so you know you're not running out of hardware space as a policy grows.57:52And in 2nd step, the proof that it's actually working is if you look at the show access list, you can see the hit count picking up on that deny line. And down here, you can see the switch is actually generating syslogs for malware block which.58:08Action deny from source group five to.58:28To contractors, sorry, from source group five contractors to destination group four employees, that that's actually proving that your enforcement is in effect. One important thing that I want to note here is on the the syslogs is that when you configure your sjcls.58:33And you put in that log keyword, this is how you're gonna generate the syslogs on your network devices.58:53However, it's not required for enforcement, so you you don't really need that log keyword. Enforcement works fine just without it. This is just to trigger the logs. All right, so that covers the presentation up to the demo.59:01Tim, if you're still with me, I'm I'm ready to hand off to you for a demo on trustsec.59:21Okay, so yeah, starting over on the ice side, 1st logical place, I know this deployment has advantage licensing, so I know the trust sec functionality is usable, but we'll start at the network device. I've got a couple added in here already.59:30Just a few things to call out that Eric had mentioned. When we name our network device up here and move down to our advanced trust sec settings, there's a box here to use the device ID for trust sec information. If this box is checked, it will use whatever we have configured up here at the top.59:47But if you have configured something else on your switch, it needs to match exactly here for the integration to happen. But basically we come in here, set our device ID, set our password, save it. Usually doing that 1st before we go to the switch to set everything else up because otherwise when this.01:00:07Which attempts to authenticate over radius the trust sec piece will fail.01:00:27Another quick thing on the ICE side, actually now we can jump to the switch. Going through kind of the the overall idea of what's in the demo today. This is just a flat VLAN, everything lives in VLAN ten. I have two catalysts 9300.01:00:33The Virtual switches running in Cisco modeling labs. They're not full functionality switches, so there is some stuff that doesn't work.01:00:53But Luckily with the newer versions of CML inline tagging is supported on these specific switch versions, so that can be displayed. But moving away from what we talked about last week, where we were looking at multiple different VLANs, having to go through an aggregated layer three interfaces.01:01:02Somewhere and having IP access lists defined to figure out what traffic should be allowed from, let's say VLAN 30 over to VLAN 20 over to VLAN ten. Configuring that at your layer three hops gets pretty overwhelming pretty quickly.01:01:22Flattening everything out into a single VLAN down here. We're doing all the enforcement for our East west traffic here. We've got employee workstations connected, IP phones, printers, servers, all within the same layer two domain, all with.01:01:40It's in the same layer three domain and nowhere really to block traffic unless we have layer three interfaces on these particular ports. So moving into trust sec, we're, we're not gonna be sending downloadable ACLs. We're not doing VLAN switching, it's.01:01:58All just based on east west traffic, same VLAN. Jumping into our switch, we'll start up here on switch number one and run through a few of the configuration commands.01:02:16Starting off, I've already got the CTS credentials in here so I can just run at the exec mode that show CTS credentials, and this is the point again matching this specific device ID with what we had configured over in the ICE network access device.01:02:34I know that piece is good, but this is configured here with our CTS credentials ID, this and then whatever password we want to use. From there we move into config mode. We get all of our radius stuff set up to allow the switch to talk to ICE over radius as well as our CTS commands.01:02:52Just jumping into a quick show run triple A for pack list mode, a change that happened over time in in the old model with pack based, you would sometimes have to have two different configurations for the same ice server, one for regular radius and another for pack key.01:03:13So in this case, we've got just our standard radius server, our IP address, i'm running it through a NAT firewall. That's why I have non standard ports here. And I just have a single key here. I'm longer using the pack key. And then I can reuse this radius server ICE in both or sorry, my group.01:03:31Server down here.01:03:51Group server radius ice which contains my ICE three.5I can use that for both the regular.1X authentication, regular.1X authorization as well as our CTS list. That's allowing everything to happen without the pack.01:03:53Moving outside of the regular radius command, we've got a few more CTS commands that run in, so I called my authorization list for that CTS list, which is then referenced.01:04:14Up here in our authorization network group, I've got role based enforcement turned on, and I've got logging by default every 5 min for anything happening on those CTS links. But once we have all those commands in, assuming everything looks good on the ICE side as far as.01:04:30Adding the network device in.01:04:50We basically have the connection done and we can take a look at our environment data just to make sure that the connection downloaded. In this case it did, so reached out to the real server IP behind the nat.01:04:53We are alive. Our local device SGT was assigned as two, which is the the static default for trusted trust sec devices. And then we download the entire list of security group tags known by ICE as the controller for.01:05:10For trust sec. The other piece I didn't cover over on the network side, network access device setup side, there are a few update timers that run by default in ice. These are set to every 24 h or once a day. But if we want our switches or other network devices to down.01:05:31Download information from ICE more often. This can be changed to seconds, minutes, hours, et cetera. For a demo environment, one day is pretty good. But we're gonna check back in every day just to make sure we're still valid in the trustsec environment. We're gonna download our SGACL list once a day by default.01:05:51And download our environment data once a day. So as we can see over here, I've got about 21 h left on both our environment data expiring, and it refreshing automatically. Jumping back to ICE.01:06:11Let's get into our trust sec work center, and 1st we'll dive into components. Like Eric mentioned, this is where we at the global level just configure all of our sgts. So as you identify what's on your network, if the default 15 or 16 that I ships are not enough.01:06:29You can come in and add more specific names and SGT values for the devices in your network. In my case, I've added a few just for my test servers.01:06:49My printers, and in most cases I'm just using whatever's coming here out of the box. The other piece we'll jump into is the security group ACL content. For our printer, I set up a couple just demo allowing IPP ports.01:07:02So 1st one, this is actually out. So this is traffic originating from the printer, sourced on TCP 06:31. In my environment, I don't want my printer devices if they were to be compromised or if something somehow grabbed that tag to be able to do anything else on the.01:07:21Network other than communicate on the printer port. So I'm allowing ECP 06:31 out of that device. And then similarly coming into that device, I don't want any users trying to do anything funky with my printers so for destination port of 06:31.01:07:41That's all that I'm allowing in this security group ACL just as a kind of high level example. Taking those moving into the policy, like Eric mentioned, we've got our source tags over here on the left, our destination tags up top, and the intersection is where we're actually applying this policy.01:08:01Policy.01:08:21So for employees over here to my printers, I've applied the IPP in security group ACL. Modifying this entry is simply just clicking the intersection point, coming over here, adding some descriptions if I'd like to enabling disabling or monitoring.01:08:22On this particular.01:08:42Security group policy, and then from the dropdown I can pick which particular SGICL I want to apply. If I don't want to apply anything specific and I want to take essentially a hatch it rule to it, we can go with the built in permit IP or deny IP. And then we can choose whether or not we want.01:08:44To log these connection points.01:09:04Once we've configured this stuff, we've got everything sent to the switch, the switch can actually see it and we verify that it's over there. When we talk about inline tagging, we move over to our policy. So jumping into the demo policy I've got set up for authentication, I've got things set up for one.01:09:08Wired.1X wired map.1x, I've got internal users set up and in my case I only want things to be doing.1x, but I do have a wired map catch all which will apply a quarantine tag two for those endpoints that fall through.01:09:28When we move down to authorization, we're basically just having our our normal radius policy set up here, whether it's IP phone, servers, printers, employees etc. Tying those to a specific user identity group, we're not passing anything other than a permit access as part of our regular profile, although.01:09:45If we decided to, we could still send downloadable ACLs, VLAN changes et cetera, along with our security group tags.01:10:05But in this case, anything that authenticates for these top four, they're basically eight oh two.1X because we're actually getting a username and not a Mac address doing mab. I'm applying these specific sgts, and then anything that falls down to mab, i'm dropping them into quarantine systems.01:10:15To later look at and figure out why they're dropping there, fix the.1X sublicant on them or do whatever else has to happen there.01:10:35But then I would ideally set up a policy blocking most access for these devices in that security group content. Okay, let's jump back over to our lab side, and then run through a few specific checks.01:10:43And thanks to call out from our presentation. So when we're looking at the sgts and SGACL content that's downloaded by each particular enforcement point, the switch or network device for inline tagging purposes is only gonna download things that are relevant to.01:11:04To this particular network device. So in this case I have employee one, which has a tag of four and I have my server, which I believe has an SGT of 17 or 18.01:11:24And then down here we have our IP phone, another employee and a printer, which have three different sgts. So when I'm doing verification on my switch, again here on switch one, when we look, we would only expect to see, policy specific to the devices connected here. So I should see policy.01:11:36Policies for.01:11:56Right SGT four, as well as our servers, which is actually 18. I changed the name of this SGT and haven't updated it yet so quick verification of this one when we are looking at what's.01:11:57It's actually allowed to happen. Again, we're only going to have things for the destination tags that this particular switch knows about. So in this case I have.01:12:17Things initiated by target group 18, which is my server to my target group employees, things from printers to employees because in the SGACL matrix employees has a block or sorry not a block, but the the IPP SGACL content.01:12:29Applied to that intersection and then down here I'm denying.01:12:49IP any any from my employees targeted to my servers. The additional piece to look at for those downloaded SGACL contents, we can do our show CTS RBACL.01:12:54And for this case, we should have about four of them. I've got my internet running protocol out, which is allowing the source TCP 06:31 denying everything else. I've got the default deny that gets downloaded. Deny IP log, I've got permit IP.01:13:10As the 3rd one here, and then the other quick thing to check is our SGT mapping, make sure.01:13:32That the switch has actually dropped the IP to SGT mappings here into our local TCAM. So in this case I've got two different IPs, two different sgts.01:13:49I've got two sessions active on this switch from gig one oh two and gig one oh three and then if we look into the details of these authentication sessions, we'll see that I have.01:14:00That 202 address dynamically assigned SGT value 18 from ICE. And then if we look at 103, I've got my username of employee one, I've got the two oh three address as well as HGT value four.01:14:22So for demonstration purposes of actually generating traffic, I'm gonna start a packet capture on this particular interface. So this is running from our gig one oh oh 24 to one oh 24 here. It's passing traffic for VLAN ten and this is the only interface in this particular configuration.01:14:45We'll do inline tagging, anything destined out this way, this switch is not SGT capable, so it would basically try to tag it leaving switch two, it would get here and it would drop the tag because it it doesn't know what to do with it. But we'll jump on to.01:15:05Employee number one, the IP address of the printer down at the bottom, is.01:15:2465, I don't expect this thing to work because our SGS ACL content is only allowing port 06:31. So this is an expected failure here. But then if I try to do a telnet, that IP address.01:15:44On 06:31, comes back as open and we can see that that traffic's allowed. Now if we move back over actually to that packet capture, I'll try and track down our.01:16:04ICMP. So our desk source of ten one oh one, which was our employee device. That's actually the wrong one I may have ran out the buffer on it. Let me try that again.01:16:26Okay, so go ahead and open up our, well we're still pinging from one oh one to one oh two Okay here's our s our sin at.01:17:01Back from.01:17:21The printer and we get into our Cisco metadata tag and we can see that that SGT four was, was applied on the wire also our logging that was set up. We can see here we had an ingress interface on this particular.01:17:22Switch of 1024 we have an SGL ACL name IPP out O two, which was allowing that 06:31 traffic as the source port.01:17:42Our source IP here from the printer, our source port 06:31, and our destination IP was back to that employee device, and then just the random destination port that popped up, but then we can see basically the the source and the destination SGT so everything was allowed there.01:17:55Another piece that you can look at for verification purposes, to make sure that our SGACL content is working in our C show CTS role based counters, forgotten my show command.01:18:15We have a few different things in here. So everything starting with software is things that should be punted to the CPU, so if if for some reason a packet comes in and the particular switch can't interpret what the SGT value was, that's really the only time we'll ever see these software denied, software permit or software.01:18:34Columns increment. The hardware denied is anything matching our basically deny policy. So from 19 to four, we had 51 denies from four to 18, we had 13000 denies. Those are probably long running pings.01:18:55And then from unknown to unknown, we actually had 827 permits. If we look at our opposite end of the link, we should see fairly similar numbers.01:19:13So from our unknown to unknown, we've got a lot of traffic transiting from 19, which is our printer to our employee. We've got some permits going through from our employees to our printer. We've got some.01:19:38Some permits going through and then we'd also had some denies likely from the the pings that were sourced.01:19:52That now we're running short on time but we can do some stuff live. Let's go for some changes to our trust sec policy. This will bring in some of the.01:20:03The kind of quickness of how fast trust sec can work in your environment. This has an example, we'll start out with same switch actually we'll, we'll start.01:20:20Down here on employee two going up to employee one. So let's say we had some sort of event or like, alright, we've got some lateral movement going on. We don't have a ton of time to well there's the source of all my icmps and the packet capture.01:20:40What is that capturing on? Okay, so this one was our employees to our server, basically SUT four to 18. I've got a deny IP there so I had a long running ICMP running, but that shows that that.01:21:01Block actually works. But right now if I, if I went in and just tried to generate some traffic from employee two up to employee one, so we'll say ping 2168 and if he's two oh three.01:21:17Our ICMP starts to work, right? So if we come over here and say, we've had a security event, we've got some malicious behavior going on in the environment, some lateral movements starting to happen. Our employees really shouldn't be talking to each other, from device to device.01:21:32Let's go ahead and block this traffic.01:21:52So we'll save that in a normal environment, we'll just go ahead and click deploy here. ICE sends out a change of authorization. The switch downloads the new policy matrix, in our environment here, that doesn't actually work because the COA port's not listening on this particular switch. So we'll just go ahead and refresh.01:21:54The policy.01:22:13So the switch will reach out to ICE, download the new event data, and then just for verification, our ICMP should have stopped, which this is NO longer incrementing. We can also look on the ice side just to make sure that that.01:22:20Event came across. So these last few, we downloaded a lot of stuff because we have multiple different ACLs, we have multiple different policy intersections, but just opening up a random one, we can see that there was a new session created. It was packless, and then we.01:22:36Downloaded the trust sec egress policy.01:22:56Depending on which one I opened up, these kind of come over line by line. In this case, we downloaded the RBACL source list for unknown, so anything with 000, we downloaded that entire column, which.01:22:59At this point, there was nothing in it, but one of those particular excuse me, one of those particular downloads would have pulled that employee to employee deny ICMP or deny IP.01:23:17SGACL, and I'm very happy the switch did not crash. Yeah, in a nutshell, I think we've got just a few minutes left, so Eric, did you have any other slides as summary that you needed to go through or? Yeah I have a one summary slide to.01:23:32To wrap up the presentation and a slide to provide links to where we can get more information on. Yeah.01:23:52Back over to you. And then when you're done I've got I've got some information on next week's session as well. Okay, awesome. I'll be quick. Thanks a lot for this great demo Tim. Let's jump back here into our presentation. So.01:24:04Let's bring it all together. We started with a problem. The traditional segmentation ties your security to your topology, and we said that's expensive and complex to manage as your network grows. Trust sec fixes it by decoupling the two across these three pillars.01:24:23So classification, we sign a tag based on who or what something is dynamically at the access layer or statically in the data center. Then we talked about propagation, we carried that tag across the network in line or over SXP.01:24:42And we also talked about enforcement, so we apply the SJCL at egress to permit or deny by group. So to to sum it up, we classify once, we propagate everywhere and we enforce consistently and the.01:25:00Results are what matter to the business, lower operational cost, a real zero trust posture that contains lateral movement and the agility to change policy centrally in minutes.01:25:20Okay, so, everything we covered today and, and a lot more depth lives at this one link. If you visit CS.co/trust sec resources, you'll find the deployment and design guides, the platform compatibility.01:25:36Matrixes and inter integration docs.01:25:57So before jumping into any implementation, I strongly recommend to take a quick look at the guides and familiar familiarize yourself with them and we should.01:26:02Have the ability to share the slides out, the presentation out. If so, we have I have a glossary here for you guys to cover all of the terms, that we talked about in case you're reviewing this in the future, this can help you with the definitions of all the terms we talked about today.01:26:18So with that, brings us to the end of our Cisco trust sec presentation, I want to thank you all so much for your time today and I can hand this back off to Tim. Thank you. So just covering what's next, next.01:26:38Thursday we've got our final.01:26:58Expert insight series session covering segmentation integrations, covering things within the Cisco ICE and ecosystem platforms. If you haven't already, you can use the QR code on the left to register for that one. We also have the QR code on the right, which links to our short five to 10 min.01:27:01Fiber capsules covering a.01:27:20Various number of, ICE demos, quick guides on configurations and things like that. So with that, we will wrap up for today. We appreciate everyone's time for joining us, and look forward to seeing you in the next one.01:27:22