Integrations by category
Integrations

Security Log Sources for Sazabi: SIEM-Style Logs Without the SIEM

By Sazabi Team

Last verified on Nov 8, 2026.

Security teams ask the same few questions again and again. Who signed in, from where, and did it work. Who changed a permission. Who read a secret. What did the firewall let through. The answers are spread across identity providers, cloud audit trails, network gear and hosts, and this category gathers the sources that bring them into one place.

What the sources record

Group them by the question they answer.

  • Who signed in. Auth0 logs logins, failed logins, MFA, password resets and attack protection blocks. Okta records System Log sign-ins and admin actions. WorkOS sends authentication, SSO and directory sync events.
  • Who changed what in the cloud. CloudTrail events keep fields such as eventName, userIdentity, sourceIPAddress and errorCode. The GitHub audit log covers repository permissions, deploy keys and tokens. See GitHub and AWS.
  • Who touched secrets. Vault audit devices log every authenticated API call. Doppler Activity Logs show who read or changed secrets and configs. See Doppler.
  • What crossed the network. AWS WAF, Palo Alto Networks, Zscaler and Tailscale cover web ACLs, firewalls, web gateways and tailnet flows. See Tailscale.
  • What happened on a host. Linux auditd and osquery come from agents on each machine, and SentinelOne and Jamf Pro forward threats, alerts and device events.

How teams use them together

One source rarely proves anything. A failed login is noise. The same address failing across forty accounts, followed by a success from that address and then a new access key in the cloud audit log, is an incident. Each step lives in a different source, so the value comes from searching them side by side on a shared field, usually an IP address, a user and a time window.

Two practical points help. Use consistent field names when you have a choice, and keep timestamps in UTC. Both make cross-source queries short.

Example: failed logins from one address

Auth0 records each event type code in auth0.type. The code f is a failed login, s a successful one and limit_wc an attack protection brute-force lockout. The caller's address is in client.address, and the event carries auth0.user_id. Failures are recorded at WARN and attack protection blocks at ERROR.

An example question for a Sazabi thread:

Count auth0.type = f by client.address in the last hour.
For the top address, list the distinct auth0.user_id values
and whether any auth0.type = s event followed.

One address with failures across many auth0.user_id values is credential stuffing. One user with failures from many addresses is more likely a forgotten password or an attack on that user. If a success follows, treat the account as exposed. Run the same shape of query on Okta using okta.client.ip_address and okta.actor.alternate_id.

What to watch for across them

  • Delivery guarantees differ. Auth0 delivers at least once, so a count can include duplicates. Check for a repeated auth0.log_id before you alert on volume.
  • Severity is not uniform. GuardDuty severity is a number from 1.0 to 10.0, which Sazabi maps to INFO for Low, WARN for Medium, ERROR for High and FATAL for Critical. Other sources use their own scale, so filter by event type as well as level.
  • Audit logging can break the system it audits. Vault stops serving requests if it can't write to any enabled audit device. Keep a second device enabled.
  • Agents split events. Each auditd line is its own record, and multi-line events share an audit_serial without being joined. sudo command lines stay hex-encoded.
  • Sensitive content. Audit trails name accounts and addresses. Limit who can search them.
  • Silence. A security source that stops sending looks the same as a quiet day. Alert on a source with zero records over a window, using whatever alerting you run.

Detections and your own queries

None of the detections Sazabi runs today is tied to security sources, so queries like the one above, and alerts on failed logins or privilege changes, are yours to write. For the raw material, start with the AWS integration and the Webhook Events source for vendors that only send webhooks.

Sources in this category

  • AWS WAF (native log source, security): Connect your AWS account so Sazabi sets up subscription filters on your AWS WAF log groups and streams web ACL logs in real time.
  • AWS CloudTrail (native log source, security): Connect your AWS account so Sazabi can subscribe to your trail's CloudWatch Logs group and stream CloudTrail events in real time.
  • Linux auditd (manual log source, security): Send Linux auditd records and journald auth messages to Sazabi through Fluent Bit or the OpenTelemetry Collector, with audit fields parsed into attributes.
  • Auth0 (manual log source, security): Create a Custom Webhook log stream in Auth0 pointed at your Sazabi intake URL to stream logins, failed logins, signups, MFA, password resets, attack protection blocks, and Management API calls.
  • AWS GuardDuty (manual log source, security): Send Amazon GuardDuty findings to Sazabi in near real time with an Amazon EventBridge rule and API destination in each Region.
  • AWS WAF (manual log source, security): Run an OpenTelemetry Collector that reads your aws-waf-logs- CloudWatch log groups and forwards AWS WAF web ACL logs to Sazabi.
  • AWS CloudTrail (manual log source, security): Run an OpenTelemetry Collector with the awscloudwatch receiver on your trail's CloudWatch Logs group and export CloudTrail events to Sazabi over OTLP.
  • Doppler (manual log source, security): Connect Doppler's Generic HTTPS logging service to your Sazabi intake URL to forward Activity Logs that show who read or changed secrets, configs, and workplace access.
  • GitHub Audit Log (manual log source, security): Stream your GitHub Enterprise Cloud audit log, including Git events, to Sazabi through GitHub's Splunk audit log streaming target.
  • Jamf Pro (manual log source, security): Create Jamf Pro webhooks pointed at your Sazabi intake URL to stream device enrollment, inventory, policy, smart group, and API activity events.
  • Okta (manual log source, security): Stream the Okta System Log to Sazabi with Okta Log Streaming and Amazon EventBridge to monitor sign-ins, MFA changes, admin actions, and suspicious sessions.
  • osquery (manual log source, security): Ship osquery scheduled query results and osqueryd status logs from Linux and macOS hosts to Sazabi through an OpenTelemetry Collector or Fluent Bit.
  • Palo Alto Networks (manual log source, security): Forward Palo Alto Networks firewall traffic, threat, and system logs to Sazabi from Strata Logging Service HTTPS forwarding, a PAN-OS HTTP server profile, or syslog through a Vector collector.
  • SentinelOne (manual log source, security): Forward SentinelOne threats and alerts to your Sazabi intake URL from a Singularity Hyperautomation workflow.
  • Tailscale (manual log source, security): Stream Tailscale configuration audit logs and network flow logs to Sazabi through Tailscale log streaming.
  • Unkey (manual log source, security): Add an HTTP log drain in the Unkey dashboard pointed at your Sazabi intake URL to forward API key verifications, rate limits, audit logs, gateway requests, and runtime logs.
  • HashiCorp Vault (manual log source, security): Ship HashiCorp Vault audit device logs to Sazabi through Vector, with each request's path, operation, auth accessor and client IP indexed for search.
  • WorkOS (manual log source, security): Add a webhook endpoint in the WorkOS dashboard pointed at your Sazabi intake URL to forward authentication, SSO connection, directory sync, user, session, and organization events.
  • Zscaler (manual log source, security): Add Zscaler Cloud NSS feeds pointed at a Sazabi endpoint to stream Zscaler Internet Access web, firewall, and DNS logs.

Frequently Asked Questions

What are SIEM logs?

They are the records a security information and event management tool collects: sign-ins, admin actions, cloud API calls, firewall decisions and endpoint events. Sazabi stores the same kinds of records as searchable logs.

Does Sazabi replace a SIEM?

Sazabi stores and searches these logs, and its live detections today are Novel event and Client errors. Rules for brute force, privilege changes and similar patterns are queries and alerts you write yourself.

How do security logs get into Sazabi?

Each source has its own path: a log stream or webhook from the vendor, an EventBridge rule, an OpenTelemetry Collector or Fluent Bit on the host, or a native connection that Sazabi manages. Every path ends at your intake URL.

Do I need to give Sazabi cloud credentials?

Not for the manual paths. The Sazabi docs say Sazabi never receives an Okta API token or AWS credentials for Okta, does not assume a role in your account for GuardDuty and keeps AWS credentials with your Collector for the Collector paths.

Sources

  1. Auth0 log stream, auth0.type event codes, severity mapping, client.address, at-least-once delivery (accessed Nov 8, 2026)
  2. Okta System Log through Log Streaming and EventBridge, okta.* attributes (accessed Nov 8, 2026)
  3. GuardDuty finding attributes and severity to log level mapping (accessed Nov 8, 2026)
  4. Vault audit device attributes, warning about audit device write failures (accessed Nov 8, 2026)
  5. auditd records, auth messages, hex-encoded sudo command lines, multi-line events not joined (accessed Nov 8, 2026)
Send your security logs to Sazabi