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 could 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 endpoint 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 have 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 somebody's trying to 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 login 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 that the IPs
and host names are all using the same format.
This also might be things like time.
If one system is using universal time,
another one is using Greenwich Mean time,
another one's 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 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 logins
and login successful attempts, and other things like that.
We have web log 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 disk 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
where 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 endpoints
and dump it into our SIEM.
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 journald daemon
which is basically the logging service
for system D 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
in 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 Rsyslog 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 it
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 it 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
that's 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 going 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 sampled 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 getting 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 backend 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, 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,
and 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
when you 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 might 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 it 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 markers
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 were 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.