- Welcome to Lesson 17: Explain Security Alerting
and Monitoring Concepts and Tools.
We're gonna start off in lesson 17.1
talking about logging and analysis.
Now, I have to tell you, I absolutely love logs.
So I'm very excited about this lesson.
Audit and event logs are great chronological records
of events and actions.
Critical log sources include what happens in our firewall,
our IDS/IPS devices, our proxy servers,
our authentication servers and devices,
our operating systems, our databases,
and our key applications.
Why are audit and event logs so wonderful?
Well, because they are
a constant truthful record of activity
and they are really a great near-time
and historical detective control.
Now, routine log analysis is beneficial
for monitoring access,
identifying malicious and suspicious activity,
including indicators of compromise and indicators of attack,
policy violations, fraudulent activity,
and even operational issues
that at first blush might not seem
like they're tied to security.
So, for example, let's say a log reports
that a drive is about to be full, right?
You're using up all the drive space.
Well, that's an operational or IT issue.
But if the drive gets full
and maybe it stops the system from operating,
well, that's an availability issue.
And now that belongs to us, right?
That's a security issue.
Just as a reminder, an indicator of an attack, an IoA,
our behaviors or actions that suggest an attack is happening
or about to happen.
Where an IoC, an indicator of compromise, is evidence
that a system may have been compromised.
Now, there's a lot of challenges in working with logs.
If you've ever looked at a raw log,
you're like, oh my god, it's crazy, right?
They're really big.
Every activity could have multiple lines, right?
Multiple entries.
They are so cryptic to read.
So if anyone ever says to you,
"Oh yeah, I can just read a log."
You have to, like, you know, call 'em out on it,
'cause you really just can't.
So here are some of the challenges with logging, right?
The volume, right?
A single device can easily generate
hundreds of events per minute.
There's a lot of noise and unnecessary stuff
in our logs, right?
Logs can contain a significant amount of useless data
that needs to be parsed before processing.
The format.
Don't know why this is true but it is.
Every device and every piece of software and every database
seems to have their own format for logs.
So before, it's really useful
for doing comparison and analysis,
logs have to be converted to a standard format
and their data normalized to ensure consistency.
Then just trying to interpret them, right?
Logs can be cryptic
and really require an interpretive process.
The logs also might contain sensitive data.
So let's say for example, your user's logging in
and they're not paying a lot of attention
so they put their password in the username field.
But that password may show up in a log.
And inaccessibility.
Sometimes access to logs are restricted.
So it could be, right?
That you don't have rights to those logs
because maybe it's a third party that has a device.
It is logging, but you don't have access to it.
So let's look at big picture log management workflow.
We have to decide what we're gonna log, right?
We're not gonna log absolutely everything,
all activity that happens in our network
because we would end up chewing up all kinds of bandwidth
and chewing up drive space.
So we're gonna prioritize.
What is it that we want to log?
And then we're going to configure our login.
So for log in a firewall or log in a domain controller,
log in a DNS server, right?
We're, you know, log in a radius server, right?
We're going to configure it.
And I wanna remind you,
and we talked about this a little bit early on,
and we always wanna look
for successful and unsuccessful attempts.
So very often people say,
"Oh, I only wanna get successful events
because that told me something happened."
But unsuccessful is also very important to us, right?
Because that tells us
that somebody or something has been trying to do something.
Once we have configured our log environment,
we will be collecting the data, the log data.
We wanna make sure that we're not just letting it sit there,
that we are analyzing it
on as close to real-time basis as possible.
If there is any issues, any indicators, right?
We're going to wanna respond to those.
And then we're going to wanna archive our logs.
Why archive our logs?
Because we may need to go back to our logs
at some point in the future
if we're doing any type of investigation
or forensic analysis.
So prioritize, configure, collect,
analyze, respond, archive.
Now the protocol we generally use for logging
is known as Syslog.
Syslog stands for System Logging Protocol.
And it's a standard protocol used to send system log
or event messages to a collection server
known as a syslog server.
Now, syslog servers are used to collect logs
from different devices
so that we can store them all in a central location
for our monitoring and review.
Now remember that logs could contain confidential data.
There's always that possibility.
So they should always be securely transmitted and stored.
So, how are logs actually analyzed?
Well, there's a number of components
in the logging analysis process.
Synchronization, normalization, aggregation,
deduplication, correlation, and identification.
Synchronization really isn't part of the analysis process.
It actually has to happen before.
But that's really the process
of when we're configuring our logs,
making sure that we're synchronizing
with an external time source
with a timestamp protocol like NTP.
Why?
Because when we're actually doing the correlation,
it's going to be based on date and timestamp.
So we wanna make sure that all of our systems are using
the same time source.
Normalization is standardizing the log details
into a consistent structure.
Aggregation is consolidating events
from the various or disparate devices and systems.
Deduplication is filtering out duplicate entries
or that excessive noise
that stuff that we don't need in there.
Correlation will be tying individual long entries together
based on related information to build a a fuller picture.
And identification is
ultimately what we're trying to do here.
Identifying normal and abnormal activity.
Now, you can't do that manually.
Now, some people have said to me,
"Oh yeah, I can look at the logs. I can figure it out."
And again, you wanna call 'em out on it.
You really need a log analysis tool.
And then to respond,
it would be nice if you had some automated response tools.
So let's look at four tools.
An SIEM, TIP, UEBA, and SOAR.
An SIEM stands
for Security Information and Event Management.
And it's an automation tool,
again, 'cause we're not gonna do this manually.
We're doing it in automated fashion
for realtime data capture,
event correlation analysis and reporting.
Now, a TIP is a Threat Intelligence Platform
which is another automation tool that combines
multiple threat intelligence feeds
and it integrates with the SIEM.
So not just saying, okay, let's compare and aggregate
what we see in the logs.
Let's now add some threat intelligence
to be able to do some identification.
UEBA stands for User and Entity Behavioral Analytics.
And that's yet another automation tool
that models the behavior of humans and machines
to identify normal and abnormal behavior.
And then lastly, we get to one of my favorite tools,
which is SOAR.
SOAR stands
for Security Orchestration, Automation and Response.
Now, it is not an analysis tool.
It is a response tool.
It's a tool that responds to alerts, can triage the data,
and can follow an automated digital workflow
to take remediation steps.
And we'll be talking more about SOAR a little bit later on.
So diving deep into each one here.
An SIEM, security information and event manager,
solutions offer real-time data capture
and continuous monitoring for multiple sources,
near-time event correlation analysis, and reporting.
Now, SIEM is really a combination of two technologies:
SIM, which was Security Information Management
and SEM, which was Security Event Management.
And they came together and we ended up with SIEM.
Now, SIM focuses on the centralized log collection,
log storage, log search, and reporting,
where SIM focuses on the threat analysis,
the incident detection and response,
and basic ticketing capability.
Now, there's a number of ways to have an SIEM
in your environment.
You might decide
that you are going to bring one in locally, right?
And that you are going to, you know,
on-prem manage and monitor it.
Or you may decide to have a third party do this for you.
So your logs actually go to a third party.
And the third party is managing and monitoring
the SIM on your behalf.
Now the TIP, the threat intelligence platform,
as I said earlier,
combines multiple threat intelligence feeds
and focuses on TTPs.
That's tactics, techniques, and procedures
to detect threats.
Now, the TIPs don't stand alone.
They integrate with an existing SIEM or SIEM solution.
The TIPs perform three basic functions:
aggregation, analysis, and action.
So aggregation funnels multiple threat intelligence feeds
into a centralized feed.
Analysis curates the data using indicators
to define and identify security threats.
And then action shares relevant threat intelligence
with their incident response and your defense teams.
Then we get to UEBA, User Entity Behavioral Analytics.
The User Entity Behavioral Analytics tools analyze user,
that's you and me, right,
and entity, that's gonna be resources, behavior,
and apply advanced analytics to detect anomalies.
So we've got four parts here.
Our user, our entity, behavioral, analytics.
Let's look at each one of them.
Right, what do we mean by user?
That could be you and I, a user,
or it could be a privileged user or it could be a service
or it could be a guest.
Entity, talking about things like routers, servers,
an enterprise application, even an IoT device.
Behavioral, well, that's a behavioral baseline
for each entry.
And then analytics is applying artificial intelligence
and machine learning to really analyze the behavior.
Now, UEBA often is integrated into a SIEM or SIEM platform,
adds behavioral context,
detects malicious insider and privilege account takeovers,
and automates identifying significant events.
And lastly, we'll predict
which incidents should be prioritized.
So let's talk about SOAR again.
SOAR stands for Security Orchestration,
Automation and Response.
Now these are tools that allow an organization
to define incident analysis and response procedures
in an automated digital workflow.
So I wanna define two terms for you:
automation and orchestration.
'Cause there's often confusion between the two.
When we use the term automation,
what we're talking about is the ability to execute
a sequence of tasks without human intervention,
without human intervention.
That's what automation is.
Where orchestration is the integration
of disparate tools and platforms for an automated response.
I always envision an orchestra.
I have an orchestra,
and we've got the violins, and the violas,
and we've got the woodwinds and the brass,
and we've got the drums, right?
Those are all disparate instruments.
But my conductor, right?
They puts the whole orchestra together
so that they work together, right?
This disparate tools and platforms
for an automated response.
And that, my friends, brings us to a three-second challenge.
Five challenge questions, three seconds each.
You ready?
All right. Here's our first question.
The process of standardizing log details
into a consistent structure.
One, two, three.
That's normalization.
Number two, the process of filtering out
duplicate entries or excessive noise.
One, two, three.
That's deduplication.
Number three, an automation tool for real-time data capture,
event correlation analysis, and reporting.
One, two, three.
It's gonna be
our Security Information and Event Management tool.
SIEM or SIEM.
Number four, an automation tool
that combines multiple threat intelligence feeds.
One, two, three.
That's gonna be our TIP, our Threat Intelligence Platform.
And lastly, number five, an automation tool
that allows an organization to define incident analysis
and response procedures in a digital workflow.
One, two, three.
And that's gonna be
Security Orchestration, Automation, and Response
known as SOAR.
And we get to revisit SOAR a little bit later on
when we're talking about incident response.
And I'll give you some SOAR examples then.
All right, let's do a security-in-action together.
This is about a budget request.
You've been tasked with recommending ways to automate
cybersecurity detective and response processes.
Now you're recommending that the organization invest in both
an SIEM and SOAR solution.
Now, at your presentation,
you were asked to explain the differences
and if having both was really necessary.
So what's your response gonna be?
Again, this is a budget request,
and you are saying that you're recommending
both a SIEM and a source solution
because you've been tasked
with detective and response processes.
So you probably have a pretty hefty budget here
and you have to go and justify it.
Go ahead and put me on pause,
write down your response and come on back.
But you wanna explain the difference between the two.
The SIEM will ingest various log and event data
from traditional infrastructure component sources.
The aggregated data then is gonna be analyzed by the SIEM
in real time to spot potential security issues.
So this is our really our detective process.
The source solutions will take
the SIEM response capabilities to the next level,
offering an automated response.
So our source systems are going to supplement,
not replace the SIEM
because our SIEMs are detectives
or our source systems are our responders.
Now, after receiving an alert from SIEM, right,
that source solution will manage
that incident response process.
So if you have both, right, they're going to work together.
The SIEM and the SOAR.
Now, if you only could choose one, they say,
"Well, you can only have one,"
I'm probably gonna start with the SIEM
because I need that strong detective capability.
We can always respond in other ways,
probably not as effectively or efficiently,
but we certainly can.
So if you had to prioritize between the two,
you would invest in the SIEM first
and then maybe in the next budget cycle, in SOAR.
And doing that, my friends, is security-in-action.
There's your word cloud.
You know what to do.
All right, I will see you
at the next lesson when you're ready.