{"id":28219,"date":"2026-06-23T04:07:23","date_gmt":"2026-06-23T04:07:23","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=28219"},"modified":"2026-06-23T04:07:26","modified_gmt":"2026-06-23T04:07:26","slug":"introduction-of-datadog-siem","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/introduction-of-datadog-siem\/","title":{"rendered":"Datadog Cloud SIEM: Complete End-to-End Master Guide"},"content":{"rendered":"\n

Current as of June 2026<\/strong>.<\/p>\n\n\n\n

Datadog Cloud SIEM is Datadog\u2019s security information and event management product for collecting security telemetry, analyzing logs and events with detection rules, generating security signals, investigating suspicious activity, and automating response. Datadog describes Cloud SIEM as a security data analysis and correlation system that ingests telemetry from cloud and on-prem systems using the Datadog Agent and API-based integrations. (Datadog<\/a>)<\/p>\n\n\n\n

This guide is written as a full practical tutorial<\/strong>: concept, architecture, features, use cases, onboarding, detection engineering, investigation, SOAR, Terraform, GitHub sample projects, and advanced implementation patterns.<\/p>\n\n\n\n

\n\n\n\n

1. What Is SIEM?<\/h1>\n\n\n\n

SIEM<\/strong> means Security Information and Event Management<\/strong>.<\/p>\n\n\n\n

A SIEM collects security-relevant data from many systems, normalizes it, analyzes it, detects threats, generates alerts, and helps security teams investigate and respond.<\/p>\n\n\n\n

Traditional SIEM examples include Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel, Elastic Security, and ArcSight.<\/p>\n\n\n\n

Datadog Cloud SIEM is different because it is built directly on top of Datadog\u2019s observability platform. That means security teams can investigate threats using logs, infrastructure metrics, Kubernetes data, cloud telemetry, application traces, user activity, service ownership, dashboards, and automation in one place.<\/p>\n\n\n\n

\n\n\n\n

2. Why Datadog Cloud SIEM?<\/h1>\n\n\n\n

Datadog Cloud SIEM is especially useful for modern environments where applications run across:<\/p>\n\n\n\n

Area<\/th>Examples<\/th><\/tr><\/thead>
Cloud<\/td>AWS, Azure, GCP, OCI<\/td><\/tr>
Kubernetes<\/td>EKS, GKE, AKS, self-managed Kubernetes<\/td><\/tr>
Applications<\/td>APIs, microservices, backend services<\/td><\/tr>
Identity<\/td>Okta, Auth0, Google Workspace, Azure AD, Duo<\/td><\/tr>
Developer tools<\/td>GitHub, GitLab, Terraform Cloud, Confluent Cloud<\/td><\/tr>
Endpoints<\/td>Windows, Linux, macOS, EDR tools<\/td><\/tr>
Network<\/td>Firewalls, DNS, proxy, WAF, VPN<\/td><\/tr>
SaaS<\/td>Slack, Zoom, Salesforce, Zendesk<\/td><\/tr>
Security tools<\/td>CrowdStrike, Wiz, SentinelOne, Palo Alto, Suricata, Zeek<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The big advantage is correlation. A suspicious AWS IAM action can be investigated alongside Kubernetes events, application logs, service ownership, deployment history, dashboards, and incident workflows.<\/p>\n\n\n\n

\n\n\n\n

3. Datadog Cloud SIEM Core Architecture<\/h1>\n\n\n
flowchart<\/span> LR<\/span>\n    A<\/span>[Security Data Sources]<\/span> --<\/span>> B<\/span>[Collection Layer]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Datadog Log Intake]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Log Pipelines \/ Parsing \/ Enrichment]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Cloud SIEM Analysis]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Detection Rules]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Security Signals]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Investigation \/ Triage]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Notification \/ Incident \/ SOAR]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Remediation \/ Reporting]<\/span>\n\n    A1<\/span>[AWS CloudTrail]<\/span> --<\/span>> B<\/span>\n    A2<\/span>[GCP Audit Logs]<\/span> --<\/span>> B<\/span>\n    A3<\/span>[Azure Platform Logs]<\/span> --<\/span>> B<\/span>\n    A4<\/span>[Kubernetes Audit Logs]<\/span> --<\/span>> B<\/span>\n    A5<\/span>[Linux \/ Windows Logs]<\/span> --<\/span>> B<\/span>\n    A6<\/span>[GitHub \/ Okta \/ SaaS Logs]<\/span> --<\/span>> B<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Datadog Cloud SIEM continuously analyzes incoming data to detect threats, generate actionable security signals, and correlate them across sources. (Datadog<\/a>)<\/p>\n\n\n\n
\n\n\n\n
4. Important Datadog SIEM Terms<\/h1>\n\n\n\n
Term<\/th>Meaning<\/th><\/tr><\/thead>
Log<\/td>Raw event collected from cloud, application, OS, identity, SaaS, or network source<\/td><\/tr>
Pipeline<\/td>Datadog processing logic used to parse, remap, enrich, and normalize logs<\/td><\/tr>
Facet<\/td>Indexed\/searchable field used for filtering and grouping<\/td><\/tr>
Content Pack<\/td>Datadog-provided onboarding package for a security data source<\/td><\/tr>
Detection Rule<\/td>Logic that analyzes logs\/events and detects suspicious activity<\/td><\/tr>
OOTB Rule<\/td>Out-of-the-box rule created by Datadog<\/td><\/tr>
Custom Rule<\/td>Rule created by your team<\/td><\/tr>
Security Signal<\/td>Alert-like object generated when a detection rule matches<\/td><\/tr>
Suppression<\/td>Logic to prevent noisy or expected activity from generating signals<\/td><\/tr>
Investigator<\/td>Graphical investigation experience for supported sources<\/td><\/tr>
Notification Rule<\/td>Routing rule for sending security signals to people or teams<\/td><\/tr>
SOAR<\/td>Security orchestration, automation, and response<\/td><\/tr>
OCSF<\/td>Open Cybersecurity Schema Framework used for normalized security data<\/td><\/tr>
Security Filter<\/td>Configuration controlling which logs Cloud SIEM analyzes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
5. Main Features of Datadog Cloud SIEM<\/h1>\n\n\n\n
5.1 Content Packs<\/h2>\n\n\n\n
Cloud SIEM Content Packs are curated security onboarding packages. Depending on the integration, a Content Pack can include detection rules, dashboards, parsers, investigators, workflow automation, and configuration guides. (Datadog<\/a>)<\/p>\n\n\n\n
This is now one of the most important Datadog SIEM concepts. Instead of manually building everything from zero, you enable a Content Pack for AWS CloudTrail, GCP Audit Logs, GitHub, Okta, Kubernetes Audit Logs, Windows Event Logs, and many other sources.<\/p>\n\n\n\n
Examples of Content Pack categories include:<\/p>\n\n\n\n
Category<\/th>Examples<\/th><\/tr><\/thead>
Authentication<\/td>Okta, Auth0, Duo, Keycloak, Google Workspace<\/td><\/tr>
Cloud Audit<\/td>AWS CloudTrail, Azure Security, GCP Audit Logs, Kubernetes Audit Logs<\/td><\/tr>
Developer Tools<\/td>GitHub, GitLab, Terraform Cloud, Confluent Cloud<\/td><\/tr>
Endpoint<\/td>Windows Event Logs, Microsoft Sysmon, Jamf, SentinelOne, CrowdStrike<\/td><\/tr>
Network<\/td>Cisco ASA, Fortinet, Palo Alto, Suricata, Zeek, Cloudflare<\/td><\/tr>
Web Security<\/td>NGINX, Apache, Fastly, App and API Protection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
5.2 Detection Rules<\/h2>\n\n\n\n
Detection rules are the brain of SIEM. They define suspicious behavior.<\/p>\n\n\n\n
Datadog provides OOTB detection rules to flag attacker techniques and misconfigurations, and Datadog\u2019s Security Research team continuously adds new default rules. (Datadog<\/a>)<\/p>\n\n\n\n
Detection examples:<\/p>\n\n\n\n
Rule Type<\/th>Example<\/th><\/tr><\/thead>
Cloud identity<\/td>AWS IAM user created access key<\/td><\/tr>
Privilege escalation<\/td>Admin role attached to user<\/td><\/tr>
Data exfiltration<\/td>BigQuery export to external bucket<\/td><\/tr>
Defense evasion<\/td>CloudTrail disabled<\/td><\/tr>
Credential access<\/td>Secret parameter accessed unexpectedly<\/td><\/tr>
Kubernetes<\/td>Suspicious exec into pod<\/td><\/tr>
Network<\/td>Connection to threat-intel-listed IP<\/td><\/tr>
Developer tool<\/td>GitHub secret exposed or repo visibility changed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
5.3 Security Signals<\/h2>\n\n\n\n
A security signal is generated when Datadog detects a threat by analyzing logs against detection rules. Signals can be viewed, searched, filtered, assigned, and correlated in Signals Explorer. (Datadog<\/a>)<\/p>\n\n\n\n
A signal usually contains:<\/p>\n\n\n\n
Signal Field<\/th>Meaning<\/th><\/tr><\/thead>
Rule name<\/td>Detection that generated the signal<\/td><\/tr>
Severity<\/td>Info, Low, Medium, High, Critical<\/td><\/tr>
Source<\/td>CloudTrail, Okta, GitHub, Kubernetes, etc.<\/td><\/tr>
Triggering logs<\/td>Events that matched the rule<\/td><\/tr>
User\/resource<\/td>Identity, account, host, pod, service, IP<\/td><\/tr>
MITRE ATT&CK mapping<\/td>Tactic\/technique where available<\/td><\/tr>
Triage state<\/td>Open, under review, archived, etc.<\/td><\/tr>
Timeline<\/td>Events and updates around the signal<\/td><\/tr>
Suggested response<\/td>Investigation\/remediation guidance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
5.4 Custom Detection Rules<\/h2>\n\n\n\n
OOTB rules cover many common cases, but custom rules are required for company-specific risks. Datadog supports custom rules for specific use cases, services, accounts, or events. (Datadog<\/a>)<\/p>\n\n\n\n
Datadog custom detection methods include:<\/p>\n\n\n\n
Detection Method<\/th>Meaning<\/th>Example<\/th><\/tr><\/thead>
Threshold<\/td>Trigger when event count exceeds threshold<\/td>More than 10 failed logins in 5 minutes<\/td><\/tr>
New Value<\/td>Trigger when unseen value appears<\/td>User logs in from new country<\/td><\/tr>
Anomaly<\/td>Trigger when behavior deviates from baseline<\/td>Unusual API call volume<\/td><\/tr>
Content Anomaly<\/td>Detect unusual content patterns<\/td>Rare command or rare user-agent<\/td><\/tr>
Impossible Travel<\/td>Detect impossible user movement<\/td>Login from Japan and Germany within minutes<\/td><\/tr>
Third Party Signal Correlation<\/td>Correlate external security signals<\/td>EDR alert + cloud activity<\/td><\/tr>
Sequence<\/td>Detect ordered chain of events<\/td>Login failure \u2192 success \u2192 privilege escalation<\/td><\/tr>
Scheduled Rule<\/td>Run periodic deeper analysis<\/td>Daily privileged access review<\/td><\/tr>
Historical Job<\/td>Backtest detection against historical logs<\/td>Check if new rule would have fired last month<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Real-time detection rules continuously monitor incoming logs and trigger immediate alerts when matching patterns or anomalies are detected. (Datadog<\/a>) Scheduled detection rules run at intervals to analyze indexed log data using a defined time window. (Datadog<\/a>) Historical jobs are one-time queries against historical logs used to backtest detections and convert interesting results into signals. (Datadog<\/a>)<\/p>\n\n\n\n
\n\n\n\n
5.5 Suppressions<\/h2>\n\n\n\n
Suppressions prevent signals from being generated under specific conditions. This is critical for reducing false positives.<\/p>\n\n\n\n
Datadog supports suppression rules across multiple detection rules. For example, suppress signals containing a specific trusted IP, service account, scanner, or maintenance window pattern. (Datadog<\/a>)<\/p>\n\n\n\n
Use suppressions for:<\/p>\n\n\n\n
Scenario<\/th>Example<\/th><\/tr><\/thead>
Known scanner<\/td>Suppress vulnerability scanner traffic<\/td><\/tr>
Trusted automation<\/td>Suppress Terraform role changes from CI<\/td><\/tr>
Break-glass test<\/td>Suppress controlled security drill<\/td><\/tr>
Internal NAT IP<\/td>Suppress known corporate egress IP<\/td><\/tr>
Test account<\/td>Suppress lab-only user activity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Important: prefer precise suppressions. Do not suppress broad rules like env:prod<\/code> or source:cloudtrail<\/code>, because that can hide real attacks.<\/p>\n\n\n\n
\n\n\n\n
5.6 OCSF Normalization<\/h2>\n\n\n\n
Datadog Cloud SIEM supports the Open Cybersecurity Schema Framework<\/strong>, or OCSF. Datadog says OCSF support is integrated directly into Cloud SIEM so incoming security logs are standardized and enriched with OCSF-compliant attributes through out-of-the-box pipelines. (Datadog<\/a>)<\/p>\n\n\n\n
Why this matters:<\/p>\n\n\n\n
Without OCSF<\/th>With OCSF<\/th><\/tr><\/thead>
Each vendor has different field names<\/td>Common normalized schema<\/td><\/tr>
Hard to write portable rules<\/td>Easier detection logic<\/td><\/tr>
Investigation requires vendor-specific knowledge<\/td>Standardized user, IP, action, resource fields<\/td><\/tr>
Cross-source correlation is difficult<\/td>Better correlation across cloud, identity, endpoint, network<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Datadog also provides an OCSF processor for custom mappings inside Log Management pipelines. (Datadog<\/a>)<\/p>\n\n\n\n
\n\n\n\n
5.7 Security Filters<\/h2>\n\n\n\n
Cloud SIEM does not always need to analyze every log. Security Filters control which ingested logs are analyzed by Cloud SIEM.<\/p>\n\n\n\n
Datadog currently documents different filtering approaches depending on the Cloud SIEM product type. For most Content Pack use cases, enabling or disabling Content Packs is the easiest way to manage which logs Cloud SIEM analyzes. For more granular control, teams can configure filters directly. (Datadog<\/a>)<\/p>\n\n\n\n
Important detail: Datadog tags ingested logs with datadog.cloud_siem:true<\/code> or datadog.cloud_siem:false<\/code> depending on whether Cloud SIEM selected the log for analysis. (Datadog<\/a>)<\/p>\n\n\n\n
Use this query in Logs Explorer:<\/p>\n\n\n
datadog<\/span>.cloud_siem<\/span>:true<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
To check logs not analyzed:<\/p>\n\n\n
datadog<\/span>.cloud_siem<\/span>:false<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
6. Datadog Cloud SIEM Use Cases<\/h1>\n\n\n\n
6.1 Cloud Threat Detection<\/h2>\n\n\n\n
Detect suspicious cloud activity:<\/p>\n\n\n\n
Cloud Threat<\/th>Example<\/th><\/tr><\/thead>
IAM abuse<\/td>New access key created<\/td><\/tr>
Privilege escalation<\/td>Admin policy attached<\/td><\/tr>
Defense evasion<\/td>CloudTrail disabled<\/td><\/tr>
Persistence<\/td>New user created<\/td><\/tr>
Data exfiltration<\/td>S3 bucket data accessed unexpectedly<\/td><\/tr>
Reconnaissance<\/td>ScoutSuite or unusual API enumeration<\/td><\/tr>
Insecure config change<\/td>Security group opened to world<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6.2 Kubernetes Security Monitoring<\/h2>\n\n\n\n
Detect Kubernetes threats:<\/p>\n\n\n\n
Kubernetes Threat<\/th>Example<\/th><\/tr><\/thead>
Suspicious exec<\/td>kubectl exec<\/code> into sensitive pod<\/td><\/tr>
Privilege escalation<\/td>Privileged pod created<\/td><\/tr>
Secret access<\/td>Kubernetes Secret read by unusual identity<\/td><\/tr>
Admission bypass<\/td>Risky admission controller change<\/td><\/tr>
Lateral movement<\/td>Service account token used unexpectedly<\/td><\/tr>
Namespace abuse<\/td>New cluster role binding created<\/td><\/tr>
Container escape indicators<\/td>Runtime events from workload protection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6.3 Identity and Access Monitoring<\/h2>\n\n\n\n
Detect identity risks:<\/p>\n\n\n\n
Identity Source<\/th>Use Case<\/th><\/tr><\/thead>
Okta\/Auth0<\/td>MFA disabled, impossible travel, admin role change<\/td><\/tr>
Google Workspace<\/td>Suspicious login, new OAuth app<\/td><\/tr>
Azure AD<\/td>Privileged role assignment<\/td><\/tr>
Duo<\/td>MFA bypass or unusual authentication<\/td><\/tr>
GitHub<\/td>Org owner added, secret pushed, repo visibility changed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6.4 Developer Tool Security<\/h2>\n\n\n\n
Modern attacks often target CI\/CD and developer tools.<\/p>\n\n\n\n
Monitor:<\/p>\n\n\n\n
Tool<\/th>Use Case<\/th><\/tr><\/thead>
GitHub<\/td>Repo visibility changes, deploy key added, secret scanning alert<\/td><\/tr>
GitLab<\/td>Runner token abuse, admin change<\/td><\/tr>
Terraform Cloud<\/td>Workspace variable changed, run triggered by unknown user<\/td><\/tr>
Confluent Cloud<\/td>API key created, ACL changed<\/td><\/tr>
Jira\/Confluence<\/td>Admin permission or page access abuse<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6.5 Endpoint and OS Security<\/h2>\n\n\n\n
Monitor:<\/p>\n\n\n\n
Source<\/th>Use Case<\/th><\/tr><\/thead>
Linux audit logs<\/td>Sudo, SSH, user creation, file changes<\/td><\/tr>
Windows Event Logs<\/td>Logon events, PowerShell, account changes<\/td><\/tr>
Sysmon<\/td>Process creation, network connection, suspicious parent-child process<\/td><\/tr>
EDR<\/td>Malware alerts, suspicious process, blocked threat<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
6.6 Network Security<\/h2>\n\n\n\n
Monitor:<\/p>\n\n\n\n
Source<\/th>Use Case<\/th><\/tr><\/thead>
DNS<\/td>Domain generation algorithm, suspicious lookup<\/td><\/tr>
Firewall<\/td>Denied traffic, risky country, threat IP<\/td><\/tr>
WAF<\/td>SQLi\/XSS attempts<\/td><\/tr>
VPN<\/td>Impossible travel, unusual country<\/td><\/tr>
Proxy<\/td>Malware download, blocked destination<\/td><\/tr>
Zeek\/Suricata<\/td>Network IDS events<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
7. End-to-End Implementation Roadmap<\/h1>\n\n\n
flowchart<\/span> TD<\/span>\n    A<\/span>[Step 1: Define Security Goals]<\/span> --<\/span>> B<\/span>[Step 2: Identify Log Sources]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Step 3: Enable Datadog Cloud SIEM]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Step 4: Enable Content Packs]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Step 5: Ingest Logs]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Step 6: Parse and Normalize]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Step 7: Validate Security Filters]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Step 8: Enable OOTB Rules]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Step 9: Create Custom Rules]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Step 10: Triage Signals]<\/span>\n    J<\/span> --<\/span>> K<\/span>[Step 11: Configure Notifications]<\/span>\n    K<\/span> --<\/span>> L<\/span>[Step 12: Automate Response]<\/span>\n    L<\/span> --<\/span>> M<\/span>[Step 13: Measure and Improve]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
8. Prerequisites<\/h1>\n\n\n\n
Before starting, prepare:<\/p>\n\n\n\n
Requirement<\/th>Why Needed<\/th><\/tr><\/thead>
Datadog account<\/td>Cloud SIEM runs inside Datadog<\/td><\/tr>
Cloud SIEM enabled<\/td>Required for SIEM analysis<\/td><\/tr>
Log Management<\/td>SIEM uses logs as primary input<\/td><\/tr>
API key<\/td>For log ingestion<\/td><\/tr>
Application key<\/td>For API\/Terraform operations<\/td><\/tr>
Admin or Security permissions<\/td>Needed to configure SIEM<\/td><\/tr>
Cloud accounts<\/td>AWS\/Azure\/GCP logs<\/td><\/tr>
GitHub access<\/td>For lab projects<\/td><\/tr>
Terraform<\/td>Optional, for IaC<\/td><\/tr>
Datadog Agent<\/td>For host\/Kubernetes logs<\/td><\/tr>
Datadog Forwarder<\/td>For AWS log forwarding<\/td><\/tr>
Test environment<\/td>Never start threat emulation directly in production<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
9. Data Source Strategy<\/h1>\n\n\n\n
A world-class SIEM project should not ingest random logs blindly. Start with high-value security logs.<\/p>\n\n\n\n
Phase 1: Must-have logs<\/h2>\n\n\n\n
Priority<\/th>Source<\/th>Why<\/th><\/tr><\/thead>
P0<\/td>Cloud audit logs<\/td>Cloud attacks show up here first<\/td><\/tr>
P0<\/td>Identity provider logs<\/td>Identity is the new perimeter<\/td><\/tr>
P0<\/td>Kubernetes audit logs<\/td>Needed for container platform security<\/td><\/tr>
P0<\/td>Datadog Audit Trail<\/td>Monitor Datadog account changes<\/td><\/tr>
P1<\/td>GitHub\/GitLab logs<\/td>CI\/CD and code security<\/td><\/tr>
P1<\/td>Linux\/Windows auth logs<\/td>Host-level access monitoring<\/td><\/tr>
P1<\/td>Firewall\/DNS\/proxy logs<\/td>Network threat detection<\/td><\/tr>
P1<\/td>WAF\/AppSec logs<\/td>Application attack detection<\/td><\/tr>
P2<\/td>EDR\/security tool alerts<\/td>Correlation with cloud and app behavior<\/td><\/tr>
P2<\/td>SaaS audit logs<\/td>Collaboration\/data access monitoring<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
10. Datadog SIEM Data Flow by Source<\/h1>\n\n\n\n
Source<\/th>Collection Method<\/th>Datadog Component<\/th><\/tr><\/thead>
AWS CloudTrail<\/td>S3 + Datadog Forwarder Lambda \/ AWS integration<\/td>Cloud SIEM Content Pack<\/td><\/tr>
GCP Audit Logs<\/td>Pub\/Sub + Dataflow Datadog template<\/td>Cloud SIEM Content Pack<\/td><\/tr>
Azure Platform Logs<\/td>Azure Event Hub \/ Datadog integration<\/td>Cloud SIEM Content Pack<\/td><\/tr>
Kubernetes Audit Logs<\/td>Control plane audit log export<\/td>Cloud SIEM Content Pack<\/td><\/tr>
Linux logs<\/td>Datadog Agent log collection<\/td>Log pipelines + Cloud SIEM<\/td><\/tr>
Windows logs<\/td>Datadog Agent \/ Windows Event Logs<\/td>Log pipelines + Cloud SIEM<\/td><\/tr>
GitHub audit logs<\/td>GitHub integration<\/td>Content Pack<\/td><\/tr>
Okta\/Auth0<\/td>SaaS integration\/API<\/td>Content Pack<\/td><\/tr>
NGINX\/Apache<\/td>Agent log collection<\/td>Web security Content Pack<\/td><\/tr>
Network devices<\/td>Syslog \/ Agent \/ Observability Pipelines<\/td>Network Content Pack<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
11. Step-by-Step: Enable Cloud SIEM<\/h1>\n\n\n\n
Step 1: Enable Cloud SIEM<\/h2>\n\n\n\n
In Datadog:<\/p>\n\n\n
Security \u2192 Cloud SIEM\n<\/code><\/span><\/pre>\n\n\n
Enable Cloud SIEM for your organization.<\/p>\n\n\n\n
Step 2: Choose Content Packs<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Ingest and Enrich \u2192 Content Packs\n<\/code><\/span><\/pre>\n\n\n
Start with:<\/p>\n\n\n
AWS CloudTrail\nDatadog Audit Trail\nKubernetes Audit Logs\nGitHub\nOkta\/Auth0\nWindows Event Logs\nLinux Audit Logs\nNGINX\/Apache\n<\/code><\/span><\/pre>\n\n\n
Cloud SIEM Content Packs are the easiest way to send security data to Datadog because they are designed specifically for SIEM onboarding. (Datadog<\/a>)<\/p>\n\n\n\n
Step 3: Validate Logs Are Ingested<\/h2>\n\n\n\n
Go to Logs Explorer and search:<\/p>\n\n\n
source<\/span>:cloudtrail<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
or:<\/p>\n\n\n
source<\/span>:github<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
or:<\/p>\n\n\n
source<\/span>:kubernetes.audit<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 4: Confirm Logs Are Analyzed by Cloud SIEM<\/h2>\n\n\n\n
Search:<\/p>\n\n\n
source<\/span>:cloudtrail<\/span> datadog<\/span>.cloud_siem<\/span>:true<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
If logs show:<\/p>\n\n\n
datadog<\/span>.cloud_siem<\/span>:false<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
then Cloud SIEM is ingesting the log into Datadog, but not analyzing it for SIEM.<\/p>\n\n\n\n
Step 5: Check Detection Rules<\/h2>\n\n\n\n
Go to:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Detection Rules\n<\/code><\/span><\/pre>\n\n\n
Confirm OOTB rules are enabled.<\/p>\n\n\n\n
Cloud SIEM applies OOTB detection rules after Content Packs are enabled and configured. (Datadog<\/a>)<\/p>\n\n\n\n
\n\n\n\n
12. AWS CloudTrail SIEM Tutorial<\/h1>\n\n\n\n
AWS CloudTrail is one of the best first SIEM projects because it detects identity, cloud control-plane, and privilege escalation attacks.<\/p>\n\n\n\n
Datadog\u2019s AWS Cloud SIEM guide explains that Cloud SIEM applies detection rules to processed logs and surfaces threats as Security Signals in Signals Explorer. (Datadog<\/a>)<\/p>\n\n\n\n
Architecture<\/h2>\n\n\n
flowchart<\/span> LR<\/span>\n    A<\/span>[AWS CloudTrail]<\/span> --<\/span>> B<\/span>[S3 Bucket]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Datadog Forwarder Lambda]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Datadog Logs Intake]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Cloud SIEM AWS CloudTrail Content Pack]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Detection Rules]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Security Signals]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Step-by-step<\/h2>\n\n\n\n
Step 1: Enable CloudTrail<\/h3>\n\n\n\n
In AWS:<\/p>\n\n\n
CloudTrail \u2192 Trails \u2192 Create trail\n<\/code><\/span><\/pre>\n\n\n
Recommended:<\/p>\n\n\n
Management events: Read + Write\nData events: S3, Lambda, important services\nMulti-region trail: Enabled\nLog file validation: Enabled\nSend to S3: Enabled\n<\/code><\/span><\/pre>\n\n\n
Step 2: Send CloudTrail logs to Datadog<\/h3>\n\n\n\n
Common architecture:<\/p>\n\n\n
CloudTrail \u2192 S3 \u2192 Datadog Forwarder Lambda \u2192 Datadog\n<\/code><\/span><\/pre>\n\n\n
Datadog\u2019s AWS SIEM setup notes that AWS service logs are collected with a Datadog Lambda function that triggers on S3 buckets and forwards logs to Datadog. (Datadog<\/a>)<\/p>\n\n\n\n
Step 3: Enable AWS CloudTrail Content Pack<\/h3>\n\n\n\n
Enable:<\/p>\n\n\n
AWS CloudTrail Content Pack\n<\/code><\/span><\/pre>\n\n\n
It provides detection rules, dashboards, investigator workflows, and configuration guidance.<\/p>\n\n\n\n
Step 4: Validate ingestion<\/h3>\n\n\n\n
In Logs Explorer:<\/p>\n\n\n
source<\/span>:cloudtrail<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Useful fields:<\/p>\n\n\n
@eventName<\/span>\n@eventSource\n@userIdentity.arn\n@userIdentity.type\n@awsRegion\n@sourceIPAddress\n@userAgent\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 5: Validate SIEM analysis<\/h3>\n\n\n
source<\/span>:cloudtrail<\/span> datadog<\/span>.cloud_siem<\/span>:true<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 6: Watch for signals<\/h3>\n\n\n\n
Go to:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Signals\n<\/code><\/span><\/pre>\n\n\n
Filter:<\/p>\n\n\n
source<\/span>:cloudtrail<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
13. AWS Threat Emulation Project Using GitHub<\/h1>\n\n\n\n
Project: Datadog AWS Cloud SIEM Threat Emulation<\/h2>\n\n\n\n
Datadog has an official GitHub project called cloud-siem-aws-threat-emulation<\/strong>. It uses Stratus Red Team-style AWS attack simulation to validate Datadog Cloud SIEM detections. The project README says to validate generated signals in Datadog by filtering Cloud SIEM Signals with CloudTrail source and Stratus Red Team user agent. (GitHub<\/a>)<\/p>\n\n\n\n
What you learn<\/h2>\n\n\n\n
Topic<\/th>Skill<\/th><\/tr><\/thead>
CloudTrail ingestion<\/td>Confirm AWS logs reach Datadog<\/td><\/tr>
OOTB rules<\/td>Validate Datadog default rules<\/td><\/tr>
Threat emulation<\/td>Simulate safe attack techniques<\/td><\/tr>
Signal triage<\/td>Investigate generated alerts<\/td><\/tr>
Cleanup<\/td>Remove created attack artifacts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Lab steps<\/h2>\n\n\n\n
Step 1: Prepare isolated AWS account<\/h3>\n\n\n\n
Use a sandbox AWS account. Do not<\/strong> run threat emulation in production.<\/p>\n\n\n\n
Step 2: Configure CloudTrail to Datadog<\/h3>\n\n\n\n
Confirm:<\/p>\n\n\n
source<\/span>:cloudtrail<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 3: Clone the GitHub project<\/h3>\n\n\n
git clone<\/span> https:\/\/github.com\/DataDog\/cloud-siem-aws-threat-emulation.git<\/span>\ncd cloud-siem-aws-threat-emulation\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 4: Follow project setup<\/h3>\n\n\n\n
Install the required tooling as documented by the repo.<\/p>\n\n\n\n
Step 5: Run a safe emulation<\/h3>\n\n\n\n
Example types of activities usually include:<\/p>\n\n\n
IAM enumeration\nAccess key activity\nCloudTrail tampering scenario\nS3 public<\/span> exposure scenario\nPrivilege escalation style activity\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 6: Validate in Datadog<\/h3>\n\n\n\n
Go to:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Signals\n<\/code><\/span><\/pre>\n\n\n
Search:<\/p>\n\n\n
source:cloudtrail @http.useragent:*stratus-red-team*\n<\/code><\/span><\/pre>\n\n\n
Step 7: Investigate signal<\/h3>\n\n\n\n
For each signal, inspect:<\/p>\n\n\n
What happened?\nWhich user?\nWhich source IP?\nWhich AWS account?\nWhich region?\nWhich API call?\nWas this<\/span> expected?\nWhat happened before and after?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 8: Cleanup<\/h3>\n\n\n\n
Run cleanup commands from the project documentation.<\/p>\n\n\n\n
\n\n\n\n
14. GCP Audit Logs SIEM Tutorial<\/h1>\n\n\n\n
Datadog\u2019s GCP Cloud SIEM guide states that Cloud SIEM applies detection rules to processed logs, including Google Cloud audit logs, and uses Google Cloud Dataflow with the Datadog template to forward logs from Google Cloud services to Datadog. (Datadog<\/a>)<\/p>\n\n\n\n
Architecture<\/h2>\n\n\n
flowchart<\/span> LR<\/span>\n    A<\/span>[GCP Audit Logs]<\/span> --<\/span>> B<\/span>[Log Sink]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Pub\/Sub Topic]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Dataflow Datadog Template]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Datadog Logs Intake]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Cloud SIEM]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Security Signals]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Steps<\/h2>\n\n\n\n
Step 1: Enable Data Access audit logs<\/h3>\n\n\n\n
Enable:<\/p>\n\n\n
Admin Read\nData Read\nData Write\n<\/code><\/span><\/pre>\n\n\n
Datadog\u2019s GCP guide specifically recommends enabling these Data Access audit log types. (Datadog<\/a>)<\/p>\n\n\n\n
Step 2: Create Pub\/Sub topic and subscription<\/h3>\n\n\n\n
Example:<\/p>\n\n\n
export<\/span>-audit-logs-to-datadog\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 3: Create log sink<\/h3>\n\n\n\n
Filter:<\/p>\n\n\n
logName:\"cloudaudit.googleapis.com\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 4: Create Dataflow worker service account<\/h3>\n\n\n\n
Grant required permissions.<\/p>\n\n\n\n
Step 6: Validate<\/h3>\n\n\n\n
Logs Explorer:<\/p>\n\n\n
source<\/span>:gcp<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Cloud SIEM:<\/p>\n\n\n
source<\/span>:gcp<\/span> datadog<\/span>.cloud_siem<\/span>:true<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Signals:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Signals\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
15. Azure SIEM Tutorial<\/h1>\n\n\n\n
Datadog\u2019s Azure Cloud SIEM guide says Cloud SIEM applies detection rules to processed Azure logs and surfaces detected threats as Security Signals in Signals Explorer. (Datadog<\/a>)<\/p>\n\n\n\n
Architecture<\/h2>\n\n\n
flowchart<\/span> LR<\/span>\n    A<\/span>[Azure Activity Logs]<\/span> --<\/span>> B<\/span>[Event Hub]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Datadog Azure Integration \/ Forwarder]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Datadog Logs]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Cloud SIEM]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Signals]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Recommended Azure logs<\/h2>\n\n\n
Azure Activity Logs\nAzure AD \/ Entra ID sign-in logs\nAzure AD audit logs\nKey Vault audit logs\nStorage account access logs\nNetwork security group flow logs\nDefender for Cloud alerts\nAKS audit logs\n<\/code><\/span><\/pre>\n\n\n
Example detections<\/h2>\n\n\n\n
Detection<\/th>Why Important<\/th><\/tr><\/thead>
Privileged role assigned<\/td>Possible privilege escalation<\/td><\/tr>
New service principal credential<\/td>Possible persistence<\/td><\/tr>
Key Vault secret read<\/td>Credential access<\/td><\/tr>
Security rule opened to internet<\/td>Exposure<\/td><\/tr>
Azure policy disabled<\/td>Defense evasion<\/td><\/tr>
Impossible travel<\/td>Account compromise<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
16. Kubernetes Audit Logs SIEM Tutorial<\/h1>\n\n\n\n
Why Kubernetes audit logs matter<\/h2>\n\n\n\n
Kubernetes audit logs show API server activity:<\/p>\n\n\n
create pod\nexec into pod\nread secret\ncreate clusterrolebinding\ndelete<\/span> deployment\npatch daemonset\ncreate privileged workload\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Recommended events to monitor<\/h2>\n\n\n\n
Event<\/th>Why<\/th><\/tr><\/thead>
create pods\/exec<\/code><\/td>Interactive shell into container<\/td><\/tr>
get secrets<\/code><\/td>Credential access<\/td><\/tr>
create clusterrolebinding<\/code><\/td>Privilege escalation<\/td><\/tr>
create privileged pod<\/code><\/td>Container escape risk<\/td><\/tr>
patch daemonset<\/code><\/td>Persistence<\/td><\/tr>
delete audit policy<\/code><\/td>Defense evasion<\/td><\/tr>
create serviceaccount token<\/code><\/td>Credential abuse<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example Datadog query<\/h2>\n\n\n
source:kubernetes.audit @verb:create @objectRef.resource:pods\n<\/code><\/span><\/pre>\n\n\n
Suspicious exec:<\/p>\n\n\n
source:kubernetes.audit @objectRef.subresource:exec\n<\/code><\/span><\/pre>\n\n\n
Secret access:<\/p>\n\n\n
source:kubernetes.audit @objectRef.resource:secrets\n<\/code><\/span><\/pre>\n\n\n
Privileged RBAC change:<\/p>\n\n\n
source:kubernetes.audit @objectRef.resource:(clusterrolebindings OR rolebindings)\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
17. Linux Audit Logs SIEM Tutorial<\/h1>\n\n\n\n
Useful Linux security logs<\/h2>\n\n\n\n
Log<\/th>Purpose<\/th><\/tr><\/thead>
\/var\/log\/auth.log<\/code><\/td>SSH, sudo, authentication<\/td><\/tr>
\/var\/log\/secure<\/code><\/td>RHEL\/CentOS auth events<\/td><\/tr>
auditd logs<\/td>Syscall and file access auditing<\/td><\/tr>
syslog<\/td>General system security events<\/td><\/tr>
sudo logs<\/td>Privilege escalation<\/td><\/tr>
SSH logs<\/td>Remote login attempts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Datadog Agent log collection example<\/h2>\n\n\n
logs:\n  - type: file\n    path<\/span>: \/var\/<\/span>log\/auth.log\n    service<\/span>: linux-auth\n    source<\/span>: auth\n    tags<\/span>:\n      - env:lab\n      - team:security\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Restart Agent:<\/p>\n\n\n
sudo systemctl restart datadog-agent\n<\/code><\/span><\/pre>\n\n\n
Validate:<\/p>\n\n\n
sudo datadog-agent status\nsudo datadog-agent stream-logs\n<\/code><\/span><\/pre>\n\n\n
Datadog query:<\/p>\n\n\n
source<\/span>:auth<\/span> service<\/span>:linux-auth<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Example custom rule: SSH brute force<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:auth \"Failed password\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Group by:<\/p>\n\n\n
host<\/span>\n@network<\/span>.client.ip\n@usr.name\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Condition:<\/p>\n\n\n
More than 10 events in 5 minutes\n<\/code><\/span><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Medium\n<\/code><\/span><\/pre>\n\n\n
Message:<\/p>\n\n\n
Possible SSH brute force attempt from<\/span> {{@network.client.ip}} against {{host.name}}.\nInvestigate successful logins from<\/span> this<\/span> IP and check whether the username was valid.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
18. Windows Event Logs SIEM Tutorial<\/h1>\n\n\n\n
Important Windows Event IDs<\/h2>\n\n\n\n
Event ID<\/th>Meaning<\/th><\/tr><\/thead>
4624<\/td>Successful logon<\/td><\/tr>
4625<\/td>Failed logon<\/td><\/tr>
4634<\/td>Logoff<\/td><\/tr>
4672<\/td>Special privileges assigned<\/td><\/tr>
4688<\/td>Process creation<\/td><\/tr>
4720<\/td>User account created<\/td><\/tr>
4728<\/td>User added to privileged group<\/td><\/tr>
4732<\/td>User added to local group<\/td><\/tr>
4740<\/td>Account locked out<\/td><\/tr>
4768<\/td>Kerberos authentication ticket requested<\/td><\/tr>
4769<\/td>Kerberos service ticket requested<\/td><\/tr>
1102<\/td>Audit log cleared<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example detection: Windows audit log cleared<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:windows @evt.id:1102\n<\/code><\/span><\/pre>\n\n\n
Severity:<\/p>\n\n\n
High\n<\/code><\/span><\/pre>\n\n\n
Why:<\/p>\n\n\n
Clearing Windows Security logs is a common defense evasion technique.\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
19. GitHub SIEM Tutorial<\/h1>\n\n\n\n
GitHub audit logs are very important because source control and CI\/CD are frequent attack targets.<\/p>\n\n\n\n
Events to monitor<\/h2>\n\n\n\n
Event<\/th>Risk<\/th><\/tr><\/thead>
Organization owner added<\/td>Privilege escalation<\/td><\/tr>
Repository visibility changed to public<\/td>Data exposure<\/td><\/tr>
Deploy key added<\/td>Persistence<\/td><\/tr>
Secret scanning alert<\/td>Secret leakage<\/td><\/tr>
GitHub Actions workflow modified<\/td>CI\/CD compromise<\/td><\/tr>
PAT created or used suspiciously<\/td>Credential abuse<\/td><\/tr>
Branch protection disabled<\/td>Defense evasion<\/td><\/tr>
Webhook added<\/td>Data exfiltration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example Datadog query<\/h2>\n\n\n
source:github @action:repo.change_visibility\n<\/code><\/span><\/pre>\n\n\n
Example custom rule<\/h2>\n\n\n\n
Name:<\/p>\n\n\n
GitHub Repository Made Public<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Query:<\/p>\n\n\n
source:github @action:repo.change_visibility @visibility:public<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
High\n<\/code><\/span><\/pre>\n\n\n
Message:<\/p>\n\n\n
A GitHub repository was made public. Validate whether this<\/span> was approved.\nCheck repository name, actor, organization, and recent commits for<\/span> sensitive data exposure.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
20. Okta\/Auth0 Identity SIEM Tutorial<\/h1>\n\n\n\n
Events to monitor<\/h2>\n\n\n\n
Event<\/th>Risk<\/th><\/tr><\/thead>
MFA disabled<\/td>Account weakening<\/td><\/tr>
Admin role assigned<\/td>Privilege escalation<\/td><\/tr>
Impossible travel<\/td>Account compromise<\/td><\/tr>
New device<\/td>Suspicious login<\/td><\/tr>
Repeated failed logins<\/td>Brute force<\/td><\/tr>
Password reset<\/td>Account recovery abuse<\/td><\/tr>
New API token<\/td>Persistence<\/td><\/tr>
Suspicious OAuth app<\/td>Consent phishing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example rule: MFA disabled<\/h2>\n\n\n
source:okta @eventType:user.mfa.factor.deactivate\n<\/code><\/span><\/pre>\n\n\n
Severity:<\/p>\n\n\n
High\n<\/code><\/span><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@usr<\/span>.id\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
21. Detection Engineering in Datadog SIEM<\/h1>\n\n\n\n
21.1 Good detection rule design<\/h2>\n\n\n\n
A good rule should have:<\/p>\n\n\n\n
Component<\/th>Example<\/th><\/tr><\/thead>
Clear title<\/td>AWS CloudTrail Disabled<\/td><\/tr>
Strong query<\/td>Match exact API event<\/td><\/tr>
Severity<\/td>Based on impact<\/td><\/tr>
Group-by<\/td>User\/account\/IP\/resource<\/td><\/tr>
Time window<\/td>5 min, 15 min, 1 hour, etc.<\/td><\/tr>
MITRE mapping<\/td>Defense Evasion, Credential Access<\/td><\/tr>
Message<\/td>What happened and how to respond<\/td><\/tr>
Suppression<\/td>Known automation excluded<\/td><\/tr>
Owner<\/td>Security\/platform team<\/td><\/tr>
Runbook<\/td>Investigation steps<\/td><\/tr>
Test method<\/td>Historical job or threat emulation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
21.2 Rule quality checklist<\/h2>\n\n\n\n
Before enabling a rule in production:<\/p>\n\n\n
Does the rule detect real attacker behavior?\nDoes it generate too many false<\/span> positives?\nCan an analyst understand the signal?\nDoes the signal include<\/span> user\/IP\/resource?\nIs there a runbook?\nIs severity correct?\nIs there an owner?\nIs there a safe suppression strategy?\nCan we test it?\nCan we backtest it?\nCan it be managed as<\/span> code?\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
22. Example Custom Rules<\/h1>\n\n\n\n
Rule 1: AWS CloudTrail Disabled<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:cloudtrail @eventName:StopLogging\n<\/code><\/span><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@userIdentity<\/span>.arn\n@awsRegion\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Critical\n<\/code><\/span><\/pre>\n\n\n
Message:<\/p>\n\n\n
CloudTrail logging was stopped by {{@userIdentity.arn}} in<\/span> {{@awsRegion}}.\nThis may indicate defense evasion. Confirm whether this<\/span> was an approved change.\nCheck recent IAM activity, source IP, user agent, and other API calls from<\/span> the same identity.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
Rule 2: IAM Access Key Created<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:cloudtrail @eventName:CreateAccessKey\n<\/code><\/span><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@userIdentity<\/span>.arn\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Medium\n<\/code><\/span><\/pre>\n\n\n
Upgrade to High if:<\/p>\n\n\n
The actor is new<\/span>\nThe source IP is unusual\nThe user is privileged\nThe key belongs to another user\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
Rule 3: S3 Bucket Policy Changed<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:cloudtrail @eventName:(PutBucketPolicy OR PutBucketAcl OR PutPublicAccessBlock)\n<\/code><\/span><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@requestParameters<\/span>.bucketName\n@userIdentity.arn\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
High\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Rule 4: Kubernetes Secret Access<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:kubernetes.audit @objectRef.resource:secrets @verb:get<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@user<\/span>.username\n@objectRef.namespace\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Medium\n<\/code><\/span><\/pre>\n\n\n
Escalate if:<\/p>\n\n\n
namespace<\/span>:prod<\/span>\nunusual<\/span> user<\/span>\nserviceaccount<\/span> outside<\/span> namespace<\/span>\nhigh<\/span> frequency<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
Rule 5: GitHub Branch Protection Disabled<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:github @action:protected_branch.destroy\n<\/code><\/span><\/pre>\n\n\n
Severity:<\/p>\n\n\n
High\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Rule 6: Windows Audit Log Cleared<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:windows @evt.id:1102\n<\/code><\/span><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Critical\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Rule 7: NGINX Possible SQL Injection<\/h2>\n\n\n\n
Query:<\/p>\n\n\n
source:nginx @http.url_details.queryString:(\"*union select*\"<\/span> OR \"*sleep(*\"<\/span> OR \"*information_schema*\"<\/span>)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Severity:<\/p>\n\n\n
Medium\n<\/code><\/span><\/pre>\n\n\n
Note: This should be tuned carefully to avoid false positives.<\/p>\n\n\n\n
\n\n\n\n
23. Creating a Custom Rule in Datadog UI<\/h1>\n\n\n\n
Go to:<\/p>\n\n\n
Security \u2192 Cloud SIEM \u2192 Detection Rules \u2192 New<\/span> Rule\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Choose:<\/p>\n\n\n
Real-Time Rule\n<\/code><\/span><\/pre>\n\n\n
Select method:<\/p>\n\n\n
Threshold\n<\/code><\/span><\/pre>\n\n\n
Define query:<\/p>\n\n\n
source:cloudtrail @eventName:StopLogging\n<\/code><\/span><\/pre>\n\n\n
Set condition:<\/p>\n\n\n
count > 0 over 5 minutes\n<\/code><\/span><\/pre>\n\n\n
Group by:<\/p>\n\n\n
@userIdentity<\/span>.arn\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Add message:<\/p>\n\n\n
CloudTrail logging stopped by {{@userIdentity.arn}}.\nInvestigate immediately.\n<\/code><\/span><\/pre>\n\n\n
Set severity:<\/p>\n\n\n
Critical\n<\/code><\/span><\/pre>\n\n\n
Add tags:<\/p>\n\n\n
team<\/span>:security<\/span>\nsource<\/span>:aws<\/span>\nmitre<\/span>:defense-evasion<\/span>\nenv<\/span>:prod<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Save rule.<\/p>\n\n\n\n
\n\n\n\n
24. Signal Investigation Workflow<\/h1>\n\n\n\n
Datadog Cloud SIEM Signals Explorer allows teams to view, search, filter, correlate, and assign signals without learning a dedicated query language. (Datadog<\/a>)<\/p>\n\n\n\n
Investigation flow<\/h2>\n\n\n
flowchart<\/span> TD<\/span>\n    A<\/span>[Signal Created]<\/span> --<\/span>> B<\/span>[Read What Happened]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Identify User \/ IP \/ Resource]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Check Triggering Logs]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Check Same User Timeline]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Check Same IP Timeline]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Check Related Cloud \/ App \/ K8s Logs]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Classify True Positive or False Positive]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Contain \/ Remediate]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Update Rule \/ Suppression \/ Runbook]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Standard triage questions<\/h2>\n\n\n
Who performed the action?\nWas the identity human or service account?\nWas MFA used?\nWas the source IP expected?\nWas the user-agent expected?\nWhat resource was affected?\nWas this<\/span> in<\/span> production?\nWas this<\/span> change approved?\nDid similar activity happen before?\nDid the same identity perform other suspicious actions?\nIs there related app, Kubernetes, network, or endpoint activity?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
25. MITRE ATT&CK Mapping<\/h1>\n\n\n\n
A strong SIEM program should map detections to MITRE ATT&CK.<\/p>\n\n\n\n
MITRE Tactic<\/th>Datadog SIEM Example<\/th><\/tr><\/thead>
Initial Access<\/td>Suspicious login from threat IP<\/td><\/tr>
Execution<\/td>Kubernetes exec into pod<\/td><\/tr>
Persistence<\/td>New IAM access key created<\/td><\/tr>
Privilege Escalation<\/td>Admin role attached<\/td><\/tr>
Defense Evasion<\/td>CloudTrail stopped<\/td><\/tr>
Credential Access<\/td>Secret read from SSM\/Secrets Manager<\/td><\/tr>
Discovery<\/td>Cloud API enumeration<\/td><\/tr>
Lateral Movement<\/td>Unusual service account activity<\/td><\/tr>
Collection<\/td>S3 object read spike<\/td><\/tr>
Exfiltration<\/td>BigQuery export to external bucket<\/td><\/tr>
Impact<\/td>Resource deletion or ransomware-like behavior<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
26. Risk Scoring and Entity Investigation<\/h1>\n\n\n\n
Datadog calculates entity risk scores based on associated signals, including signal severity and how many times a signal fired over the past 14 days. (Datadog<\/a>)<\/p>\n\n\n\n
Use risk scoring to answer:<\/p>\n\n\n
Which user is riskiest?\nWhich host has repeated suspicious behavior?\nWhich cloud account has the highest risk?\nWhich service account needs review?\nWhich IP appears in multiple signals?\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
27. Notifications and Alert Routing<\/h1>\n\n\n\n
Signals are only useful if they reach the right team.<\/p>\n\n\n\n
Common routing:<\/p>\n\n\n\n
Signal Type<\/th>Notify<\/th><\/tr><\/thead>
Critical cloud control-plane attack<\/td>Security on-call + cloud platform team<\/td><\/tr>
Kubernetes privilege escalation<\/td>Platform SRE + security<\/td><\/tr>
GitHub organization change<\/td>DevSecOps + repo owner<\/td><\/tr>
Okta admin change<\/td>IAM team + security<\/td><\/tr>
WAF attack spike<\/td>AppSec + application owner<\/td><\/tr>
Windows log cleared<\/td>SOC + endpoint team<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Datadog allows Notification Rules to route signals to individuals or teams, and signal modification requires Security Signals Write permission. (Datadog<\/a>)<\/p>\n\n\n\n
\n\n\n\n
28. SOAR and Response Automation<\/h1>\n\n\n\n
SOAR means Security Orchestration, Automation, and Response<\/strong>.<\/p>\n\n\n\n
Datadog Cloud SIEM can work with Workflow Automation. Content Packs may include workflow automation to accelerate investigation and remediation. (Datadog<\/a>)<\/p>\n\n\n\n
Example automation ideas<\/h2>\n\n\n\n
Signal<\/th>Automated Action<\/th><\/tr><\/thead>
IAM access key created by unusual user<\/td>Create Jira ticket, notify Slack, enrich user details<\/td><\/tr>
GitHub repo made public<\/td>Notify repo owner, open incident, collect repo metadata<\/td><\/tr>
Okta MFA disabled<\/td>Notify IAM, ask for approval evidence<\/td><\/tr>
Threat IP seen in firewall logs<\/td>Query related logs, enrich IP, notify SOC<\/td><\/tr>
Kubernetes secret accessed<\/td>Notify platform team, collect namespace\/pod\/service account details<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Do not automatically delete users, revoke production credentials, or block IPs without a clear approval process unless your organization has mature playbooks.<\/p>\n\n\n\n
\n\n\n\n
29. Datadog SIEM with Terraform<\/h1>\n\n\n\n
Terraform is useful for managing Datadog configuration as code. The official Datadog Terraform provider is used to interact with Datadog resources and requires proper credentials. (GitHub<\/a>)<\/p>\n\n\n\n
Useful Terraform-managed SIEM resources<\/h2>\n\n\n\n
Resource Type<\/th>Use<\/th><\/tr><\/thead>
Detection rules<\/td>Manage custom SIEM rules as code<\/td><\/tr>
Monitors<\/td>Alert on ingestion gaps or SIEM health<\/td><\/tr>
Dashboards<\/td>Security dashboards<\/td><\/tr>
Log pipelines<\/td>Parsing and normalization<\/td><\/tr>
Log indexes<\/td>Retention and cost control<\/td><\/tr>
Sensitive data scanner<\/td>Redaction controls<\/td><\/tr>
Integrations<\/td>Cloud\/source integrations where supported<\/td><\/tr>
Teams\/roles<\/td>Access governance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Sample Terraform skeleton<\/h2>\n\n\n
terraform {\n  required_providers {\n    datadog = {\n      source  = \"DataDog\/datadog\"<\/span>\n      version = \"~> 3.0\"<\/span>\n    }\n  }\n}\n\nprovider \"datadog\"<\/span> {\n  api_key = var<\/span>.datadog_api_key\n  app_key = var<\/span>.datadog_app_key\n  api_url = var<\/span>.datadog_api_url\n}\n\nvariable \"datadog_api_key\"<\/span> {\n  type      = string\n  sensitive = true<\/span>\n}\n\nvariable \"datadog_app_key\"<\/span> {\n  type      = string\n  sensitive = true<\/span>\n}\n\nvariable \"datadog_api_url\"<\/span> {\n  type    = string\n  default<\/span> = \"https:\/\/api.datadoghq.com\/\"<\/span>\n}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Official GitHub project: Terraform security modules<\/h2>\n\n\n\n
Datadog has an official GitHub repository named terraform-modules-datadog-security<\/strong>, which contains Terraform modules for common integrations between Datadog security products and cloud providers. (GitHub<\/a>)<\/p>\n\n\n\n
Use this repository as a reference for cloud security onboarding patterns.<\/p>\n\n\n\n
\n\n\n\n
30. Sigma to Datadog Rules<\/h1>\n\n\n\n
Sigma is a generic detection rule format used by detection engineers.<\/p>\n\n\n\n
Datadog has an official pysigma-backend-datadog<\/strong> GitHub project. It supports output formats for Datadog query syntax and can convert Sigma rules into Datadog Cloud SIEM detection format. (GitHub<\/a>)<\/p>\n\n\n\n
Use case<\/h2>\n\n\n\n
You have Sigma rule:<\/p>\n\n\n
title: Suspicious PowerShell Encoded Command\nlogsource<\/span>:\n  product: windows\n  category<\/span>: process_creation\ndetection<\/span>:\n  selection:\n    CommandLine|contains: \"-enc\"<\/span>\n  condition<\/span>: selection\nlevel<\/span>: high\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
You convert it into Datadog-compatible query\/rule format.<\/p>\n\n\n\n
Why useful<\/h2>\n\n\n\n
Benefit<\/th>Explanation<\/th><\/tr><\/thead>
Detection portability<\/td>Reuse community Sigma detections<\/td><\/tr>
Faster rule creation<\/td>Convert baseline logic<\/td><\/tr>
Standard detection workflow<\/td>Detection-as-code<\/td><\/tr>
Easier migration<\/td>Move from another SIEM to Datadog<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
31. Recommended GitHub Projects for Hands-On Learning<\/h1>\n\n\n\n
Project<\/th>Owner<\/th>Purpose<\/th><\/tr><\/thead>
cloud-siem-aws-threat-emulation<\/td>DataDog<\/td>Validate AWS Cloud SIEM detections using threat emulation<\/td><\/tr>
terraform-provider-datadog<\/td>DataDog<\/td>Manage Datadog resources with Terraform<\/td><\/tr>
terraform-modules-datadog-security<\/td>DataDog<\/td>Security-focused Terraform modules for cloud integrations<\/td><\/tr>
pysigma-backend-datadog<\/td>DataDog<\/td>Convert Sigma detections to Datadog queries\/SIEM rules<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
32. Complete Lab Roadmap<\/h1>\n\n\n\n
Lab 1: Basic SIEM with Linux auth logs<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Collect Linux SSH\/sudo logs and create brute-force detection.\n<\/code><\/span><\/pre>\n\n\n
Skills:<\/p>\n\n\n
Datadog Agent\nLog collection\nLog Explorer\nCustom detection rule\nSecurity signal triage\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 2: AWS CloudTrail SIEM<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Forward CloudTrail logs into Datadog and enable AWS CloudTrail Content Pack.\n<\/code><\/span><\/pre>\n\n\n
Skills:<\/p>\n\n\n
CloudTrail\nS3\nDatadog Forwarder\nContent Packs\nOOTB detections\nSignals Explorer\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 3: AWS Threat Emulation<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Use<\/span> DataDog<\/span>\/cloud<\/span>-siem<\/span>-aws<\/span>-threat<\/span>-emulation<\/span> to<\/span> trigger<\/span> test<\/span> signals<\/span>.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Skills:<\/p>\n\n\n
Threat simulation\nCloudTrail detection validation\nRule testing\nTriage\nCleanup\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 4: Kubernetes Audit Logs<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Detect suspicious Kubernetes API activity.\n<\/code><\/span><\/pre>\n\n\n
Skills:<\/p>\n\n\n
Kubernetes audit policy\nControl plane logs\nKubernetes SIEM detection\nRBAC investigation\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 5: GitHub Audit Logs<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Detect repository visibility changes and privileged user changes.\n<\/code><\/span><\/pre>\n\n\n
Skills:<\/p>\n\n\n
GitHub audit logs\nDeveloper security\nCustom detections\nNotification routing\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 6: Detection-as-Code<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Manage SIEM rules and dashboards with<\/span> Terraform.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Skills:<\/p>\n\n\n
Terraform provider\nRule versioning\nPull request review\nEnvironment promotion\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
Lab 7: Sigma Conversion<\/h2>\n\n\n\n
Goal:<\/p>\n\n\n
Convert Sigma rules into Datadog-compatible query\/rule format.\n<\/code><\/span><\/pre>\n\n\n
Skills:<\/p>\n\n\n
Sigma\npysigma-backend-datadog\nDetection engineering\nRule portability\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
33. Production Reference Architecture<\/h1>\n\n\n
flowchart<\/span> TB<\/span>\n    subgraph<\/span> Cloud<\/span>[\"Cloud Accounts\"<\/span>]<\/span>\n        A1<\/span>[AWS CloudTrail]<\/span>\n        A2<\/span>[GCP Audit Logs]<\/span>\n        A3<\/span>[Azure Activity Logs]<\/span>\n    end<\/span>\n\n    subgraph<\/span> Platform<\/span>[\"Platform\"<\/span>]<\/span>\n        B1<\/span>[Kubernetes Audit Logs]<\/span>\n        B2<\/span>[Datadog Agent]<\/span>\n        B3<\/span>[Workload Protection]<\/span>\n    end<\/span>\n\n    subgraph<\/span> SaaS<\/span>[\"SaaS \/ Identity \/ Dev Tools\"<\/span>]<\/span>\n        C1<\/span>[Okta\/Auth0]<\/span>\n        C2<\/span>[GitHub\/GitLab]<\/span>\n        C3<\/span>[Google Workspace]<\/span>\n    end<\/span>\n\n    subgraph<\/span> Network<\/span>[\"Network \/ Edge\"<\/span>]<\/span>\n        D1<\/span>[Firewall]<\/span>\n        D2<\/span>[DNS]<\/span>\n        D3<\/span>[WAF]<\/span>\n        D4<\/span>[Proxy]<\/span>\n    end<\/span>\n\n    Cloud<\/span> --<\/span>> E<\/span>[Datadog Log Intake]<\/span>\n    Platform<\/span> --<\/span>> E<\/span>\n    SaaS<\/span> --<\/span>> E<\/span>\n    Network<\/span> --<\/span>> E<\/span>\n\n    E<\/span> --<\/span>> F<\/span>[Parsing \/ OCSF \/ Enrichment]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Cloud SIEM Analysis]<\/span>\n    G<\/span> --<\/span>> H<\/span>[OOTB + Custom Rules]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Security Signals]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Signals Explorer \/ Investigators]<\/span>\n    I<\/span> --<\/span>> K<\/span>[Notifications]<\/span>\n    I<\/span> --<\/span>> L<\/span>[Workflow Automation]<\/span>\n    I<\/span> --<\/span>> M<\/span>[Incidents \/ Cases \/ Reports]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
34. Best Practices for Datadog SIEM<\/h1>\n\n\n\n
34.1 Start with high-value logs<\/h2>\n\n\n\n
Do not onboard every log first. Start with:<\/p>\n\n\n
CloudTrail\nGCP Audit Logs\nAzure Activity Logs\nIdentity provider logs\nKubernetes audit logs\nGitHub\/GitLab audit logs\nDatadog Audit Trail\nEndpoint authentication logs\n<\/code><\/span><\/pre>\n\n\n
34.2 Use Content Packs first<\/h2>\n\n\n\n
Content Packs give you faster time to value because they include prebuilt security content.<\/p>\n\n\n\n
34.3 Normalize logs<\/h2>\n\n\n\n
Use OOTB pipelines and OCSF where possible.<\/p>\n\n\n\n
34.4 Tune detections<\/h2>\n\n\n\n
Every production SIEM needs tuning.<\/p>\n\n\n\n
Tune:<\/p>\n\n\n
query\nthreshold\ngroup-by\nseverity\nsuppression\nmessage\nowner\nnotification\nrunbook\n<\/code><\/span><\/pre>\n\n\n
34.5 Avoid over-suppression<\/h2>\n\n\n\n
Suppress only known-good activity. Do not suppress broad categories.<\/p>\n\n\n\n
34.6 Create runbooks<\/h2>\n\n\n\n
Every high\/critical rule should have:<\/p>\n\n\n
What happened?\nWhy it matters\nHow to validate\nHow to contain\nHow to remediate\nWho owns it\nHow to close\n<\/code><\/span><\/pre>\n\n\n
34.7 Measure SIEM quality<\/h2>\n\n\n\n
Track:<\/p>\n\n\n
Signal volume\nFalse<\/span> positive rate\nMean time to triage\nMean time to respond\nCoverage by MITRE tactic\nTop noisy rules\nTop risky users\nTop risky cloud accounts\nUnparsed log volume\nLogs not analyzed by Cloud SIEM\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
34.8 Manage detections as code<\/h2>\n\n\n\n
Use Terraform, GitHub pull requests, peer reviews, and environment promotion.<\/p>\n\n\n\n
34.9 Separate dev\/test\/prod<\/h2>\n\n\n\n
Use tags:<\/p>\n\n\n
env<\/span>:prod<\/span>\nenv<\/span>:stage<\/span>\nteam<\/span>:security<\/span>\nsource<\/span>:cloudtrail<\/span>\ncloud_provider<\/span>:aws<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
34.10 Validate continuously<\/h2>\n\n\n\n
Use:<\/p>\n\n\n
Threat emulation\nHistorical jobs\nTabletop exercises\nPurple team tests\nSynthetic attack logs\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
35. Common Mistakes<\/h1>\n\n\n\n
Mistake<\/th>Impact<\/th><\/tr><\/thead>
Ingesting too many logs without strategy<\/td>Cost and noise<\/td><\/tr>
Not enabling cloud audit logs fully<\/td>Blind spots<\/td><\/tr>
No identity logs<\/td>Cannot detect account compromise<\/td><\/tr>
No Kubernetes audit logs<\/td>Cannot detect cluster abuse<\/td><\/tr>
Ignoring log parsing<\/td>Rules do not work correctly<\/td><\/tr>
No OCSF\/normalization<\/td>Harder correlation<\/td><\/tr>
Too many critical alerts<\/td>Alert fatigue<\/td><\/tr>
No suppressions<\/td>False positives<\/td><\/tr>
Too many suppressions<\/td>Missed attacks<\/td><\/tr>
No runbooks<\/td>Slow response<\/td><\/tr>
No owner\/team mapping<\/td>Nobody acts<\/td><\/tr>
No detection-as-code<\/td>Rule drift<\/td><\/tr>
No testing<\/td>Rules may not work<\/td><\/tr>
No ingestion monitoring<\/td>Silent SIEM failure<\/td><\/tr>
No cost controls<\/td>Unexpected bills<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
36. Datadog SIEM Troubleshooting<\/h1>\n\n\n\n
Problem: No security signals<\/h2>\n\n\n\n
Check:<\/p>\n\n\n
Are logs arriving?\nAre logs parsed?\nAre logs tagged datadog.cloud_siem:true<\/span>?\nAre Content Packs enabled?\nAre OOTB rules enabled?\nDoes the activity actually match a rule?\nAre suppressions hiding signals?\nIs the time window<\/span> correct?\nDo you have permission to view signals?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Problem: Logs visible but not analyzed<\/h2>\n\n\n\n
Search:<\/p>\n\n\n
datadog<\/span>.cloud_siem<\/span>:false<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
Fix:<\/p>\n\n\n
Enable relevant Content Pack\nAdjust Security Filter\nCheck index filter if using Cloud SIEM Standalone\n<\/code><\/span><\/pre>\n\n\n
Datadog notes that Security Filters or log index filters control which logs Cloud SIEM analyzes, depending on the Cloud SIEM product type. (Datadog<\/a>)<\/p>\n\n\n\n
Problem: Too many noisy signals<\/h2>\n\n\n\n
Fix:<\/p>\n\n\n
Add precise suppressions\nTune thresholds\nGroup by user\/IP\/resource\nReduce low-value rules\nLower severity for expected activity\nAdd maintenance exclusions\nCreate separate rule for prod only\n<\/code><\/span><\/pre>\n\n\n
Problem: Rule does not trigger<\/h2>\n\n\n\n
Check:<\/p>\n\n\n
Does the query return<\/span> logs in<\/span> Log Explorer?\nAre fields parsed as<\/span> expected?\nIs the time window<\/span> correct?\nIs the group-by correct?\nIs rule enabled?\nIs source log selected for<\/span> SIEM analysis?\nIs a suppression hiding it?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Problem: Wrong severity<\/h2>\n\n\n\n
Review:<\/p>\n\n\n
Business impact\nAsset criticality\nEnvironment\nUser privilege\nData sensitivity\nAttack stage\nRepeat behavior\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
37. SIEM Governance Model<\/h1>\n\n\n\n
A mature Datadog SIEM implementation should define:<\/p>\n\n\n\n
Area<\/th>Owner<\/th><\/tr><\/thead>
Cloud log onboarding<\/td>Cloud platform team<\/td><\/tr>
SIEM detection rules<\/td>Security engineering<\/td><\/tr>
Kubernetes audit logs<\/td>Platform\/SRE<\/td><\/tr>
Identity logs<\/td>IAM team<\/td><\/tr>
GitHub logs<\/td>DevSecOps<\/td><\/tr>
Log pipelines<\/td>Observability\/platform team<\/td><\/tr>
Incident response<\/td>SOC\/security operations<\/td><\/tr>
Terraform modules<\/td>DevOps\/platform<\/td><\/tr>
Access control<\/td>Security + IAM<\/td><\/tr>
Cost monitoring<\/td>FinOps + platform<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
38. Access Control and Data Security<\/h1>\n\n\n\n
Security logs can contain sensitive data.<\/p>\n\n\n\n
Control:<\/p>\n\n\n
Who can view security signals?\nWho can edit detection rules?\nWho can create suppressions?\nWho can view sensitive logs?\nWho can manage API\/app keys?\nWho can trigger workflows?\nWho can export<\/span> logs?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Datadog notes that modifying security signals requires Security Signals Write permission. (Datadog<\/a>)<\/p>\n\n\n\n
Use:<\/p>\n\n\n
RBAC\nTeams\nScoped application keys\nService accounts\nSensitive Data Scanner\nLog index access controls\nAudit Trail\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
39. Cost Management for Cloud SIEM<\/h1>\n\n\n\n
SIEM cost can grow quickly if unmanaged.<\/p>\n\n\n\n
Control these:<\/p>\n\n\n\n
Area<\/th>Cost Risk<\/th>Control<\/th><\/tr><\/thead>
Log ingestion<\/td>Too many logs<\/td>Source filtering<\/td><\/tr>
SIEM analyzed logs<\/td>Every log analyzed<\/td>Security Filters \/ Content Packs<\/td><\/tr>
Indexed logs<\/td>High retention\/search volume<\/td>Index strategy<\/td><\/tr>
Custom metrics from logs<\/td>Too many generated metrics<\/td>Strict metric creation<\/td><\/tr>
Archives<\/td>Long retention<\/td>Lifecycle policies<\/td><\/tr>
Synthetics\/RUM correlation<\/td>Extra telemetry<\/td>Sampling<\/td><\/tr>
Debug logs<\/td>Huge volume<\/td>Disable debug after testing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Use:<\/p>\n\n\n
Content Pack scoping\nSecurity Filters\nLog exclusion filters\nArchive for compliance\nIndex only useful logs\nMonitor ingestion volume\nReview top sources monthly\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
40. Advanced Topic: Security Filters vs Detection Rules<\/h1>\n\n\n\n
This is very important.<\/p>\n\n\n\n
Layer<\/th>Purpose<\/th><\/tr><\/thead>
Security Filter<\/td>Decides which logs Cloud SIEM analyzes<\/td><\/tr>
Detection Rule<\/td>Decides which analyzed logs create signals<\/td><\/tr>
Suppression<\/td>Decides which matching signals should not be generated<\/td><\/tr>
Notification Rule<\/td>Decides who gets notified<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Example:<\/p>\n\n\n
Security Filter:\nAnalyze source:cloudtrail\n\nDetection Rule:\nDetect @eventName:StopLogging\n\nSuppression:\nIgnore known automation role\n\nNotification:\nSend Critical cloud alerts to security-oncall\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
41. Advanced Topic: Real-Time vs Scheduled vs Historical<\/h1>\n\n\n\n
Type<\/th>Use Case<\/th><\/tr><\/thead>
Real-Time Rule<\/td>Immediate threat detection<\/td><\/tr>
Scheduled Rule<\/td>Periodic deeper analysis<\/td><\/tr>
Historical Job<\/td>Backtesting and retrospective hunting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Use real-time rules for:<\/p>\n\n\n
CloudTrail disabled\nAdmin role attached\nGitHub owner added\nKubernetes secret read\nWindows audit log cleared\n<\/code><\/span><\/pre>\n\n\n
Use scheduled rules for:<\/p>\n\n\n
Daily review of unusual admin activity\nWeekly service account access review\nPeriodic data access analysis\n<\/code><\/span><\/pre>\n\n\n
Use historical jobs for:<\/p>\n\n\n
Testing new<\/span> detection rule\nIncident retrospective\nThreat hunting against past logs\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
42. Advanced Topic: Threat Hunting Queries<\/h1>\n\n\n\n
AWS suspicious user-agent<\/h2>\n\n\n
source:cloudtrail @userAgent:(*kali* OR *nmap* OR *scoutsuite* OR *stratus-red-team*)\n<\/code><\/span><\/pre>\n\n\n
AWS IAM changes<\/h2>\n\n\n
source:cloudtrail @eventSource:iam.amazonaws.com\n<\/code><\/span><\/pre>\n\n\n
CloudTrail stopped<\/h2>\n\n\n
source:cloudtrail @eventName:(StopLogging OR DeleteTrail OR UpdateTrail)\n<\/code><\/span><\/pre>\n\n\n
S3 public access changes<\/h2>\n\n\n
source:cloudtrail @eventName:(PutBucketPolicy OR PutBucketAcl OR PutPublicAccessBlock)\n<\/code><\/span><\/pre>\n\n\n
Kubernetes exec<\/h2>\n\n\n
source:kubernetes.audit @objectRef.subresource:exec\n<\/code><\/span><\/pre>\n\n\n
Kubernetes secret access<\/h2>\n\n\n
source:kubernetes.audit @objectRef.resource:secrets\n<\/code><\/span><\/pre>\n\n\n
GitHub repo public<\/h2>\n\n\n
source:github @action:repo.change_visibility\n<\/code><\/span><\/pre>\n\n\n
Windows failed logons<\/h2>\n\n\n
source:windows @evt.id:4625\n<\/code><\/span><\/pre>\n\n\n
Windows privileged logon<\/h2>\n\n\n
source:windows @evt.id:4672\n<\/code><\/span><\/pre>\n\n\n
NGINX suspicious attack strings<\/h2>\n\n\n
source:nginx (\"union select\"<\/span> OR \"information_schema\"<\/span> OR \"..\/\"<\/span> OR \"cmd.exe\"<\/span> OR \"\/etc\/passwd\"<\/span>)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
43. World-Class SIEM Operating Model<\/h1>\n\n\n\n
Daily<\/h2>\n\n\n
Review critical\/high signals\nCheck signal queue health\nReview top noisy rules\nCheck ingestion failures\nReview new<\/span> risky entities\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Weekly<\/h2>\n\n\n
Tune noisy rules\nReview suppressions\nReview new<\/span> Datadog OOTB rules\nReview MITRE coverage\nCheck onboarding gaps\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Monthly<\/h2>\n\n\n
Threat detection review\nFalse<\/span> positive analysis\nSIEM cost review\nAccess control review\nRun purple team test\nUpdate runbooks\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Quarterly<\/h2>\n\n\n
Detection coverage assessment\nCloud account onboarding audit\nKubernetes security review\nIdentity provider review\nIncident response tabletop\nCompliance evidence export<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
44. Complete Implementation Checklist<\/h1>\n\n\n\n
Foundation<\/h2>\n\n\n
Cloud SIEM enabled\nLog Management enabled\nAPI\/app keys secured\nRBAC configured\nSecurity team access configured\nTeams and ownership configured\n<\/code><\/span><\/pre>\n\n\n
Ingestion<\/h2>\n\n\n
AWS CloudTrail onboarded\nGCP Audit Logs onboarded\nAzure Activity Logs onboarded\nKubernetes audit logs onboarded\nDatadog Audit Trail onboarded\nIdentity provider logs onboarded\nGitHub\/GitLab logs onboarded\nLinux\/Windows logs onboarded\nNetwork\/WAF logs onboarded\n<\/code><\/span><\/pre>\n\n\n
Processing<\/h2>\n\n\n
Logs parsed\nStatus remapped correctly\nService\/source\/env tags standardized\nOCSF normalization verified\nSensitive data scanning configured\nUnparsed logs monitored\n<\/code><\/span><\/pre>\n\n\n
SIEM Analysis<\/h2>\n\n\n
Content Packs enabled\nSecurity Filters validated\nOOTB rules enabled\nCustom rules created\nSuppressions configured\nHistorical jobs used for backtesting\nMITRE mapping reviewed\n<\/code><\/span><\/pre>\n\n\n
Response<\/h2>\n\n\n
Signals routed\nNotification rules configured\nRunbooks attached\nWorkflow automation configured\nIncident process defined\nEscalation paths tested\n<\/code><\/span><\/pre>\n\n\n
Governance<\/h2>\n\n\n
Terraform\/IaC implemented\nPull request review process established\nRule owners assigned\nQuarterly rule review scheduled\nCost monitoring enabled\nAudit Trail monitored\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
45. Final Recommended Learning Path<\/h1>\n\n\n\n
Follow this order:<\/p>\n\n\n
1.<\/span> Learn SIEM concepts\n2.<\/span> Learn Datadog logs and pipelines\n3.<\/span> Enable Cloud SIEM\n4.<\/span> Enable AWS CloudTrail Content Pack\n5.<\/span> Generate AWS test signals with<\/span> Datadog threat emulation repo\n6.<\/span> Learn Signals Explorer\n7.<\/span> Write simple custom rules\n8.<\/span> Add suppressions\n9.<\/span> Add identity provider logs\n10.<\/span> Add Kubernetes audit logs\n11.<\/span> Add GitHub audit logs\n12.<\/span> Learn OCSF normalization\n13.<\/span> Manage rules with<\/span> Terraform\n14.<\/span> Convert Sigma rules\n15.<\/span> Build SOAR workflows\n16.<\/span> Measure coverage and false<\/span> positives\n17.<\/span> Run purple-team validation\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
46. Final Architecture Recommendation for Real Companies<\/h1>\n\n\n\n
For a production organization, I would implement Datadog Cloud SIEM like this:<\/p>\n\n\n\n
Stage<\/th>Recommendation<\/th><\/tr><\/thead>
Phase 1<\/td>AWS\/GCP\/Azure audit logs + identity logs + Datadog Audit Trail<\/td><\/tr>
Phase 2<\/td>Kubernetes audit logs + GitHub\/GitLab + Linux\/Windows auth logs<\/td><\/tr>
Phase 3<\/td>WAF, DNS, firewall, proxy, EDR\/security tools<\/td><\/tr>
Phase 4<\/td>Custom detections, Terraform, Sigma conversion<\/td><\/tr>
Phase 5<\/td>SOAR workflows, risk scoring, MITRE coverage, purple-team validation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Minimum production baseline:<\/p>\n\n\n
CloudTrail \/ GCP Audit \/ Azure Activity\nIdentity provider logs\nKubernetes audit logs\nGitHub\/GitLab logs\nDatadog Audit Trail\nCritical app\/WAF logs\nOOTB Content Packs\n10<\/span>-20<\/span> custom high-value rules\nSignal routing\nRunbooks\nSuppression review\nCost monitoring\nDetection-as<\/span>-code\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The \u201cworld-class\u201d version is not just turning on Cloud SIEM. It is building a security operating system around it: high-quality telemetry, normalized fields, strong detections, signal triage, automated enrichment, response workflows, ownership, IaC, testing, and continuous tuning.<\/p>\n","protected":false},"excerpt":{"rendered":"
Current as of June 2026. Datadog Cloud SIEM is Datadog\u2019s security information and event management product for collecting security telemetry, analyzing logs and events with detection rules,… <\/p>\n","protected":false},"author":1,"featured_media":28220,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[25768],"tags":[],"class_list":["post-28219","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datadog"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/28219","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=28219"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/28219\/revisions"}],"predecessor-version":[{"id":77131,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/28219\/revisions\/77131"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/28220"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=28219"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=28219"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=28219"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Step 5: Run Dataflow Datadog template<\/h3>\n\n\n\n
Use the Datadog Dataflow template.<\/p>\n\n\n\n
Important: Datadog says Pub\/Sub Push subscription collection is being deprecated for this use case and recommends Pull subscription with the Datadog Dataflow template instead. (Datadog<\/a>)<\/p>\n\n\n\n