Safeguard.sh Documentation Center

SecOps (SIEM)

OCSF-normalized security event ingestion, continuous detection with Sigma rules and IOC matching, and deduplicated alerts — the SIEM substrate, with SOAR, XDR, and an agentic SOC analyst on the roadmap.

SecOps (SIEM)

SecOps turns the security signals already flowing through Safeguard — plus your cloud and identity logs — into a normalized event spine with continuous detection on top. It is built to be the foundation an autonomous SOC eventually stands on, so it ships bottom-up: the event store and detection first, orchestration and the agentic analyst as clearly-marked roadmap.

What's available today. Event ingestion, OCSF normalization, and continuous detection + IOC matching into deduplicated alerts are built (SIEM Wave 0 and Wave 1). The SOC console UI is rolling out. SOAR, XDR, and the agentic SOC analyst are on the roadmap (see below) and are not yet available.

Event ingestion

Collectors feed a normalized event pipeline. Internal sources land first because they need no external credentials:

  • Internal — runtime (CWPP) events, AppSec findings, and API traffic, adapted from the tenant-scoped streams already inside the platform.
  • Cloud — AWS CloudTrail, Azure Activity, and GCP audit logs, pulled incrementally with a persisted per-account cursor.
  • Push — a syslog/CEF listener and a generic webhook endpoint.

Ingestion is backpressure-aware: a bounded per-tenant channel drops-with-metric on overflow rather than blocking a producer or crashing — loss is surfaced, not hidden.

Normalization (OCSF)

Every raw log is mapped to an OCSF-aligned SecEvent: a class (authentication, process, network, file, api, config, dns, …), extracted actor / target / source and destination IPs, and ATT&CK technique tags where the source event implies a technique. The full raw record is preserved at the hot tier so hunts can reach unmapped fields. Mappers are data-driven — a new source is usually a new field map, not new code.

The event store is retention-tiered: a hot tier (full fidelity, days), a warm tier (downsampled), and a cold archive, moved automatically by lifecycle policy. Every read and write is tenant/org/descendant-scoped.

Continuous detection and IOC matching

Detection runs continuously over the event stream:

  • Detection rules + Sigma are executed against new events per tenant; each match produces an Alert carrying the rule, contributing event IDs, severity, and ATT&CK tags.
  • Real-time IOC matching checks every event's IPs, hashes, and domains against the threat-intel store; a hit raises an alert.
  • Deduplication collapses identical alerts within a sliding window (keyed by rule, primary entity, and a coarse time bucket) so a noisy condition produces one alert, not thousands.

Alerts you get

Alerts are the built output surface. Each alert records the firing rule or IOC, the events that contributed to it, a severity, and ATT&CK technique tags — queryable through the API and (as it rolls out) the SOC console. Example detections available today include Sigma "impossible travel" on authentication events and known-bad IOC matches on network events.

Roadmap

These capabilities are designed and specified but not yet available. They are documented here so the intended shape is clear; do not plan against them as shipping features.

  • SOAR — workflow automation. A DAG-based playbook runtime (enrich → condition → action → loop) with a typed connector registry. Destructive actions (isolate, quarantine, disable-account, revoke-key) are approval-gated by default and safe-fail.
  • Correlation and UEBA. Stateful sequence/threshold correlation across a sliding window (for example, failed logins → privilege change → sensitive-data access collapsing into one account-takeover alert) and per-entity behavioral baselining with a cold-start guard.
  • XDR — cross-domain correlation. Endpoint, workload, cloud, identity, and app signals fused into one ATT&CK attack timeline on the shared attack-path graph.
  • Case management. Related alerts aggregated into cases with a timeline, ownership, and severity-derived SLAs.
  • SIEM interop. Bidirectional forwarding to and from Splunk, Microsoft Sentinel, Elastic, and Chronicle.
  • Agentic SOC analyst. A triage → investigate → respond loop over production Safeguard AI, strictly advisory: it reads within a bounded tool budget and can only propose SOAR actions — destructive responses always require human approval, and it is granted no direct connector access.

Configuration

The SecOps engine is gated by server-enforced feature flags (ff.siem, and the roadmap ff.soar / ff.xdr / ff.agentic_soc), fail-safe off. Internal collectors activate with the platform; register a cloud collector with:

safeguard secops collector add --kind cloudtrail --account <ref>

Events, alerts, and every future action are tenant/org/descendant-scoped, access-controlled, and audit-logged, with per-tenant retention and residency.

On this page