Threat Observability concepts

Latest Dynatrace
Explanation

This page provides an overview of the data available for security use cases in Grail and explains how you can work with this data using DQL. For practical examples, see DQL examples for security data.

Types of data in Grail

Data in Grail can originate from your monitored environment or from third‑party sources.

Dynatrace collects several types of data from your monitored environment that can be queried in Grail:

For details, see:

Security-related data

Security-related data can originate from Dynatrace native capabilities (via OneAgent or ActiveGate), or from third-party tools via log ingestion or OpenPipeline. Once ingested, this data can be queried, aggregated, visualized, and correlated with observability information to support a broad range of security use cases.

Grail does not distinguish between observability and security data. Any data you ingest can be used for security analytics. For example, authentication logs ingested for business purposes can also be used to detect potential brute force attacks.

Examples of security use cases:

Security events

Security events are a key category of security-related data stored in Grail. They represent security‑relevant events generated by Dynatrace or ingested from third‑party tools. The security.events table provides a consistent and efficient way to store, explore, and analyze these events across your environment.

Security events include:

Vulnerability events
Compliance events
Detection finding events

Storage

Grail stores security events in dedicated buckets within the security.events table. This structure helps you distinguish between events generated by Dynatrace and those originating from external sources:

Dynatrace‑generated security events — Stored in default_securityevents_builtin for three years.
Externally ingested security events — Stored in default_securityevents for one year.

All raw payloads are preserved in dt.raw_data. To access raw data, use the following DQL query:

fetch security.events
| parse dt.raw_data, """JSON:dt.raw_data"""
| fields dt.raw_data

Permissions

To query security events, the following permissions apply:

storage:security.events:read — read access to the security.events table
storage:logs:read — required when querying ingested logs used as security data

These permissions allow granular control over access to security‑sensitive data.

Ingesting security events

Security events can originate from Dynatrace native capabilities or from external security tools and are ingested into Grail through OpenPipeline or log ingestion.

Ingestion endpoints

Use the following endpoints to send security events to Grail:

Default ingestion: /platform/ingest/v1/security.events
Custom ingest sources: /platform/ingest/v1/security.events/<custom_ingest_source>

Dynatrace processors and OpenPipeline configurations support this ingest scope out of the box.

For details, see Ingest sources in OpenPipeline.

Event categories

Security events are grouped into buckets based on their origin. This separation helps you filter and analyze events according to whether they were generated by Dynatrace or ingested from third‑party tools.

Built‑in events generated by Dynatrace
Externally ingested events from third‑party systems

This separation enables filtering and analysis by event source.

Querying security events

Use the security.events table for all queries involving security‑related events.

Basic query:
```
fetch security.events
```

Filter by Dynatrace-generated events:

  fetch security.events
| filter dt.system.bucket == "default_securityevents_builtin"

Filter by externally ingested events:

  fetch security.events
| filter dt.system.bucket == "default_securityevents"

Vulnerability events

Vulnerability events can be classified by event levels (event.level), event groups (event.group_label), and event types (event.type). See below for details.

Event levels

Event levels	Description
`VULNERABILITY`	The vulnerability on the global level, including general information, global statuses, and changes. The unique identifier is `vulnerability.id` or `vulnerability.display_id`.
`ENTITY`	The vulnerable entity with vulnerability-related information scoped to the entity. The unique identifier is a tuple of (`affected_entity.id`, `vulnerability.id`).

Event groups

Event groups	Description
`CHANGE_EVENT`	Change that occurs on a vulnerability or its affected entity.
`STATE_REPORT`	The full historical state of a vulnerability or its affected entity and is reported periodically over time: `OPEN` (muted and not muted) vulnerabilities are reported every 15 minutes; `RESOLVED` vulnerabilities are reported only once (when open vulnerabilities get resolved). To analyze resolved vulnerabilities, filter for the desired time range.

Event types

Event types	Description
`VULNERABILITY_STATE_REPORT_EVENT`	Historical vulnerability states reported periodically.
`VULNERABILITY_COVERAGE_REPORT_EVENT`	Historical coverage events reported periodically.
`VULNERABILITY_STATUS_CHANGE_EVENT`	Vulnerability status changes reported on change. These include resolution and mute statuses.
`VULNERABILITY_ASSESSMENT_CHANGE_EVENT`	Vulnerability assessment changes reported on change. These include the Dynatrace Security Score and Dynatrace Assessment.
`VULNERABILITY_FINDING`¹	A single vulnerability identified in a specific process at a given time.
`VULNERABILITY_SCAN`¹	The analysis of detected packages within a specific process at a given time.

This event type can be ingested both from third-party security tools and from third-party libraries used by Dynatrace-monitored processes.

For a list of vulnerability event fields mapped to Grail, see Dynatrace Semantic Dictionary.

Vulnerability findings

Use Vulnerabilities Vulnerabilities to analyze, prioritize, and efficiently manage findings in your monitored environments.

A vulnerability finding is a security event that highlights a detected weakness in a system, software component, or environment. It represents a single instance of a flaw or misconfiguration that could be exploited.

Each finding is stored as an individual event at the time it is detected. These records may come from external sources such as third‑party scanners or libraries used by Dynatrace‑monitored processes. Dynatrace ingests and stores these events as raw data but does not perform additional analysis (for example, no Dynatrace Security Score is calculated).

Findings include details such as:

Severity and risk level
Affected component and remediation status
Metadata (timestamps, unique IDs, and source information)
Technical attributes (CVSS scores, exploit availability, and CVE references)

Compliance events

A compliance event is a type of security event specific to the Security Posture Management capability. It represents the assessment of a resource in the context of the rule specified in the compliance standard.

Event types	Description
`COMPLIANCE_SCAN_COMPLETED`	A compliance scan completed event is generated when a scan of a configuration dataset against compliance rules is completed.
`COMPLIANCE_FINDING`	A compliance finding event is generated when an object is evaluated against a compliance rule during a scan. The event contains the results of this evaluation and the compliance status of the given object.

For a list of compliance event fields mapped to Grail, see Dynatrace Semantic Dictionary.

Detection finding events

A detection finding event is generated when suspicious activity is observed around an object. The event contains all information available and deemed useful at the moment of detection.

Use Threats & Exploits to evaluate, triage, and investigate detection findings.

Event types	Description
`DETECTION_FINDING`	An alert or detection generated by security tools using correlation algorithms, detection rules, or other analytical methods.

To retrieve detection finding events, use a query such as the following:

fetch security.events
| filter event.kind == "SECURITY_EVENT" AND event.type == "DETECTION_FINDING"
| filter product.name == "Runtime Application Protection"
| makeTimeseries count()

For a list of detection finding event fields mapped to Grail, see Dynatrace Semantic Dictionary.

Threat report events

A threat report event is generated when open threat intelligence, such as a pulse or indicator of compromise (IP address, domain, URL, or file hash), is ingested from an external threat-intelligence source.

Event types	Description
`THREAT_REPORT`	Threat intelligence alerts and reports, and its related indicators of compromise, ingested from an external threat-intelligence source.

To retrieve threat report events, use a query such as the following:

fetch security.events
| filter event.type == "THREAT_REPORT"

For a list of threat report event fields mapped to Grail, see Dynatrace Semantic Dictionary.

Enrichment

Enrichment is the process of adding external context to observables such as IP addresses using threat‑intelligence sources. It helps you:

Validate detections faster
Prioritize investigations
Understand the intent or reputation associated with an observable

Enrichment doesn't generate new security events. Instead, it enhances existing data by adding attributes such as:

Reputation and risk indicators
Geolocation and network ownership
Threat classifications and confidence levels
Vendor‑specific metadata

With Security Enrichment, you can connect external threat‑intelligence APIs, normalize their responses, and add contextual data to your observables. Enrichment results are available across Investigations, Threats & Exploits, and Workflows, where they support faster validation, triage, and automation.

OpenPipeline integration

With OpenPipeline, you can ingest external security events from multiple third-party products into Grail and operationalize your data on the Dynatrace platform.

Out-of-the-box integrations

Dynatrace provides seamless OpenPipeline integration options for specific technologies. Ingested data is automatically stored in Grail and mapped to the Dynatrace Semantic Dictionary unified format. We provide ready-made dashboards and workflows to help you visualize data and automatize notifications. For a practical example, see Visualize and analyze security findings use case.

Support for custom ingestion

You can use our built-in security events API endpoint or create a custom API endpoint to ingest any kind of security events from any third-party system into Grail. You can configure a pipeline to manually map your data to the Semantic Dictionary conventions. Once your events comply with the Semantic Dictionary, you can leverage the dashboards and workflows provided by other integrations to view, analyze, and automate those findings alongside existing security data.

Severity and score normalization

When findings are ingested from different vulnerability sources, Dynatrace distinguishes between the values reported by the provider and the normalized values used across the platform. Normalization ensures that all findings can be consistently compared and prioritized, regardless of their origin.

Ingested severity: Severity level reported by the original vendor or scanner. The severity level is stored in the finding.severity field.
Normalized severity: Severity mapped to a unified Dynatrace risk scale (dt.security.risk.level) to ensure consistency across products.
Ingested risk score: Risk score defined by the provider (for example, Dynatrace Security Score). When provided by the source tool, the ingested risk score is stored in the finding.score field.
Normalized risk score: Risk score converted to a unified Dynatrace scale (dt.security.risk.score) so you can consistently cross‑prioritize vulnerabilities.

Each finding also specifies the product (product.name and product.vendor) that detected it (for example, Runtime Vulnerability Analytics), so you can identify the source of the data. For more information and the complete security model specification, see Security events.