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.