If you are monitoring the security of your network, then you are almost certainly using a SIEM. In this video, you’ll learn about SEIMs, using syslog, and the fundamentals of SOAR.
<< Previous Video: Vulnerability Scans Next: Penetration Testing >>
To be able to manage the massive amount of information you receive from log files and event notifications, you’ll want to use a Security Information and Event Management Device or SIEM. A SIEM is designed to collect information from anything on the network that can create log files, security alerts, or any type of real time information that can tell us about what’s happening on the network right now. The SIEM is commonly used as a central repository. So everything will be logged and aggregated into the central database of the SIEM. From there, you can create reports and historical perspectives of what’s been happening on the network over time.
You might also be able to correlate data from different devices to see if you can start to see events occurring even though the data sources that you’re receiving are very different between these different devices. And, of course, since you’re collecting all of this information into a central database, it’s a perfect place to go to be able to perform forensics after a security event has occurred.
The data that’s being fed into the SIEM is coming from very different devices. A Windows server works very differently than a Linux workstation, which works very differently than a router or a switch. So there needs to be a standard way to be able to send log files from other devices into this central repository. And the name of that standard is called syslog. There is usually a syslog compatible collector that is part of the SIEM itself. This collector is waiting for messages to be sent from all of those different diverse devices on the network. And the format of those messages coming in to the syslog collector are in this standard syslog format.
As you could have probably already guessed, being able to store all of this data from all of these devices over a long period of time is going to require a lot of storage space. So it’s very common on a SIEM to allocate terabytes and terabytes of storage so that you can collect a lot of this information and store it for a long period of time.
So what types of information would be valuable to store in a SIEM? Well, from a security perspective you’d love to be able to see who may be attempting to authenticate into a server. Maybe you’d like some record, a VPN connectivity or firewall session logs. Or perhaps you want to see people that are trying to communicate outbound from your network to a location that you would not like to allow– those would be the denied outbound traffic flows– or maybe just a generic overview of network utilization and something that you can track and trend over time. It’s also common to grab raw packet captures as well. Especially if an event occurs, and you can add the packet captures into the event to add more information about what may have happened during that time frame. It’s common in larger organizations to have a Security Operations Center, or a SOC. Someone in the SOC is able to monitor all of these SIEMs, evaluate the type of data that may be coming in, and be able to react to some of the information that’s provided from the dashboard of the SIEM.
As you can imagine, there is a constant flow of traffic and information being put into the SIEM. So it’s very important that you’re able to react to the data that you’re receiving. The logs that are being added to the SIEM are able to be parsed and then the Sim can identify if a security exception might exist within those log files. From there, notifications can be sent over email or text message to inform people of the exceptions that have been found. And this could even be automated through a ticketing system, so that as soon as a problem is identified, it can be assigned to a technician who can then evaluate what the next steps might be.
At the core of the SIEM is the log information. This is a screenshot from a SIEM that shows an example of the logs you would get from a Windows system. For example, here is a log entry that shows a user account was enabled. It shows a security ID, an account name of “Administrator”– and here’s the domain name associated with that– and then some additional account information from that computer as well. Obviously, there is a large amount of log information that is stored on the system with an extensive amount of data. That’s why most SIEMs are going to have a dashboard that rolls up that information into a mode that can be easily identified and easy to understand what’s happening. So you can see trending of logs, how many types of security events have been received, the top devices that are reporting in, and even the severity of those Windows events. We can see that we’ve had successes, a large number of failures, and some informational severities as well.
Most Sims also include report writers. So you’ll be able to gather information into the logs and then create a more readable view of that data, especially over a long period of time. Being able to pull important information from this very large amount of data relies on different techniques and analytics. One of these would be big data analytics which is the ability to look through large amounts of very diverse data to be able to identify patterns that normally would be invisible to a human being.
Another type of analytics looks at how people are acting. So you would have user and entity behavior analytics which examine how people are using the network. Even if they’re not directly attacking a device, there may be a way to tell if that particular type of pattern could cause potential problems in the future.
And another type of analytics is a sentiment analytics. This examines how the public views a particular organization. For example, if a public opinion of an organization happens to be very bad, it tends to attract hackers who can then create problems on that network. So being able to measure how your organization is viewed on social media may have a direct impact on the type of security you would need on your network.
These days organizations are trying to take advantage of all of this data and all of this technology by the use of SOAR. SOAR stands for Security Orchestration Automation and Response. The goal of SOAR is to take these processes in security that were manual or tedious and automate them so that all of it is done at the speed of the computer.
With orchestration, we’re managing many, many different devices and automating the access that we have to those devices. In some cases, we are configuring or reconfiguring devices with this orchestration. So we might modify firewall rules, or change the permissions associated with a particular account, or change the email filters we’re seeing and do this all dynamically as this information is being evaluated by our systems.
Instead of having an individual configure our firewalls, or our accounts, or these email filters, we will have our systems themselves provide this through automation. This is an important key of this, because the computers much faster than we happened to be. And it can identify what may be happening at any time of the day and put barriers or mitigation in place to prevent those problems from happening on our network.
And the response part of SOAR means that we’re able to have this orchestration and automation occur at any time of the day and be able to react to anything that may be occurring in our network.