Current as of June 2026.

Datadog Cloud SIEM is Datadog’s 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)

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

1. What Is SIEM?

SIEM means Security Information and Event Management.

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

Traditional SIEM examples include Splunk Enterprise Security, IBM QRadar, Microsoft Sentinel, Elastic Security, and ArcSight.

Datadog Cloud SIEM is different because it is built directly on top of Datadog’s 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.

2. Why Datadog Cloud SIEM?

Datadog Cloud SIEM is especially useful for modern environments where applications run across:

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.

3. Datadog Cloud SIEM Core Architecture

flowchart LR
    A[Security Data Sources] --> B[Collection Layer]
    B --> C[Datadog Log Intake]
    C --> D[Log Pipelines / Parsing / Enrichment]
    D --> E[Cloud SIEM Analysis]
    E --> F[Detection Rules]
    F --> G[Security Signals]
    G --> H[Investigation / Triage]
    H --> I[Notification / Incident / SOAR]
    I --> J[Remediation / Reporting]

    A1[AWS CloudTrail] --> B
    A2[GCP Audit Logs] --> B
    A3[Azure Platform Logs] --> B
    A4[Kubernetes Audit Logs] --> B
    A5[Linux / Windows Logs] --> B
    A6[GitHub / Okta / SaaS Logs] --> B
Code language: CSS (css)

Datadog Cloud SIEM continuously analyzes incoming data to detect threats, generate actionable security signals, and correlate them across sources. (Datadog)

4. Important Datadog SIEM Terms

5. Main Features of Datadog Cloud SIEM

5.1 Content Packs

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)

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.

Examples of Content Pack categories include:

5.2 Detection Rules

Detection rules are the brain of SIEM. They define suspicious behavior.

Datadog provides OOTB detection rules to flag attacker techniques and misconfigurations, and Datadog’s Security Research team continuously adds new default rules. (Datadog)

Detection examples:

5.3 Security Signals

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 signal usually contains:

5.4 Custom Detection Rules

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)

Datadog custom detection methods include:

Real-time detection rules continuously monitor incoming logs and trigger immediate alerts when matching patterns or anomalies are detected. (Datadog) Scheduled detection rules run at intervals to analyze indexed log data using a defined time window. (Datadog) Historical jobs are one-time queries against historical logs used to backtest detections and convert interesting results into signals. (Datadog)

5.5 Suppressions

Suppressions prevent signals from being generated under specific conditions. This is critical for reducing false positives.

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)

Use suppressions for:

Important: prefer precise suppressions. Do not suppress broad rules like env:prod or source:cloudtrail, because that can hide real attacks.

5.6 OCSF Normalization

Datadog Cloud SIEM supports the Open Cybersecurity Schema Framework, 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)

Why this matters:

Datadog also provides an OCSF processor for custom mappings inside Log Management pipelines. (Datadog)

5.7 Security Filters

Cloud SIEM does not always need to analyze every log. Security Filters control which ingested logs are analyzed by Cloud SIEM.

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)

Important detail: Datadog tags ingested logs with datadog.cloud_siem:true or datadog.cloud_siem:false depending on whether Cloud SIEM selected the log for analysis. (Datadog)

Use this query in Logs Explorer:

datadog.cloud_siem:true
Code language: CSS (css)

To check logs not analyzed:

datadog.cloud_siem:false
Code language: CSS (css)

6. Datadog Cloud SIEM Use Cases

6.1 Cloud Threat Detection

Detect suspicious cloud activity:

6.2 Kubernetes Security Monitoring

Detect Kubernetes threats:

6.3 Identity and Access Monitoring

Detect identity risks:

6.4 Developer Tool Security

Modern attacks often target CI/CD and developer tools.

Monitor:

6.5 Endpoint and OS Security

Monitor:

6.6 Network Security

Monitor:

7. End-to-End Implementation Roadmap

flowchart TD
    A[Step 1: Define Security Goals] --> B[Step 2: Identify Log Sources]
    B --> C[Step 3: Enable Datadog Cloud SIEM]
    C --> D[Step 4: Enable Content Packs]
    D --> E[Step 5: Ingest Logs]
    E --> F[Step 6: Parse and Normalize]
    F --> G[Step 7: Validate Security Filters]
    G --> H[Step 8: Enable OOTB Rules]
    H --> I[Step 9: Create Custom Rules]
    I --> J[Step 10: Triage Signals]
    J --> K[Step 11: Configure Notifications]
    K --> L[Step 12: Automate Response]
    L --> M[Step 13: Measure and Improve]
Code language: CSS (css)

8. Prerequisites

Before starting, prepare:

9. Data Source Strategy

A world-class SIEM project should not ingest random logs blindly. Start with high-value security logs.

Phase 1: Must-have logs

10. Datadog SIEM Data Flow by Source

11. Step-by-Step: Enable Cloud SIEM

Step 1: Enable Cloud SIEM

In Datadog:

Security → Cloud SIEM

Enable Cloud SIEM for your organization.

Step 2: Choose Content Packs

Go to:

Security → Cloud SIEM → Ingest and Enrich → Content Packs

Start with:

AWS CloudTrail
Datadog Audit Trail
Kubernetes Audit Logs
GitHub
Okta/Auth0
Windows Event Logs
Linux Audit Logs
NGINX/Apache

Cloud SIEM Content Packs are the easiest way to send security data to Datadog because they are designed specifically for SIEM onboarding. (Datadog)

Step 3: Validate Logs Are Ingested

Go to Logs Explorer and search:

source:cloudtrail
Code language: CSS (css)

or:

source:github
Code language: CSS (css)

or:

source:kubernetes.audit
Code language: CSS (css)

Step 4: Confirm Logs Are Analyzed by Cloud SIEM

Search:

source:cloudtrail datadog.cloud_siem:true
Code language: CSS (css)

If logs show:

datadog.cloud_siem:false
Code language: CSS (css)

then Cloud SIEM is ingesting the log into Datadog, but not analyzing it for SIEM.

Step 5: Check Detection Rules

Go to:

Security → Cloud SIEM → Detection Rules

Confirm OOTB rules are enabled.

Cloud SIEM applies OOTB detection rules after Content Packs are enabled and configured. (Datadog)

12. AWS CloudTrail SIEM Tutorial

AWS CloudTrail is one of the best first SIEM projects because it detects identity, cloud control-plane, and privilege escalation attacks.

Datadog’s AWS Cloud SIEM guide explains that Cloud SIEM applies detection rules to processed logs and surfaces threats as Security Signals in Signals Explorer. (Datadog)

Architecture

flowchart LR
    A[AWS CloudTrail] --> B[S3 Bucket]
    B --> C[Datadog Forwarder Lambda]
    C --> D[Datadog Logs Intake]
    D --> E[Cloud SIEM AWS CloudTrail Content Pack]
    E --> F[Detection Rules]
    F --> G[Security Signals]
Code language: CSS (css)

Step-by-step

Step 1: Enable CloudTrail

In AWS:

CloudTrail → Trails → Create trail

Recommended:

Management events: Read + Write
Data events: S3, Lambda, important services
Multi-region trail: Enabled
Log file validation: Enabled
Send to S3: Enabled

Step 2: Send CloudTrail logs to Datadog

Common architecture:

CloudTrail → S3 → Datadog Forwarder Lambda → Datadog

Datadog’s 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)

Step 3: Enable AWS CloudTrail Content Pack

Enable:

AWS CloudTrail Content Pack

It provides detection rules, dashboards, investigator workflows, and configuration guidance.

Step 4: Validate ingestion

In Logs Explorer:

source:cloudtrail
Code language: CSS (css)

Useful fields:

@eventName
@eventSource
@userIdentity.arn
@userIdentity.type
@awsRegion
@sourceIPAddress
@userAgent
Code language: CSS (css)

Step 5: Validate SIEM analysis

source:cloudtrail datadog.cloud_siem:true
Code language: CSS (css)

Step 6: Watch for signals

Go to:

Security → Cloud SIEM → Signals

Filter:

source:cloudtrail
Code language: CSS (css)

13. AWS Threat Emulation Project Using GitHub

Project: Datadog AWS Cloud SIEM Threat Emulation

Datadog has an official GitHub project called cloud-siem-aws-threat-emulation. 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)

What you learn

Lab steps

Step 1: Prepare isolated AWS account

Use a sandbox AWS account. Do not run threat emulation in production.

Step 2: Configure CloudTrail to Datadog

Confirm:

source:cloudtrail
Code language: CSS (css)

Step 3: Clone the GitHub project

git clone https://github.com/DataDog/cloud-siem-aws-threat-emulation.git
cd cloud-siem-aws-threat-emulation
Code language: PHP (php)

Step 4: Follow project setup

Install the required tooling as documented by the repo.

Step 5: Run a safe emulation

Example types of activities usually include:

IAM enumeration
Access key activity
CloudTrail tampering scenario
S3 public exposure scenario
Privilege escalation style activity
Code language: PHP (php)

Step 6: Validate in Datadog

Go to:

Security → Cloud SIEM → Signals

Search:

source:cloudtrail @http.useragent:*stratus-red-team*

Step 7: Investigate signal

For each signal, inspect:

What happened?
Which user?
Which source IP?
Which AWS account?
Which region?
Which API call?
Was this expected?
What happened before and after?
Code language: JavaScript (javascript)

Step 8: Cleanup

Run cleanup commands from the project documentation.

14. GCP Audit Logs SIEM Tutorial

Datadog’s 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)

Architecture

flowchart LR
    A[GCP Audit Logs] --> B[Log Sink]
    B --> C[Pub/Sub Topic]
    C --> D[Dataflow Datadog Template]
    D --> E[Datadog Logs Intake]
    E --> F[Cloud SIEM]
    F --> G[Security Signals]
Code language: CSS (css)

Steps

Step 1: Enable Data Access audit logs

Enable:

Admin Read
Data Read
Data Write

Datadog’s GCP guide specifically recommends enabling these Data Access audit log types. (Datadog)

Step 2: Create Pub/Sub topic and subscription

Example:

export-audit-logs-to-datadog
Code language: JavaScript (javascript)

Step 3: Create log sink

Filter:

logName:"cloudaudit.googleapis.com"
Code language: JavaScript (javascript)

Step 4: Create Dataflow worker service account

Grant required permissions.

Step 5: Run Dataflow Datadog template

Use the Datadog Dataflow template.

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)

Step 6: Validate

Logs Explorer:

source:gcp
Code language: CSS (css)

Cloud SIEM:

source:gcp datadog.cloud_siem:true
Code language: CSS (css)

Signals:

Security → Cloud SIEM → Signals

15. Azure SIEM Tutorial

Datadog’s 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)

Architecture

flowchart LR
    A[Azure Activity Logs] --> B[Event Hub]
    B --> C[Datadog Azure Integration / Forwarder]
    C --> D[Datadog Logs]
    D --> E[Cloud SIEM]
    E --> F[Signals]
Code language: CSS (css)

Recommended Azure logs

Azure Activity Logs
Azure AD / Entra ID sign-in logs
Azure AD audit logs
Key Vault audit logs
Storage account access logs
Network security group flow logs
Defender for Cloud alerts
AKS audit logs

Example detections

16. Kubernetes Audit Logs SIEM Tutorial

Why Kubernetes audit logs matter

Kubernetes audit logs show API server activity:

create pod
exec into pod
read secret
create clusterrolebinding
delete deployment
patch daemonset
create privileged workload
Code language: JavaScript (javascript)

Recommended events to monitor

Example Datadog query

source:kubernetes.audit @verb:create @objectRef.resource:pods

Suspicious exec:

source:kubernetes.audit @objectRef.subresource:exec

Secret access:

source:kubernetes.audit @objectRef.resource:secrets

Privileged RBAC change:

source:kubernetes.audit @objectRef.resource:(clusterrolebindings OR rolebindings)

17. Linux Audit Logs SIEM Tutorial

Useful Linux security logs

Datadog Agent log collection example

logs:
  - type: file
    path: /var/log/auth.log
    service: linux-auth
    source: auth
    tags:
      - env:lab
      - team:security
Code language: JavaScript (javascript)

Restart Agent:

sudo systemctl restart datadog-agent

Validate:

sudo datadog-agent status
sudo datadog-agent stream-logs

Datadog query:

source:auth service:linux-auth
Code language: CSS (css)

Example custom rule: SSH brute force

Query:

source:auth "Failed password"
Code language: JavaScript (javascript)

Group by:

host
@network.client.ip
@usr.name
Code language: CSS (css)

Condition:

More than 10 events in 5 minutes

Severity:

Medium

Message:

Possible SSH brute force attempt from {{@network.client.ip}} against {{host.name}}.
Investigate successful logins from this IP and check whether the username was valid.
Code language: JavaScript (javascript)

18. Windows Event Logs SIEM Tutorial

Important Windows Event IDs

Example detection: Windows audit log cleared

Query:

source:windows @evt.id:1102

Severity:

High

Why:

Clearing Windows Security logs is a common defense evasion technique.

19. GitHub SIEM Tutorial

GitHub audit logs are very important because source control and CI/CD are frequent attack targets.

Events to monitor

Example Datadog query

source:github @action:repo.change_visibility

Example custom rule

Name:

GitHub Repository Made Public
Code language: PHP (php)

Query:

source:github @action:repo.change_visibility @visibility:public
Code language: PHP (php)

Severity:

High

Message:

A GitHub repository was made public. Validate whether this was approved.
Check repository name, actor, organization, and recent commits for sensitive data exposure.
Code language: JavaScript (javascript)

20. Okta/Auth0 Identity SIEM Tutorial

Events to monitor

Example rule: MFA disabled

source:okta @eventType:user.mfa.factor.deactivate

Severity:

High

Group by:

@usr.id
Code language: CSS (css)

21. Detection Engineering in Datadog SIEM

21.1 Good detection rule design

A good rule should have:

21.2 Rule quality checklist

Before enabling a rule in production:

Does the rule detect real attacker behavior?
Does it generate too many false positives?
Can an analyst understand the signal?
Does the signal include user/IP/resource?
Is there a runbook?
Is severity correct?
Is there an owner?
Is there a safe suppression strategy?
Can we test it?
Can we backtest it?
Can it be managed as code?
Code language: PHP (php)

22. Example Custom Rules

Rule 1: AWS CloudTrail Disabled

Query:

source:cloudtrail @eventName:StopLogging

Group by:

@userIdentity.arn
@awsRegion
Code language: CSS (css)

Severity:

Critical

Message:

CloudTrail logging was stopped by {{@userIdentity.arn}} in {{@awsRegion}}.
This may indicate defense evasion. Confirm whether this was an approved change.
Check recent IAM activity, source IP, user agent, and other API calls from the same identity.
Code language: JavaScript (javascript)

Rule 2: IAM Access Key Created

Query:

source:cloudtrail @eventName:CreateAccessKey

Group by:

@userIdentity.arn
Code language: CSS (css)

Severity:

Medium

Upgrade to High if:

The actor is new
The source IP is unusual
The user is privileged
The key belongs to another user
Code language: JavaScript (javascript)

Rule 3: S3 Bucket Policy Changed

Query:

source:cloudtrail @eventName:(PutBucketPolicy OR PutBucketAcl OR PutPublicAccessBlock)

Group by:

@requestParameters.bucketName
@userIdentity.arn
Code language: CSS (css)

Severity:

High

Rule 4: Kubernetes Secret Access

Query:

source:kubernetes.audit @objectRef.resource:secrets @verb:get
Code language: JavaScript (javascript)

Group by:

@user.username
@objectRef.namespace
Code language: CSS (css)

Severity:

Medium

Escalate if:

namespace:prod
unusual user
serviceaccount outside namespace
high frequency
Code language: CSS (css)

Rule 5: GitHub Branch Protection Disabled

Query:

source:github @action:protected_branch.destroy

Severity:

High

Rule 6: Windows Audit Log Cleared

Query:

source:windows @evt.id:1102

Severity:

Critical

Rule 7: NGINX Possible SQL Injection

Query:

source:nginx @http.url_details.queryString:("*union select*" OR "*sleep(*" OR "*information_schema*")
Code language: JavaScript (javascript)

Severity:

Medium

Note: This should be tuned carefully to avoid false positives.

23. Creating a Custom Rule in Datadog UI

Go to:

Security → Cloud SIEM → Detection Rules → New Rule
Code language: PHP (php)

Choose:

Real-Time Rule

Select method:

Threshold

Define query:

source:cloudtrail @eventName:StopLogging

Set condition:

count > 0 over 5 minutes

Group by:

@userIdentity.arn
Code language: CSS (css)

Add message:

CloudTrail logging stopped by {{@userIdentity.arn}}.
Investigate immediately.

Set severity:

Critical

Add tags:

team:security
source:aws
mitre:defense-evasion
env:prod
Code language: CSS (css)

Save rule.

24. Signal Investigation Workflow

Datadog Cloud SIEM Signals Explorer allows teams to view, search, filter, correlate, and assign signals without learning a dedicated query language. (Datadog)

Investigation flow

flowchart TD
    A[Signal Created] --> B[Read What Happened]
    B --> C[Identify User / IP / Resource]
    C --> D[Check Triggering Logs]
    D --> E[Check Same User Timeline]
    E --> F[Check Same IP Timeline]
    F --> G[Check Related Cloud / App / K8s Logs]
    G --> H[Classify True Positive or False Positive]
    H --> I[Contain / Remediate]
    I --> J[Update Rule / Suppression / Runbook]
Code language: CSS (css)

Standard triage questions

Who performed the action?
Was the identity human or service account?
Was MFA used?
Was the source IP expected?
Was the user-agent expected?
What resource was affected?
Was this in production?
Was this change approved?
Did similar activity happen before?
Did the same identity perform other suspicious actions?
Is there related app, Kubernetes, network, or endpoint activity?
Code language: JavaScript (javascript)

25. MITRE ATT&CK Mapping

A strong SIEM program should map detections to MITRE ATT&CK.

26. Risk Scoring and Entity Investigation

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)

Use risk scoring to answer:

Which user is riskiest?
Which host has repeated suspicious behavior?
Which cloud account has the highest risk?
Which service account needs review?
Which IP appears in multiple signals?

27. Notifications and Alert Routing

Signals are only useful if they reach the right team.

Common routing:

Datadog allows Notification Rules to route signals to individuals or teams, and signal modification requires Security Signals Write permission. (Datadog)

28. SOAR and Response Automation

SOAR means Security Orchestration, Automation, and Response.

Datadog Cloud SIEM can work with Workflow Automation. Content Packs may include workflow automation to accelerate investigation and remediation. (Datadog)

Example automation ideas

Do not automatically delete users, revoke production credentials, or block IPs without a clear approval process unless your organization has mature playbooks.

29. Datadog SIEM with Terraform

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)

Useful Terraform-managed SIEM resources

Sample Terraform skeleton

terraform {
  required_providers {
    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.0"
    }
  }
}

provider "datadog" {
  api_key = var.datadog_api_key
  app_key = var.datadog_app_key
  api_url = var.datadog_api_url
}

variable "datadog_api_key" {
  type      = string
  sensitive = true
}

variable "datadog_app_key" {
  type      = string
  sensitive = true
}

variable "datadog_api_url" {
  type    = string
  default = "https://api.datadoghq.com/"
}
Code language: JavaScript (javascript)

Official GitHub project: Terraform security modules

Datadog has an official GitHub repository named terraform-modules-datadog-security, which contains Terraform modules for common integrations between Datadog security products and cloud providers. (GitHub)

Use this repository as a reference for cloud security onboarding patterns.

30. Sigma to Datadog Rules

Sigma is a generic detection rule format used by detection engineers.

Datadog has an official pysigma-backend-datadog GitHub project. It supports output formats for Datadog query syntax and can convert Sigma rules into Datadog Cloud SIEM detection format. (GitHub)

Use case

You have Sigma rule:

title: Suspicious PowerShell Encoded Command
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    CommandLine|contains: "-enc"
  condition: selection
level: high
Code language: JavaScript (javascript)

You convert it into Datadog-compatible query/rule format.

Why useful

31. Recommended GitHub Projects for Hands-On Learning

32. Complete Lab Roadmap

Lab 1: Basic SIEM with Linux auth logs

Goal:

Collect Linux SSH/sudo logs and create brute-force detection.

Skills:

Datadog Agent
Log collection
Log Explorer
Custom detection rule
Security signal triage

Lab 2: AWS CloudTrail SIEM

Goal:

Forward CloudTrail logs into Datadog and enable AWS CloudTrail Content Pack.

Skills:

CloudTrail
S3
Datadog Forwarder
Content Packs
OOTB detections
Signals Explorer

Lab 3: AWS Threat Emulation

Goal:

Use DataDog/cloud-siem-aws-threat-emulation to trigger test signals.
Code language: PHP (php)

Skills:

Threat simulation
CloudTrail detection validation
Rule testing
Triage
Cleanup

Lab 4: Kubernetes Audit Logs

Goal:

Detect suspicious Kubernetes API activity.

Skills:

Kubernetes audit policy
Control plane logs
Kubernetes SIEM detection
RBAC investigation

Lab 5: GitHub Audit Logs

Goal:

Detect repository visibility changes and privileged user changes.

Skills:

GitHub audit logs
Developer security
Custom detections
Notification routing

Lab 6: Detection-as-Code

Goal:

Manage SIEM rules and dashboards with Terraform.
Code language: JavaScript (javascript)

Skills:

Terraform provider
Rule versioning
Pull request review
Environment promotion

Lab 7: Sigma Conversion

Goal:

Convert Sigma rules into Datadog-compatible query/rule format.

Skills:

Sigma
pysigma-backend-datadog
Detection engineering
Rule portability

33. Production Reference Architecture

flowchart TB
    subgraph Cloud["Cloud Accounts"]
        A1[AWS CloudTrail]
        A2[GCP Audit Logs]
        A3[Azure Activity Logs]
    end

    subgraph Platform["Platform"]
        B1[Kubernetes Audit Logs]
        B2[Datadog Agent]
        B3[Workload Protection]
    end

    subgraph SaaS["SaaS / Identity / Dev Tools"]
        C1[Okta/Auth0]
        C2[GitHub/GitLab]
        C3[Google Workspace]
    end

    subgraph Network["Network / Edge"]
        D1[Firewall]
        D2[DNS]
        D3[WAF]
        D4[Proxy]
    end

    Cloud --> E[Datadog Log Intake]
    Platform --> E
    SaaS --> E
    Network --> E

    E --> F[Parsing / OCSF / Enrichment]
    F --> G[Cloud SIEM Analysis]
    G --> H[OOTB + Custom Rules]
    H --> I[Security Signals]
    I --> J[Signals Explorer / Investigators]
    I --> K[Notifications]
    I --> L[Workflow Automation]
    I --> M[Incidents / Cases / Reports]
Code language: CSS (css)

34. Best Practices for Datadog SIEM

34.1 Start with high-value logs

Do not onboard every log first. Start with:

CloudTrail
GCP Audit Logs
Azure Activity Logs
Identity provider logs
Kubernetes audit logs
GitHub/GitLab audit logs
Datadog Audit Trail
Endpoint authentication logs

34.2 Use Content Packs first

Content Packs give you faster time to value because they include prebuilt security content.

34.3 Normalize logs

Use OOTB pipelines and OCSF where possible.

34.4 Tune detections

Every production SIEM needs tuning.

Tune:

query
threshold
group-by
severity
suppression
message
owner
notification
runbook

34.5 Avoid over-suppression

Suppress only known-good activity. Do not suppress broad categories.

34.6 Create runbooks

Every high/critical rule should have:

What happened?
Why it matters
How to validate
How to contain
How to remediate
Who owns it
How to close

34.7 Measure SIEM quality

Track:

Signal volume
False positive rate
Mean time to triage
Mean time to respond
Coverage by MITRE tactic
Top noisy rules
Top risky users
Top risky cloud accounts
Unparsed log volume
Logs not analyzed by Cloud SIEM
Code language: PHP (php)

34.8 Manage detections as code

Use Terraform, GitHub pull requests, peer reviews, and environment promotion.

34.9 Separate dev/test/prod

Use tags:

env:prod
env:stage
team:security
source:cloudtrail
cloud_provider:aws
Code language: CSS (css)

34.10 Validate continuously

Use:

Threat emulation
Historical jobs
Tabletop exercises
Purple team tests
Synthetic attack logs

35. Common Mistakes

36. Datadog SIEM Troubleshooting

Problem: No security signals

Check:

Are logs arriving?
Are logs parsed?
Are logs tagged datadog.cloud_siem:true?
Are Content Packs enabled?
Are OOTB rules enabled?
Does the activity actually match a rule?
Are suppressions hiding signals?
Is the time window correct?
Do you have permission to view signals?
Code language: JavaScript (javascript)

Problem: Logs visible but not analyzed

Search:

datadog.cloud_siem:false
Code language: CSS (css)

Fix:

Enable relevant Content Pack
Adjust Security Filter
Check index filter if using Cloud SIEM Standalone

Datadog notes that Security Filters or log index filters control which logs Cloud SIEM analyzes, depending on the Cloud SIEM product type. (Datadog)

Problem: Too many noisy signals

Fix:

Add precise suppressions
Tune thresholds
Group by user/IP/resource
Reduce low-value rules
Lower severity for expected activity
Add maintenance exclusions
Create separate rule for prod only

Problem: Rule does not trigger

Check:

Does the query return logs in Log Explorer?
Are fields parsed as expected?
Is the time window correct?
Is the group-by correct?
Is rule enabled?
Is source log selected for SIEM analysis?
Is a suppression hiding it?
Code language: JavaScript (javascript)

Problem: Wrong severity

Review:

Business impact
Asset criticality
Environment
User privilege
Data sensitivity
Attack stage
Repeat behavior

37. SIEM Governance Model

A mature Datadog SIEM implementation should define:

38. Access Control and Data Security

Security logs can contain sensitive data.

Control:

Who can view security signals?
Who can edit detection rules?
Who can create suppressions?
Who can view sensitive logs?
Who can manage API/app keys?
Who can trigger workflows?
Who can export logs?
Code language: JavaScript (javascript)

Datadog notes that modifying security signals requires Security Signals Write permission. (Datadog)

Use:

RBAC
Teams
Scoped application keys
Service accounts
Sensitive Data Scanner
Log index access controls
Audit Trail

39. Cost Management for Cloud SIEM

SIEM cost can grow quickly if unmanaged.

Control these:

Use:

Content Pack scoping
Security Filters
Log exclusion filters
Archive for compliance
Index only useful logs
Monitor ingestion volume
Review top sources monthly

40. Advanced Topic: Security Filters vs Detection Rules

This is very important.

Example:

Security Filter:
Analyze source:cloudtrail

Detection Rule:
Detect @eventName:StopLogging

Suppression:
Ignore known automation role

Notification:
Send Critical cloud alerts to security-oncall

41. Advanced Topic: Real-Time vs Scheduled vs Historical

Use real-time rules for:

CloudTrail disabled
Admin role attached
GitHub owner added
Kubernetes secret read
Windows audit log cleared

Use scheduled rules for:

Daily review of unusual admin activity
Weekly service account access review
Periodic data access analysis

Use historical jobs for:

Testing new detection rule
Incident retrospective
Threat hunting against past logs
Code language: JavaScript (javascript)

42. Advanced Topic: Threat Hunting Queries

AWS suspicious user-agent

source:cloudtrail @userAgent:(*kali* OR *nmap* OR *scoutsuite* OR *stratus-red-team*)

AWS IAM changes

source:cloudtrail @eventSource:iam.amazonaws.com

CloudTrail stopped

source:cloudtrail @eventName:(StopLogging OR DeleteTrail OR UpdateTrail)

S3 public access changes

source:cloudtrail @eventName:(PutBucketPolicy OR PutBucketAcl OR PutPublicAccessBlock)

Kubernetes exec

source:kubernetes.audit @objectRef.subresource:exec

Kubernetes secret access

source:kubernetes.audit @objectRef.resource:secrets

GitHub repo public

source:github @action:repo.change_visibility

Windows failed logons

source:windows @evt.id:4625

Windows privileged logon

source:windows @evt.id:4672

NGINX suspicious attack strings

source:nginx ("union select" OR "information_schema" OR "../" OR "cmd.exe" OR "/etc/passwd")
Code language: JavaScript (javascript)

43. World-Class SIEM Operating Model

Daily

Review critical/high signals
Check signal queue health
Review top noisy rules
Check ingestion failures
Review new risky entities
Code language: JavaScript (javascript)

Weekly

Tune noisy rules
Review suppressions
Review new Datadog OOTB rules
Review MITRE coverage
Check onboarding gaps
Code language: JavaScript (javascript)

Monthly

Threat detection review
False positive analysis
SIEM cost review
Access control review
Run purple team test
Update runbooks
Code language: PHP (php)

Quarterly

Detection coverage assessment
Cloud account onboarding audit
Kubernetes security review
Identity provider review
Incident response tabletop
Compliance evidence export
Code language: JavaScript (javascript)

44. Complete Implementation Checklist

Foundation

Cloud SIEM enabled
Log Management enabled
API/app keys secured
RBAC configured
Security team access configured
Teams and ownership configured

Ingestion

AWS CloudTrail onboarded
GCP Audit Logs onboarded
Azure Activity Logs onboarded
Kubernetes audit logs onboarded
Datadog Audit Trail onboarded
Identity provider logs onboarded
GitHub/GitLab logs onboarded
Linux/Windows logs onboarded
Network/WAF logs onboarded

Processing

Logs parsed
Status remapped correctly
Service/source/env tags standardized
OCSF normalization verified
Sensitive data scanning configured
Unparsed logs monitored

SIEM Analysis

Content Packs enabled
Security Filters validated
OOTB rules enabled
Custom rules created
Suppressions configured
Historical jobs used for backtesting
MITRE mapping reviewed

Response

Signals routed
Notification rules configured
Runbooks attached
Workflow automation configured
Incident process defined
Escalation paths tested

Governance

Terraform/IaC implemented
Pull request review process established
Rule owners assigned
Quarterly rule review scheduled
Cost monitoring enabled
Audit Trail monitored

45. Final Recommended Learning Path

Follow this order:

1. Learn SIEM concepts
2. Learn Datadog logs and pipelines
3. Enable Cloud SIEM
4. Enable AWS CloudTrail Content Pack
5. Generate AWS test signals with Datadog threat emulation repo
6. Learn Signals Explorer
7. Write simple custom rules
8. Add suppressions
9. Add identity provider logs
10. Add Kubernetes audit logs
11. Add GitHub audit logs
12. Learn OCSF normalization
13. Manage rules with Terraform
14. Convert Sigma rules
15. Build SOAR workflows
16. Measure coverage and false positives
17. Run purple-team validation
Code language: JavaScript (javascript)

46. Final Architecture Recommendation for Real Companies

For a production organization, I would implement Datadog Cloud SIEM like this:

Minimum production baseline:

CloudTrail / GCP Audit / Azure Activity
Identity provider logs
Kubernetes audit logs
GitHub/GitLab logs
Datadog Audit Trail
Critical app/WAF logs
OOTB Content Packs
10-20 custom high-value rules
Signal routing
Runbooks
Suppression review
Cost monitoring
Detection-as-code
Code language: JavaScript (javascript)

The “world-class” 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.

Rajesh Kumar

I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.

Do you want to learn Quantum Computing?

Please find my social handles as below;

Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND

Rajesh Kumar DailyLogs