Alright, on to the fun topic of security.
And as we've said before, security is completely baked into the SD-WAN solution
from the ground
up.
It's not created as an afterthought, Cisco, and the original Vatella team have
taken this
very, very seriously.
Remember, we don't want to allow threat actors to access our SD-WAN, and they
're trying to.
If they can get onto our SD-WAN environment, they can do a whole lot of damage.
And this can take two different forms.
First of all, I guess we'll write access here, and we're trying to get access
to the
SD-WAN.
So first of all, we could have a rogue edge device that's managed by one of
these threat
actors, and it's trying to join our SD-WAN environment.
Imagine that.
Imagine if a rogue router actually was able to connect into our SD-WAN, and our
other
routers form tunnels to it, and start forwarding traffic, that rogue device
will be able to
do a whole lot of damage.
So we want to prevent that.
The second thing we have to prevent is the idea of an actual legitimate edge
device.
So this is an organizational edge, and it accidentally, not accidentally,
thanks to the
threat actor, it joins a threat actor's router or network, rather.
And so whatever information is on here and the users who are behind it, once it
forms
IPsec tunnels out to the threat actor, it starts forwarding traffic, they're
going to
be able to figure out what we're sending and analyze our traffic.
So yeah, we want to prevent them from joining a validator and a controller and
a manager
that are part of a rogue SD-WAN environment.
So we're going to put two layers of security into our model.
The first layer is going to be certificates, which are going to serve
certificates, which
are going to serve to authenticate our devices.
And the second layer of security is going to be our device lists.
Our device lists are going to allow for edges and for controllers, so our
control devices
are going to be entered into a whitelist model, meaning they're not allowed to
join just because
they're an edge.
They're not allowed to join just because they're a controller or a validator or
a manager.
And so this whitelist model is going to not only prevent threat actors from
maybe getting
access to an environment, but also it's going to make it so that we can better
control which
devices are onboarding at a time.
Maybe we've got a site that's going to come on next week.
I don't want it joining until next week, so I wouldn't add that device and that
site
to the whitelist until it's ready to go.
Now certificates, this can be a very big pain point when trying to especially
lab up an
SD-WAN environment, but even just getting an SD-WAN environment onboarded and
ready to
go, it's going to take some amount of knowledge typically around certificates
and moving them
around and getting them signed.
So let's just sort of walk through what this process looks like for us to use
certificates
in an SD-WAN environment.
So the ultimate goal of using these certificates is whether it's an edge device
or a controller
or a validator, either way, we are going to use the manager device and make
sure that
we get signed certificates onto all of these devices.
And so yes, that does include the manager and we'll see later on how exactly
this all
comes together, but the goal, this is the goal.
To get signed certificates onto these devices now signed by whom?
Well, a certificate gets signed by what's known as a certificate authority,
which is
abbreviated as a CA.
The CA in this case can be a number of different entities.
We could, for example, provide an organizational certificate authority.
This could be a scaled up organizational configuration that we have in place,
or it could be a small
Linux virtual machine that we spin up to serve as a certificate authority.
So that is certainly something that we could use.
However, we can also leverage Cisco smart accounts.
This is a feature that they have on their website.
And the advantage to this is that Cisco, as long as we're buying legit
authentic Cisco
devices, Cisco knows our hardware.
So Cisco already knows our serial numbers and they can greatly help us to get
our certificates
online and deployed.
So it's a little bit trickier if we're going to do it ourselves, but it is
absolutely doable.
So let's go and walk through the process of what this looks like.
The way this works is we're going to get onto our certificate authority and
this provides
a root certificate.
The root certificate is going to be used to produce other certificates.
That's why we call it a root certificate.
And so we're going to be able to share this root certificate with other devices
.
So we're going to take this root certificate and we're going to deploy it to
our controller
and our validator and our manager.
When I say deploy it, I mean that we're going to probably use some, ideally, a
secure form
of communication like SCP or maybe SFTP, but we want to transfer this
certificate onto
the different devices.
And yeah, we're going to focus on our controllers.
And right now we'll talk about edges later on in the course.
So we're going to transfer those root certificates on there.
And then we're going to install them.
So there is a set of commands that we can use in order to do this.
And this is basically telling the devices that yes, this is a trustworthy
certificate.
So because we as the admins have manually intervened, the device can know that
this is
indeed a trusty certificate or a trust worthy certificate.
And so we can use this to again drive towards the ultimate goal over here,
which is to get
signed certificates, which by the way, we don't actually have that yet.
So what are we going to do from here?
Well, once the controllers have installed the certificate, we are then going to
produce
what's known as a CSR or a certificate signing request.
This itself is a file.
And so we're going to have one of these for each one of our devices that we're
bringing
online.
And we're actually going to transfer these back to the certificate authority.
Kind of interesting.
So the certificate signing request, as the name implies, is us telling the
certificate
or the certificate authority, the CA, that we need a signed certificate.
Now what we're doing here is we're leveraging the root certificate as well as
local keys
in order to do this.
And it's going to have other information baked in, for example, our
organization name
and our organizational unit concept and all of these security foundational
principles
that we're using in order to try to get a signed certificate.
So I'm providing this information to the CA and the CA then provides the signed
certificate.
So it's going to have one for each one of these devices.
So signed certificate, signed certificate, signed certificate.
And lastly, I can deploy these back to the devices.
So it's a little bit of a circular process and we'll certainly take a look at
this later
on, but just be aware of what this looks like in order to get our certificates
online.
Now something to keep in mind is that later on, we're going to be using Cisco
modeling
labs as our lab environment of choice for SD-WAN.
CML has SD-WAN devices baked in, meaning I can just spin up SD-WAN validators
and controllers
and managers.
I can log into it.
And again, we're going to walk through that later.
But where do these certificates all come from for a lab environment like Cisco
modeling
labs?
Well, we can still use all over here Cisco smart accounts in order to do this.
So we'll walk through it later and see exactly how that works.
Now lastly, let's not forget that we've got device lists here.
So when we're talking about device lists, we're talking about whitelist
modeling, meaning
we're only going to allow devices onto our network that we explicitly allow and
that
we explicitly want on there.
And so this is going to take the form of two different lists.
First of all, we're going to have a controller list.
And this controller list is going to be formed manually.
So it's going to be a manual list that's configured on manager.
We can do a lot of configuration in manager.
Once we have access to manager, we can log in and do certificate management.
We can also inform it of the IP addresses of the other controllers so it can
reach out
across that VPN zero and communicate with them.
So this is a manual process and we will see that process in action as we add
controllers
to our SD-WAN environment.
The other device list is going to be an edge list.
And this edge list is going to be created a little bit differently.
It's going to be an automated process that once again is coming from, you
guessed it,
Cisco Smart Accounts.
Seems like that's going to come up a lot whether we wanted to or not.
So we're going to go out to Cisco Smart Accounts and we're going to enter in
the serial numbers
that they already know about because they have all of our information, a TIDOR
organization.
And so that's going to allow us to produce a list that we are then going to
upload onto
our SD-WAN environment.
So the nice thing about the whitelist model is that if, for example, we've got
this device
and it's got the signed certificate on this and then a threat actor compromises
this,
grabs the router and takes it home with them.
Well at that point in theory, the SD-WAN router would actually be able to form
IPsec
tunnels because it has the certificates and it's all authenticated.
Well we as the admins can go to our edge list and we can exclude that device
and so that
provides an extra layer of security and that's just an example of why it's
important to have
multiple layers of security.
So between certificates and our device lists, we're going to be able to lock
down our SD-WAN
environment making sure that only authentic devices can connect and also make
sure that
only authentic devices that we want to connect can actually connect.