Alerting & SIEM Integration

LinuxGuard routes security signals to external alerting and SIEM destinations through a delivery system built on two components: delivery channels and notification rules. A delivery channel is a configured connection to a specific destination — a webhook endpoint, a syslog receiver, or a Splunk HTTP Event Collector. A notification rule is the routing layer that connects signals to one or more channels, applying conditions to select which signals are delivered, and optional throttle and quiet hours controls to manage delivery volume and timing.

Delivery Channels

Three delivery channel types are available. Choose based on your existing alerting infrastructure:

Webhook — delivers a structured JSON payload to any HTTPS endpoint via HTTP POST. Use webhooks when you have a custom receiver, an automation platform (such as a SOAR or ticketing system), or any service that accepts HTTP callbacks. LinuxGuard signs every request with HMAC-SHA256 so the receiving system can verify authenticity. See Webhook Integration for setup and signature verification guidance.

Syslog — forwards signals as standard syslog messages to any receiver that accepts UDP, TCP, or TLS connections. Syslog is the broadest-compatibility option: virtually every SIEM, log aggregator, and log management system accepts syslog input. Both RFC 3164 and RFC 5424 formats are supported. RFC 5424 is recommended for structured environments because it preserves signal metadata in structured data elements. See Syslog Forwarding for protocol, format, and TLS configuration.

Splunk HEC — delivers signals directly to the Splunk HTTP Event Collector using the native HEC JSON format. Use this channel in Splunk-native environments where signals should appear with a consistent sourcetype in your Splunk index. See Splunk HEC Integration for token configuration and event field reference.

Notification Rules

A notification rule defines when and where signals are delivered. When a signal is created, the platform evaluates each enabled notification rule in turn. If a rule's conditions match the signal, the platform delivers the signal to every channel configured on that rule.

Conditions use AND logic: all configured conditions on a rule must match the signal for the rule to fire. A rule can filter by signal severity, category, agent environment, agent tag, or identity type — or any combination of these.

A rule with no conditions configured matches every signal. This is a deliberate design choice: an unconditioned rule is the simplest way to forward all signals to a SIEM destination for ingestion and correlation. See Configure Notification Rules for the full conditions reference and setup steps.

Throttle

Throttle limits the number of deliveries a rule makes within a time window. It protects receiving systems from high signal volumes during incident peaks and reduces noise when many signals of the same type fire in quick succession. Two throttle patterns are available: a simple per-hour cap (max_per_hour) and a flexible period-based cap (max_per_period combined with period_minutes). Throttle is configured per rule, so different rules can have different delivery rate limits. Signals that exceed the throttle limit for a rule are not delivered for that rule during the current window.

Quiet Hours

Quiet hours define a daily time window during which a rule suppresses signal delivery. Configure quiet hours when a rule targets an on-call channel and you want to avoid non-urgent notifications during off-hours. The window is specified as start and end times in HH:MM format, and all times are evaluated in UTC. Overnight windows — where the start time is later than the end time — are supported. An optional critical_bypass flag allows critical-severity signals to be delivered even during the quiet window, ensuring that the highest-severity events are never silently suppressed.

---

Related: Configure Notification Rules | Webhook Integration | Syslog Forwarding | Splunk HEC Integration