Cloudflare SIEM integration guide
This guide helps teams connect Cloudflare logs to SIEM and analytics destinations with the right datasets, field mapping, parsing, normalization, retention, dashboards, alert tuning, ownership, and investigation workflows.
This guide helps teams connect Cloudflare logs to SIEM and analytics destinations with the right datasets, field mapping, parsing, normalization, retention, dashboards, alert tuning, ownership, and investigation workflows.
Topics: cloudflare, resource, cloudflare, siem, integration, guide
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Confirm Cloudflare logs are already arriving in a usable form - the right datasets and fields delivered to the destination - then start the SIEM work at ingestion rather than re-solving log export.
- 2
Map each Cloudflare field to your SIEM's schema or data model: align client IP, host, path, HTTP status, ray ID, action, rule ID, bot score, and timestamps to the equivalent fields in Splunk CIM, the Elastic Common Schema, Sentinel tables, or your Datadog pipeline.
- 3
Build or configure the parser and source type so records are correctly tokenised, timestamps are parsed in the right timezone, and JSON fields are extracted - validating against real sample events, not assumptions.
- 4
Normalise across datasets so HTTP, firewall, DNS, and Zero Trust events share consistent field names and event categories, letting a single search or correlation rule span them.
- 5
Set retention and index/table placement by data class - hot, searchable retention for security events and longer, cheaper retention for high-volume HTTP traffic - to control SIEM cost.
- 6
Build the dashboards analysts will actually use: WAF and firewall action breakdowns, top blocked sources, bot score distribution, rate-limit triggers, origin error trends, and DNS and Zero Trust activity.
- 7
Write and tune detection and alert rules against Cloudflare signals - WAF block spikes, credential-abuse patterns on login, bot anomalies, traffic surges to sensitive paths - starting in low-severity or monitoring mode to control false positives.
- 8
Document ownership and the investigation workflow: who maintains parsers and field mappings as Cloudflare adds fields, how an analyst pivots from a SIEM alert to the Cloudflare dashboard and ray ID, and how rules are reviewed over time.
Risk register
Risks to control
Cloudflare fields are mismatched to the SIEM schema, so correlation searches and prebuilt content silently miss Cloudflare events.
Map every field to the target data model (CIM, ECS, Sentinel tables) and validate that normalised searches return the Cloudflare data they should.
Parsers misread timestamps or timezones, putting events at the wrong time and breaking incident timelines.
Configure timestamp and timezone parsing explicitly and verify against known events before trusting the timeline.
All Cloudflare logs are ingested into expensive hot storage, blowing the SIEM licensing or ingest budget.
Tier retention by data class - hot for security events, cheaper longer-term storage for high-volume HTTP - and filter low-value records before ingest.
Detection rules are copied from generic templates and fire constantly on normal Cloudflare traffic.
Tune rules against your own baseline, start in monitoring/low-severity mode, and promote only after the false-positive rate is understood.
Field names and event types drift as Cloudflare adds datasets and fields, quietly breaking parsers and dashboards.
Assign an owner to track Cloudflare log-format changes and keep parsers, mappings, and content under review.
Analysts can't pivot from a SIEM alert back to Cloudflare context, slowing investigations.
Standardise on shared identifiers like the ray ID and document the workflow from SIEM alert to the Cloudflare dashboard and Log Explorer.
Output
Useful deliverables
- Field-mapping table aligning Cloudflare dataset fields to the target SIEM schema or data model.
- Parser/source-type configuration with validated timestamp, timezone, and JSON field extraction.
- Cross-dataset normalisation scheme giving HTTP, firewall, DNS, and Zero Trust events consistent field names and categories.
- Retention and index/table placement plan tiered by data class and cost.
- Analyst dashboard set covering WAF actions, blocked sources, bot scores, rate-limit triggers, origin errors, and Zero Trust activity.
- Detection and alert rule pack tuned to your baseline with severities and tuning notes.
- Ownership and investigation runbook covering parser maintenance, field drift, and the SIEM-to-Cloudflare pivot via ray ID.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Which SIEM platforms does Cloudflare integrate with?
Cloudflare logs can be delivered into Splunk, Microsoft Sentinel, Datadog, Elastic, and others, as well as object storage like R2, S3, GCS, and Azure that those platforms ingest from. The integration work that follows - field mapping, parsing, dashboards, and detection rules - is broadly the same regardless of which platform you land on.
What is the hardest part of integrating Cloudflare logs into a SIEM?
Field mapping and parsing, not transport. Getting Cloudflare's fields aligned to your SIEM's data model (Splunk CIM, the Elastic Common Schema, or Sentinel tables) so that timestamps parse correctly and correlation searches actually match Cloudflare events is where most integrations succeed or fail.
How do we keep Cloudflare data from blowing up our SIEM ingest cost?
Tier it. Keep security events - firewall, WAF, rate-limit - in hot searchable storage, push high-volume HTTP request logs to cheaper longer-term storage, and filter low-value records before ingest. The aim is to pay hot-storage rates only for the data analysts actually query day to day.
Why are our Cloudflare-based alerts so noisy?
Usually because the rules are generic templates run against normal traffic. Tune detections to your own baseline, start them in monitoring or low-severity mode, and only promote to actionable alerts once you understand the false-positive rate. WAF block spikes and bot anomalies in particular need thresholds set from your traffic.
How does an analyst get from a SIEM alert back to Cloudflare detail?
Through shared identifiers, primarily the ray ID. If the ray ID and consistent host/path fields are mapped into the SIEM, an analyst can pivot from an alert straight to the matching request in the Cloudflare dashboard or Log Explorer. Documenting that pivot is part of the integration, not an afterthought.
Nanosek
Design SIEM integration
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.