So now we get to begin our discussion on next-gen campus networks. What do we mean
by next-gen campus networks? We mean newer technologies, newer features, newer
services that many of you may or may not be using in your organization right now
or don't even know exist. Some of the stuff we'll talk about you know. So
hopefully you know about like things like network access control, 802.1
export based authentication, MAC authentication bypass. What else is there?
WebAuth, those things. Hopefully you already know about those. If not, that's
okay. You'll learn about them here at a high level. But also things like TrustSec
and MACSec and LISP and VXLAN and SD-Access and SD-WAN. These are all
topics that are going to show up in the certification exam. So I am very
confident in telling you that everything we're about to talk about expect one or
two questions on the exam for every single discussion we have here for the
rest of today's session. Same thing with COP. Expect two, at least two questions on
the exam about COP. And some of this stuff is going to overwhelm you here in
today's session. Because it's new stuff and you'll be like I don't
understand why would we even need that. Well you don't need it. But larger
enterprises do. And the larger enterprises are doing this. And so Cisco
is getting you primed and ready for maybe your potential future. And maybe
not. The fact of the matter is it's part of the exam and you got to learn it. So
our first discussion is going to be on network access control, TrustSec and MACSec.
So let's think about our environment here. We have our access layers. We have
our distribution layers. We have our core layers. We have the edge of our
environment that goes to the WAN, to our remote offices and internet connections.
We have some IPSec tunnels there. Maybe some GRE over IPSec tunnels. Might even
have a DMVPN setup. But what we want to talk about right now is controlling
access to the actual network. Not from a management standpoint anymore folks, but
from an end-user standpoint. How can we authenticate who or what is actually
connecting to our wired or wireless network. So folks, any of you here using
any of these three options to control who or what is allowed to connect to the
wired or wireless network. If you are, chat in which ones you're using.
And what is the purpose of all three of these? Let's keep it simple. To deny
access until the user or device has been successfully authenticated. Now good
news here folks, for the exam you do not have to be able to configure, verify or
troubleshoot any of these. So that is not what our discussion is about. Our
discussion is what you have the ability to pick them out of a lineup or pick
them out of a drag-and-drop. That is the goal here. So what is 802.1X and why
would I want to use it? What is MAP and why would I want to use it? And what is
WebAuth and why would I want to use it? But remember they're all part of network
access control. So any question that says what are examples of network access
control, these are the ones you want to know about for the exam. Now is port
security folks? Port security. Remember port security from CCNA?
Is port security a type of network access control or can it be a type of
network access control? Sure it can be. Absolutely it can be. And we would be
controlling who or what is allowed to connect to the port. The port based on
MAC addresses in that case. So that is an option. The problem is that's not a
scalable solution. It's not a flexible solution. It's not an easy solution at
all. Especially in our high-paced ever-evolving network environments. And
if you're like my network doesn't evolve, okay you're you're one of the
exceptions potentially. But the idea here is that 802.1X is a really great
option we have for network access control whereby people enter usernames
and passwords. So any senior on the exam that talks about having to enter a
username and a password, a good option is 802.1X. However, there's an
extra aspect that you have to think about this. Also a supplicant. What is a
supplicant? A supplicant is 802.1X compliant software that has been
installed on the device. So Windows comes with a supplicant you can use. Cisco
Secure Access has a supplicant that you can use like Cisco AnyConnect. So
that would be the supplicant. So I would have the supplicant software installed
on my device. So my device, me, I'm known as the supplicant in an 802.1X
scenario. Then we need an authenticator. Well who's the authenticator in this
case? Does anybody know who the authenticator would be with 802.1X in
this scenario right now? Yeah, the network device you're connected to. Perfect. So in
our case is the switch, right? Authenticator. So I would have to set
this up with 802.1X port-based authentication configuration commands
and use AAA authentication method lists in order to accomplish that. So that's my
authenticator. And then I have an authentication server that is over here.
In my case, it's Identity Services Engine. It's my authentication server. Now
specifically with 802.1X we have to use RADIUS.
So what happens here is that the supplicant will be constantly using
what are called extensible authentication protocol, so EAP,
extensible authentication protocol, over LAN frames for an initial
communication and setup. And then we have RADIUS being used from here all the
way over to here in order to verify those current credentials that are being
applied. So once you authenticate using EAPOL and you have successfully
authenticated, then that means that you are now going to be allowed to use that
particular port. The port essentially opens up and your data traffic is allowed
to flow through. So until you authenticate, only those EAPOL messages
are allowed in and out of that port. Everything else gets dropped. Once you
authenticate, then the rest of your traffic is allowed through that
particular port. So the challenges we face with this, with 802.1X though, is the
fact that someone has to be able to type in a username and password and that
device has to be able to support a supplicant. So if you can't type in a
username and password, you can't install a supplicant, then 802.1X is not going to
be your answer for that scenario on the certification exam. So another option we
have is MAC authentication bypass. So MAC authentication bypass is what?
MAC authentication bypass is about authenticating with MAC addresses.
MAC addresses. So that is very similar to port security. But what's the difference now?
What's the difference? We have a centralized database of allowed and
denied MAC addresses. So I have my authentication server. Whereas it's port
security, you don't. So let's say you have a camera, okay, not really that type
of camera, but and your camera, let's say it's a security camera, it's connected up
to the switch. So the camera has to authenticate to the network before it
can be used, right? Do we have the ability to type in a username and
password on a camera? Probably not. Do we have the ability to install a
supplicant on a camera? Probably not. Therefore, MAC authentication bypass
would be the better option for that. Because what does a camera have, an
Ethernet-based camera have? It has a MAC address. So in my authentication server
database over here, I would have my MAC address database over there. And then
between the identity services engine server, the authentication server, and
here we'd be using RADIUS. And then whenever you try to connect to that
port, so I'd have to set up MAC authentication bypass on that port. Then
when you try to communicate, right, I'm gonna then have to take your MAC
address, send it over here and say, hey, is this legit or not? And then the
answer is yes, good, you are now allowed to use my particular port. The challenge
that we face with MAC authentication bypass is that MAC addresses can be
easily spoofed. So if a cyber criminal can figure out a device's MAC address
and then change their MAC address on their device and then connect, let's say,
to another port using that MAC address, then they technically could possibly get
connectivity. But again, it's better than nothing, right? You're better off to do
this than not have authentication.
So think about the two now. Compare them to each other. If the snare on the exam
is talking about a device that only has a MAC address and you can't install a
supplicant on it, and no user can type in a username and password, then probably
this is the answer you want to pick. Because if you can't type anything in
and you can't install a supplicant, then what? Authenticate based on MAC address.
That's going to be your answer. And then what about WebAuth? Okay, so WebAuth is
where people have to type in usernames and passwords into a web, what? A web
portal, a web page. So what type of scenario would be good for this? Well, a
scenario whereby a user has a device that doesn't support a supplicant, but
supports a web browser. Because if it supports a web browser, you can have a
web page, a web portal, they type in their username, they type in their
password, then they authenticate using that web portal connection. So now they
can access the network based on being authenticated. So as you try to connect,
you connect up, whether it's wireless or wired, you can use web portals, and when
you try to connect, you're then all of a sudden redirected to the web portal, and
then you're redirected to the web portal, and then you're asked for your
credentials, you put them in, and then if you're right, then you're allowed to
communicate on the network. If not, then you're going to be denied from
communicating on the network, because the port will not be opened up for you. So as
you can see, there's three different options here that are relevant for the
certification exam, and as you can see, they have very specific scenarios and
situations associated with them. So your goal for the certification exam is to be
able to say, hey, based on the scenario circumstance, which one of these is the
one I should go with? So let me give you, let me just give you, let's try
something here. Chat in your answer. You have guests, contractors, temporary
workers that need access to your network, using their own devices, their own
laptops, their own phones, their own tablets. Which of these three options do
you think is the best option to implement in that scenario? You could say
right now, well Raymond, there's a little bit, a few details missing. Okay, but
that's all you're given. Think about it from a real world. Would you fight with
them to install a supplicant on their devices? Probably not. So it doesn't make
sense to do 802.1X, because they're not going to want to use a supplement, a
supplicant most of them. You're not going to just authenticate based on their Mac
addresses, right, but you could set up a web portal, you could have a web portal,
create individual accounts for them using that web portal, and then in the
end they type in their username and passwords and they can connect through
their guest accounts, the contractor accounts, or whatever accounts that you
have for them. So yeah, exactly. You can't control the devices? Web off. So typically
it's hard to control guest devices, contractor devices, temporary worker
devices, if you don't own those devices. But think about a scenario where you own
the devices. You own the devices and you can install a supplicant, then you would
pick 802.1X. So that's the way I want you to think about these three
different options as you prepare for the certification exam. So like I said, you're
not gonna have to worry about configuring it, verifying it, troubleshooting it, it's
about do you understand what network access control is? Yes, you do now if you
didn't know. And do you know these three primary different options that exist?
Now another thing we want to talk about for the certification exam is a feature
called TrustSec. Now this is a Cisco proprietary solution. Anybody here using
TrustSec? Yes, if you are. No, if you are not. TrustSec. TrustSec. So let me tell
you about it so you can pick things out of a lineup on the certification exam.
Good. If you don't know what it is, put in a question mark. That's always a great
answer here. I don't know what you're talking about. Good. You're gonna learn
about it. So let's think about this environment here right now. Wait now. How?
How do we ensure consistent, repeatable policy enforcement throughout the
network? I mean it's a big challenge and it's not easy. It's gonna be made up of
a whole bunch of different things that are just gonna cause more problems.
That's how we mostly deal with our networks today. At the moment, we
typically, most of us, are implementing policies at our layer 2, layer 3
boundary.
And how do we typically do that? What are we typically using for policy
enforcement at our layer 2, layer 3 boundaries, folks?
ACLs. Exactly. We have policy enforcement at the edge of our
environment. Firewalls, ACLs, application layer filtering. Okay. It's a little
better than what's going on here. But what we want to realize is what we have
right now is something that is not scalable. Why? Because the larger the
network grows, the more services we have, the more resources we have, the more
users we have, the more subnets we have. And that becomes very difficult to
manage, monitor, maintain. The policies that are at this distribution layer, the
policies that are at this distribution layer, the policies that are at this
distribution layer, the policies that are at that distribution layer. That becomes
a challenge. Also, the way we have it set up is not mobile. If a user moves from
one location to another location, I have to adjust the policies to reflect this
move. If a new app gets installed, or a new device gets installed, or a new
feature, a new service gets installed, right? Well, now my policies have to be
adjusted, or maybe things don't work. Or maybe we have a security flaw if we
don't adjust those policies. And the thing is, is policy enforcement is
typically based on a really dirty word today, and that is location. And location
is typically tied to what? Your IP address. That's right. That is typically
how we implement policy, based on location and IP addresses. So, if you're
here, you get this policy applied to you, because why? You are in that location,
and you belong to this particular subnet VLAN broadcast domain. If you're here,
then you get this other policy. Why? Because of your location, because of your
IP address, because of those things. Your subnet, your VLAN, your broadcast domain.
And so, this type of mentality is what we've used for a really long time, and
what many of us still use to this very day. And it's not all that great for
users. It's not all that great for admins, because it's really hard to manage,
monitor, maintain, secure, control, and keep the cyber criminals out, folks.
Instead, we want policies to be based not on location and IP addresses anymore. We
want policies based on who you are, what you are doing, what you are using, why you
are doing it, when you are doing it. And we want to do all of that from a centralized location,
as opposed to everywhere in our environment. And if you move, if you pick up from here,
and you come down here, I want those exact same policies that applied to you here,
applied to you here. And that is where TrustSec comes into play. TrustSec is Cisco proprietary.
This feature, TrustSec, is Cisco's implementation of a zero-trust architecture. Notice they don't
call it that, though. They call it TrustSec. And there's a lot more that goes into this
than just TrustSec. But it's part of their zero-trust architecture, where you zero-trust
and you always verify. Never trust, always verify. And it doesn't matter where you are,
your policies follow you everywhere. So if I'm in the office, headquarters, or branch,
or at home, the same policies apply to me. If I'm on my laptop, I have these policies applied. If
I'm using a mobile phone, these policies apply. If I'm using my tablet, these policies apply.
Right down to the software that is installed and updated on the device. That is all part of the
identification and authentication process. So if all of a sudden I download a new app on my laptop,
and that app was not approved by IT, I'm in breach of the policy and I could be denied access to the
network. Or my privileges could be dropped down and I would no longer have administrative access
to this, that, or the other. Or I would no longer be able to access, let's say,
confidential information. I can still access the internet, but I'm now blocked dynamically
from doing what? Accessing that confidential document. Why? Because I've installed an app
that's unapproved, that has not been vetted and identified for risk and vulnerabilities.
How cool is that? And all of that can be handled right from here. Identity Services Engine. Oh,
wait. Okay. So what does that mean? It means that when it comes to TrustSec, we're going to need
ICE to centrally manage everything that's going on here. So if you want TrustSec, you got to spend
a lot of money on Identity Services Engine, which is a AAA server that supports RADIUS and supports
TACACS+, and all that fun stuff. So I want you to know that you need ICE. What else do you need?
Well, you need switches that support TrustSec. And the modern-day Cisco switches all support
TrustSec. So that 9000 series family, no problem. You got TrustSec there. So switches, routers,
firewalls, wireless devices, wireless LAN controllers, like all of that stuff nowadays
with Cisco. Then modern stuff all supports TrustSec because this is what they're pushing.
This is what they want everybody to start using. One, because it's more money for them,
obviously. But two, it actually is a lot better security solution for all of us in the real world.
Huge learning curve, lots of money, but in the end, you are going to be better protected from
the cyber criminals of the world. Because think about this. If someone in your organization all
of a sudden installed an app on their laptop, why? Because they double-clicked on an email
attachment that then installed malware on their system. As soon as that happens, you are now in
violation of your policy, which means you are blocked. You are isolated. You are stuck where
you are. Cyber criminal is stuck on your system. Done. You see how we're trying to ensure that we
can have dynamic security policies that adjust on the fly based on things people do. So the
cyber criminals, if they get a hold of something, they are stopped because it breaches the policy.
And the policy is not just based on IP address and location. The policy is based on, yes,
it could be IP address, location, username, password, biometric identification. It could
be based on the device in use with the operating system version, coupled together with antivirus
updates, coupled together with software installed on the device. And whether that's updated,
if anything else is added, then you're in breach of that policy. Location as well. Are you here?
Are you there? And your levels, your permissions, your authorization levels can change dynamically
throughout the day based on what you've done. Without administrators even having to get involved.
It's like stuff of the future I'm talking about, but it's here today. It's a good list of stuff
to know. Like I said, right? What are the main components of TrustSec? ICE, switches, firewalls,
routers, all that stuff. Centralized. Know that. Centralized. Policy enforcement. Centralized.
Classification. So you define the policies where? In ICE. And then these devices enforce
the policy. They enforce the policy. Enforcement. So now do I need access control lists at the
distribution layer? Well, technically speaking, no. We can eliminate them all, right? Because
let's think about it. Traditionally, network access was based on what? Based on your VLAN.
You're in this VLAN. You belong to this subnet. You belong to this broadcast domain. We put an
access control list at the distribution layer. That's how we control you. So the VLANs are linked
to what? Your IPs, your departments, your roles, your functions. Therefore, security is based on
your IP, your location, your subnet, your VLAN. And that's not good because think about not everybody
in the sales department necessarily needs what? The same levels of policy. Just like everybody in
HR doesn't need the same levels of policy. Just like everybody, you see the difference here? I
can get so granular now with my centralized policy enforcement that I can do it on a user-by-user
basis if I wanted to. Least privilege principle is one of the primary components of TrustSec.
You now have the ability to do that really easily. Most of us don't implement the least
privilege principle in our organization because it's just too hard to go through all the employees
and say, well, you don't need this. You don't need this. I'll take it off of you. But you need
them, so I'll keep it for you. But you don't need them. We don't have time for that garbage. So we
don't do it. And because we don't do it, the cyber criminals are winning. But now we shift the whole
system around. And when I can now get really granular a lot easier and have dynamic changes
enforcements in play based on policies we set up, we have the ability to win the game. But again,
it comes at a price up front. So typically, we're filtering with our access control list,
the layer three devices. And what is it based on? Well, it's based on having an ACL and the
routed ports. And then it's based on what? Source and destination IP, source and destination port
numbers, all of that stuff, and really nothing else. Now, yeah, we could do a little bit of
application layer filtering in there and so on and so forth. And if we implement some firewalls in
there, now we're getting really crazy and it's getting expensive anyways. We would then be able
to maybe do application layer firewalling a lot closer to devices. But we typically don't do that.
We don't put a firewall right there at the distribution layer in our enterprise environment
by our end users. And then if you move somewhere, oh my gosh, well, I mean, there's no way to keep
that policy with the user in traditional environments. So not scalable, impossible to
control on a device-by-device, user-by-user basis. So with TrustSec, we can do it differently. We can
throw all this old school stuff out of the window. Because right now, if you're not using TrustSec,
the more source and destination permissions, the more complex the access control has become. And
the more movement of end devices in your network, the less manageable this becomes for you. So
instead with TrustSec, and this is an important key right here, you are basing security on the
contextual identity, that's the word, of the endpoint. The contextual identity of the endpoint.
Things like who, what, where, when, why, how. So who is doing this right now? Oh, it's Raymond. Why?
Because Raymond put in his username and password. Okay, but what is he trying to do? What is he
trying to do? Where is he trying to do this from? When is he trying to do this? Why is he trying to
do this? How is he trying to do it? What device is he actually using? Is that device's posture at
the levels it needs to be to meet what he, who, what, where, why, and how? And if so, grant him
access. If not, either drop his access levels down or deny him completely. It's up to you how you want
to approach that. So when does a lot of this decision come into play? It comes into play as
soon as you're connecting to the network. So what does this mean? Need. We need to have a
supplicant installed on those devices. That is going to give us the opportunity to what? Verify
the posture of the device. So we need some endpoint solution on it. Let's put it that way.
But also the user's ability to authenticate themselves and have that entire posture of
the device verified. Because I don't want you to go any further than this unless all of that is
approved. But the great thing about this is it doesn't matter whether you're here or whether
you move down here and plug in. I can do the exact same posture verification and identity
verification. Why? Because it's this device here, identity services engine, that's taking care of
that. And so here's the thing. There's a lot more going on here. But remember contextual identity,
right? So at the point of network access, we need to figure out the who's, the what's, the where's,
the why's, and the how. Why? Because at this point in time, that switch needs to figure out
from the identity services engine, which group you belong to. So on identity services engine,
we are going to create what are called security groups at a minimum. For let's say different roles
and responsibilities you have in your environment. But could you get as granular as having groups for
users? Sure, of course. Like a single user in a group? Of course you can. Right? If you really
wanted to, you could have a different group for every single user. It's your choice how you want
to do this. But let's say you just go with like auditors, bring your own devices, contractors,
developers, development servers, employees, guests, network services, etc., etc., etc., etc., etc. The
list goes on. So you create these groups. And then you have the opportunity to define what
are the parameters that indicate if you are part of that group or not. So for example, Raymond,
usernames and password, plus Raymond's laptop's posture, okay, or the posture of the laptop must
be this, this, this, this, this, this, and this. And Raymond authenticating or Conrad or John
authenticating, right? And then in the end, when all that comes together, that information can be
used to determine, oh, Raymond right now is part of the employees group. But let's say all of a
sudden, I am now connecting with my personal phone. Same username and password, but now it's my personal
phone. But because of all that information that's being passed over here, I says, oh,
Raymond's part of BYOD. So why is this important? Because notice there are security group tags that
we have for each and every single group. So for example, if Raymond's in the employee group,
he gets a group tag of four. In decimal, it's four. In hexadecimal, it's 0004. But something
like 12, as you can see, would be 000C. So they show up both in decimal and hexadecimal. But let's
just go with the decimal numbers to keep our lives simple here. Four. So what does that mean? It means
now this switch knows because the server tells the switch, employees group, the group number is four.
The switch now knows that anything that's coming for Raymond gets tagged with four. That's right,
tagged with four. So now that switch, when receiving my frame, is going to do what? It's
going to put in not only the 802.1Q header for what? Going over the trunk, but also this Cisco
metadata header, CMD, Cisco metadata header. And notice it has information inside of it. So it's
another tag. And there's the security group tag value. So in our case, four. Why now? Because
this is going to follow me everywhere I go. So every single device now that receives this is
going to know that I am in security group four. That wasn't the page we were on. Where are we?
There we go. So tagged with four. So based on my contextual identity, it has been determined
that I am in the employees group and the group is four. So now that tag of four can be used here.
It can be used here. It can be used here. And ultimately, it can be used by any single device
that supports TrustSec. Why? To make a decision. A decision about what? If I'm allowed to do what
I'm trying to do at any point in time. That is now what determines whether I am or I'm not allowed
to do something. Okay, so how does that come into play? Well, let's go back to our groups. Okay,
what we also need to create are what are called security group ACLs. So what is a security group
ACL? A security group ACL is an access control list. But the only thing you specify in the access
control list is, is it a permit? Is it a deny? What protocol? And what ports? Look at that.
So for example, web-only, permit TCP equal to 80. Maybe permit ICMP. Maybe deny TCP port 23.
Very, very simple. Notice there's no source. There's no destination. Look at here. Look at
all these examples we have. So this security group ACL I created, I just dumped all these
in here. This one I created over here, I just dumped all those in here. So you're going to
create ACLs for specific goals and objectives you want to accomplish. And then what do you do
with these ACLs? You put them into the matrix. You follow the white rabbit folks. You take the pill.
Here's your matrix. We call this the trust set matrix. That is where you identify your trust
set policies. See? In our matrix. So notice that the matrix has source and destination listed in
it. These are all the sources. Notice these are the same names we had. The matrix is automatically
populated based on the groups you create. Every group you create is listed as a source. Every
group you create is listed as a destination. Then what do you do? You pick the box and you
apply your ACL that you created. So the ACLs we created over here, these ACLs, I can then just
pick, click here, pick the ACL from the list. Boom, it's applied. So now you can see developers,
source, this is the source, this is the destination. So if traffic is coming from
group eight going to, what was this, group 12, this access control policy is being applied.
And so again, every single one of your trust set devices, all your routers, all your switches,
all your firewalls have the ability to use this matrix. Here's the cool thing about it. Here's the
cool thing about it, Conrad. This matrix is actually downloadable by all the devices. Meaning
they don't have to contact the server to check this. They get a copy of it. Yes. So they can
make the decisions themselves without bugging ice. So you update this, they get a copy of the
update. That's pretty cool. And this is a lot easier than trying to create ACLs on every single
device. Just think about that right now. Yes. Any device that supports TrustSec, like we said,
routers, switches, firewalls, Cisco, Cisco TrustSec products, which pretty much all modern
day Cisco TrustSec products or Cisco routers, switches, firewalls, wireless LAN controllers,
all of them, they support TrustSec because this is the way Cisco is going. And so that means for
you now as an admin, you've got this centralized server where you can define everything you need
to define all your different groups. And then when a user connects to the network, they are put in a
group based on their contextual identity. So let's say I was a developer. I connect with my development
PC. My development PC is up to date. I'm using my Raymond username and password. I am put into the
developer group. That means now I can go to the development servers. Look, I can't go anywhere
else. I can't go anywhere else. Just the development servers. And an admin just has to come in here and
change things as they need to. And it affects every single networking device. So now any one of these
routers, any one of these switches can use that TrustSec matrix in order now to make a decision.
That's pretty cool. So classification is what? Classification is all about determining what
security group tag is applied to that end user. And I just described it to you, right? I just
described it based on what? Based on the user authenticating. It could be 802.1X. It could be
MAC authentication bypass. It could be web auth. But let's not forget about the contextual identity
of the entire device itself that you are using as well can come into play. So if I am a developer,
but I'm not using my development machine, I'm using my personal machine, and they authenticate me,
but put me into the guest group instead. And so if I'm in the guest group, I now cannot do any of
my work. I can't. But think about it. Without TrustSec, if you're using traditional security,
I could bring in my laptop, personal laptop, plug it into the network, put in my username and
password, connect to the domain, and I could start working on my stuff. That is dangerous. That is
super risky. But it's hard to control that. I mean, there's ways to do it, but it's hard to control
that, right? So with TrustSec, if I bring in my personal laptop, plug it in, immediately goes,
well, that's not the right posture. Right username and password, wrong posture. Oh,
that means Raymond's in the guest group. Or Raymond's in the internet-only access group
in that particular case. So now I'm like, it's not working. So I call up the IT department. I'm like,
I brought in my personal laptop today. I plugged it in. I'm trying to do my work with it. And
they're like, okay, well, that's the reason. You can't do that. Well, why not? Because our
TrustSec policy has blocked you. You got to use the approved machines to do what you want to do.
Why? But I don't want to do that. Well, I mean, that's our policies, right? It's about keeping
the cyber criminals out. And you could have brought a cyber criminal into the company on
your laptop today and not even know it. So we just protected the company by stopping you from
doing that. You see, it makes our lives easier as security admins. That's the whole point behind
it. Yes, a lot of work up front, but in the end, oh my gosh, you're so much better protected.
Because other than that, think about all the static work you would have to do. Now,
you can do static classification with TrustSec. So you can still do static based on IP address of
the device, the subnet of the device, the VLAN the device is in, the port the device is connected to,
but then you are still old school. You're tying it to the IT infrastructure and you're limited on
what you can classify based on. But if you go with dynamic classification, where now you are
using 802.1X, MAB, WebAuth plus the actual posture of the device and the who's, the what's, where's,
when the why the how's, in the end, so much better, so much better in the end.
So like we said, that security group tag is going to follow you now. It's in the frame. I know it's
in the frame and your frame gets rewritten every time, but every device is going to be responsible
for taking that tag and putting it back into the frame they create, putting it back in the frame
they create, because they have to make sure that you stay in that group. Question is, can you be
part of multiple groups? Not at the exact same time, right? So for example, if I authenticate
on my work PC, then I'm going to have to be in a very specific group based on that. So I'm either
going to be, let's say, if I'm a developer, I'm in the developer group. I'm an instructor, I'm in
an instructor group. If I'm, right, why? Because that tag has to be applied to your frames. You
can't have more than one group specified in that at any given time. Now you might be saying, well,
then how do you get access to what you need if you're only in one group? Well, that's where this
comes into play, right? So if the developer needs access to development servers, the developer needs
access to the internet, well, then go ahead. Go to where that you have internet as a group
potentially, and then what do you do? You turn around and you put allowed to go to the internet,
right? What about BYOD, right? Developers connected to this, or developers connected to that, or this
connected to this, then you just pick and choose, okay? So I want this source to be able to get to
that destination, so let's put in an ACL in there. I want that source to get to that, I want to put
an ACL in there. And so source is always here, destination is always, it's a lot easier than
working with your ACLs because we saw ACLs in a couple sessions ago, or it was yesterday, right?
Yesterday? Yeah, it was yesterday. And remember like how complicated it can get, right? Okay,
so traffic source, traffic destination, source ports, destination ports, no, right? You don't
have to specify source and destination, just do you want to allow that source to talk to that
destination, yes or no? And if so, what ports, what protocols? Put it in there. And it doesn't
matter which way the traffic's going, the device can figure it out. The device can figure it out.
That's the power behind this. So no, if you're a member of two groups, that would possibly cause
conflicts, right? So when does enforcement happen? This is interesting because when I first learned
about when enforcement would happen, I'm like, that doesn't make sense. That really doesn't
make sense. Because I've always been taught, I want to enforce policies as close to the source
as possible. Why? So the traffic never goes into the network and cause excessive bandwidth to only
be dropped, right? I want to stop it as early as possible. Well, with TrustSec, it's actually
destination-based. That's right. It's the complete opposite of what we typically do. It says here
enforce typically on the egress network device. Destination-based using the matrix. Every network
device therefore needs a copy of the matrix so they download it from the identity services engine.
So that way they don't have to bug the identity services engine. I mentioned that earlier. So
if I am adding the tag here, so I add the tag here of eight, remember security group eight,
and we said the security group of the servers here is 12. So this is my server and it's 12.
The security group here is 12 for that server. So I want to connect to that particular server.
So when I try to do that, right, I get tagged with a security group of eight because that is
my contextual identity. That's who I am. And then my traffic flows. My traffic gets to the end and
then the end device, the end network device that's connected to that destination device takes a look
at the matrix and says security group eight is the source. Security group 12 is the destination,
right? Because the destination is not actually in what? The destination is not actually in the frame.
So we don't know the destination along the way. That's why we are destination-based.
So now we come through here all the way. We get to the end and it says you are allowed.
You are allowed. So therefore you are allowed to communicate. But let's say we were
security group six. I think security group six is guests. So you connect to the network,
you are security group six and this can, you get security group tags whether you're wired or
wireless. This works wired and wireless folks, not just wired, wired and wireless. So let's
pretend you're a wireless client. You're part of security group six. You are a guest.
And now you are trying to go to the development servers. So your traffic goes through the network.
It arrives at the other side. And what do we have? We have six going to who? To 12.
The matrix says denied. So your traffic is going to be dropped.
Now the first thing that comes to people's mind is, well, that's excessive for the network. We're
doing a lot of routing. We're doing a lot of switching only for traffic to be dropped.
But let's pause for a moment. Can anybody tell me what type of traffic is typically
used inside of our environments more than 90% of the time between end stations and servers
or end stations in the internet? Is it going to be UDP traffic? Is it going to be TCP traffic?
Is it going to be? Yes, it is TCP traffic, TCP traffic. So my question to you now is,
what has to happen first with TCP? What's the very first thing that has to happen?
Three-way handshake. That's it. So will any data even get transmitted if you are denied?
So for example, the guest, this would have to be the three-way handshake first, right?
Six going to 12 is what? Denied. Sorry, three-way handshake doesn't even form,
which means no data even gets the flow. So it works, right? It's not excessive.
It's not excessive at all when you think about it that way. So that's why they decided to go
this route because they're like, wait a second. That means we don't have to worry about carrying
both the source and destination tags in our frames or even this device having to know,
the access device having to know where you're even trying to go. It doesn't matter. They just
have to know who you are, put the tag in it, and then the end device can determine
whether that is okay or not. Now you might be saying, oh, but what about UDP traffic? Okay,
well, yeah, unfortunately with UDP traffic, if I decide to send or try to connect 1,500 bytes
or send 1,500 bytes to that server in UDP, it's going to end up going there just to be dropped,
just to be dropped, just to be dropped. But there's not enough UDP traffic for
us to be concerned about that saturating the network in that particular case.
And if that does become an issue, then you may want to filter out certain types of UDP
traffics, maybe using other methods of security as well. But this allows you now what? Just
let's go take this a step further. If I pick up here and I go down here,
I am Raymond, the developer, and I want to access my server.
Security group tag what? Eight gets applied to me. Eight going to 12. I am allowed. So as you can
see, no matter where I am connected to in the environment, I am allowed.
That's some cool stuff. That really is some cool stuff when you think about it.
But it really requires you to have a different mental shift in your attitude towards security
and how you secure your environment. So remember this, at the point of network access,
the switch contacts the identity services engine. It identifies and therefore to figure out which
group you belong to. Once the identity services engine collects all the information from the
switch, it can tell you which group the device belongs to. So that way there you can put the
group number, the security group tag in the Cisco metadata tag of the frame going forward.
So that way there the source of that device, the source tag, can be sent along and therefore at
the destination we can enforce the policy based on source and destination tags. Because the end
device will know what the tags are for the devices that are connected to it. Because when the server
connects to the network, the switch is going to know, oh, you're part of group 12. So every
device knows who's connected to them and what their tags are to make all this work.
Should security really belong to the network engineer? Well, Andrew, no. The network engineer
is not responsible for this. Your security professionals would be responsible for this
with the networking engineers ensuring it's being enforced on the devices in question.
So what is it? It's a combination of what? Security and operations together. SecOps.
SecOps. Security and operations together. It's all part of a new mindset. Instead of being siloed
with the security people and the network to people and the server people, it's about working
together now to ensure that our entire environment is 100% safe and secure. We got to work together
nowadays. It's just not one or the other. Yep. All right. So MACSEC is something else I want to
talk about and then we're going to take a break. MACSEC is a feature we have that gives us the
opportunity, and it's an open standard. TrustSec was just a proprietary. MACSEC is an industry
standard whereby we can do layer two hop-by-hop encryption. Layer two hop-by-hop encryption.
What does that mean? It means that I can actually encrypt traffic from here to here
and then encrypt traffic from here to here. Then I can encrypt traffic from here
to here and then I can encrypt traffic from here to here at a minimum.
Why do I say at a minimum? Because if we were using the right services on our devices,
then I can also encrypt traffic from here to here and I can encrypt traffic from here to here.
So notice how I kept saying here to here, here to here, here to here, here to here, okay? This is
not end-to-end encryption. Be clear about that. It's not end-to-end encryption. It's hop-by-hop
encryption. Hop-by-hop encryption. It's about encrypting the traffic as it's being transmitted
from device to device to device to device to device to device to device to device.
Therefore, we get confidentiality and integrity on a hop-by-hop basis. We encrypt the traffic
between MACSEC peers. If I'm running, for example, Cisco's secure access client,
Cisco AnyConnect client, in this particular case here, we could use MACSEC in that case because
that client supports it. I could do MACSEC here, MACSEC here, MACSEC here, MACSEC here,
and same thing here. Install a software there, then I can do MACSEC there as well.
Note that traffic needs to be unencrypted by the switches, by the routers, by every device in
between because they have to look at what? Security group tags. What else do they have to look at?
They have to look at trunking tags or any other tags that are in there. They have to look at QoS
markings and classification values. So this is going to give us secure communication channels
for traffic on a hop-by-hop basis at layer two of the OSI model. And just to show you here,
when you look at MACSEC, here's the header for MACSEC.
And so you'll see with the MACSEC header, we now end up encrypting everything from the 802.1q tag
all the way up to the end of our payload, including the security group tags.
And everything from here to here is authenticated. So we get both authentication, encryption,
integrity checking of everything from what? The 802.1q header right to the end of your data,
right to the end of your data because the payload here would be your packet as an example.
All right, so it's really important for you to remember that for the exam, what MACSEC is. Again,
you don't have to implement TRUSTSEC. You don't have to implement MACSEC. What do you have to
be able to do? Understand what they are, understand what they accomplish
based on how I've described them to you. So that way, they have to use terms like contextual
identity, enforcement, dynamically adjusting your security policies on the fly, right?
TRUSTSEC, right? MACSEC, layer two, hop-by-hop encryption
in our environment, not end-to-end encryption, hop-by-hop encryption.
All right, so make sure you know those for the exam. Again, expect two or three questions maybe,
being able to pick them out of a lineup, right? What feature does this or what feature does that?
That's what you're trying to do here.