Well, our SD-WAN infrastructure can also operate as a different type of security appliance, not just a firewall,
but also as an intrusion prevention system or an IPS.
This system is going to be based on Snort.
Snort is an open source IDS and IPS.
It's been around since the late 90s, and this was actually acquired by Cisco when they acquired SourceFire,
system, and yes, they did keep it open source.
And so other companies still continue to run Snort,
but naturally Cisco also has really good access to the code, and so they incorporate it into SD-WAN.
That actually kind of implies, and I'll just be very clear here, that Viptela didn't actually do this.
This is something that Cisco layered on top of SD-WAN after they purchased the solution from Viptela.
So it's kind of cool to see Cisco
incorporating some technology that they have access to into this system to improve it and make it better.
So what is an IDS and an IPS for that matter? How exactly does it work?
Well, the way it works is this. We have some device that's looking at traffic. So traffic arrives,
it's going to look at the traffic,
analyze it, and
either mark it safe for transport or say, no, this isn't allowed.
So we're either going to accept it or
we're going to mark it as maybe bad. So it's either good or bad traffic.
And then the question is, what do we do with it? Do we send it on or do we end up dropping it?
Now an IDS can certainly say that, hey, this is bad traffic, but it's an intrusion
detection system, not a prevention system. So even though it's bad, in fact, whether it's good or bad,
it's going to send the traffic on.
Just kind of interesting. But at least it flags reports and lets us know that, hey, we're seeing something out here,
we might want to take a look. But it does require manual intervention.
Meanwhile, an IPS, the intrusion prevention system, will look at it and say, hey, if it's good,
then we'll send it out. If it's deemed bad, then we're going to drop it.
And so that's the difference between an IDS and an IPS. And yes, the SD-WAN environment can technically operate as either one,
but usually we're talking about configuring it in the IPS role.
So next question, when it's evaluating this traffic, how does it know whether it's good or bad?
Well, it's going to be paying attention to something we call signatures.
This is a very common technique that's used in the world of antiviruses. It's used in the world of
IDS and IPS. It's used in firewalling. The idea here is to look at sequences
and
to look at specific patterns.
that traffic could be malicious because we can't look at every single packet at every single byte and know exactly whether this is malicious or
not. But we do know that certain attacks
have
different patterns, or specific patterns, and they have specific sequences. If I see certain attacks,
you know, certain packets go back and forth and back and forth in the same way that specific attacks do, then it might be worth
paying attention to that and taking a look. And so the reality is that we never know
for sure that a packet is good or bad. We have to go on a level of suspicion.
We have to say, yeah, we're pretty sure that this is a,
you know, maybe a problem, some kind of an attack, or maybe it's not. But again,
we've got to decide whether to block it at that point.
So how do we decide what to do with it?
Well, this is going to come down to us understanding a couple of things. First of all,
we have to look at the Common Vulnerability Scoring System, or the CVSS.
When we're looking at these signatures, we have specific attacks
that are going to
bring in, for a signature, a different CVSS, or
specifically a score.
And that score can be between 0 and 10. And there's actually decimals involved here.
So, you know, I will say 10.0 here. It could be a 9.5. It could be a 1.5, or something along those lines.
Based on the severity of a signature, where 10 is something that's severe,
so something considered very dangerous, where a 0 is probably not. It would be light, or
we'd even say safe if it's a 0. But either way, the closer to 0 it is, the lighter
risk there is of us allowing this traffic.
So then we have to ask again, based on our suspicion, and based on the CVSS score,
what are we going to do about this? And that comes down to our
configuration. Because we're going to find that we actually have
three different levels that we can configure
as part of this. So we've got the balanced option, which is the default.
And as the name implies, it's trying to strike a balance here.
Because what we usually find on a security scale is that we have the utmost security at one end of
the scale, and then the utmost in usefulness on the other side. And the scale tends to look like
this. If I want to err on the side of security, I can maybe place my marker somewhere at this point.
So what am I saying? I'm saying that I'm more likely to drop packets here than to drop packets
here, because I'm erring on the side of security. The problem is I might drop packets that I
suspected were bad, but weren't actually bad. Meaning that all of a sudden, the usability of
this network has gone down a little bit. Because people are going to try to do things they'd
normally do, and the network is going to stop them. It's going to be cumbersome. We're going
to have support tickets provided. We're going to have to run traffic analysis. It can be,
again, very cumbersome. So I could err on the side of usefulness, and say, you know what,
err on the side of allowing traffic. So basically, are we erring on the side of denying traffic,
or are we erring on the side of allowing traffic? And so at that point, we favor usability,
but we recognize we might actually allow traffic that is bad. A host is under attack, and we
picked up on the signature, but because it's maybe not that risky of an attack, we've decided
to allow that traffic, just in case it's actually good traffic. So when we look at our three levels
here, we are saying that balanced is going to be right here in the middle, where we're just going
to try to not make things too secure, but also not make things too usable. We really want to
do our best to balance out between the two. So how exactly do we define that? Well, we define it
this way. We're going to base it on specifically the amount of time that we have had signatures
around. We're going to look at the last three years worth of signatures. So I'm not worried
about signatures that were defined five years ago, because those attacks probably don't really
happen anymore. Furthermore, I'm also going to base it on a CVSS score, and so we're
going to say that if it's greater than or equal to nine, then we definitely want to not allow that
traffic. But even if it's an eight or an 8.5, we're going to say, you know what, we're going to
allow it, because we do need to strike a balance here. So as you can imagine, there's a couple other
options here. Specifically, we're going to have connectivity, which as the name implies, we're
going to err on the side of allowing for connectivity. That would be allowing us to
more easily use the network. And so now we're saying that we're only going to look at the last
two years, including the current year. So from a time perspective, it's going to be the last two
years of defined signatures, and a CVSS score is going to have to be 10 in order for us to block
this traffic. So it has to be a very severe risk in order for us to drop traffic. Lastly, we also have
the ability to go to the other side. So what's this side? We're erring on the side of security.
Well, the name itself is security. And so at this point, we're going to be looking again at the last
three years. So this actually is the same thing. So time-wise is the last three years.
But this time we're saying a CVSS score that's greater than or equal to eight. So it's basically
the same thing as balanced, but I'm no longer allowing traffic through that has an 8.5 or an 8
or anything like that. So we have to decide what makes the most sense for our organization. We might
look at this and say, well, I want to crank it all the way to security. And that would be
potentially the right answer. But if we have users constantly calling in and help desk
tickets constantly being opened, because our SD-WAN edges are constantly dropping traffic here
as it analyzes the traffic coming through, well, then maybe that wasn't the right call.
Furthermore, connectivity should be something that we only use if we're really desperate.
Maybe we just keep having problems. Even at balanced level, we keep having problems.
And so maybe we need to swing it over to connectivity until we get our signatures better
defined. So that leads us to a final question, which is how exactly do we define these signatures?
I mean, are these baked into our SD-WAN edges? And the answer is ultimately no, they are not
automatically baked in. Our edges are going to need to be provided with something we call a
Unified Threat Defense or UTD file. And this UTD file is going to contain the signatures that it
will use as part of this process. This file comes from Cisco. So I get onto the Cisco website and
I'm able to obtain the UTD file. And then I have to deploy this onto our edges. The way I do this,
by the way, is actually, I'll scratch this off. If I am the admin, I'm going to obtain the file.
I'm going to load it into manager. And then manager is actually going to directly push it
down to the edges. So if we have 10,000 edges, don't fret about this. We don't have to download
it to 10,000 different edges. I just have to update it once on manager and then it will push
it down. I'm also going to need to update this regularly over the course of time. But it's the
signatures that allow our edges to act as an IDS and an IPS. And again, we have to define here,
importantly, these three different levels. We have to choose one of them as far as how strict do we
want to be about these signatures and how strict we're going to be about dropping traffic.