Managed SIEM

Managed SIEM creates an escalation when a device does not report within the configured timeframe. Currently, the only way to stop repeated alerts is to mute the device, which must later be manually unmuted. Please add an option to classify or silence a device as “Known Offline” for its current offline period. This status should automatically clear when the device checks in again, allowing a new escalation to be created the next time it goes offline. This would eliminate the ongoing process of manually muting and unmuting devices while ensuring future offline events are still detected. A permanent mute option should remain available for devices whose alerts should stay disabled until manually restored. Offline alerts cannot simply be ignored because a failure to report may indicate an agent or logging issue on a computer that is still running, rather than a computer that is intentionally offline.

It would be nice if there were an option to create an alert for successful and/or attempted logins for specified admin account(s).

Huntress should always escalate when a newly discovered device is not sending SIEM logs, regardless of the status of its other agents. After the device has established a history of successfully reporting, Huntress can use EDR and Microsoft Defender status to determine whether a future reporting gap requires escalation. When a device first checks in but does not send SIEM logs, Huntress should always create an escalation because this may indicate a missed deployment, misconfiguration, or allowlisting issue. The status of other agents should not suppress this initial alert. After a learning period, such as seven days of confirmed operation and successful SIEM reporting, Huntress should correlate future reporting gaps with the EDR and Defender agents on that same device. If either agent remains online while SIEM logs stop, Huntress should escalate because the device is active and the logging failure requires attention. If all available agents are offline, Huntress can reasonably classify the device as offline and suppress the missing-log escalation until it returns.

Cisco advices MSP's generally to use one Organization in the Meraki Dashboard and create Networks for the customers. This structure has the smallest administrative overhead. For example, one subscription can be used for all customers instead of seperate contracts with Cisco for each customer. In order to correctly map the customer's equipment with the corresponding customer in the Huntress SIEM, either a Network to Organization mapping between Meraki Dashboard and Huntres SIEM should be possible, or the possibility to map individual Cisco Meraki API devices to customers in Huntress. Would it be possible to implement something like this?

We have multiple firewalls sending syslogs to different servers to allow for the agents on those servers to forward the logs to the SIEM. The source is always the name of the server, not the name or brand name of the firewalls. It would be nice if we could change the names of the source type and agent for them so they are easier to find.

I'd like to set a query on a generic syslog (my own device) and when I see a certain keyword or flag - fire off an email or text alert.

Currently, Non-Reporting Log Source Escalations are global and will create notifications for endpoints that hit the configured non-report window. This creates unnecessary noise for clients with expected inactive/shelved endpoints. Please allow the setting "Escalate Non-Reporting Data Sources" to be scoped for individual organizations and/or endpoints.

Hi Team, Are there any plans to support SIEM with Checkpoint?

EventID 100 in the application log with the source of ScreenConnect contains connection information when an admin or user connects to a system with ScreenConnect. The details include the name of the user that made the connection and would be helpful to capture in SIEM.

SIEM integration for https://www.defensx.com/