WEBVTT 00:00:00.000 --> 00:00:12.000 So now we get to begin our discussion on next-gen campus networks. What do we mean 00:00:12.000 --> 00:00:20.160 by next-gen campus networks? We mean newer technologies, newer features, newer 00:00:20.160 --> 00:00:29.400 services that many of you may or may not be using in your organization right now 00:00:29.400 --> 00:00:36.599 or don't even know exist. Some of the stuff we'll talk about you know. So 00:00:36.599 --> 00:00:39.919 hopefully you know about like things like network access control, 802.1 00:00:39.919 --> 00:00:44.919 export based authentication, MAC authentication bypass. What else is there? 00:00:44.919 --> 00:00:48.680 WebAuth, those things. Hopefully you already know about those. If not, that's 00:00:48.680 --> 00:00:52.439 okay. You'll learn about them here at a high level. But also things like TrustSec 00:00:52.439 --> 00:00:57.959 and MACSec and LISP and VXLAN and SD-Access and SD-WAN. These are all 00:00:57.959 --> 00:01:04.440 topics that are going to show up in the certification exam. So I am very 00:01:04.440 --> 00:01:08.320 confident in telling you that everything we're about to talk about expect one or 00:01:08.320 --> 00:01:13.279 two questions on the exam for every single discussion we have here for the 00:01:13.279 --> 00:01:17.680 rest of today's session. Same thing with COP. Expect two, at least two questions on 00:01:17.680 --> 00:01:26.879 the exam about COP. And some of this stuff is going to overwhelm you here in 00:01:26.879 --> 00:01:30.519 today's session. Because it's new stuff and you'll be like I don't 00:01:30.519 --> 00:01:34.559 understand why would we even need that. Well you don't need it. But larger 00:01:34.559 --> 00:01:38.480 enterprises do. And the larger enterprises are doing this. And so Cisco 00:01:38.480 --> 00:01:44.040 is getting you primed and ready for maybe your potential future. And maybe 00:01:44.040 --> 00:01:48.120 not. The fact of the matter is it's part of the exam and you got to learn it. So 00:01:48.120 --> 00:01:52.040 our first discussion is going to be on network access control, TrustSec and MACSec. 00:01:52.400 --> 00:02:04.080 So let's think about our environment here. We have our access layers. We have 00:02:04.080 --> 00:02:08.199 our distribution layers. We have our core layers. We have the edge of our 00:02:08.199 --> 00:02:12.119 environment that goes to the WAN, to our remote offices and internet connections. 00:02:12.119 --> 00:02:16.960 We have some IPSec tunnels there. Maybe some GRE over IPSec tunnels. Might even 00:02:16.960 --> 00:02:24.960 have a DMVPN setup. But what we want to talk about right now is controlling 00:02:24.960 --> 00:02:29.800 access to the actual network. Not from a management standpoint anymore folks, but 00:02:29.800 --> 00:02:36.960 from an end-user standpoint. How can we authenticate who or what is actually 00:02:36.960 --> 00:02:43.039 connecting to our wired or wireless network. So folks, any of you here using 00:02:43.199 --> 00:02:53.039 any of these three options to control who or what is allowed to connect to the 00:02:53.039 --> 00:02:58.199 wired or wireless network. If you are, chat in which ones you're using. 00:03:05.160 --> 00:03:09.399 And what is the purpose of all three of these? Let's keep it simple. To deny 00:03:09.399 --> 00:03:17.399 access until the user or device has been successfully authenticated. Now good 00:03:17.399 --> 00:03:21.800 news here folks, for the exam you do not have to be able to configure, verify or 00:03:21.800 --> 00:03:26.520 troubleshoot any of these. So that is not what our discussion is about. Our 00:03:26.520 --> 00:03:30.839 discussion is what you have the ability to pick them out of a lineup or pick 00:03:30.839 --> 00:03:36.600 them out of a drag-and-drop. That is the goal here. So what is 802.1X and why 00:03:36.600 --> 00:03:40.199 would I want to use it? What is MAP and why would I want to use it? And what is 00:03:40.199 --> 00:03:45.320 WebAuth and why would I want to use it? But remember they're all part of network 00:03:45.320 --> 00:03:48.600 access control. So any question that says what are examples of network access 00:03:48.600 --> 00:03:56.000 control, these are the ones you want to know about for the exam. Now is port 00:03:56.000 --> 00:04:03.759 security folks? Port security. Remember port security from CCNA? 00:04:07.600 --> 00:04:15.360 Is port security a type of network access control or can it be a type of 00:04:15.360 --> 00:04:21.519 network access control? Sure it can be. Absolutely it can be. And we would be 00:04:21.519 --> 00:04:27.519 controlling who or what is allowed to connect to the port. The port based on 00:04:27.519 --> 00:04:31.600 MAC addresses in that case. So that is an option. The problem is that's not a 00:04:31.600 --> 00:04:35.399 scalable solution. It's not a flexible solution. It's not an easy solution at 00:04:35.399 --> 00:04:40.000 all. Especially in our high-paced ever-evolving network environments. And 00:04:40.000 --> 00:04:44.760 if you're like my network doesn't evolve, okay you're you're one of the 00:04:44.760 --> 00:04:52.000 exceptions potentially. But the idea here is that 802.1X is a really great 00:04:52.000 --> 00:04:57.799 option we have for network access control whereby people enter usernames 00:04:57.799 --> 00:05:02.920 and passwords. So any senior on the exam that talks about having to enter a 00:05:02.920 --> 00:05:11.160 username and a password, a good option is 802.1X. However, there's an 00:05:11.160 --> 00:05:17.200 extra aspect that you have to think about this. Also a supplicant. What is a 00:05:17.200 --> 00:05:24.679 supplicant? A supplicant is 802.1X compliant software that has been 00:05:24.679 --> 00:05:29.839 installed on the device. So Windows comes with a supplicant you can use. Cisco 00:05:29.880 --> 00:05:35.920 Secure Access has a supplicant that you can use like Cisco AnyConnect. So 00:05:35.920 --> 00:05:42.559 that would be the supplicant. So I would have the supplicant software installed 00:05:42.559 --> 00:05:47.440 on my device. So my device, me, I'm known as the supplicant in an 802.1X 00:05:47.440 --> 00:05:51.920 scenario. Then we need an authenticator. Well who's the authenticator in this 00:05:51.920 --> 00:06:00.760 case? Does anybody know who the authenticator would be with 802.1X in 00:06:00.760 --> 00:06:09.760 this scenario right now? Yeah, the network device you're connected to. Perfect. So in 00:06:09.760 --> 00:06:16.200 our case is the switch, right? Authenticator. So I would have to set 00:06:16.200 --> 00:06:23.519 this up with 802.1X port-based authentication configuration commands 00:06:23.519 --> 00:06:35.720 and use AAA authentication method lists in order to accomplish that. So that's my 00:06:35.720 --> 00:06:40.760 authenticator. And then I have an authentication server that is over here. 00:06:40.760 --> 00:06:52.600 In my case, it's Identity Services Engine. It's my authentication server. Now 00:06:52.600 --> 00:06:59.040 specifically with 802.1X we have to use RADIUS. 00:06:59.040 --> 00:07:11.160 So what happens here is that the supplicant will be constantly using 00:07:11.160 --> 00:07:14.040 what are called extensible authentication protocol, so EAP, 00:07:14.040 --> 00:07:22.160 extensible authentication protocol, over LAN frames for an initial 00:07:22.160 --> 00:07:29.160 communication and setup. And then we have RADIUS being used from here all the 00:07:29.160 --> 00:07:33.799 way over to here in order to verify those current credentials that are being 00:07:33.799 --> 00:07:41.359 applied. So once you authenticate using EAPOL and you have successfully 00:07:41.359 --> 00:07:46.399 authenticated, then that means that you are now going to be allowed to use that 00:07:46.399 --> 00:07:50.519 particular port. The port essentially opens up and your data traffic is allowed 00:07:50.519 --> 00:07:55.799 to flow through. So until you authenticate, only those EAPOL messages 00:07:55.799 --> 00:07:59.160 are allowed in and out of that port. Everything else gets dropped. Once you 00:07:59.160 --> 00:08:02.839 authenticate, then the rest of your traffic is allowed through that 00:08:02.839 --> 00:08:07.920 particular port. So the challenges we face with this, with 802.1X though, is the 00:08:07.920 --> 00:08:13.679 fact that someone has to be able to type in a username and password and that 00:08:13.679 --> 00:08:17.399 device has to be able to support a supplicant. So if you can't type in a 00:08:17.399 --> 00:08:23.119 username and password, you can't install a supplicant, then 802.1X is not going to 00:08:23.119 --> 00:08:29.160 be your answer for that scenario on the certification exam. So another option we 00:08:29.160 --> 00:08:37.960 have is MAC authentication bypass. So MAC authentication bypass is what? 00:08:37.960 --> 00:08:47.559 MAC authentication bypass is about authenticating with MAC addresses. 00:08:47.559 --> 00:08:55.320 MAC addresses. So that is very similar to port security. But what's the difference now? 00:08:55.320 --> 00:09:07.559 What's the difference? We have a centralized database of allowed and 00:09:07.559 --> 00:09:17.960 denied MAC addresses. So I have my authentication server. Whereas it's port 00:09:17.960 --> 00:09:28.039 security, you don't. So let's say you have a camera, okay, not really that type 00:09:28.039 --> 00:09:33.760 of camera, but and your camera, let's say it's a security camera, it's connected up 00:09:33.760 --> 00:09:40.239 to the switch. So the camera has to authenticate to the network before it 00:09:40.239 --> 00:09:44.599 can be used, right? Do we have the ability to type in a username and 00:09:44.599 --> 00:09:48.159 password on a camera? Probably not. Do we have the ability to install a 00:09:48.159 --> 00:09:52.880 supplicant on a camera? Probably not. Therefore, MAC authentication bypass 00:09:52.880 --> 00:09:57.159 would be the better option for that. Because what does a camera have, an 00:09:57.159 --> 00:10:03.520 Ethernet-based camera have? It has a MAC address. So in my authentication server 00:10:03.520 --> 00:10:10.599 database over here, I would have my MAC address database over there. And then 00:10:10.599 --> 00:10:14.760 between the identity services engine server, the authentication server, and 00:10:14.760 --> 00:10:21.159 here we'd be using RADIUS. And then whenever you try to connect to that 00:10:21.159 --> 00:10:25.039 port, so I'd have to set up MAC authentication bypass on that port. Then 00:10:25.039 --> 00:10:28.400 when you try to communicate, right, I'm gonna then have to take your MAC 00:10:28.400 --> 00:10:33.559 address, send it over here and say, hey, is this legit or not? And then the 00:10:33.559 --> 00:10:40.479 answer is yes, good, you are now allowed to use my particular port. The challenge 00:10:40.479 --> 00:10:43.239 that we face with MAC authentication bypass is that MAC addresses can be 00:10:43.239 --> 00:10:49.119 easily spoofed. So if a cyber criminal can figure out a device's MAC address 00:10:49.119 --> 00:10:51.799 and then change their MAC address on their device and then connect, let's say, 00:10:51.799 --> 00:10:56.679 to another port using that MAC address, then they technically could possibly get 00:10:56.679 --> 00:11:00.159 connectivity. But again, it's better than nothing, right? You're better off to do 00:11:00.159 --> 00:11:04.479 this than not have authentication. 00:11:05.320 --> 00:11:12.159 So think about the two now. Compare them to each other. If the snare on the exam 00:11:12.159 --> 00:11:18.280 is talking about a device that only has a MAC address and you can't install a 00:11:18.280 --> 00:11:24.479 supplicant on it, and no user can type in a username and password, then probably 00:11:24.479 --> 00:11:28.119 this is the answer you want to pick. Because if you can't type anything in 00:11:28.119 --> 00:11:32.559 and you can't install a supplicant, then what? Authenticate based on MAC address. 00:11:32.559 --> 00:11:38.840 That's going to be your answer. And then what about WebAuth? Okay, so WebAuth is 00:11:38.840 --> 00:11:43.280 where people have to type in usernames and passwords into a web, what? A web 00:11:43.280 --> 00:11:54.599 portal, a web page. So what type of scenario would be good for this? Well, a 00:11:54.599 --> 00:12:04.719 scenario whereby a user has a device that doesn't support a supplicant, but 00:12:04.719 --> 00:12:10.039 supports a web browser. Because if it supports a web browser, you can have a 00:12:10.039 --> 00:12:12.760 web page, a web portal, they type in their username, they type in their 00:12:12.760 --> 00:12:22.640 password, then they authenticate using that web portal connection. So now they 00:12:22.640 --> 00:12:27.080 can access the network based on being authenticated. So as you try to connect, 00:12:27.080 --> 00:12:31.840 you connect up, whether it's wireless or wired, you can use web portals, and when 00:12:31.840 --> 00:12:35.479 you try to connect, you're then all of a sudden redirected to the web portal, and 00:12:35.479 --> 00:12:39.760 then you're redirected to the web portal, and then you're asked for your 00:12:39.760 --> 00:12:42.159 credentials, you put them in, and then if you're right, then you're allowed to 00:12:42.159 --> 00:12:45.559 communicate on the network. If not, then you're going to be denied from 00:12:45.559 --> 00:12:50.880 communicating on the network, because the port will not be opened up for you. So as 00:12:50.880 --> 00:12:53.679 you can see, there's three different options here that are relevant for the 00:12:53.679 --> 00:13:00.280 certification exam, and as you can see, they have very specific scenarios and 00:13:00.280 --> 00:13:05.599 situations associated with them. So your goal for the certification exam is to be 00:13:05.599 --> 00:13:10.320 able to say, hey, based on the scenario circumstance, which one of these is the 00:13:10.320 --> 00:13:15.280 one I should go with? So let me give you, let me just give you, let's try 00:13:15.320 --> 00:13:22.520 something here. Chat in your answer. You have guests, contractors, temporary 00:13:22.520 --> 00:13:31.359 workers that need access to your network, using their own devices, their own 00:13:31.359 --> 00:13:36.280 laptops, their own phones, their own tablets. Which of these three options do 00:13:36.280 --> 00:13:44.320 you think is the best option to implement in that scenario? You could say 00:13:44.320 --> 00:13:47.039 right now, well Raymond, there's a little bit, a few details missing. Okay, but 00:13:47.039 --> 00:13:52.520 that's all you're given. Think about it from a real world. Would you fight with 00:13:52.520 --> 00:13:58.119 them to install a supplicant on their devices? Probably not. So it doesn't make 00:13:58.119 --> 00:14:02.320 sense to do 802.1X, because they're not going to want to use a supplement, a 00:14:02.320 --> 00:14:07.960 supplicant most of them. You're not going to just authenticate based on their Mac 00:14:07.960 --> 00:14:12.559 addresses, right, but you could set up a web portal, you could have a web portal, 00:14:12.559 --> 00:14:17.280 create individual accounts for them using that web portal, and then in the 00:14:17.280 --> 00:14:20.440 end they type in their username and passwords and they can connect through 00:14:20.440 --> 00:14:23.479 their guest accounts, the contractor accounts, or whatever accounts that you 00:14:23.479 --> 00:14:28.960 have for them. So yeah, exactly. You can't control the devices? Web off. So typically 00:14:28.960 --> 00:14:32.679 it's hard to control guest devices, contractor devices, temporary worker 00:14:32.679 --> 00:14:38.119 devices, if you don't own those devices. But think about a scenario where you own 00:14:38.119 --> 00:14:44.280 the devices. You own the devices and you can install a supplicant, then you would 00:14:44.280 --> 00:14:48.960 pick 802.1X. So that's the way I want you to think about these three 00:14:48.960 --> 00:14:52.359 different options as you prepare for the certification exam. So like I said, you're 00:14:52.359 --> 00:14:55.559 not gonna have to worry about configuring it, verifying it, troubleshooting it, it's 00:14:55.559 --> 00:14:59.960 about do you understand what network access control is? Yes, you do now if you 00:14:59.960 --> 00:15:06.320 didn't know. And do you know these three primary different options that exist? 00:15:09.119 --> 00:15:15.679 Now another thing we want to talk about for the certification exam is a feature 00:15:15.679 --> 00:15:23.679 called TrustSec. Now this is a Cisco proprietary solution. Anybody here using 00:15:23.679 --> 00:15:35.760 TrustSec? Yes, if you are. No, if you are not. TrustSec. TrustSec. So let me tell 00:15:35.760 --> 00:15:40.799 you about it so you can pick things out of a lineup on the certification exam. 00:15:42.440 --> 00:15:46.000 Good. If you don't know what it is, put in a question mark. That's always a great 00:15:46.000 --> 00:15:48.239 answer here. I don't know what you're talking about. Good. You're gonna learn 00:15:48.239 --> 00:15:57.440 about it. So let's think about this environment here right now. Wait now. How? 00:15:57.440 --> 00:16:09.400 How do we ensure consistent, repeatable policy enforcement throughout the 00:16:09.400 --> 00:16:18.599 network? I mean it's a big challenge and it's not easy. It's gonna be made up of 00:16:18.599 --> 00:16:22.640 a whole bunch of different things that are just gonna cause more problems. 00:16:22.760 --> 00:16:28.479 That's how we mostly deal with our networks today. At the moment, we 00:16:28.479 --> 00:16:32.840 typically, most of us, are implementing policies at our layer 2, layer 3 00:16:32.840 --> 00:16:35.320 boundary. 00:16:42.840 --> 00:16:47.280 And how do we typically do that? What are we typically using for policy 00:16:47.280 --> 00:16:51.520 enforcement at our layer 2, layer 3 boundaries, folks? 00:16:52.640 --> 00:17:04.400 ACLs. Exactly. We have policy enforcement at the edge of our 00:17:04.400 --> 00:17:15.839 environment. Firewalls, ACLs, application layer filtering. Okay. It's a little 00:17:15.839 --> 00:17:20.119 better than what's going on here. But what we want to realize is what we have 00:17:20.119 --> 00:17:24.719 right now is something that is not scalable. Why? Because the larger the 00:17:24.719 --> 00:17:30.160 network grows, the more services we have, the more resources we have, the more 00:17:30.160 --> 00:17:36.839 users we have, the more subnets we have. And that becomes very difficult to 00:17:36.839 --> 00:17:41.280 manage, monitor, maintain. The policies that are at this distribution layer, the 00:17:41.280 --> 00:17:44.280 policies that are at this distribution layer, the policies that are at this 00:17:44.280 --> 00:17:48.160 distribution layer, the policies that are at that distribution layer. That becomes 00:17:48.160 --> 00:17:55.199 a challenge. Also, the way we have it set up is not mobile. If a user moves from 00:17:55.199 --> 00:18:00.079 one location to another location, I have to adjust the policies to reflect this 00:18:00.079 --> 00:18:05.400 move. If a new app gets installed, or a new device gets installed, or a new 00:18:05.400 --> 00:18:11.319 feature, a new service gets installed, right? Well, now my policies have to be 00:18:11.319 --> 00:18:16.040 adjusted, or maybe things don't work. Or maybe we have a security flaw if we 00:18:16.040 --> 00:18:21.280 don't adjust those policies. And the thing is, is policy enforcement is 00:18:21.280 --> 00:18:28.359 typically based on a really dirty word today, and that is location. And location 00:18:28.359 --> 00:18:35.280 is typically tied to what? Your IP address. That's right. That is typically 00:18:35.280 --> 00:18:40.760 how we implement policy, based on location and IP addresses. So, if you're 00:18:40.760 --> 00:18:48.160 here, you get this policy applied to you, because why? You are in that location, 00:18:48.160 --> 00:18:53.920 and you belong to this particular subnet VLAN broadcast domain. If you're here, 00:18:53.920 --> 00:18:58.520 then you get this other policy. Why? Because of your location, because of your 00:18:58.520 --> 00:19:07.760 IP address, because of those things. Your subnet, your VLAN, your broadcast domain. 00:19:08.760 --> 00:19:16.119 And so, this type of mentality is what we've used for a really long time, and 00:19:16.119 --> 00:19:24.400 what many of us still use to this very day. And it's not all that great for 00:19:24.400 --> 00:19:32.239 users. It's not all that great for admins, because it's really hard to manage, 00:19:32.479 --> 00:19:37.719 monitor, maintain, secure, control, and keep the cyber criminals out, folks. 00:19:37.719 --> 00:19:50.079 Instead, we want policies to be based not on location and IP addresses anymore. We 00:19:50.079 --> 00:20:00.839 want policies based on who you are, what you are doing, what you are using, why you 00:20:01.160 --> 00:20:15.040 are doing it, when you are doing it. And we want to do all of that from a centralized location, 00:20:15.040 --> 00:20:28.560 as opposed to everywhere in our environment. And if you move, if you pick up from here, 00:20:28.560 --> 00:20:36.719 and you come down here, I want those exact same policies that applied to you here, 00:20:36.719 --> 00:20:52.839 applied to you here. And that is where TrustSec comes into play. TrustSec is Cisco proprietary. 00:20:53.520 --> 00:21:10.760 This feature, TrustSec, is Cisco's implementation of a zero-trust architecture. Notice they don't 00:21:10.760 --> 00:21:15.319 call it that, though. They call it TrustSec. And there's a lot more that goes into this 00:21:15.319 --> 00:21:22.199 than just TrustSec. But it's part of their zero-trust architecture, where you zero-trust 00:21:22.359 --> 00:21:30.880 and you always verify. Never trust, always verify. And it doesn't matter where you are, 00:21:30.880 --> 00:21:39.160 your policies follow you everywhere. So if I'm in the office, headquarters, or branch, 00:21:39.160 --> 00:21:46.959 or at home, the same policies apply to me. If I'm on my laptop, I have these policies applied. If 00:21:47.000 --> 00:21:52.599 I'm using a mobile phone, these policies apply. If I'm using my tablet, these policies apply. 00:21:52.599 --> 00:22:02.640 Right down to the software that is installed and updated on the device. That is all part of the 00:22:02.640 --> 00:22:08.319 identification and authentication process. So if all of a sudden I download a new app on my laptop, 00:22:08.319 --> 00:22:16.680 and that app was not approved by IT, I'm in breach of the policy and I could be denied access to the 00:22:16.680 --> 00:22:22.359 network. Or my privileges could be dropped down and I would no longer have administrative access 00:22:22.359 --> 00:22:25.599 to this, that, or the other. Or I would no longer be able to access, let's say, 00:22:25.599 --> 00:22:30.680 confidential information. I can still access the internet, but I'm now blocked dynamically 00:22:30.680 --> 00:22:36.280 from doing what? Accessing that confidential document. Why? Because I've installed an app 00:22:36.280 --> 00:22:42.920 that's unapproved, that has not been vetted and identified for risk and vulnerabilities. 00:22:42.920 --> 00:22:50.680 How cool is that? And all of that can be handled right from here. Identity Services Engine. Oh, 00:22:50.680 --> 00:22:56.079 wait. Okay. So what does that mean? It means that when it comes to TrustSec, we're going to need 00:22:56.079 --> 00:23:03.599 ICE to centrally manage everything that's going on here. So if you want TrustSec, you got to spend 00:23:03.599 --> 00:23:08.920 a lot of money on Identity Services Engine, which is a AAA server that supports RADIUS and supports 00:23:08.920 --> 00:23:13.760 TACACS+, and all that fun stuff. So I want you to know that you need ICE. What else do you need? 00:23:13.760 --> 00:23:19.520 Well, you need switches that support TrustSec. And the modern-day Cisco switches all support 00:23:19.520 --> 00:23:26.680 TrustSec. So that 9000 series family, no problem. You got TrustSec there. So switches, routers, 00:23:26.680 --> 00:23:31.359 firewalls, wireless devices, wireless LAN controllers, like all of that stuff nowadays 00:23:31.359 --> 00:23:37.079 with Cisco. Then modern stuff all supports TrustSec because this is what they're pushing. 00:23:37.239 --> 00:23:44.760 This is what they want everybody to start using. One, because it's more money for them, 00:23:44.760 --> 00:23:50.319 obviously. But two, it actually is a lot better security solution for all of us in the real world. 00:23:50.319 --> 00:23:56.040 Huge learning curve, lots of money, but in the end, you are going to be better protected from 00:23:56.040 --> 00:24:00.439 the cyber criminals of the world. Because think about this. If someone in your organization all 00:24:00.439 --> 00:24:08.119 of a sudden installed an app on their laptop, why? Because they double-clicked on an email 00:24:08.119 --> 00:24:14.319 attachment that then installed malware on their system. As soon as that happens, you are now in 00:24:14.319 --> 00:24:20.520 violation of your policy, which means you are blocked. You are isolated. You are stuck where 00:24:20.520 --> 00:24:29.199 you are. Cyber criminal is stuck on your system. Done. You see how we're trying to ensure that we 00:24:29.239 --> 00:24:37.079 can have dynamic security policies that adjust on the fly based on things people do. So the 00:24:37.079 --> 00:24:42.959 cyber criminals, if they get a hold of something, they are stopped because it breaches the policy. 00:24:42.959 --> 00:24:48.560 And the policy is not just based on IP address and location. The policy is based on, yes, 00:24:48.560 --> 00:24:55.839 it could be IP address, location, username, password, biometric identification. It could 00:24:55.839 --> 00:25:02.439 be based on the device in use with the operating system version, coupled together with antivirus 00:25:02.439 --> 00:25:08.800 updates, coupled together with software installed on the device. And whether that's updated, 00:25:08.800 --> 00:25:14.000 if anything else is added, then you're in breach of that policy. Location as well. Are you here? 00:25:14.000 --> 00:25:20.520 Are you there? And your levels, your permissions, your authorization levels can change dynamically 00:25:20.520 --> 00:25:27.640 throughout the day based on what you've done. Without administrators even having to get involved. 00:25:27.640 --> 00:25:38.439 It's like stuff of the future I'm talking about, but it's here today. It's a good list of stuff 00:25:38.439 --> 00:25:43.359 to know. Like I said, right? What are the main components of TrustSec? ICE, switches, firewalls, 00:25:43.359 --> 00:25:49.640 routers, all that stuff. Centralized. Know that. Centralized. Policy enforcement. Centralized. 00:25:49.680 --> 00:26:00.959 Classification. So you define the policies where? In ICE. And then these devices enforce 00:26:00.959 --> 00:26:12.000 the policy. They enforce the policy. Enforcement. So now do I need access control lists at the 00:26:12.000 --> 00:26:17.280 distribution layer? Well, technically speaking, no. We can eliminate them all, right? Because 00:26:17.280 --> 00:26:21.319 let's think about it. Traditionally, network access was based on what? Based on your VLAN. 00:26:21.319 --> 00:26:26.680 You're in this VLAN. You belong to this subnet. You belong to this broadcast domain. We put an 00:26:26.680 --> 00:26:32.599 access control list at the distribution layer. That's how we control you. So the VLANs are linked 00:26:32.599 --> 00:26:37.400 to what? Your IPs, your departments, your roles, your functions. Therefore, security is based on 00:26:37.400 --> 00:26:45.359 your IP, your location, your subnet, your VLAN. And that's not good because think about not everybody 00:26:45.400 --> 00:26:51.400 in the sales department necessarily needs what? The same levels of policy. Just like everybody in 00:26:51.400 --> 00:26:55.680 HR doesn't need the same levels of policy. Just like everybody, you see the difference here? I 00:26:55.680 --> 00:27:01.199 can get so granular now with my centralized policy enforcement that I can do it on a user-by-user 00:27:01.199 --> 00:27:11.239 basis if I wanted to. Least privilege principle is one of the primary components of TrustSec. 00:27:11.239 --> 00:27:15.520 You now have the ability to do that really easily. Most of us don't implement the least 00:27:15.520 --> 00:27:20.839 privilege principle in our organization because it's just too hard to go through all the employees 00:27:20.839 --> 00:27:24.599 and say, well, you don't need this. You don't need this. I'll take it off of you. But you need 00:27:24.599 --> 00:27:28.800 them, so I'll keep it for you. But you don't need them. We don't have time for that garbage. So we 00:27:28.800 --> 00:27:35.719 don't do it. And because we don't do it, the cyber criminals are winning. But now we shift the whole 00:27:35.760 --> 00:27:44.640 system around. And when I can now get really granular a lot easier and have dynamic changes 00:27:44.640 --> 00:27:53.400 enforcements in play based on policies we set up, we have the ability to win the game. But again, 00:27:53.400 --> 00:27:59.319 it comes at a price up front. So typically, we're filtering with our access control list, 00:27:59.319 --> 00:28:04.359 the layer three devices. And what is it based on? Well, it's based on having an ACL and the 00:28:05.119 --> 00:28:10.239 routed ports. And then it's based on what? Source and destination IP, source and destination port 00:28:10.239 --> 00:28:15.160 numbers, all of that stuff, and really nothing else. Now, yeah, we could do a little bit of 00:28:15.160 --> 00:28:19.479 application layer filtering in there and so on and so forth. And if we implement some firewalls in 00:28:19.479 --> 00:28:23.239 there, now we're getting really crazy and it's getting expensive anyways. We would then be able 00:28:23.239 --> 00:28:27.479 to maybe do application layer firewalling a lot closer to devices. But we typically don't do that. 00:28:27.479 --> 00:28:31.800 We don't put a firewall right there at the distribution layer in our enterprise environment 00:28:31.800 --> 00:28:37.880 by our end users. And then if you move somewhere, oh my gosh, well, I mean, there's no way to keep 00:28:37.880 --> 00:28:42.800 that policy with the user in traditional environments. So not scalable, impossible to 00:28:42.800 --> 00:28:51.760 control on a device-by-device, user-by-user basis. So with TrustSec, we can do it differently. We can 00:28:51.760 --> 00:28:58.359 throw all this old school stuff out of the window. Because right now, if you're not using TrustSec, 00:28:58.359 --> 00:29:02.479 the more source and destination permissions, the more complex the access control has become. And 00:29:02.479 --> 00:29:08.880 the more movement of end devices in your network, the less manageable this becomes for you. So 00:29:08.880 --> 00:29:17.839 instead with TrustSec, and this is an important key right here, you are basing security on the 00:29:17.839 --> 00:29:26.920 contextual identity, that's the word, of the endpoint. The contextual identity of the endpoint. 00:29:27.040 --> 00:29:35.359 Things like who, what, where, when, why, how. So who is doing this right now? Oh, it's Raymond. Why? 00:29:35.359 --> 00:29:41.280 Because Raymond put in his username and password. Okay, but what is he trying to do? What is he 00:29:41.280 --> 00:29:48.760 trying to do? Where is he trying to do this from? When is he trying to do this? Why is he trying to 00:29:48.760 --> 00:29:57.319 do this? How is he trying to do it? What device is he actually using? Is that device's posture at 00:29:57.319 --> 00:30:06.040 the levels it needs to be to meet what he, who, what, where, why, and how? And if so, grant him 00:30:06.040 --> 00:30:12.520 access. If not, either drop his access levels down or deny him completely. It's up to you how you want 00:30:12.520 --> 00:30:22.439 to approach that. So when does a lot of this decision come into play? It comes into play as 00:30:22.439 --> 00:30:29.280 soon as you're connecting to the network. So what does this mean? Need. We need to have a 00:30:29.280 --> 00:30:36.959 supplicant installed on those devices. That is going to give us the opportunity to what? Verify 00:30:36.959 --> 00:30:41.760 the posture of the device. So we need some endpoint solution on it. Let's put it that way. 00:30:41.760 --> 00:30:47.959 But also the user's ability to authenticate themselves and have that entire posture of 00:30:47.959 --> 00:30:53.640 the device verified. Because I don't want you to go any further than this unless all of that is 00:30:53.640 --> 00:30:58.319 approved. But the great thing about this is it doesn't matter whether you're here or whether 00:30:58.319 --> 00:31:05.439 you move down here and plug in. I can do the exact same posture verification and identity 00:31:05.439 --> 00:31:13.119 verification. Why? Because it's this device here, identity services engine, that's taking care of 00:31:13.119 --> 00:31:22.199 that. And so here's the thing. There's a lot more going on here. But remember contextual identity, 00:31:22.199 --> 00:31:29.479 right? So at the point of network access, we need to figure out the who's, the what's, the where's, 00:31:29.479 --> 00:31:37.400 the why's, and the how. Why? Because at this point in time, that switch needs to figure out 00:31:37.400 --> 00:31:47.880 from the identity services engine, which group you belong to. So on identity services engine, 00:31:47.880 --> 00:31:55.640 we are going to create what are called security groups at a minimum. For let's say different roles 00:31:55.640 --> 00:32:01.040 and responsibilities you have in your environment. But could you get as granular as having groups for 00:32:01.040 --> 00:32:06.959 users? Sure, of course. Like a single user in a group? Of course you can. Right? If you really 00:32:06.959 --> 00:32:11.040 wanted to, you could have a different group for every single user. It's your choice how you want 00:32:11.040 --> 00:32:16.839 to do this. But let's say you just go with like auditors, bring your own devices, contractors, 00:32:16.839 --> 00:32:23.319 developers, development servers, employees, guests, network services, etc., etc., etc., etc., etc. The 00:32:23.359 --> 00:32:31.479 list goes on. So you create these groups. And then you have the opportunity to define what 00:32:31.479 --> 00:32:40.920 are the parameters that indicate if you are part of that group or not. So for example, Raymond, 00:32:40.920 --> 00:32:49.040 usernames and password, plus Raymond's laptop's posture, okay, or the posture of the laptop must 00:32:49.040 --> 00:32:54.400 be this, this, this, this, this, this, and this. And Raymond authenticating or Conrad or John 00:32:54.400 --> 00:33:00.319 authenticating, right? And then in the end, when all that comes together, that information can be 00:33:00.319 --> 00:33:06.439 used to determine, oh, Raymond right now is part of the employees group. But let's say all of a 00:33:06.439 --> 00:33:14.079 sudden, I am now connecting with my personal phone. Same username and password, but now it's my personal 00:33:14.079 --> 00:33:18.680 phone. But because of all that information that's being passed over here, I says, oh, 00:33:19.560 --> 00:33:32.079 Raymond's part of BYOD. So why is this important? Because notice there are security group tags that 00:33:32.079 --> 00:33:45.000 we have for each and every single group. So for example, if Raymond's in the employee group, 00:33:45.000 --> 00:33:51.239 he gets a group tag of four. In decimal, it's four. In hexadecimal, it's 0004. But something 00:33:51.239 --> 00:33:56.880 like 12, as you can see, would be 000C. So they show up both in decimal and hexadecimal. But let's 00:33:56.880 --> 00:34:02.680 just go with the decimal numbers to keep our lives simple here. Four. So what does that mean? It means 00:34:02.680 --> 00:34:11.840 now this switch knows because the server tells the switch, employees group, the group number is four. 00:34:12.000 --> 00:34:22.280 The switch now knows that anything that's coming for Raymond gets tagged with four. That's right, 00:34:22.280 --> 00:34:34.320 tagged with four. So now that switch, when receiving my frame, is going to do what? It's 00:34:34.439 --> 00:34:42.520 going to put in not only the 802.1Q header for what? Going over the trunk, but also this Cisco 00:34:42.520 --> 00:34:50.919 metadata header, CMD, Cisco metadata header. And notice it has information inside of it. So it's 00:34:50.919 --> 00:35:02.600 another tag. And there's the security group tag value. So in our case, four. Why now? Because 00:35:03.000 --> 00:35:11.879 this is going to follow me everywhere I go. So every single device now that receives this is 00:35:11.879 --> 00:35:28.120 going to know that I am in security group four. That wasn't the page we were on. Where are we? 00:35:33.600 --> 00:35:42.199 There we go. So tagged with four. So based on my contextual identity, it has been determined 00:35:42.199 --> 00:35:52.239 that I am in the employees group and the group is four. So now that tag of four can be used here. 00:35:52.239 --> 00:36:00.080 It can be used here. It can be used here. And ultimately, it can be used by any single device 00:36:00.080 --> 00:36:07.719 that supports TrustSec. Why? To make a decision. A decision about what? If I'm allowed to do what 00:36:07.719 --> 00:36:13.439 I'm trying to do at any point in time. That is now what determines whether I am or I'm not allowed 00:36:13.439 --> 00:36:20.800 to do something. Okay, so how does that come into play? Well, let's go back to our groups. Okay, 00:36:20.800 --> 00:36:27.120 what we also need to create are what are called security group ACLs. So what is a security group 00:36:28.120 --> 00:36:32.760 ACL? A security group ACL is an access control list. But the only thing you specify in the access 00:36:32.760 --> 00:36:43.159 control list is, is it a permit? Is it a deny? What protocol? And what ports? Look at that. 00:36:43.159 --> 00:36:52.560 So for example, web-only, permit TCP equal to 80. Maybe permit ICMP. Maybe deny TCP port 23. 00:36:52.560 --> 00:37:02.560 Very, very simple. Notice there's no source. There's no destination. Look at here. Look at 00:37:02.560 --> 00:37:11.479 all these examples we have. So this security group ACL I created, I just dumped all these 00:37:11.479 --> 00:37:17.120 in here. This one I created over here, I just dumped all those in here. So you're going to 00:37:17.120 --> 00:37:25.760 create ACLs for specific goals and objectives you want to accomplish. And then what do you do 00:37:25.760 --> 00:37:35.600 with these ACLs? You put them into the matrix. You follow the white rabbit folks. You take the pill. 00:37:35.600 --> 00:37:45.679 Here's your matrix. We call this the trust set matrix. That is where you identify your trust 00:37:45.840 --> 00:37:56.239 set policies. See? In our matrix. So notice that the matrix has source and destination listed in 00:37:56.239 --> 00:38:02.560 it. These are all the sources. Notice these are the same names we had. The matrix is automatically 00:38:02.560 --> 00:38:09.000 populated based on the groups you create. Every group you create is listed as a source. Every 00:38:09.000 --> 00:38:19.239 group you create is listed as a destination. Then what do you do? You pick the box and you 00:38:19.239 --> 00:38:28.120 apply your ACL that you created. So the ACLs we created over here, these ACLs, I can then just 00:38:28.120 --> 00:38:35.360 pick, click here, pick the ACL from the list. Boom, it's applied. So now you can see developers, 00:38:36.360 --> 00:38:41.760 source, this is the source, this is the destination. So if traffic is coming from 00:38:41.760 --> 00:38:50.439 group eight going to, what was this, group 12, this access control policy is being applied. 00:38:50.439 --> 00:39:03.199 And so again, every single one of your trust set devices, all your routers, all your switches, 00:39:03.199 --> 00:39:09.840 all your firewalls have the ability to use this matrix. Here's the cool thing about it. Here's the 00:39:09.840 --> 00:39:19.679 cool thing about it, Conrad. This matrix is actually downloadable by all the devices. Meaning 00:39:19.679 --> 00:39:30.719 they don't have to contact the server to check this. They get a copy of it. Yes. So they can 00:39:30.719 --> 00:39:39.159 make the decisions themselves without bugging ice. So you update this, they get a copy of the 00:39:39.159 --> 00:39:47.280 update. That's pretty cool. And this is a lot easier than trying to create ACLs on every single 00:39:47.280 --> 00:39:52.959 device. Just think about that right now. Yes. Any device that supports TrustSec, like we said, 00:39:52.959 --> 00:39:59.320 routers, switches, firewalls, Cisco, Cisco TrustSec products, which pretty much all modern 00:39:59.320 --> 00:40:04.479 day Cisco TrustSec products or Cisco routers, switches, firewalls, wireless LAN controllers, 00:40:04.479 --> 00:40:10.399 all of them, they support TrustSec because this is the way Cisco is going. And so that means for 00:40:10.399 --> 00:40:15.239 you now as an admin, you've got this centralized server where you can define everything you need 00:40:15.239 --> 00:40:21.439 to define all your different groups. And then when a user connects to the network, they are put in a 00:40:21.439 --> 00:40:28.479 group based on their contextual identity. So let's say I was a developer. I connect with my development 00:40:28.840 --> 00:40:34.399 PC. My development PC is up to date. I'm using my Raymond username and password. I am put into the 00:40:34.399 --> 00:40:39.040 developer group. That means now I can go to the development servers. Look, I can't go anywhere 00:40:39.040 --> 00:40:45.399 else. I can't go anywhere else. Just the development servers. And an admin just has to come in here and 00:40:45.399 --> 00:40:52.800 change things as they need to. And it affects every single networking device. So now any one of these 00:40:52.879 --> 00:40:59.800 routers, any one of these switches can use that TrustSec matrix in order now to make a decision. 00:40:59.800 --> 00:41:11.159 That's pretty cool. So classification is what? Classification is all about determining what 00:41:11.159 --> 00:41:16.760 security group tag is applied to that end user. And I just described it to you, right? I just 00:41:16.760 --> 00:41:21.479 described it based on what? Based on the user authenticating. It could be 802.1X. It could be 00:41:21.479 --> 00:41:26.199 MAC authentication bypass. It could be web auth. But let's not forget about the contextual identity 00:41:26.199 --> 00:41:32.879 of the entire device itself that you are using as well can come into play. So if I am a developer, 00:41:32.879 --> 00:41:37.840 but I'm not using my development machine, I'm using my personal machine, and they authenticate me, 00:41:37.840 --> 00:41:44.600 but put me into the guest group instead. And so if I'm in the guest group, I now cannot do any of 00:41:44.600 --> 00:41:53.000 my work. I can't. But think about it. Without TrustSec, if you're using traditional security, 00:41:53.000 --> 00:42:00.199 I could bring in my laptop, personal laptop, plug it into the network, put in my username and 00:42:00.199 --> 00:42:06.919 password, connect to the domain, and I could start working on my stuff. That is dangerous. That is 00:42:06.919 --> 00:42:14.320 super risky. But it's hard to control that. I mean, there's ways to do it, but it's hard to control 00:42:14.520 --> 00:42:26.840 that, right? So with TrustSec, if I bring in my personal laptop, plug it in, immediately goes, 00:42:26.840 --> 00:42:31.159 well, that's not the right posture. Right username and password, wrong posture. Oh, 00:42:31.159 --> 00:42:35.840 that means Raymond's in the guest group. Or Raymond's in the internet-only access group 00:42:35.840 --> 00:42:41.320 in that particular case. So now I'm like, it's not working. So I call up the IT department. I'm like, 00:42:41.479 --> 00:42:45.120 I brought in my personal laptop today. I plugged it in. I'm trying to do my work with it. And 00:42:45.120 --> 00:42:48.239 they're like, okay, well, that's the reason. You can't do that. Well, why not? Because our 00:42:48.239 --> 00:42:52.560 TrustSec policy has blocked you. You got to use the approved machines to do what you want to do. 00:42:52.560 --> 00:42:56.360 Why? But I don't want to do that. Well, I mean, that's our policies, right? It's about keeping 00:42:56.360 --> 00:42:59.199 the cyber criminals out. And you could have brought a cyber criminal into the company on 00:42:59.199 --> 00:43:03.520 your laptop today and not even know it. So we just protected the company by stopping you from 00:43:03.520 --> 00:43:08.959 doing that. You see, it makes our lives easier as security admins. That's the whole point behind 00:43:09.159 --> 00:43:13.520 it. Yes, a lot of work up front, but in the end, oh my gosh, you're so much better protected. 00:43:13.520 --> 00:43:19.399 Because other than that, think about all the static work you would have to do. Now, 00:43:19.399 --> 00:43:25.239 you can do static classification with TrustSec. So you can still do static based on IP address of 00:43:25.239 --> 00:43:31.399 the device, the subnet of the device, the VLAN the device is in, the port the device is connected to, 00:43:31.399 --> 00:43:37.239 but then you are still old school. You're tying it to the IT infrastructure and you're limited on 00:43:38.080 --> 00:43:42.840 what you can classify based on. But if you go with dynamic classification, where now you are 00:43:42.840 --> 00:43:48.800 using 802.1X, MAB, WebAuth plus the actual posture of the device and the who's, the what's, where's, 00:43:48.800 --> 00:43:53.439 when the why the how's, in the end, so much better, so much better in the end. 00:43:53.439 --> 00:44:03.760 So like we said, that security group tag is going to follow you now. It's in the frame. I know it's 00:44:03.760 --> 00:44:09.600 in the frame and your frame gets rewritten every time, but every device is going to be responsible 00:44:09.600 --> 00:44:13.760 for taking that tag and putting it back into the frame they create, putting it back in the frame 00:44:13.760 --> 00:44:22.919 they create, because they have to make sure that you stay in that group. Question is, can you be 00:44:22.919 --> 00:44:30.719 part of multiple groups? Not at the exact same time, right? So for example, if I authenticate 00:44:30.719 --> 00:44:37.879 on my work PC, then I'm going to have to be in a very specific group based on that. So I'm either 00:44:37.879 --> 00:44:41.520 going to be, let's say, if I'm a developer, I'm in the developer group. I'm an instructor, I'm in 00:44:41.520 --> 00:44:47.120 an instructor group. If I'm, right, why? Because that tag has to be applied to your frames. You 00:44:47.120 --> 00:44:52.080 can't have more than one group specified in that at any given time. Now you might be saying, well, 00:44:52.080 --> 00:44:55.000 then how do you get access to what you need if you're only in one group? Well, that's where this 00:44:55.000 --> 00:44:59.719 comes into play, right? So if the developer needs access to development servers, the developer needs 00:44:59.719 --> 00:45:03.679 access to the internet, well, then go ahead. Go to where that you have internet as a group 00:45:03.679 --> 00:45:07.520 potentially, and then what do you do? You turn around and you put allowed to go to the internet, 00:45:07.520 --> 00:45:12.760 right? What about BYOD, right? Developers connected to this, or developers connected to that, or this 00:45:12.760 --> 00:45:17.399 connected to this, then you just pick and choose, okay? So I want this source to be able to get to 00:45:17.399 --> 00:45:22.560 that destination, so let's put in an ACL in there. I want that source to get to that, I want to put 00:45:22.560 --> 00:45:27.280 an ACL in there. And so source is always here, destination is always, it's a lot easier than 00:45:27.280 --> 00:45:31.479 working with your ACLs because we saw ACLs in a couple sessions ago, or it was yesterday, right? 00:45:31.479 --> 00:45:37.360 Yesterday? Yeah, it was yesterday. And remember like how complicated it can get, right? Okay, 00:45:37.360 --> 00:45:43.360 so traffic source, traffic destination, source ports, destination ports, no, right? You don't 00:45:43.360 --> 00:45:48.320 have to specify source and destination, just do you want to allow that source to talk to that 00:45:48.320 --> 00:45:55.600 destination, yes or no? And if so, what ports, what protocols? Put it in there. And it doesn't 00:45:55.600 --> 00:46:02.080 matter which way the traffic's going, the device can figure it out. The device can figure it out. 00:46:02.080 --> 00:46:13.080 That's the power behind this. So no, if you're a member of two groups, that would possibly cause 00:46:13.080 --> 00:46:19.520 conflicts, right? So when does enforcement happen? This is interesting because when I first learned 00:46:19.520 --> 00:46:23.800 about when enforcement would happen, I'm like, that doesn't make sense. That really doesn't 00:46:23.800 --> 00:46:32.479 make sense. Because I've always been taught, I want to enforce policies as close to the source 00:46:32.479 --> 00:46:41.919 as possible. Why? So the traffic never goes into the network and cause excessive bandwidth to only 00:46:41.919 --> 00:46:47.320 be dropped, right? I want to stop it as early as possible. Well, with TrustSec, it's actually 00:46:47.320 --> 00:46:54.520 destination-based. That's right. It's the complete opposite of what we typically do. It says here 00:46:54.520 --> 00:47:07.959 enforce typically on the egress network device. Destination-based using the matrix. Every network 00:47:07.959 --> 00:47:12.159 device therefore needs a copy of the matrix so they download it from the identity services engine. 00:47:12.399 --> 00:47:18.639 So that way they don't have to bug the identity services engine. I mentioned that earlier. So 00:47:18.639 --> 00:47:24.000 if I am adding the tag here, so I add the tag here of eight, remember security group eight, 00:47:24.000 --> 00:47:31.760 and we said the security group of the servers here is 12. So this is my server and it's 12. 00:47:31.760 --> 00:47:39.360 The security group here is 12 for that server. So I want to connect to that particular server. 00:47:39.360 --> 00:47:48.360 So when I try to do that, right, I get tagged with a security group of eight because that is 00:47:48.360 --> 00:47:55.919 my contextual identity. That's who I am. And then my traffic flows. My traffic gets to the end and 00:47:55.919 --> 00:48:04.360 then the end device, the end network device that's connected to that destination device takes a look 00:48:05.320 --> 00:48:12.840 at the matrix and says security group eight is the source. Security group 12 is the destination, 00:48:12.840 --> 00:48:20.040 right? Because the destination is not actually in what? The destination is not actually in the frame. 00:48:20.040 --> 00:48:25.080 So we don't know the destination along the way. That's why we are destination-based. 00:48:26.120 --> 00:48:32.439 So now we come through here all the way. We get to the end and it says you are allowed. 00:48:32.439 --> 00:48:40.199 You are allowed. So therefore you are allowed to communicate. But let's say we were 00:48:41.479 --> 00:48:48.760 security group six. I think security group six is guests. So you connect to the network, 00:48:48.760 --> 00:48:52.840 you are security group six and this can, you get security group tags whether you're wired or 00:48:52.840 --> 00:48:57.719 wireless. This works wired and wireless folks, not just wired, wired and wireless. So let's 00:48:57.719 --> 00:49:01.959 pretend you're a wireless client. You're part of security group six. You are a guest. 00:49:02.919 --> 00:49:08.760 And now you are trying to go to the development servers. So your traffic goes through the network. 00:49:08.760 --> 00:49:15.159 It arrives at the other side. And what do we have? We have six going to who? To 12. 00:49:15.719 --> 00:49:20.439 The matrix says denied. So your traffic is going to be dropped. 00:49:22.360 --> 00:49:26.919 Now the first thing that comes to people's mind is, well, that's excessive for the network. We're 00:49:26.919 --> 00:49:31.959 doing a lot of routing. We're doing a lot of switching only for traffic to be dropped. 00:49:32.520 --> 00:49:43.399 But let's pause for a moment. Can anybody tell me what type of traffic is typically 00:49:43.399 --> 00:49:53.399 used inside of our environments more than 90% of the time between end stations and servers 00:49:54.280 --> 00:50:03.239 or end stations in the internet? Is it going to be UDP traffic? Is it going to be TCP traffic? 00:50:03.800 --> 00:50:11.719 Is it going to be? Yes, it is TCP traffic, TCP traffic. So my question to you now is, 00:50:11.719 --> 00:50:17.959 what has to happen first with TCP? What's the very first thing that has to happen? 00:50:24.360 --> 00:50:33.399 Three-way handshake. That's it. So will any data even get transmitted if you are denied? 00:50:33.399 --> 00:50:40.760 So for example, the guest, this would have to be the three-way handshake first, right? 00:50:41.719 --> 00:50:51.080 Six going to 12 is what? Denied. Sorry, three-way handshake doesn't even form, 00:50:51.080 --> 00:50:56.760 which means no data even gets the flow. So it works, right? It's not excessive. 00:50:58.040 --> 00:51:04.360 It's not excessive at all when you think about it that way. So that's why they decided to go 00:51:04.360 --> 00:51:10.760 this route because they're like, wait a second. That means we don't have to worry about carrying 00:51:10.760 --> 00:51:17.959 both the source and destination tags in our frames or even this device having to know, 00:51:18.280 --> 00:51:21.639 the access device having to know where you're even trying to go. It doesn't matter. They just 00:51:21.639 --> 00:51:27.560 have to know who you are, put the tag in it, and then the end device can determine 00:51:27.560 --> 00:51:31.479 whether that is okay or not. Now you might be saying, oh, but what about UDP traffic? Okay, 00:51:31.479 --> 00:51:38.439 well, yeah, unfortunately with UDP traffic, if I decide to send or try to connect 1,500 bytes 00:51:38.439 --> 00:51:44.360 or send 1,500 bytes to that server in UDP, it's going to end up going there just to be dropped, 00:51:44.439 --> 00:51:49.080 just to be dropped, just to be dropped. But there's not enough UDP traffic for 00:51:49.080 --> 00:51:53.399 us to be concerned about that saturating the network in that particular case. 00:52:01.479 --> 00:52:05.159 And if that does become an issue, then you may want to filter out certain types of UDP 00:52:05.159 --> 00:52:11.560 traffics, maybe using other methods of security as well. But this allows you now what? Just 00:52:11.560 --> 00:52:15.959 let's go take this a step further. If I pick up here and I go down here, 00:52:18.199 --> 00:52:22.040 I am Raymond, the developer, and I want to access my server. 00:52:23.959 --> 00:52:32.840 Security group tag what? Eight gets applied to me. Eight going to 12. I am allowed. So as you can 00:52:32.840 --> 00:52:39.320 see, no matter where I am connected to in the environment, I am allowed. 00:52:42.840 --> 00:52:47.159 That's some cool stuff. That really is some cool stuff when you think about it. 00:52:47.959 --> 00:52:54.199 But it really requires you to have a different mental shift in your attitude towards security 00:52:54.199 --> 00:52:59.800 and how you secure your environment. So remember this, at the point of network access, 00:52:59.800 --> 00:53:05.080 the switch contacts the identity services engine. It identifies and therefore to figure out which 00:53:05.080 --> 00:53:08.919 group you belong to. Once the identity services engine collects all the information from the 00:53:08.919 --> 00:53:12.840 switch, it can tell you which group the device belongs to. So that way there you can put the 00:53:12.840 --> 00:53:21.320 group number, the security group tag in the Cisco metadata tag of the frame going forward. 00:53:21.320 --> 00:53:29.159 So that way there the source of that device, the source tag, can be sent along and therefore at 00:53:29.159 --> 00:53:34.679 the destination we can enforce the policy based on source and destination tags. Because the end 00:53:34.679 --> 00:53:40.919 device will know what the tags are for the devices that are connected to it. Because when the server 00:53:40.919 --> 00:53:45.959 connects to the network, the switch is going to know, oh, you're part of group 12. So every 00:53:45.959 --> 00:53:50.120 device knows who's connected to them and what their tags are to make all this work. 00:53:53.000 --> 00:53:56.600 Should security really belong to the network engineer? Well, Andrew, no. The network engineer 00:53:56.600 --> 00:53:59.879 is not responsible for this. Your security professionals would be responsible for this 00:54:00.520 --> 00:54:07.000 with the networking engineers ensuring it's being enforced on the devices in question. 00:54:07.000 --> 00:54:13.159 So what is it? It's a combination of what? Security and operations together. SecOps. 00:54:13.719 --> 00:54:21.879 SecOps. Security and operations together. It's all part of a new mindset. Instead of being siloed 00:54:21.879 --> 00:54:26.600 with the security people and the network to people and the server people, it's about working 00:54:26.600 --> 00:54:35.399 together now to ensure that our entire environment is 100% safe and secure. We got to work together 00:54:35.399 --> 00:54:40.679 nowadays. It's just not one or the other. Yep. All right. So MACSEC is something else I want to 00:54:40.679 --> 00:54:48.199 talk about and then we're going to take a break. MACSEC is a feature we have that gives us the 00:54:48.199 --> 00:54:53.399 opportunity, and it's an open standard. TrustSec was just a proprietary. MACSEC is an industry 00:54:53.399 --> 00:54:59.879 standard whereby we can do layer two hop-by-hop encryption. Layer two hop-by-hop encryption. 00:55:00.600 --> 00:55:06.600 What does that mean? It means that I can actually encrypt traffic from here to here 00:55:07.399 --> 00:55:12.840 and then encrypt traffic from here to here. Then I can encrypt traffic from here 00:55:12.840 --> 00:55:17.080 to here and then I can encrypt traffic from here to here at a minimum. 00:55:18.199 --> 00:55:22.919 Why do I say at a minimum? Because if we were using the right services on our devices, 00:55:22.919 --> 00:55:29.719 then I can also encrypt traffic from here to here and I can encrypt traffic from here to here. 00:55:29.719 --> 00:55:34.600 So notice how I kept saying here to here, here to here, here to here, here to here, okay? This is 00:55:34.600 --> 00:55:40.040 not end-to-end encryption. Be clear about that. It's not end-to-end encryption. It's hop-by-hop 00:55:40.040 --> 00:55:46.040 encryption. Hop-by-hop encryption. It's about encrypting the traffic as it's being transmitted 00:55:46.040 --> 00:55:49.560 from device to device to device to device to device to device to device to device. 00:55:50.439 --> 00:55:57.159 Therefore, we get confidentiality and integrity on a hop-by-hop basis. We encrypt the traffic 00:55:57.159 --> 00:56:03.560 between MACSEC peers. If I'm running, for example, Cisco's secure access client, 00:56:03.560 --> 00:56:09.639 Cisco AnyConnect client, in this particular case here, we could use MACSEC in that case because 00:56:09.639 --> 00:56:14.360 that client supports it. I could do MACSEC here, MACSEC here, MACSEC here, MACSEC here, 00:56:14.360 --> 00:56:18.120 and same thing here. Install a software there, then I can do MACSEC there as well. 00:56:19.080 --> 00:56:25.959 Note that traffic needs to be unencrypted by the switches, by the routers, by every device in 00:56:25.959 --> 00:56:30.840 between because they have to look at what? Security group tags. What else do they have to look at? 00:56:30.840 --> 00:56:36.280 They have to look at trunking tags or any other tags that are in there. They have to look at QoS 00:56:36.280 --> 00:56:41.639 markings and classification values. So this is going to give us secure communication channels 00:56:41.639 --> 00:56:48.040 for traffic on a hop-by-hop basis at layer two of the OSI model. And just to show you here, 00:56:48.840 --> 00:56:52.360 when you look at MACSEC, here's the header for MACSEC. 00:56:55.320 --> 00:57:02.280 And so you'll see with the MACSEC header, we now end up encrypting everything from the 802.1q tag 00:57:02.919 --> 00:57:09.800 all the way up to the end of our payload, including the security group tags. 00:57:10.760 --> 00:57:17.639 And everything from here to here is authenticated. So we get both authentication, encryption, 00:57:17.639 --> 00:57:23.639 integrity checking of everything from what? The 802.1q header right to the end of your data, 00:57:23.639 --> 00:57:28.439 right to the end of your data because the payload here would be your packet as an example. 00:57:30.199 --> 00:57:34.439 All right, so it's really important for you to remember that for the exam, what MACSEC is. Again, 00:57:34.439 --> 00:57:38.600 you don't have to implement TRUSTSEC. You don't have to implement MACSEC. What do you have to 00:57:38.600 --> 00:57:43.239 be able to do? Understand what they are, understand what they accomplish 00:57:45.320 --> 00:57:49.320 based on how I've described them to you. So that way, they have to use terms like contextual 00:57:49.320 --> 00:57:56.120 identity, enforcement, dynamically adjusting your security policies on the fly, right? 00:57:56.120 --> 00:58:00.520 TRUSTSEC, right? MACSEC, layer two, hop-by-hop encryption 00:58:01.639 --> 00:58:05.239 in our environment, not end-to-end encryption, hop-by-hop encryption. 00:58:06.199 --> 00:58:11.800 All right, so make sure you know those for the exam. Again, expect two or three questions maybe, 00:58:11.800 --> 00:58:16.360 being able to pick them out of a lineup, right? What feature does this or what feature does that? 00:58:16.360 --> 00:58:17.560 That's what you're trying to do here.