As we continue our security conversations,
what we find is that our SD-WAN infrastructure
is kind of right in the middle of everything,
which is why, number one,
we want to make sure that the SD-WAN is secure,
but the SD-WAN is kind of already secure.
I mean, we're running IPSec protocols
and control plane information and TLS and DTLS tunnels.
I mean, we are very secure,
even if the underlying network, the underlay,
is the public internet.
Even at that point, it's considered secure.
So what we're going to find
is that we can not only keep our WAN traffic secure,
but we can also look at this from the perspective
that if we've got these edge routers,
again, kind of right in the middle of the network,
facilitating communications among places
like our headquarters location
and maybe a secondary site,
maybe some major location
that's in a different part of the world,
and then we've got our potentially smaller sites
like retail sites that are out here as well,
that we've got all of these different types of locations,
and again, what's right in the middle is the SD-WAN.
So it's not just about keeping the traffic secure.
It's also about what kind of value can the SD-WAN bring.
And yes, we can provide a lot of value
to the security of our overall network,
even so far as to say
that if we wanted to keep the internet
which we talked earlier in the course
about the concept of on-ramp,
on-ramp for SaaS, on-ramp for IaaS.
I mean, there's really good reasons
to keep the SD-WAN kind of plugged into the internet.
Well, at this point, we could even secure connectivity
that's going out to the internet.
So maybe we're trying to go out to these good sites,
and that's a good thing for our users to go out to,
but maybe we're also trying to go out to these bad websites,
something a little more suspicious,
whether that's just content
we don't want to allow our users to access
or potentially even blocking phishing websites.
If we're aware that a particular website is usually used,
not usually, but like if we have identified
that that's used as part of phishing scams,
then we definitely don't want to allow our users
to go out there.
And so it's this concept right here,
the fact that the SD-WAN being in the middle of things,
that we can provide all this extra value
by securing our communications,
even independent of the WAN itself.
we can maybe even help cost justify an SD-WAN solution.
On top of that, it just helps us overall
manage the security of our network,
which is one of Cisco's goals with this solution.
So as we dive into this,
what we want to talk about here in this video
is a solution known as URL filtering.
And every video after this in this skill,
we're going to find that we've got another security product
or another security feature
in some way solving the problems that we have
using one of these additional security functions.
So let's start with URL filtering.
As the name implies,
we want to block access to bad websites.
So we try to go out to a bad website.
We being a user, again,
somebody over here who's on their computer
or their mobile device, something along those lines,
they're trying to go out to, again, a bad website.
Now, on the surface,
this seems like a pretty straightforward conversation.
We don't want to go to bad websites.
But what are we talking about here?
I mean, are websites objectively good or objectively bad?
And the reality is that there is no such thing as good versus bad
when it comes to the websites.
What we do have, however, is a range
and what we might refer to as a reputation.
And so Cisco is going to rely on a reputation score here
that ranges from 0 to 100,
with 0 being that sort of objectively bad website
and 100 being an objectively good website
or at least as objective as it gets,
meaning that we don't necessarily know what...
or we really arguably never know
what a website is really doing with our information.
But if we find out that a website
is maybe not doing what we think it's doing,
well, then that reputation is going to go down.
And so this is managed by a centralized database.
So what we need to understand about this
is that there's a range of scores to pay attention to.
At the very low end here, we'll start down here,
we're going to have high-risk websites,
which are ranging from 0 to 20
as far as the reputation score is concerned.
We also have a category known as suspicious websites,
and that would be 21 to 40.
Then we have moderate-risk websites,
and as we can kind of notice the pattern here,
it's going to be every 20.
So 41 to 60 would be moderate risk.
Then we have low-risk websites.
Now we're starting to get to websites
that we might find to be more trustworthy,
so 61 to 80.
And then we have the considered trustworthy websites.
This is probably as good as it gets,
and it's going to fit into that 81 to 100 range.
So again, we can't necessarily say that a website is bad,
I don't know, something like a 75,
so the user tries to go out on their laptop,
try to go out to a website,
and the edge is going to take a look at the fact
that we're trying to go to a particular URL.
And so it checks the URL in the database,
and it finds again that it's got that 75 score,
and so it's considered a low-risk site,
but it's not considered trustworthy.
We might want to evaluate
whether or not we're going to allow those types of websites
as part of our URL filtering process.
So we get to decide that.
We get to determine whether this is high enough for us
to say, yeah, you're allowed,
or if it's too low, at which point we would reject it,
and every organization gets to set the policy themselves.
We essentially set a level,
and we're allowed to go to anything more trustworthy
than that level.
Now, on top of this, we do have access
to the ability to use whitelists,
and we have actually a process here that we want to follow.
So that process starts with the whitelist,
meaning that I can configure a list of sites
that are always allowed.
It's the allowed list.
And then we can have a blacklist.
We might say, yeah, that one website has a URL score of 65.
That technically qualifies as low-risk,
and we would normally allow that,
but we want to blacklist that,
and we don't want to blacklist specific websites
that we've just heard about or whatever the situation is.
It doesn't matter.
We have total control as network admins here,
and so we can deny access to websites on the blacklist.
And so lastly, we can go to category and reputation scores.
Now, a couple of things here.
First of all, notice the order of operations here.
There is a specific order here,
so if we have the exact same URL in the whitelist and the blacklist,
what's going to happen?
Well, we process the whitelist, we see it's allowed, and we're done.
And so if we have a URL in both of these lists,
I don't know why we would,
but the website would be allowed access to
because it's on the whitelist, and that's what's checked first.
So whitelist, then blacklist, in that order.
Second of all, we just covered the reputation.
This is going to be that 0 to 100 number,
that we want to allow versus not allow.
And like we mentioned, we can also do category-based filtering,
and so we can block specific types of websites
or really categories of websites,
and we have full control over that as well.
For example, we might want to block violent websites
or something along those lines.
That would be a category or a type.
That doesn't matter what its reputation is.
It doesn't matter or anything like that.
We would just want to block it.
But again, keep in mind, if something is on the whitelist,
it's allowed even if it would have gotten denied by the blacklist
or the reputation or the category.
So the whitelist does kind of rule over all of that,
and if something is on there, it will always be allowed.
So as mentioned, there is a database that's out there
that's going to provide all this information.
It's known as the URL database,
and this is going to be downloaded from manager to the edge.
and they're the ones who are going to be enforcing the policy.
Furthermore, it is worth noting that only certain edges
are going to support this.
So there will be most, really most of the portfolio
is going to support URL filtering,
but it is worth noting that ASR 1Ks will not actually support this method,
and neither will the Catalyst 8200s.
So we don't spend a lot of time in this course
talking about actual hardware
because this kind of changes over the course of time.
But it is worth noting this as part of our conversation that,
yeah, you might find that your own SD-WAN environment
consists of these platforms, or at a minimum,
maybe you're looking into deploying an SD-WAN solution,
and you're considering Catalyst 8200s,
which are a lower-end version of the 8300s,
which is what Cisco would really like us to be deploying.
And so there are some features that are going to be excluded
by deploying some of that cheaper hardware,
and ASR 1Ks at this point, they're just a lot older,
and they lack the hardware requirements in order to deploy these.
So even if they're supported from an SD-WAN perspective,
they can't deploy certain security solutions like the URL filtering.