S-I-E-M, or SIEM, stands for Security Information and Event
Management.
This is usually a device that is logging information
from many different resources on the network,
and consolidating all of those logs back to one
single reporting tool.
This allows us to perform analysis of the data
to create security alerts and real time information
about what's happening on the network right now.
Since we have collected all of this log information,
we're aggregating it into one place,
and creating a long term storage so
that we can create some extensive reports
over a long period of time.
There's also the ability to correlate different types
of data together.
We're bringing together data from firewalls, servers,
switches, routers, and other devices on the network.
This allows us to correlate data together
that normally would be completely separate.
And of course, if we have some type of security event,
we can go back through these logs
to determine what happened during that time frame,
and what other details can we gather
about this specific security issue.
A SIEM can gather information from many different devices.
We can of course gather log files
from operating systems like Windows or Linux,
and have that information sent into the central SIEM database.
There's also log files that are in our switches, our routers,
our firewalls, and other devices.
And of course, those log files can also be parsed and stored
in the SIEM database.
We might also use third-party sensors,
which follow standards such as NetFlow,
that can provide information about traffic flows
across our network.
And if you can imagine consolidating
all of this information from so many different devices
into a single database, and then trying
to read through the database to find information
that we might be able to use, it's almost overwhelming.
So it's important to use a SIEM that is able to parse the data,
and perhaps put the information into different categories.
Perhaps some of these log entries
can be categorized as informational.
Others might have a warning category.
And others could be categorized as urgent.
Because we're able to capture this information over a very
long period of time, we can start to see trends in the way
that the data is changing.
We can see spikes whenever a particular security
event occurs, or we might be able to tell
that a particular network is more
or less utilized than normal.
The SIEM also has intelligence that can parse this data,
look through the information for details,
and proactively provide you with alarming and alerting.
You could then drill down into the raw data that's
inside the SIEM to be able to create reports and view
other details about that event.
And we can begin correlating these very different data
types into a standard set of information.
For example, you may be able to see
the relationships between source and destination IP
addresses, users, source type, and other information
that you could gather from the log files.
I'm connected to SIEM that has 339,000 events inside
of the database that go back five years.
The latest event was two days ago.
And we can begin searching for information inside of the SIEM.
I'm going to perform a search of the word fail,
and the word fail, or failure, or anything after it,
and the word password.
And it's going to search through that database
and show me all of these log entries
where I have matches for the word fail or failure,
and the word password.
And you can see some of these entries
you're able to determine that it was Microsoft authentication.
You can see server names and other information inside of it.
And there's additional details that you could drill down
into if you would like to.
There's also information along the left side of the screen
that tells me information about, perhaps,
what the source type was for these particular records.
And if I click that, it will summarize or create
an incident report that shows me that 2,400 of these
were Windows authentication instances.
But there were some of Linux devices
that had this particular entry.
A database audit and a secure file service.
If we click Linux secure, it will add that to our list.
And now we're looking at Linux-specific events
where there was a failed password.
And then we can find more information
about each one of those events, and what was associated
with that particular log file.
It will be interesting to see what
devices had this particular authentication failure.
So I'm going to choose an option on the left side
for the destination.
I can see there are eight destinations listed,
and 57% of these events were to the corp file server.
So now we know exactly which service
is having the most number of events,
or perhaps the most number of brute force attacks, all
because we were able to search very quickly through the SIEM
database.