Skip to main content
SIEM Export forwards Oso data to storage you control, so your security team can ingest it into a SIEM or other analysis pipeline alongside the rest of your telemetry.

​
What you can export

Each export destination has a source:
  • Alerts: Oso’s detections, including the alert type, severity, the agent/user/session/tool involved, and detection-specific detail.
  • Events: raw agent activity, including tool names and parameters, for every monitored session.
Records are delivered as gzipped JSON objects. An OCSF-mapped format is in development; JSON is the only format available today.

​
Destination types

Today, Oso exports to any S3-compatible bucket: AWS S3, MinIO, Ceph, or similar. Support for direct webhook and OpenSearch destinations is planned but not yet available.

​
Setting up a destination

  1. In Oso, go to Settings → Connections and find the SIEM Export card.
  2. Add a destination, choosing:
    • Source: Alerts or Events
    • Destination type: Amazon S3 (or an S3-compatible store)
    • Bucket, region, and an optional key prefix
    • Authentication: static access key/secret, or AWS role assumption
A destination only ships records created from that point forward. It doesn’t back-fill historical alerts or events.

​
Authentication

​
AWS role assumption

Oso can assume a role in your AWS account without you sharing any keys:
  1. Create the destination with the role-assumption auth method and leave the role ARN blank.
  2. Oso generates an ExternalId and shows you a role template.
  3. Create an IAM role in your account that trusts Oso’s principal, conditioned on that ExternalId, with permission to write to your bucket.
  4. Paste the role ARN back into Oso. Oso verifies the role can only be assumed with the correct ExternalId before accepting it, which protects against another Oso customer’s environment being tricked into using your role.

​
Static access key and secret

Static credentials work with AWS S3 and with S3-compatible stores that don’t support role assumption, such as MinIO or Ceph. This is the only supported method for self-hosted deployments using their own S3-compatible storage. Once saved, the secret is stored encrypted and isn’t displayed again.

​
Delivery behavior

Oso ships new records roughly every 60 seconds. Delivery is at-least-once: a retried delivery can occasionally produce a duplicate copy of the same record, so downstream consumers should dedupe on the record’s id field. If delivery to a destination fails, Oso retries with backoff and keeps its place, so a temporary outage on your end doesn’t lose data.

​
Limitations

  • JSON only; OCSF mapping is in development.
  • S3-compatible destinations only; no direct webhook, Splunk, or syslog output yet.
  • No historical backfill when a destination is first created.