Huntress SIEM currently ingests both our NDR sensor logs and our clients' SonicWall firewall logs. Both data sources are present, correctly parsed and queryable — but there is no way to turn a multi-source pattern into a first-class SIEM alert or a SOC incident. The concrete gap: we can see, in the SIEM, inbound SSH connection attempts from IP addresses that are widely known-bad, targeting our clients' exposed public addresses. We cannot alert on them. Detection today is entirely retrospective and manual — an analyst has to run the query and notice. Real example from our tenant (2026-08-04) Source IPs 2.57.121.112, 2.57.121.25, 193.46.255.86 (AS47890, RO) repeatedly hitting the client's public address, NAT'd to an internal SSH host on port 22. SonicWall syslog, event code 713, logged the connections correctly in the SIEM (13:51, 15:21, 16:51, 18:19 CEST — sustained over days). Our NDR raised only a generic signature ("PuTTY potentially vulnerable if version < 0.80") — an informational client-banner match, not a threat detection. On its own this is noise and gets tuned out. VirusTotal on 2.57.121.112: 15/91 vendors malicious, community score -19, and crowdsourced telemetry showing 128,074 events across 5 attack vectors — 114,757 SSH brute-force attempts, 11,821 ssh-fortinet brute-force attempts, 949 malicious processes spawned via SSH (post-exploitation), 532 port-scanning events. First seen 2025-10-04, still active. Individually, each signal is below the threshold anyone would alert on. Correlated — known-bad source reputation + inbound authentication attempt against an exposed service — it is a high-confidence, actionable detection, and one that is trivially preventable once surfaced (firewall hardening, geo-blocking, SSH exposure review). Requested capability Partner-defined correlation rules that produce native SIEM alerts, with configurable severity, threshold/time-window logic (e.g. N events from the same source IP within M minutes), and de-duplication/suppression. Threat-intelligence enrichment as a rule condition — the ability to match on source IP reputation (Huntress-native TI, and/or partner-supplied IOC lists, and/or third-party feeds) rather than on static IP lists we have to maintain manually. Cross-source correlation — rules that can join events across data sources already in the SIEM (NDR + firewall syslog + EDR), rather than being confined to a single provider. Optional SOC routing, so partner-defined detections above a chosen severity can be escalated into a Huntress SOC incident with the same workflow as native detections. Rule templating across tenants, so an MSP/MSSP can author a detection once and deploy it to all managed organizations, with per-tenant variables (public IP ranges, exposed services). As an MSSP we onboard clients onto Huntress SIEM specifically to consolidate detection. Today we ingest the data but have to run detection logic elsewhere, which undermines the value of the platform and leaves us explaining to clients why a known-bad IP brute-forcing their perimeter for weeks generated no alert. This is also directly relevant to EU clients under NIS2, where demonstrable detection and timely incident notification are regulatory obligations, not best practice. Given SonicWall and NDR logs ingested into the SIEM, I can define a rule stating "inbound connection to TCP/22 on a client public IP, where source IP matches a threat-intel indicator", and receive a SIEM alert within minutes of the first match, deduplicated per source IP, routable to a per-client notification channel.
