Here's a formula for you to remember.
S equals P plus D plus R.
What does that mean? Security is about prevention,
detection and response.
Remember the CIA triad I mentioned in the second video of this series?
It's about confidentiality, integrity and availability.
And I said everything we do in security is about trying to achieve one or more of those things.
Well, that's kind of the
“what” of cybersecurity.
This is what we're trying to do.
This equation is the “how”.
This is how we're going to go about doing that.
And that is with prevention, detection and response.
Now, what we've covered as we've gone through the domains up to this point:
Identity and access management.
Endpoint security, network security, application security and data security.
This is all largely been about prevention. Not 100%,
but mostly with the controls that we put in place down here are about trying
to prevent a data attack, a breach, any of those kinds of things.
So that's what that's about.
Now we're going to start looking at the other parts of the equation.
Today in particular, we're going to focus on the D part of this-- this detection aspect.
And then in the next video, we'll cover response.
Now, how do we do detection?
Well, it basically means I need to get information from all of these different domains
that I've been discussing previously and feed them into some sort of monitoring engine.
So that's what we're going to be taking a look at. Monitoring.
Then we're going to analyze.
Then we're going to report.
And then we're going to do this thing called threat hunting.
This is what the purview of this area is.
And then in that final video, we'll take a look at the response.
What do I do with all of this information once I realize that I've got a problem?
Now, these two functions are largely done
by an organization called the SOC, the Security Operations Center.
So bear in mind, this is kind of all
coming together in that one organization that's going to do that particular work.
And what are the technologies that they're used to do, this kind of detection, to do this kind of work?
Well, it's basically two predominant things.
It's a security information and event management system
or an XDR, an extended detection and response system.
We're going to take a look at both of those as we go through this video.
Okay. Now, we've introduced this idea of detection.
Let's go into it a little bit deeper.
And specifically, we're going to start off talking about this thing.
The security information and event management system or SIEM.
Some people pronounce it “seam”, you can choose to pronounce it
however you like. So I'll call it a SIEM.
What is a SIEM do? What's its purpose?
Well, it's if you think of this way, we look at all the different domains that we've talked about in the past.
Each one of these could be a source of security information.
And in fact, what typically happens this is not best practice-- it’s typical practice --is I have a console
some sort of security management system that is unique to that particular domain.
The identity management security console, the access management
security console, the endpoint management console and so on and so forth.
In fact, I've got multiples of those consoles and really multiples of the individuals,
the security operators, analysts that have to deal
with those particular domains and have that specific domain knowledge.
You can see this is very expensive.
And also, what else is missing here?
I don't have any consistent single view of what's happening.
So the left hand doesn't know what the right hand is doing.
And if an attacker comes in and hits one of these systems,
it may generate alarms in lots of these systems.
And then we've got a lot of people chasing all the same problem.
It's not very efficient.
So this is why the SIEM came into existence.
Its purpose then was to say, instead of operating all of these things independently,
let's come along with a layer on top of them
where we take all of these information systems,
feed it into a higher level system.
That's our SIEM.
So we create a database up here that is about this collection stuff.
We're going to collect logs, we're going to collect alarms and events
that occur, and we're going to collect flow data that goes across the network.
So each one of these systems would be able to give us different types of information.
We take all of that and we bring that up to the SIEM--
big database, and then we start applying some analytics to it.
One of the things we're going to do is correlate because as I mentioned, a single attack
might generate an alarm in multiples of these domains and across multiples of these systems.
So what I'd like to be able to do is not see this as four different events or four different alarms.
I want to see this as a single.
So one of the first things the SIEM will do after it's collected is correlate
all that information and get it down to a smaller, more manageable subset.
Another thing we're going to do then is start analyzing the information we have.
We're going to take a look at, for instance, rules that are based upon our security policies.
I might say if a certain condition, such as traffic coming from a particular geo
and then it meets some other criteria,
like someone tries to log in too many times or something like that
and some other criteria. So we can start building these very complex rules.
And a good SIEM will have a lot of these that already come out of the box.
But I can also customize them and build all these rules.
Then if all of those things happen, I want to take a specific action.
I want to generate an alarm.
I want it to be of a certain priority.
I want it to be assigned to a particular person.
And so ultimately, what I'm going to do with those priorities
is I'm going to assign them as well as high, medium and low.
The SIEM system ought to be able to do that.
And I could do that from a rule or I could have the system do that
automatically based upon its confidence level,
based upon calculations that it's done and things of that sort.
Another thing in the analysis I want to do is look for anomalies.
So these are things where I know I'm looking for a specific use
case, a specific set of examples, a specific set of indicators of compromise.
And when I see those, then I know I've got a problem, or at least I know
I have a high probability there's a problem and someone should investigate.
In this case, I may be looking to say, just tell me if something looks weird.
I don't know what weird is. You figure it out.
And so this is where things like artificial intelligence, in particular machine
learning is particularly good because it can find patterns that we might not otherwise find. Feed it
tons of this kind of information, and then tell it to look for what's the anomaly.
And a particular technology we do we use to do this is called user behavior analytics.
So UBA might leverage these underlying technologies
as a way to find what's the thing that doesn't belong.
Why is this user doing something different than all of his peers?
Or why is certain things happening at certain times when we don't expect them to happen?
So that's looking for the anomalies.
Here we say, this is what I'm looking for; here
I say, tell me for something that I don't really know what I'm looking for.
And then ultimately I look for trends. I want to see
because I want to generate reports to management to say, because remember, this whole organization
I mentioned in the previous portion is the SOC, the security operations center.
And the SOC wants to know, are we doing better this month than we were last month?
Are we detecting more alarms? Are we not?
Are we resolving those more quickly?
And so the reporting of all of this, it would be important to know, These are some of the major functions then of a SIEM.
It's about trying to reduce the footprint that we have down here
and give us a single point where I can look and see the visibility of all of my systems,
gather all of that information, bring it up and do these kinds of analysis activities.
Okay, we've just covered the SIEM.
Now let's take a look at the other technology I mentioned, XDR.
This is extended detection and response.
Let's do a little compare and contrast of these two different technologies so we can see how they fit together.
Is it really SIEM versus XDR or not?
We'll see.
So, first of all, SIEMs, these again came into existence--
Largely, the vendors that did these came from one of two different camps.
They were either log management vendors and they would the idea
was they take the system logs from all the different
devices, operating systems, databases, applications,
and manage all of those things and bring them up to some centralized database.
And then we do the analysis I mentioned previously.
Or they were focused on the network side of things.
So it's network behavior, anomaly detection, this kind of technology.
Most of the SIEM vendors came either from the log management or the network management view of security,
and the SIEM was designed to basically be able to reach across both of those.
Well, the SIEMs could always do more than that, but that was where they traditionally came from.
How about this newer technology called XDR, extended detection response?
It grew out of a thing called endpoint detection and response.
So we already talked about how we did detection and response here in the SIEM.
The idea here was we're taking most of the information up.
It was kind of a bottoms up approach. With the XDR,
it's really more of a top down. And here's what I mean.
What we would do with an EDR system is we would actually install
some kind of capability, some kind of agent on each one of these systems,
and that would sit there and would do detection and would do a certain level of response.
And the idea here is we're pushing the the actions down.
It's more of a instead of a “let's bring everything up
and then take action”, let's do as much as we can and automate the response
there on the platform as close to the source of the outage,
as close to the source of the attack as we can make it.
And that's what this did. With XDR, though
we still need an ability to bring this information up.
And this would be from servers, from desktops, from laptops.
Those are the systems that we're trying to enforce policy on
and look for anomalous behavior and things of that sort.
So the EDR capabilities basically needed a way to report up
and so that they could all give a more comprehensive view.
And that's really where XDR came into existence, was to do those kinds of things.
Now, it turns out you could take an XDR system and read all of these endpoint devices into it.
You could actually even take the information from the SIEM and forward it into an XDR,
just as you could have taken the endpoint information and fed it to the SIEM.
So there's a lot of different ways that you can make these things work.
But what's really interesting is that some vendors have come up with
this idea is we'll keep both of these here, but we're going to add a capability
here to the XDR that's called Federated Search.
And what Federated Search does is it says,
I want to look for particular indicators of compromise or particular
incidents, particular alerts, particular conditions.
And I'm going to take those and I'm going to say I'm going to query all my systems and say,
do any of you have these kind of conditions happening on your system right now?
The advantage to that is I don't need all of the data
pre-fetched and stored in advance in some big database.
I go out and get it just in time.
So we leave the data in place and then we go out and gather it just as we need it.
And a federated search basically tells each one of these systems,
search your local database of information and see if there's a problem
that matches the specific conditions that I'm spelling out.
And if you have that, then report this back up.
And that's the way these things work.
It's a lot like the card game that a lot of kids play
called Go Fish, where you say, does anybody have any threes?
And everyone looks in their hand to see if they have any three cards.
And if they do, then they have to turn that in.
It's the same thing here.
We're saying everyone run a search on your system locally and then only report the results.
It's much more efficient, but in fact, we kind of need both of these
because the SIEM is particularly good at doing alarms since all the information is coming up.
But what we want to do is have high quality alarms.
We don't want to just have tons and tons of information there.
SIEMs tend to get more expensive the more information you feed into them.
XDRs get around that problem by saying leave most of the data here and I'll go fetch it just in time.
But still, the XDR operator
needs to know that there's a reason they need to go out and look in the first place.
So an alarm coming in from a SIEM might be a trigger to
then cause an investigation to occur.
So it's really not XDR versus SIEM.
I want to leave you with the point that it's XDR plus.
SIEM. These two work together and can complement each other
and be part of a stronger security response.
Okay.
Now, we've talked about the SIEM and XDR
technologies, which basically allow us to monitor, to analyze
and report on the stuff that we see happening in our environment.
Now let's talk about hunting.
What is hunting about?
Well, the reason we want to do this in the first place is
this is an attack scenario, a timeline.
And the first thing the bad guy does is reconnaissance.
They basically check out your site, they case the joint.
They try to figure out where your weak points are.
So they're going to spend some time doing that initially.
Then, according to Ponemon Institute’s Cost of a Data Breach survey,
there's a delay in time until we have the mean-time-to-identify (MTTI).
In other words, the guy attacks me at this point after he's finished his reconnaissance, he goes in.
Now, how long does it take before the organization is aware that they've been attacked?
Well, it turns out this is on the order of 200 days.
That's a huge problem, because imagine if a bad guy
was in your house for 200 days before you realized that you had been broken into.
And then the mean-time-to-contain (MTTC), that is, after I am aware that there's a problem,
how long before I actually have it fixed?
Now we're taking a look at it about another 70 days.
You put those two together, 270 days.
It's the better part of a year that the since when you were attacked
until you finally have recovered from all of this.
So what would we like to be able to do in this?
I'd like to be able to move awareness back earlier into this.
If I can't completely prevent the attack, at least become aware of it sooner.
And the way we do that is with threat hunting.
Now, threat hunting, as compared to a basic investigation.
With an investigation, we're reacting.
So the system is giving me an alarm,
a guy has broken in and now I'm doing
the forensic investigation to find out what happened.
That's what we typically do with SIEM and XDR tools.
But there's something else we could do, and that's this idea of threat hunting,
where I'm going to be more proactive.
I'm going to basically use the skills, the experience
and the instincts of a skilled
cybersecurity analyst who has seen everything--
hopefully --and kind of comes up with what is essentially a hypothesis.
They say, I wonder if someone has done this or that or the other thing.
We don't have an alarm yet.
No one has told us that we've been broken into.
But I want to get ahead of this before anyone even allows the alarm to be sounded.
So they develop a hypothesis based upon their experience
and their instincts about what would someone go after?
How might they attack us?
What kinds of things would they do?
We're looking at the way other attackers are breaching
networks and systems and using that in our hypothesis as well.
And the threat hunter then uses tools like these,
the SIEM and the XDR, to go off
and look for searches and look for indicators of compromise.
And if they do it correctly, what we end up with is early detection.
We basically move the bar back. In a perfect world,
we'd be able to detect future crimes and we'd arrest the bad guys before they even break in.
But we don't live in that world.
The next best thing we can do is try to find out as close
to the attack as possible if we can't prevent it at all.
Now, what we've done with this so far is we've talked
about the detection aspect of all of these things.
What we want to do in the final video in the series is talk about response.
So make sure you don't miss it.
Thanks for watching.
Please remember to hit like and subscribe and don't miss the notify bell
so that you don't miss any videos in this series.