Google SecOps organizes data very well by log type, but it does not provide a simple native "data sources" view where you can reliably list every sending host or source IP across log types.
That becomes a practical problem when you need to answer questions like:
- which devices are sending this log type?
- which source stopped sending logs?
- how many unique senders do I have for this source?
- which new source IPs appeared recently?
Relying only on UDM hostname fields is not always enough.
Fields such as `principal.hostname`, `target.hostname`, or `asset.hostname` depend on the parser and on what the original product included in the payload. In real environments, hostnames can be duplicated, missing, misleading, or unrelated to the device that actually sent the log.
For syslog-style ingestion, the sender IP is often known at the transport or receiver layer, but it may not exist inside the raw message body. If the parser cannot extract it, it may never become a useful UDM field.
## Workaround
If you use Bindplane, you can capture the peer/source IP at ingestion time and copy it into a Google SecOps ingestion label.
Conceptually:
The exact source attribute depends on the receiver and protocol, so validate the actual field exposed by your Bindplane source.
## Why Bindplane
Google documents Bindplane as a supported collection path for Google SecOps and also documents a similar pattern for silent host monitoring, where `host.name` is copied into:
The same idea can be adapted for source IP tracking.
What This Enables
Once the source IP is stored as an ingestion label, you can build dashboards or searches for:
- unique source IPs by log type
- last seen time per source IP
- source IPs that stopped sending
- new source IPs
- source IPs sending to unexpected log types
This gives you a practical ingestion-source inventory, even when the UDM parser does not expose a reliable hostname or source field.
Important Caution
This is not the same as asset identity.
The ingestion source IP may represent:
- the real device
- a relay
- a collector
- a NAT address
- a load balancer
So the label should be treated as ingestion-source context, not as proof of the business asset.
Still, for SIEM operations, this is often exactly the missing view: what is feeding the platform, by log type, and when did it last send data?
## References
- Google SecOps data ingestion: https://docs.cloud.google.com/chronicle/docs/secops/secops-ingestion
- Data processing pipelines: https://docs.cloud.google.com/chronicle/docs/ingestion/data-processing-pipeline
- Bindplane silent host monitoring: https://docs.cloud.google.com/chronicle/docs/ingestion/bindplane-silent-host-monitoring
- Bindplane Add Fields processor: https://docs.bindplane.com/integrations/processors/add-fields
-- gromero-sec | Detection Engineering | github.com/gromerosec/
