What Data Types to Prioritize in Your SIEM

Customers regularly ask me what types of data sources they should be sending to their SIEMs to get the most value out of the solution. The driver for these conversations is often because the customers have been locked into a SIEM product where they have to pay more for consumption. More log data equals more money and, as a result, enterprises have to make a difficult choice around what log sources and data are what they guess is the most important. This often leads to blind spots from a logging perspective and requires that your analysts pivot to other tools and consoles to get any additional context and detail they can during an investigation.

While I understand the business model that drives this approach, as a security practitioner I’ve always hated this trade-off. I have yet to see an organization that is logging all the data sources that they would like -or logging all the sources into a single place that would help them with investigations or threat hunting. They simply can’t keep going back to the well to get more budget every time they blow through the data limits, thus their SIEM has a limited view of what is actually happening in the environment. Lack of info reduces the value of the SIEM.

At Sumo Logic, we have a pricing model where we don’t put limits on the amount of data that is consumed. Data is what helps you do your job, and ultimately what keeps your company safe. It gives context to what may have happened beyond a single or individual alert, and can help you pull out new insights that may not have been possible before.

Of course, not everyone is a Sumo Logic customer yet, so the question about what data sources are most important is definitely still top of mind for many SOC engineers and managers. While this answer will vary a bit depending on the particular customer environment and what is most important to them (i.e. what part of the business is the crown jewels), I’ve found that there are several data types that make sense to prioritize across the board. Many of these are common sense, but some of these may not be centralized to one location in your enterprise today:

1. Firewall Logs – Firewall logs are a great source of detailed flow information. However, with many of the next generation firewalls, you also get rich data on application types, threats, malware, C2 and other similarly interesting things.

It’s important not to limit this data to just your perimeter firewalls. If you have firewalls between your user segment and your Data Center or even micro-segmentation inside the Data Center, send all of these logs to your SIEM. Where your end users are connecting is critical information from a threat analysis perspective. Internal visibility is key to looking for lateral movement.

2. Proxy/Web Filtering Logs – Your NG Firewall may already include this data, but if you use a separate Proxy or Web Filtering solution, these logs should absolutely be sent to your SIEM too. The IP, Domain, and URL information is naturally very important and can give you information on connections to known-bad locations. And if you can also capture the User-Agent string, then you should. This can give the threat hunter lots of insight into what might be happening. There are countless stories about finding major breaches and issues by monitoring the various user-agent strings in an environment and investigating the anomalous or uncommon ones you find.

3. Other Network Security Products – Some of these may already be covered with a next generation firewall, but you may have standalone systems in place. Logs from tools like Network IPS/IDS, Network DLP, Sandboxes, and even router NetFlow data are all rich intelligence sources for the SOC analyst.

4. Network Sensors – Many of our customers have network sensors that sit on TAP or SPAN ports and do Deep Packet Inspection on north/south as well as east/west traffic internally. These sensors will give deeper metadata around the traffic flows than a traditional NetFlow solution would. They can see things like SMB writes and deletes, HTTP header information and user-agent strings, and many other specifics. This additional detail is very interesting when looking for anomalous activity that could indicate things like lateral movement. These types of sensors can help you track down events that you wouldn’t have seen otherwise.

5. Windows Authentication and AD info – As we all know, users move around and often get new IPs. If this happens in the middle of a security event, it can be challenging trying to pick the trail back up and connect the dots. By tracking user authentication information, disparate record types across various IPs can be combined to paint a better picture of the entire activity around the event. In addition, tying a user to the events can help answer the questions around if this user should be accessing these resources. And it makes it easier to track that device down if needed for manual intervention or cleaning.

6. Endpoint Security Solutions – Endpoint information is helpful on multiple fronts:

• Data from Endpoint solutions can help enrich the existing alerts by giving you inventory data like the OS, logged-in user, AD memberships, resource utilization and so on. As an example, you may not need to investigate an Oracle, Linux, or other IPS alert further if the endpoint doesn’t run Oracle or isn’t Linux. This can be a real time saver.
• Alert data is also key info that should be sent to your SIEM. If the AV, endpoint firewall or other product alerted on something, it has often taken care of the initial threat; however, there may be additional threats still on the endpoint that weren’t caught with the current signatures or rules. It’s trivial for an attacker to modify existing malware to get by many of these protections. If anomalous activity is seen by another tool and there is a recent endpoint alert, this may be something you should investigate further versus closing out immediately.

7. Threat Intelligence – More and more, organizations are bringing threat intelligence into their SIEM solutions, which can help dramatically when investigating individual alerts. There are many free Threat Intelligence lists out there, so at a minimum bring a few of these data sources in. Even better would be subscribing to one of the many paid feeds out there. These paid feeds tend to be better maintained with better details and more accurate information. Threat Intel hits in your device logs could indicate malware that got past your endpoint solution or any number of other things that should be interesting to a SOC analyst.

These are the top log and data sources that you should focus on consuming in your SIEM and then expand from there. All enterprises are unique and, as such, when looking for what logs to add next, try to think about what’s important to your company – what is it that you do that no one else can and start from there. This might mean certain application log types (user authentication), web server logs (various error types, etc), or many other things. Often, these new log sources are determined when working actual alerts. Do you wish the alert had more context around it instead of you having to reach out to another console? Then let’s add that context and data. The possibilities are limitless and often start with just a small glimmer of an idea.