I would like to open a discussion around something that repeatedly appears in SIEM operations:
Who should own data ingestion?
Not for common sources where the path is already clear: Windows, Linux, major firewalls, common EDRs, cloud connectors, etc.
I mean the gray area:
- a source with partial or outdated documentation
- a vendor that only provides guidance for another SIEM
- a product owner who knows the platform but not its log export options
- a SIEM team that can receive data but does not control the source
- a network team that owns the path but not the use case
- a client or business team expecting the integration to “just work”
In those cases, responsibility becomes blurry very quickly.
The vendor owns the product, but not necessarily the SIEM integration.
The SIEM vendor owns the platform, but not every possible source.
The source owner controls the technology, but may not know how to expose the right telemetry.
The SIEM administrator needs the data, but may not own the source, network, licensing or vendor relationship.
So the practical question is:
Who should drive the ingestion process when ownership is split across teams?
Should SIEM administrators wait until the source owner provides the logs?
Should they take ownership of the process as a best-effort technical lead?
Should this be formally owned by the client, the vendor, the MSSP, or a dedicated integration team?
My take: SIEM administrators should usually own the process, not every dependency.
Meaning: drive the questions, identify blockers, define boundaries, involve the right teams, request vendor support when needed, and make clear what is best effort versus what depends on external ownership.
I wrote a longer reflection about this here:
https://medium.com/@gromerosec/siem-detection-engineering-field-notes-001-the-other-elephant-in-the-room-data-ingestion-397b2dac1884
Curious how others handle this in real environments.
When ingestion falls into this gray area, who drives it in your organization?
