Instructor: Investigative data.
In this lesson, we're going to talk about
some of the different pieces of information you may use
when you're conducting an incident response.
Now for the exam,
you don't need to be an expert in all of these
different tools or areas that we're going to talk about,
but instead you need to be able to understand
what sources are available to you
and pick the right one based on a given scenario.
So, as we look at this,
you have to remember that when we look at a network,
there are tons and tons of pieces of data.
And as a security analyst,
it's our job to take that information in
and create a consolidated picture.
Based on that picture,
we're going to be able to understand better
what is happening inside our network
and in response to the event we're working on.
Now, the first thing we're going to talk about is a SIEM.
Now we've talked about SIEMs before,
but a SIEM is a Security Information
and Event Monitoring System.
Now, this is important because it's going to be a combination
of a lot of different data sources into this one SIEM tool.
And this provides us with real time analysis
of security alerts that are generated by applications
and network hardware.
As we go through,
we're going to be able to see a SIEM dashboard.
Now from that dashboard, we can see
the number of hosts we have,
the number of authentications that have happened.
The number of unique IPS we're seeing,
all the different hosts in our network,
and we can cut through that data,
using different search parameters
to find the information we need.
When you're doing an incident response,
a SIEM is a really helpful thing for you.
Now, when you think about a SIEM,
there are lots of different pieces of information
and a lot of ways for this information to get there.
The first thing we have to think about is our sensor.
This is the actual end point that's being monitored.
That sensor can then feed that data up into the SIEM.
Another thing we have to think about with our SIEMs
is their sensitivity.
Now the sensitivity is focused on how much
or how little you're going to be logging.
Based on how you configure that sensor,
that's going to determine how much data
is being sent to the SIEM.
Now you may think it's great to send everything to the SIEM
and in a lot of cases, it is,
but you have to remember that a SIEM can become overloaded
with too much information.
All that information takes processing power.
It takes network bandwidth, and it takes storage to hold it.
So you have to think about these things
as you're configuring your system
and creating the right sensitivity levels.
Another thing we to think about is trends.
By using a SIEM and its graphical ability
to look across these logs,
we can start seeing trends in our network.
For instance, we may see
the number of failed authentication attempts going up.
That might be the indication
that's someone's trynna brute force our network.
These trends are very useful to us.
Another thing we think about is the alerts.
Inside the SIEM, we can set it up
so that there's certain alerts that happen
based on certain parameters.
For example, using the failed log in attempts.
We can use that as a good example.
We might say that every time
there is five failed login attempts,
I want to have an alert sent to a system administrator
to look into that account.
That would be an example of an alert
based on different inputs across the SIEM.
And then finally correlation.
This is one of the big things within a SIEM
because we're getting data from all sorts
of different sources, across all different types of hosts
and network devices.
All these things need to be correlated
so that we have a good picture of what is really happening.
This includes making sure that the IPS
and host names are all using the same format.
This also may be things like time.
If one system is using universal time,
another one is using Greenwich meantime
another ones using European time
and another one's using New York time,
that can actually be a big issue for us.
So we want to correlate those all to a common standard.
And normally we do that using UTC, Universal Time.
Now, the next thing we want to talk about is log files.
When we talk about log files,
this is any file that records either events
that occur in an operating system
or other software that's running
or messages between different users
of a communication software.
Essentially, we're going to write something down.
Now we're going to digitally write it down.
And that's what a log file is.
Now there's lots of different types of log files out there.
For example, we have network log files
that are going to keep track of all of the things
that are going through our routers and our switches.
We have system log files that tell us what's happening
on an individual host or server.
We have application log files that tell us exactly
what each application is doing on a given system.
We have security log files.
They're going to monitor things like failed log-ins
and logins successful attempts and other things like that.
We have web blog files,
and this might be like your proxy server logs,
where we could see what websites have been accessed
by your users, or if you're running a web server,
what files are being touched by an outsider
as they're accessing that server.
We also have DNS logs and these are going to be used to tell us
what requests been made of that DNS server.
So we can see who's trying to get what IP addresses
from what domain names.
We're also going to have authentication logs.
This is going to tell us who has successfully logged in,
who has successfully logged out
or who has failed to log in or logged out.
It'll tell us any kind of authentication
across all of our files, our systems and our servers.
We also have dump files.
Now dump files are when things happen to crash.
For instance, if I have a host and it crashes,
it can actually dump the memory contents
to disc while it's crashing,
that can actually be uploaded as a log file into our system
for us to use that for analysis as well.
We also have things like VoIP.
Now, a lot of our systems nowadays are using VoIP as well.
And this can be captured as part of our network log files,
or specifically as voiceover IP devices.
This way we can get metadata about the calls being made.
And if we go into the call manager,
we can actually record calls as well.
This is one of those things that VoIP gives us that ability
we can see exactly who's been calling,
how long they were calling
and even what the contents of that conversation were,
if we have that allowed by our policies and procedures.
Now, the next thing we want to talk about is syslog,
rsyslog and syslog-ng.
Now all three of these are basically three variations
that do the same thing.
They all are going to permit logging of data
from different types of systems into a central repository.
One of the things our SIEM relies heavily on is using
syslog or rsyslog or syslog-ng to grab that information
from all the various end points and dump it into our SIEM.
Now, again, there are three different variations of this
and you really don't need to know the difference of them,
except for the fact that syslog was the oldest one.
Rsyslog was the second version
and syslog-ng is the third version that has more capability.
The next tool we want to talk about is journalctl.
And this is actually a Linux command line utility
that's used for querying and displaying logs
from the journald which is the journal Damon,
which is basically the logging service for systemd
on a Linux machine.
And so if you want to be able to look at the logs
on a Linux machine, you can use journalctl to do it.
The next one we're going to talk about is nxlog.
Now this is a multi-platform log management tool
that helps us to easily identify security risks,
policy breaches, or analyze operational problems
and server logs, operational system logs,
and application logs.
Now, when you think about nxlog,
I want you to remember that it is a multi-platform
or cross-platform tool, and it's also open source.
This also means that it has a lot of similarities
with our syslog or syslog-ng.
So what's the difference?
Well, rsyslog and syslog-ng only work on Linux
and Unix systems, but nxlog is cross-platform.
So you can use on Unix, Linux, and Windows too.
The next thing we're going to talk about is netflow.
Now netflow is used in networking
and it's a network protocol system
that was created by Cisco.
And it's going to collect active IP network traffic
as it's flowing into or out of an interface.
So as you start thinking about things going into
or out of your network, through the firewall
or through a router,
netflow can actually capture that information.
Now, some of the information that captures
is things like the point of origin, the destination,
the volume, and the pass on the network.
This is not a packet capture.
We're not capturing everything,
every single one and zero is going in or out of our network.
Instead, netflow is more of a summarization of that data
that's going in and out of our network.
It can help us with things like understanding
who's using the most bandwidth
or where there are traffic spikes,
but it can't tell us exactly the file that went into
or out of our network.
For that we would need to have a full packet capture.
Now, the next one we have is sflow.
And this stands for Sampled Flow.
Essentially, this was an open source version of netflow,
where netflow is made by Cisco and it's proprietary,
sflow was more of the generic version.
It's to provide a means for exporting truncated packets,
as well as having an interface counter
that is going to be used for network monitoring.
So again, we're not going to have full packet capture here.
We're just going to get some of the sample flow.
So when we talk about sflow,
a lot of times what it'll do, is it'll do packet captures
where it captures one out of a hundred
or one out of a thousand packets
that will help us reduce the size,
while still give you an idea
of what's going through our networks.
The next thing we have is IPfix,
which is the internet protocol flow information export.
Now, this is a universal standard for the export
of internet protocol flow information from your routers,
your probes and other devices.
That's going to be used by mediation systems,
accounting and billing systems
and network management systems
to facilitate services such as measurement,
accounting and billing by defining how IP flow information
is to be format and transferred from an exporter
to a collector.
Wow, that is a mouthful.
And you may be wondering, what did I just say?
Well, really what IPfix is used for
is on the back end of service management.
Let's say for instance,
that I was running a cell phone company
and I was going to charge you $10 for every gigabyte of data
that you transfer per month.
Well, if I'm using IPfix, I can count up
until I get to one gigabyte,
pass that to the billing system in the standard format
and then my system can charge you that $10.
That's what IPfix is used for.
Now, all three of these tools,
netflow, sflow and IPfix can give you a good idea
of how much bandwidth is being used in your environment.
You can use a lot of different tools
that actually make this in a graphical format
like you see here.
Now here, you can notice that there's one big spike.
This tells me as I'm monitoring my bandwidth,
that that point had the largest amount of usage.
And this was traffic outbound.
Now it's significantly higher than the other ones.
So as an analyst, I might go,
hey, something doesn't seem right there.
Why did we just double or triple the amount of traffic
leaving our network?
And I can go back and pull that time,
which in this case, it says 20.11.
And as I pull that information,
we can then look through our SIEM to figure out,
was there one host that was sending a lot of data?
If so, maybe it's been infected
and it's doing a data exfiltration,
or was it a lot of hosts?
Maybe it was just the fact
that there was some kind of a big sale on Amazon
and everybody logged on to start buying things.
So data was leaving the network with their credit card
and their queries to try to get information.
These are the things you have to think about
as a cybersecurity analyst.
Now, the next thing we're going to talk about is metadata.
Metadata is going to be data that describes other data,
basically by providing an underlying definition
or description by summarizing basic information
about the data that makes finding
and working with particular instances of data, much easier.
Essentially, when you think about metadata,
this is data about the data.
So the easiest way to think about this is something like,
your cell phone.
If you think about your end of the month bill,
you can get from your cell phone,
it will show you the day and time of each of your calls,
the number you called and the length of that call
that is metadata it's data about the call.
It doesn't tell you what you said on that call,
but it could remind you that on August 8th,
I talked to my mother for five minutes
and that would tell me that,
because I could see the time I used it,
what number I called and how long that call lasted,
but I won't know exactly what was said.
That's the idea with metadata.
Now, does that mean metadata isn't useful?
Of course not.
As a cybersecurity analyst,
metadata is extremely useful to us
and there's lots of different places
you can look at this metadata to get information
about things.
For instance, you may be looking at email.
If you had somebody who sent an email
that was part of a phishing campaign,
you can look at the metadata about that,
such as the time it was sent, who sent it,
which servers it came from,
which servers that transited through
and all that information,
to be able to figure out exactly what happened
with that email.
Even if you didn't look at the content of the email itself.
You might also look at mobile metadata.
Again, using the example of a cell phone.
You can know how much data was transferred
or how long the calls were and who those people are calling
and who they're talking to.
In the case of web, we might look at things like
which websites are you visiting?
And how long are you staying on them?
This is something marketers are learning about you
all the time.
They don't know exactly what you clicked on necessarily
or where your eyes were looking on the screen,
but they do know how long you are on a particular page
before you clicked away.
And this is metadata they use to re-target you
and work their systems to try to sell you more stuff.
Another thing we have is file metadata.
When I look at a particular file, like a video,
that has a lot of metadata associated with it too,
who created it?
When did they create it?
When was the last time it was watched?
How long do people watch that file for?
All this stuff is data about the data, this is all metadata,
and it can be very helpful
as you're going through an investigation
and doing an incident response.