SIEM – CompTIA Security+ SY0-501 – 2.1

Most organization’s network. They will have switches,
routers, firewalls, servers, desktops, laptops, mobile
devices, and much more. And there’s always some
type of security event that’s occurring across many of
these devices, and very often occurring simultaneously. It’s useful if you have a way
to log all of that information to one place. This would be the security
information and event management console. This is a centralized
logging device that’s able to get data from all
of those very diverse devices, and bring it all back
to a single database. This can provide you
with security alerts, because you are getting real
time information across all of these different devices. And of course, it’s
storing this information over a very long period of time. That means later on if you’d
like to create some advanced reports on what’s been
seen over the last 24 hours, the last week,
or even the last year, you can do that from your SIEMs. Many SIEMs include additional
data correlation functionality. For example, you might have
a certain manufacturer’s firewall, and then you might
also be using a Windows server. Obviously the data
that’s contained on both of those devices
is very different. The mini SIEMs can begin
correlating that data together, so that you can see someone
logging in to their VPN connection on the
firewall, and then see what resources they were
accessing on the Windows server. From a security
perspective, it’s great to have all of
this information stored in one central place. That means that there is
an event after the fact, you can go back
through your logs and get more details
on what exactly occurred during
that security event. If you are deciding
to collect logs against all of these
different devices, one of the challenges
you’re going to have is with the time stamp that’s
inside of all of those logs. Each switch, router,
firewall, server, workstation, mobile device, and anything else
that’s connected to the network has its own clock inside of it. So we need to synchronize
all of these devices to one single clock. You can see why this
would be important. If later on we want to
go back through our logs and try to correlate
what happened on a switch with what was happening on
a router and a file server during exactly the same time,
we need some way to synchronize all of those things together. One of the most
common ways to do this is using a very
standardized protocol, NTP. This is the Network
Time Protocol. That allows all of the devices
you’re using to automatically synchronize their clock. And they’re all synchronizing
it to one single clock source. This means that you can control
how a device is synchronized the clock, and the frames that
it uses for synchronization. But it’s also going to provide
very accurate timekeeping. If you’re synchronizing
the NTP, the accuracy of all of these devices will
be about one millisecond apart, if you’re synchronizing them all
on a single local time source. Now that we’ve decided to
gather all of this log data from all of these
very diverse devices, we need some standardized way
to transfer that information. And the way that we use
today is through syslog. This is a very standard
method to transfer logs between devices, even
when those logs contain very different types of information. Whether you’re using switches,
or routers, or firewalls they all probably have a way to
transfer their log data using the standard syslog transfer. Usually there is a
central receiver. Most often this is
integrated into your SIEM. And this means that you’re going
to need a lot of storage space. These SIEMs are
usually gathering data from these devices constantly. And you’re going to need
terabytes, upon terabytes, to be able to store all of
this for a long period of time. Many organizations
that are focused on the security of these
logs, will offload them on to some type of storage
method that can’t be changed. They might use WORM
drive technology. Worm stands for write
once, read many. DVD-Rs are a good
example of where you can write to
these optical drives, and then nothing on that drive
can be changed after the fact. On many of these
logging devices, you might have the
problem of an event storm. For example, let’s say
that a wide area network connection goes down. Did you lose one connection,
or did you lose 50 connections to your 50 remote sites? Whenever an event
like that occurs, it can fill up the event
log with information. Many SIEMS are going to be able
to deduplicate these events. And so instead of looking
through pages of events, you can focus down
to the events that really matter for that outage. You might also see this occur
if you have an interface that is constantly going down,
it’s coming back up again, and then it’s going
down again, constantly flapping up and down. This could fill up an
event log but many SIEMs are designed to
interpret these messages, and to set timers when
these things happen. That means instead of
writing 100 separate events to the event log,
the SIEM can instead deduplicate this and
put a single event that says that this
event occurred 100 times. Most SIEMs allow
you to configure how this suppression will work. So you can set your
own timers, configure how these are handled,
and sent it up to work best for
your environment. Once you have your
SIEM configured, you’ve got plenty
of drive space, and you have all of these
devices sending their log information in
via syslog, you’re going to have a constant
flow of information. Somewhere in that
information flow is going to be the
important details that you’re looking for. You can generally track
the important statistics, and perhaps even have
graphs shown on screen so you can get a feel for what’s
happening in your environment at any particular time. And if there are exceptions,
you can mark them and put them into the log. Many SIEMS also have a way
to automate some functions, so you can receive
an alert, and then have the SIEM open up a
ticket, delete temporary files, or reboot a device. Here’s an example of some of
the raw logs you might see from inside one of these SIEMs. You can see that these
are all security events. Here’s one at the top that
shows that a process has exited. Somebody who was
running a CMD.exe on one of your Windows servers. Here’s another one where someone
has logged into a device, and they’ve logged in
with a particular user ID. And you can see others might be
someone logging in to a domain controller as an anonymous user. So some of these
events might prompt you to take some
additional action once you see what’s happening
with these security events. Instead of looking through pages
and pages of real time logs, most SIEMs allow you to
collapse all of that information into a single dashboard. So you can see this dashboard
includes event categories, security events, all events,
important events, alerts, and so on. This allows you
to very easily see events that may be
immediately occurring, something you may
want to look at, and other events
that can break it out by informational, success,
alert, debug, or even emergency events. And of course many SIEMs have
their own report generator built in. So you could create a
weekly or monthly report that rolls up all of that
data you’ve been collecting into a single graphical view.

One Comment

Add a Comment

Your email address will not be published. Required fields are marked *