June 23, 2026: “Feeds, BindPlane, and Cloud Connectors: How Data Enters SecOps”
Why Ingestion Matters
Detection rules only work if the right data is flowing. A perfect brute force rule is useless if authentication logs never arrive.
Path 1: Google Cloud Connector
The simplest path for GCP-native sources. Provides direct integration for GCP audit logs and Cloud Logging. Configured in SecOps Settings > Feeds. For GCP audit logs, no separate log sink is required.
Common log types: GCP_CLOUDAUDIT (Admin Activity, Data Access, System Event audit logs) and GCP_CLOUD_LOGGING (application logs, VPC Flow Logs, firewall logs).
Path 2: BindPlane Agent
For on-premises and self-managed sources that cannot push to a cloud API. The legacy Chronicle forwarder is end of life, and BindPlane is the supported replacement. The BindPlane agent is an OpenTelemetry-based collector that accepts syslog (TCP/UDP), CEF, LEEF, raw log files, and Windows Event Logs, then sends to SecOps over an encrypted channel. It runs on Linux or Windows and is managed centrally through the BindPlane management console, so you configure collection across many agents from one place instead of hand-editing YAML on each host.
Typical sources: on-premises firewalls (Palo Alto, Zscaler), Windows Event Logs, and network appliances.
Path 3: API-Based Feeds
For third-party cloud services. API feeds poll external APIs on a schedule and pull events into SecOps. Configured on the Feeds management page with API credentials, log type, and polling interval.
Common integrations:
- OKTA: Authentication events, user lifecycle changes
- CS_EDR (CrowdStrike): Endpoint detection, process telemetry
- AZURE_AD: Sign-in logs, audit logs, conditional access
- AWS CloudTrail: API call history across AWS services
Path 4: Ingest API (Direct Programmatic Ingestion)
For custom applications and sources with no prebuilt feed, push events directly over the SecOps Ingestion API instead of waiting for a poll. Two import paths:
- UDM events import: Send events you have already shaped into UDM. You build the structured record yourself, so no parser runs and there is no parse-rate risk. Ideal for in-house apps, enrichment pipelines, or anything that can emit clean UDM.
- Unstructured log entries import: Send raw logs and let the assigned parser convert them, the same as a feed but pushed on your schedule.
Both require a service account with the ingestion role and an API key or OAuth credentials. Use this when you need full control over timing and format, or to backfill events a feed cannot reach.
Path 5: Webhook Feeds
For SaaS sources that support outbound webhooks. SecOps generates a unique endpoint URL and secret on the Feeds management page; the external service POSTs events to it. This is push-based, so events arrive in near real time rather than on a polling interval. Assign the correct log type just as you would for an API feed.
Choosing a Path
- GCP-native -> Cloud Connector
- On-premises / self-managed -> BindPlane
- Third-party cloud, poll model -> API feed
- Third-party cloud, push model -> Webhook feed
- Custom app or your own structured UDM -> Ingest API
Log Type Assignment
Every feed must be assigned a log type that selects the correct parser. Assigning the wrong log type means the parser fails to extract fields, and events arrive partially parsed or unparsed. Start with default parsers. Google maintains parsers for hundreds of log sources.
Verifying Ingestion
After configuring a new feed:
- Open the Data Ingestion and Health dashboard.
- Check volume to confirm events arrive at the expected rate.
- Check parse rate to verify UDM conversion. Low parse rates indicate a parser mismatch.
- Check latency for acceptable delay.
Confirm with a quick UDM Search:
metadata.log_type = "OKTA" AND metadata.event_type = "USER_LOGIN"
If results appear, the pipeline works end to end.
