Integrations

Integrations pillar — JIRA, Microsoft Teams, Slack, Syslog, SIEM, generic webhooks, and delivery tracking from the LinuxGuard console.

The Integrations pillar manages outbound connections from LinuxGuard to the systems where alerts, findings, and operational events should land — issue trackers, chat platforms, log aggregators, SIEMs, and generic webhook receivers. It is used by detection engineers wiring LinuxGuard signals into the existing incident pipeline, operations leads routing findings to the right on-call rotations, and compliance teams ensuring evidence flows reach the audit log destination.

Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.

Integrations is the console-managed half of LinuxGuard's outbound surface. The other half — file-based or CLI-configured forwarders (/etc/linuxguard/agent.config for syslog facility settings, for example) — lives outside the console and is documented under Configure and the Respond section's per-target pages. The console surface is for operator-friendly target management; the agent surface is for what the agent does locally.

JIRA

The JIRA integration creates issues in a target JIRA project when LinuxGuard generates a finding or signal that matches a configured rule. Each integration entry captures the JIRA base URL, the credentials used (API token recommended; basic auth supported for self-hosted instances), the project key, the default issue type, and field mappings for severity, summary, description, and labels.

LinuxGuard does not poll JIRA — the integration is one-way (LinuxGuard → JIRA). Issue state changes inside JIRA do not flow back into the LinuxGuard console; status tracking remains in JIRA where the assigned engineer is already working.

Typical use: route critical severity Zero Trust findings to a SECURITY project; route compliance suppressions to a COMPLIANCE project; route efficiency rightsizing recommendations to a PLATFORM project. The notification rule that fires the integration is configured under Notifications (see Notifications).

Microsoft Teams

The Teams integration posts adaptive-card messages to a configured Teams channel via an incoming webhook URL. Cards include the finding summary, severity badge, originating server, MITRE technique (where applicable), and a deep link back to the LinuxGuard console for full detail.

Teams is the channel surface most security and platform teams use for awareness-grade notifications — the kind of event that should appear in front of the on-call channel but does not need to open an issue. Teams cards are tuned for skimmability: a single line of summary, color-coded severity, and a clickable link.

A single Teams integration entry holds the webhook URL and a default card template. Multiple channels can be wired by adding multiple integration entries, each with its own webhook URL and template overrides.

Slack

The Slack integration is functionally parallel to Teams. It posts block-kit messages to a Slack channel via an incoming webhook URL or a Slack Bot token where workspace-level installation is configured. Messages include severity color (Slack attachment color), finding summary, server, MITRE technique, and a deep link to the console.

Many tenants run both Teams and Slack integrations — Teams for some teams (corporate IT, audit) and Slack for others (engineering, security). The notification rule layer is what decides which integration receives which signal; Integrations only configures the outbound endpoints.

Threading: where Slack threading is enabled on the integration, identical signals collected within a deduplication window are appended as replies in the original thread rather than as new top-level messages, reducing channel noise.

Syslog

The Syslog integration forwards events to a syslog target over TCP, UDP, or TLS-encrypted TCP (RFC 5425). The integration captures the target host, port, transport, facility, severity floor (events below this severity are not forwarded), and optional client-certificate material for mutual TLS.

Two message format options are supported:

Format	Use case
RFC 3164	Legacy receivers; lower fidelity (limited structured data)
RFC 5424	Modern receivers; structured-data sections preserve metadata fidelity

Most aggregators (rsyslog, syslog-ng) prefer RFC 5424. The LinuxGuard console default is RFC 5424; legacy receivers can opt into RFC 3164 per integration entry.

Note that syslog forwarding from individual agents (the agent forwarding its own log to a syslog target on the host) is configured at the agent level under Configure → Log Level and Rotation. The console Syslog integration is for forwarding LinuxGuard-generated events (signals, findings) from the LinuxGuard backend to a tenant-managed receiver, not for per-agent log forwarding.

SIEM

The SIEM integration is a typed wrapper around the underlying transport (HTTPS POST, Syslog over TLS, or HEC-style endpoint) with vendor-specific message shaping. The supported SIEM types include Splunk (via HEC), Microsoft Sentinel (via Log Analytics workspace ingestion), and Elastic (via Elastic Common Schema POST). Other receivers are wired through the generic webhook integration.

Each SIEM integration captures the vendor type, target endpoint, authentication material (HEC token, workspace shared key, Elastic API key), index / table / data-stream target, and a field-mapping override allowing the operator to align LinuxGuard's event fields to the tenant's existing schema.

SIEM-typed integrations differ from generic webhooks in that the message body is shaped to the SIEM's expected schema — Splunk events are wrapped in the HEC {event: ..., source: ..., sourcetype: ...} envelope; Sentinel events use the Log Analytics API JSON shape; Elastic events follow ECS field naming. The operator does not write the wrapper; the integration does.

Generic webhooks

The generic webhook integration posts a JSON body to an arbitrary HTTPS endpoint. It is the integration of choice for receivers that don't fit JIRA / Teams / Slack / Syslog / typed SIEM patterns: in-house alerting systems, custom automation runners, or third-party services not yet first-class integrations.

Each webhook entry captures the URL, HTTP method (defaults to POST), authentication (none, bearer token, basic auth, or HMAC signing with shared secret), retry policy, and the JSON body template. The body template uses field substitution to insert event fields ({{ severity }}, {{ summary }}, {{ server }}, etc.); the substitution vocabulary is documented in the integration's template editor.

Webhooks are the integration with the highest configuration surface and the lowest opinion. They are also the integration most likely to need debugging — see the Deliveries section for the canonical place to see what was sent, when, and what the receiver responded.

Deliveries

Deliveries is the per-integration delivery history. It records every outbound attempt to every integration: the timestamp, the integration entry, the originating event or rule, the request payload sent, the HTTP response code (or error class for syslog), the latency, and the retry count.

Deliveries is the load-bearing surface for debugging an integration that is "not working." Before suspecting LinuxGuard, check the delivery record:

• Was a delivery attempt made? (No → check the notification rule's match conditions)

• What response did the receiver return? (Non-2xx → check the receiver's authentication and acceptance criteria)

• Were retries attempted? (Yes but all failed → check connectivity and rate limits)

• What did the request body actually contain? (For webhook / SIEM templates that may not render fields as expected)

Each delivery row is inspectable — full request body, full response body, headers, and timing. This level of fidelity is what makes Deliveries the first place to look when an integration is silent or producing unexpected receiver behavior.

Data sources

Integrations is fed by:

• Console-configured integration entries (endpoint, credentials, template) — operator-supplied

• Notification rules that match events and route to integrations — see Notifications

• Events from across the LinuxGuard surface (signals, findings, compliance events, efficiency findings) — produced by the rest of the console pillars

No external sources feed Integrations directly. The integration surface is outbound-only.

Module gating

Subscription gating documented in console. Some integration types (e.g., typed SIEM integrations beyond the most common vendors) may be tier-gated. Generic webhooks and Syslog are commonly available across tiers. Deliveries retention windows vary by tier.

Cross-references

• Related CLI commands: config (agent-level log forwarding settings)

• Related Concepts: Notifications (notification rules route events to integrations), Compliance Expansion (compliance events are a common source of integration deliveries)

• Related How-to: Notification Rules, Webhook Integration, Syslog Forwarding, Splunk HEC Integration

---

Related: Console | Notifications | Respond | Alerting & SIEM Integration | Glossary