It is time to review what we've been learning over the last several skills.
We're going to focus in on security, quality of service mechanisms, as well as quality of service configuration,
and then also the management administration of our manager and SD-WAN environment.
So let's go ahead and jump right in. As always, I'm going to ask the question.
I'm just going to kind of jump right into the answer.
So please hit the pause button and make sure you can answer each question individually
before we discuss it together. So question number one here.
And there are eight questions in this security quiz.
When deploying a firewall using service insertion, what command is used on the edge to advertise it?
So, yeah, it's a little bit of configuration, but we did discuss this.
And importantly, we're going to want to make sure we have a good understanding of service insertion.
This is where we have an edge and it's going to have a device hanging off of it in the user VPN space.
So something like VPN 10 or VPN 20. And this could be a firewall. It could be a load balancer.
That is a really bad firewall diagram. But either way, we're going to advertise out that we have a service.
And we're going to advertise out some information about that service, like the IP address and so on and so forth.
So importantly, there are two aspects to this. First of all, again, we need to advertise this service.
And second of all, our vSmart or our controller is going to receive this advertisement
and push it down to everyone as part of as part of a centralized policy.
And so this policy is going to have the match action statements where we match something.
And then we said an action. And as part of that action, we're going to accept and then set.
And so the the controller is going to have this set service firewall as part of our action and our accept within the world of policies.
So when we think about it from an edge perspective, this is really an OMP configuration.
We need to send out service routes. So we need to advertise the service to the controller again via OMP.
And so that is going to be the OMP configuration here, where B here, where we set a service within the OMP parameters.
That is going to be our answer. When we see the word set, that should imply for us that we're part of a match action statement.
And that will be part of a policy. But we don't use that as part of an OMP type of configuration.
Question two, when using the application aware firewall, what is the difference between pass and inspect rules?
Well, our application aware firewall, like all other firewalls, probably we are allowed to pass traffic and we're allowed to block traffic or deny traffic.
But right in the middle is this concept of inspect. What exactly does it mean?
Well, it's all about D here, allowing the return traffic to come back.
Because as we for those of us who have configured firewalls before, we know that there's a little bit of a conundrum here,
which is that I can allow traffic outbound. I can allow almost all traffic outbound.
But most of the traffic coming inbound, I want to block and deny this traffic.
And so if I'm allowing traffic out, the question is, how exactly do I allow the return traffic to come back in?
I can try to manually configure my own firewall rules and deny most of what's coming in,
but somehow still allow the traffic to come in that would qualify as valid return traffic.
Or I can just use something like inspect mode, which allows the firewall to say, OK, I'm inspecting this flow.
And so when I see the return traffic, I'm going to make sure it looks like real return traffic and didn't change the ports or anything.
But based on all of that, it's going to allow that traffic to come in without me having to manually create some very complicated firewall security configurations.
Next question, which two SD-WAN security integrations require the use of a UTD file?
Well, let's first of all, it helps us to remember what the answer is if we think about what a UTD file is.
UTD stands for Unified Threat Defense, and UTD files are going to include signatures.
It's a lot of signatures that we're going to use for inspecting certain traffic types,
and so we don't just want to automatically put it on all of our edge devices.
We really want to load the signatures via the UTD file if we're going to run a couple of these security integrations.
So the question is, which of these integrations requires the use of signatures?
Remember what signatures are.
We're really looking at patterns and behavior within packet flow and within packets themselves that would make it so that this is a little bit suspicious.
Maybe this is something nefarious, maybe it's something that's not,
but we're going to have to rate how nefarious or really how suspicious we are of a packet and decide what to do with it from there.
Well, the two services that require signatures are going to be my IPS and IDS, so B here, as well as AMP, which is D.
AMP would be our Advanced Malware Protection Package from Cisco, and it's going to be looking at files,
and so we're looking at signatures within files as the files are being downloaded and as the files are being used on a machine.
Whereas IPS and IDS, we're looking strictly at traffic flows and trying to identify, is somebody launching an attack?
It's not to have anything to do with downloading files.
It has to do with where the traffic is going and what types of ports are being used and those kinds of things.
So these are the two services that require the use of that UTD file.
Question number four, a network tech finds that URL filtering, which Cisco and really Viptela like to abbreviate as URLF,
is configured with the same URL on the whitelist and blacklist.
So what happens when a user attempts to navigate to that URL?
So it's an interesting situation here.
I don't know why we'd have the same URL on the whitelist and the blacklist,
but really what we're asking here is what is the order that we're using to check these different lists?
And the reality is that we check the whitelist before we check the blacklist,
meaning that anything configured on the whitelist is going to override anything that conflicts with it on the blacklist.
So flat out, access is going to be allowed.
If that URL is truly on both lists, we are going to default to the whitelist allowing it.
We might assume that for security purposes, we block it first,
but the whitelist usually is meant to be a few things that we're explicitly allowing in.
The blacklist is supposed to cover a lot.
And so we do kind of have to evaluate it in this order.
And that's why if there is an override in place, Cisco assumes that that override is there for a reason.
All right, question number five, we're halfway there.
Which security product is able to decrypt traffic in order to inspect it?
So recall the problem here.
The problem is that we could deploy great security mechanisms, SD-WAN, everything.
And so if a threat actor over here has some bad files and the threat actor tricks a user to click on a link,
that user will go out, grab whatever file this is, and it'll download the malware.
And so we say, OK, cool, we're going to do what we just talked about.
We're going to deploy IPS in here, and we're going to deploy AMP in here,
and we're going to detect that this file is bad news.
Except the threat actors got smart about this kind of thing,
and so they decided that rather than just having a server out here like an HTTP server, there we go,
rather than just an HTTP server, we are going to use HTTPS or use some other secure mechanism,
which means now this file is encrypted.
So this is the problem that we as network admins are trying to solve,
because AMP and IPS, as great as they are, they're not going to be able to do nearly as much
when the traffic is actually encrypted.
So what do we do?
We deploy the SSL and TLS proxy.
And what we effectively do is we make it so the user makes an encrypted tunnel here to the edge device.
And then on the other side of things, assuming there is another router in here involved,
but maybe it's just this one here.
So either way, I'll just draw it like this, where we've got our threat actor.
Now he's crying a little bit, I think.
He's not as happy, because we're encrypting it in both ways,
but we are able to decrypt so here it's unencrypted on the edge itself,
which means I can run my IPS processes.
I can run my AMP processes.
And if I see something suspicious, now the traffic is unencrypted.
So as we joked about in the skill, this is taking a little bit of a page out of the threat actor's playbook,
where we're performing a man-in-the-middle attack.
But, of course, if we as network admins are doing this, then it's okay.
We're okay with running man-in-the-middle attacks,
because in this case we're going to protect our users from this type of scenario.
So SSL and TLS proxy, that is a very important part of an overall security framework
when we're deploying SD-WAN security.
Question number six, how does Umbrella protect our users?
So that's a very basic question.
If we know what Umbrella is, we should be able to answer this.
If we kind of forget, then, yeah, this is going to be a little bit of a challenge.
Remember, Umbrella came to Cisco when they purchased OpenDNS.
OpenDNS is still a product for residential use, like you and me could download it.
But for the enterprise side, Cisco turned that into Umbrella.
And it's very sophisticated DNS security.
So, again, back to the situation we just had, where our threat actor sent a URL,
probably via some kind of phishing link, to this user.
The user clicked the URL.
Well, remember that that's not an IP address.
The user can't go straight there.
Instead, the user has to go to a DNS server, and the DNS server has to say,
oh, you want to go to this URL?
Cool, buddy, here's the IP address for getting to the bad guy's site.
And the DNS, standard DNS server, wouldn't know that this is a bad guy's site.
But what if, instead of this, we had Umbrella running as part of our process?
Now, Umbrella ties into Cisco's security framework, that Talos cloud that we talked about.
It knows about bad guy websites.
It passes the, well, really the URL, but the DNS request to the security cloud.
It gets a response back.
It says, no go, don't go there, that's bad news.
And so we redirect the user to some kind of proxy page, something that says,
hey, you're not allowed to go to this website, it's bad news, don't go there.
And so before we even get to the whole coming out and downloading files
and having to decrypt it and having to run AMP to scan files and all of these things,
before we even get to that point, if we can just block this connection from happening,
that would be wonderful.
So when we're looking at the choices here, C would be our answer,
it blocks DNS resolution to bad sites.
This is such a great part of a layered security approach,
because it makes it so that hopefully we never even are able to go out to these bad URLs.
And if we are, this is why security exists in layers,
if we are able to go out to that URL and we start downloading a file,
now we have IPS running, we have AMP running,
we can unencrypt the traffic as it flows back and forth,
and hopefully one of these processes will catch the fact
that our users are trying to download something malicious.
Question seven, how does Secure Internet Gateway assist with network planning?
Well, we didn't really talk a whole lot about network planning or network design in this course,
so why are we asking about it?
Well, because Secure Internet Gateway is all about B here,
offloading our edge security processing.
And it's important for us to understand how this fits into the architecture.
And the idea here is that everything we've talked about, IPS and AMP and SSL and TLS proxy
and all of these things, Umbrella even, these require processing power on a router.
And so if I'm deploying an edge with maybe, let's say, like 10 users,
I might say, cool, I'm just going to deploy this little router to that site
and it will be my SD-WAN edge.
Except I want to run all these security mechanisms,
and so I'm going to need a much beefier router, even though it only has 10 users.
especially if I have to deploy that to dozens or hundreds or even potentially thousands of sites.
So what do I do instead?
I deploy the SIG here, and it's going to, as it receives traffic,
it will send it out a tunneled connection to the SIG.
So the Secure Internet Gateway is out here and it's able to bring traffic in
and make security reports based on these services.
And that way, our little router out here doesn't have to do it
and it saves us a whole lot of money as far as network design is concerned
because I don't have to deploy super beefy routers at every single location.
All right, last question.
Which Cisco product is required when integrating Cisco Tresec with SD-WAN?
Well, Cisco is very proud of their portfolio for this exact reason.
as we've talked about many times.
And now when it was just Viptela, it was just sort of its own SD-WAN thing.
But now we can integrate it with other security products from Cisco, such as ICE.
And so A here is the answer.
Our Identity Services Engine is instrumental to deploying Cisco Tresec,
where Cisco Tresec more or less hardens our entire network as far as access control is concerned.
So this is a network access control or NAC concept.
The idea here is we'll use those SGTs, the Scalable Group Tags or Security Group Tags.
We tag it on ingress to the network.
This tells us where that traffic came from, what user group it's part of.
And then as it goes through the network, at some point we can say,
hey, you're not allowed to access that resource and we can block it.
Ideally, we block it way over here, but, you know,
sometimes maybe it goes a little further than we would have liked.
So that is how Cisco Tresec works.
And at the heart of that is ICE because ICE is the one that pretty much determines for us
who can access which resources and allows us to deploy the SGTs.
So that is an overview of the Cisco products in the security world
and how they integrate in with SD-WAN.
Let's go ahead and change things up now and start talking about quality of service.