SIEM (Security Information and Event Management) is an important part of any security strategy. In this video, you’ll learn how a SIEM can be used to gather and report on syslog data from all of your infrastructure devices.
<< Previous Video: Access Points Next: Data Loss Prevention >>
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.