A SIEM can provide extensive visibility and reporting options. In this video, you’ll learn about using a SIEM (Security Information and Event Management) console and searching for important security details.
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.