Security teams regularly ask me about the different types of log sources and security information they should be sent to their SIEM platform to get the most value out of SIEM features. The driver for these conversations is often because the customers have been locked into a SIEM solution where they have to pay more for consumption. More log data equals more money, so enterprises have to make a difficult choice about what log sources and data are 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 they would like -or logging all the sources into a single place to help them with security incident investigations, incident response or threat hunting. They can’t keep returning to the well to get more budget every time they blow through the event data limits. Thus their SIEM tool has a limited view of suspicious activity or what is actually happening in the environment. This lack of security data reduces the value of the SIEM software for detecting a security threat or cyber threats.
At Sumo Logic, we have a pricing model to optimize the costs around your data, including flexible data tiers. 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 previously possible.
Log sources for SIEM technology
Several data types 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 next-generation firewalls, you also get rich data on application types, threats, malware, C2 and more.
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 these logs to your SIEM system. Where your end users connect is critical information from a threat analysis perspective for detecting possible insider threats.
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 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 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 may already be covered with a next-generation firewall, but you may have standalone systems. 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 inspections on internal north/south and east/west traffic. 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, 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 sensors can help you track down events 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 during a security event, it can be challenging 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 about 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 security alerts by giving you inventory data like the OS, logged-in user, AD memberships, resource utilization, etc. For example, you may not need to investigate further an Oracle, Linux, or other IPS alert if the endpoint doesn’t run Oracle or isn’t Linux. This can be a real time saver.
- Alert data are key information 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 attackers 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 an individual SIEM alert. There are many free threat intelligence lists, so at a minimum, bring a few of these data sources in. Even better would be subscribing to one of the many paid feeds. 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 some other cyber security breach.
Final thoughts: types of log sources for SIEM
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 others. Often, these new log sources are determined when working on 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.
Don’t let blind spots be your weak spot. Learn how Sumo Logic’s Cloud SIEM and log analytics can broaden your visibility and speed up incident investigations.
