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.

Huntress SIEM currently appears to be collecting only security-relevant events available through API integration. Clients may want to log more or all events (depending on their budget for log size) but there is no option to change this. Category

There should be a way to configure alerting for ingested firewall logs. We can connect the firewalls via syslog ingestion, but it feels like that data isn't being utilized to its fullest potential. There should be options to configure alerting based on activity. Some good prebuilt alerts would be common items like firewall admin creations, deletions, changes and similar activities that pose a high threat if the actions are not legitimate.

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?

I understand that internal Syslog collection is supported, but external Syslog collection is not yet available. It would be advantageous to have support for external Syslog collection to broaden the scope of log sources that can be integrated into Huntress SIEM.

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.

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

Current HEC log ingestion does not usefully index nested json. Business Justification Our organization is adopting OpenTelemetry as the standard observability framework for collecting logs, metrics, traces, and events across cloud, on-premises, and application environments. While OpenTelemetry has become the industry standard for telemetry collection, the current SIEM integration options are either limited or require custom ingestion pipelines. Native OpenTelemetry support would simplify integrations, reduce operational overhead, improve telemetry consistency, and enable broader security visibility across modern infrastructure. Requested Capability Native OpenTelemetry Data Ingestion Support direct ingestion of: OpenTelemetry Protocol (OTLP) over gRPC OTLP over HTTP OpenTelemetry Collector forwarding Structured OpenTelemetry logs Metrics relevant to security monitoring Distributed traces OpenTelemetry Schema Awareness Automatically recognize and normalize standard OpenTelemetry fields such as: service.name service.namespace service.version host.name cloud.provider cloud.region deployment.environment trace_id span_id severity_number severity_text Resource attributes Instrumentation scope attributes Security Correlation Enable correlation between: Logs and traces Infrastructure telemetry and security alerts Application events and security incidents User actions across distributed services Examples: Correlate authentication failures across microservices using Trace IDs. Trace lateral movement activity across distributed applications. Link API abuse indicators to backend service traces. OpenTelemetry Collector Integration Provide validated configurations and documentation for: OpenTelemetry Collector Azure Monitor Exporter Kubernetes deployments Containerized workloads AWS, Azure, and GCP environments Detection Content Provide out-of-the-box dashboards and detections that leverage OpenTelemetry data: Authentication anomalies API abuse patterns Service-to-service communication anomalies Application compromise indicators Distributed denial-of-service indicators Suspicious trace patterns Performance and Scalability Support: High-volume OTLP ingestion Multi-tenant collection architectures Collector-based aggregation Sampling-aware analytics Buffered and resilient ingestion mechanisms Expected Benefits Operational Benefits Reduced custom parser and connector maintenance Faster onboarding of new applications Standardized telemetry pipeline Improved data quality and consistency Security Benefits Better visibility into modern cloud-native environments Enhanced attack-path analysis Improved incident investigation through trace correlation Stronger detection coverage across distributed systems Business Benefits Reduced integration costs Faster deployment of new services Alignment with industry standards Future-proof telemetry architecture Priority High Use Cases Correlate security events across microservices using Trace IDs. Investigate suspicious application behavior end-to-end. Monitor Kubernetes workloads through OpenTelemetry Collectors. Centralize observability and security telemetry using a single standard. Reduce dependence on vendor-specific agents and collectors. Desired Outcome The SIEM should be capable of ingesting, parsing, normalizing, correlating, and analyzing OpenTelemetry telemetry natively, allowing organizations to leverage OpenTelemetry as a first-class data source for security monitoring, threat detection, and incident response. Impact: High value for organizations adopting cloud-native architectures, Kubernetes, Azure/AWS/GCP services, and modern observability platforms.

Requesting on behalf of a Partner.