Well, all these security services are great.
We have to think about this from the perspective that in our SD-WAN environment,
we've got, I mentioned earlier, those retail sites, the small locations.
Maybe we're not a retail shop. Maybe we're health care.
We've got small clinics or we've just got these regional or maybe even rural locations.
And what are we going to do when it comes to the edge hardware?
Well, we're going to make it as low end as possible.
We want to reduce the cost because we might have a lot of these.
But furthermore, we might only have something like, I don't know, 5 to 10 users at a site.
I mean, how much hardware costs do we need to incur?
So we lower the cost and we lower the performance.
And even though we as network engineers love to say, hey, let's overspec that thing and get it cranked up.
The reality is that this is actually a really good design philosophy.
We have to spend our money where we need it because money is not infinite.
Budgets aren't infinite.
And so we have to be very smart. And really, ultimately, that's supposed to be a checkmark there, not a V.
But we need to do something known as right sizing.
We have to right size the hardware.
So here's the problem with that.
We've gotten through this long conversation with all these security services,
and we want to put all of these security services onto all of these edges.
And so the large edges that serve as the hubs, these are great.
We can put these on here, no problem.
But when we try to put them on a lower end device, this is going to be a no-go.
We're not going to be able to place IPS and AMP and all of these services and agents all running on these lower end edge devices.
So what are we going to do about this?
Well, certainly one solution is to ramp up the hardware and the performance and say, well, we're not going to right size it anymore,
even though there's only 5 or 10 users.
And as you can imagine, that's not the right solution.
So what is the right solution?
Well, there's probably lots of decent solutions out there,
but certainly one that we'd want to consider is Cisco's Secure Internet Gateway,
which is often abbreviated as SIG or SIG.
So what is this Secure Internet Gateway?
Essentially, the Secure Internet Gateway is a cloud device.
We'll just call it a cloud router out there.
It's a gateway after all.
And this cloud router is running all of the security services.
If this cloud router is running all the security services,
now all of a sudden we can direct all of the traffic that needs to be analyzed to it,
and therefore we can offload our smaller edges.
This is a pretty decent compromise from a solutions perspective because now I can have this small edge.
So, again, it's got low performance, low memory or CPU or whatever it is.
I can't deploy all of these security services, but I still want to take advantage of them.
So now what happens is the user sends traffic, and we want to deploy some kind of security solution against that.
Maybe it's AMP, maybe it's IPS, whatever it is.
And so now instead of running it locally, we send it through the cloud,
or really through the Internet into the cloud, and we send it up here to the Secure Internet Gateway.
The Secure Internet Gateway is running all kinds of services.
It can run firewall services or IPS or DNS security and all kinds of things, et cetera, et cetera.
So it's got full documentation for all of the characteristics of the SIG.
And so we can send our traffic that way, and it gets redirected back to the router if need be
or sent on to the destination depending on the service.
And so this gives us sort of a best of both worlds perspective or at least some kind of compromise
because at a minimum, yeah, we might see that there's some additional latency involved here,
but the reality is that for the few users that exist out here, again, 5, 10, 15 users, it's probably fine.
These users are going to have to deal with a little bit more latency on some of their Internet applications,
but in the end, we care more about the security than we care about maybe a few milliseconds.
Now what's interesting about this is we need to deploy policy onto this edge
in order to take advantage of the Secure Internet Gateway.
So what we do is we create policy, and we use those match action statements.
We have to decide what traffic we're going to match and include as part of this framework,
Now keep in mind, we have to actually say action accept here as well, so don't forget that part.
But I can say basically just, hey, use the Secure Internet Gateway that we have configured,
and I can also use SIG action here, and what this is going to allow me to do is decide whether or not we're going to,
well, not decide whether we're going to, but it's going to create a fallback configuration.
So basically, what happens if all of the tunnels are down?
If the Secure Internet Gateways are down, what are we going to do?
Are we going to just allow that traffic, or are we going to drop that traffic now that we have no access to the set of security services
that we were hoping to rely on?
So we have to decide if that's going to be allowed or blocked.
Now worth mentioning, because I just kind of tossed that out there, that we are indeed running IPSec tunnels to the Secure Internet Gateway.
It's got to be secure. After all, it's right there in the name.
And so we're going to actually tell whether or not we've got tunnels enabled,
and that's going to tell us whether or not we have access to those services.
So if there's some issue with the service, our IPSec tunnel is going to go down,
and that's when we have to decide what to do about that fallback policy.
Now lastly, it's worth also talking about Cisco TrustSec.
And Cisco TrustSec here.
That's a... yeah, I guess that's probably fine.
It's a little bit dark, but we call it CTS.
Let me lighten up my blue a little.
So Cisco TrustSec is another security product that Cisco has,
and TrustSec basically provides an embedded security framework into the network,
and it's all about access control.
Who can talk to whom, to use proper English.
then Cisco TrustSec is going to allow us to block that communication.
Maybe those are hosts trying to communicate into the data center
or hosts communicating to other hosts at different locations, whatever that is.
And so we naturally would want SD-WAN to participate in this framework.
Now the way that CTS works is it relies on what's known as the SGT,
which stands for Scalable Group Tags.
And you are probably going to see documentation that refers to this as Security Group Tags.
So the S has changed over the course of time.
It used to be known as Security Group Tags.
Now it's Scalable Group Tags, but the acronym stayed the same.
It's still SGT.
And so generally speaking, the way this works is we've got our SD-WAN environment here with our tunnels,
but way over here at the access layer when traffic comes in,
we want to tag this traffic with the SGT.
This tag gets carried through the network,
whatever path it ends up taking before it lands on the SD-WAN device.
So first of all, we're going to want to enforce policy if it hasn't already been enforced.
But the other thing to consider is that we want to make sure that we're carrying the SGT inside of these IPSec tunnels.
And Cisco does allow us to configure that.
If we're configured for Scalable Group Tags, then those tags will actually be embedded inside of the IPSec header.
So that's step number one of our SD-WAN integration.
Step number two is that we can also configure SGT to IP bindings within Manager.
So our SD-WAN Manager allows us to manually configure certain IP addresses to use certain tags.
That's if we really need to do something manual, but hey, we at least have that capability.
Now one other thing to keep in mind in all of this is all of this policy and all of these tags,
these are all part of Cisco's Identity Services Engine, which is that other product that we alluded to earlier.
So Cisco TrustSec is more of a framework, but ICE is at the heart of this.
If I, as an admin, want to block this communication or want to create specific Scalable Group Tags, I do this on ICE.
So ICE is the one that's pushing policies down to the access switches,
and that allows them to tag their traffic, but it also allows them to enforce policy.
So number three is that we can actually run integration with ICE.
So if we want to, we can run SD-WAN integration with our Identity Services Engine,
and that's going to rely on what's known as the Scalable Group Tag Exchange Protocol, or SXP.
So from an architecture perspective, what we really need to understand is that SGTs are a part of the whole architecture around access control.
This is known as Cisco TrustSec.
We have ICE at the heart of Cisco TrustSec.
It largely exists outside of the SD-WAN environment, but certainly we want our SD-WAN environment to be able to carry those tags,
perform enforcement if needed, and otherwise allow us to configure specific tags to specific IP addresses.