Huntress Managed SIEM and Log Value
SIEM’s and Logs
Historically, SIEM’s have heavily promoted an emphasis on collecting all telemetry, with no distinction on value or actual requirements. While this is generally an effective path towards compliance, it is not cost effective, or an effective strategy for threat detection. As most SIEMs bill on some measurement of volume, either through ingested log volume, or through more convoluted means like compute use, it is in SIEM provider’s financial interest to promote a “collect everything” methodology. To justify the cost, vendors point to obscure compliance needs and an expansive detection library that serves more to inflate marketing numbers than to provide actual security value.
The factors that have long made SIEM difficult to acquire, setup, and maintain stem around the issues listed above. SIEMs have been unobtainable for most organizations due to prohibitive costs from indiscriminate log collection and vast libraries of noisy detections that require a legion of analysts to sort through and engineers to tune.
Smart Filtering
To make SIEM accessible and available to not just the Fortune 100, Huntress invested a significant amount of research into understanding the actual compliance requirements for logging. In short - we found that most of the debug, verbose, and informational logs being collected historically, were completely unnecessary for compliance requirements to be met. While making SIEM more affordable is a great achievement, we also need to ensure that saving money doesn’t come at the expense of decreased threat detection capability. This provides a guiding principle that establishes when we include logs that may otherwise be filtered.
Given the compliance permissibility to filter or not collect all logs - Huntress Managed SIEM leverages Smart Filters to drop logs based on a published, static, but evolving list of smart filtered event types (sign into support to view). Each event type added to Smart Filters is vetted by our Detection Engineering and Threat Research teams to confirm we aren’t removing security relevant logs. In addition, where there is any concern around the operational or security value of an individual log, we always err on the side of caution.
When Do We Filter?
The process of reviewing logs occurs weekly, and is narrowly defined on the top event types by log volume. This allows us to focus on event types that are most likely to contribute to customer overages, and ideally prevent overage charges. Each event type, unique to a specific source/vendor, is reviewed for security and operational value. Logs related to user access, permissions, authentication, modification, deletion, or any other non-automated action are always kept - never smart filtered. Logs like heartbeats, attribute checks, and things generally included in debug, verbose, and informational logs are considered for filtering. Given some of these lower level logs can still be leveraged for threat hunting techniques like lateral movement, enumeration, and data exfiltration, we will always consider those factors before filtering.
Our primary process is predicated on using a light hand, erring on the side of caution, and always evaluating each prospective event type thoroughly. In other words, if in doubt, we’ll store it as security relevant until proven otherwise. Our priority is our customers compliance and security, neither of which should be put into a situation where without Smart Filtering, we’d have been covered. Any concerns or individual requirements on smart filtering are treated as immediate priorities by the Managed SIEM team and evaluated for security and compliance efficacy.