 It’s the situation every SOC analyst dreads: You’re working an incident using the logs available to you in your SIEM and realize that what you’re looking for simply isn’t there. When did we stop receiving logs? What other logs are we missing? How are we going to explain that we didn’t notice this?  Given the challenges teams face ensuring log ingestion fidelity, FireEye Helix has introduced an advanced analytic module named LogTracker. LogTracker provides capabilities that offer security teams assurance that data is coming in, and that Helix has all of the information it needs to analyze security incidents. What about real-time log monitoring? We’ve got you covered—this module provides many helpful checks on the following: This module includes a variety of reporting timeframes, including hourly presence and reporting, 24 hours presence, daily reporting, and weekly reporting to provide a full perspective. Let’s take a look at some examples of how the LogTracker module in Helix would help identify log fidelity issues and immediately notify security teams. This is the example described in the beginning of the post—a situation involving a decrease in logs for a given event class, which could be an early indication of a problem. LogTracker can help teams identify problems in logging infrastructure before they become larger issues. In Figure 1, we can see that an alert was generated when logs categorized as coming from NetSkope dropped by a whopping 53%!o(MISSING)ver the previous hour. Normal fluctuations occur at the beginning and end of a workday, but this is something that most certainly needs to be investigated. This alert provides the information needed to go to the NetSkope device and ensure logs are being sent. Figure 1: Alert created during ingestion decrease What happens when security teams haven’t received logs from the proxy over the last 24 hours? LogTracker will alert them and provide them with the information needed to go to the team that owns the proxy, so that team can ensure logging is restored as quickly as possible (Figure 2). Figure 2: LogTracker alert that logs were not received How do security teams know when they are receiving logs again? LogTracker will let them know that data has been restored (Figure 3). Figure 3: LogTracker alerting that logs are being received We just covered situations where logs weren’t present, but what about when there is a burst in one of the tools logging to the SIEM and the overage starts to cause issues with real-time alerting? LogTracker has that situation covered as well. In Figure 4, we can see that an alert was created when the “unix mgmtd” log class spiked 23%!o(MISSING)ver the last hour, indicating the potential for over-ingestion. LogTracker is constantly profiling the levels in which event classes are being ingested, forming a baseline and alerting when changes occur in either direction. In this case it was over-sending. Figure 4: Alert created during ingestion increase Spikes do happen, but the good news is that Helix events are queued versus dropped, so the logs will get processed when the spike comes back down. Again, this alert provides the information needed to proactively address the logging situation before further issues arise. Whether the issue involves receiving no logs or too many logs within Helix, the LogTracker module has got it covered. We expect a variety of teams to benefit from this module, including operational groups and security analysts alike. Issues happen, but that’s why modules such as LogTracker are there—so teams aren’t asking where their logs are when they’re needed most. Ready to get started? Head over to our page to connect with us and to see a demo. Already using Helix, but not familiar with LogTracker? Reach out to your Sales Engineer to get more information and a walkthrough of how LogTracker can help!		It’s the situation every SOC analyst dreads: You’re working an incident using the logs available to you in your SIEM and realize that what you’re looking for simply isn’t there. When did we stop receiving logs? What other logs are we missing? How are we going to explain that we didn’t notice this? Given the challenges teams face ensuring log ingestion fidelity, FireEye Helix has introduced an advanced analytic module named LogTracker.What is LogTracker?LogTracker provides capabilities that offer security teams assurance that data is coming in, and that Helix has all of the information it needs to analyze security incidents. What about real-time log monitoring? We’ve got you covered—this module provides many helpful checks on the following:Log ingestion stopsLog ingestion spikes per event classLog ingestion deviations from a baseline per event classThis module includes a variety of reporting timeframes, including hourly presence and reporting, 24 hours presence, daily reporting, and weekly reporting to provide a full perspective.Let’s take a look at some examples of how the LogTracker module in Helix would help identify log fidelity issues and immediately notify security teams.Ingestion DecreaseThis is the example described in the beginning of the post—a situation involving a decrease in logs for a given event class, which could be an early indication of a problem. LogTracker can help teams identify problems in logging infrastructure before they become larger issues.In Figure 1, we can see that an alert was generated when logs categorized as coming from NetSkope dropped by a whopping 53%!o(MISSING)ver the previous hour. Normal fluctuations occur at the beginning and end of a workday, but this is something that most certainly needs to be investigated. This alert provides the information needed to go to the NetSkope device and ensure logs are being sent.Figure 1: Alert created during ingestion decreaseWhat happens when security teams haven’t received logs from the proxy over the last 24 hours? LogTracker will alert them and provide them with the information needed to go to the team that owns the proxy, so that team can ensure logging is restored as quickly as possible (Figure 2).Figure 2: LogTracker alert that logs were not receivedHow do security teams know when they are receiving logs again? LogTracker will let them know that data has been restored (Figure 3).Figure 3: LogTracker alerting that logs are being receivedIngestion IncreaseWe just covered situations where logs weren’t present, but what about when there is a burst in one of the tools logging to the SIEM and the overage starts to cause issues with real-time alerting?LogTracker has that situation covered as well. In Figure 4, we can see that an alert was created when the “unix mgmtd” log class spiked 23%!o(MISSING)ver the last hour, indicating the potential for over-ingestion. LogTracker is constantly profiling the levels in which event classes are being ingested, forming a baseline and alerting when changes occur in either direction. In this case it was over-sending.Figure 4: Alert created during ingestion increaseSpikes do happen, but the good news is that Helix events are queued versus dropped, so the logs will get processed when the spike comes back down. Again, this alert provides the information needed to proactively address the logging situation before further issues arise.ConclusionWhether the issue involves receiving no logs or too many logs within Helix, the LogTracker module has got it covered. We expect a variety of teams to benefit from this module, including operational groups and security analysts alike. Issues happen, but that’s why modules such as LogTracker are there—so teams aren’t asking where their logs are when they’re needed most.Ready to get started? Head over to our page to connect with us and to see a demo. Already using Helix, but not familiar with LogTracker? Reach out to your Sales Engineer to get more information and a walkthrough of how LogTracker can help!