Threat Observability concepts

Latest Dynatrace
Explanation

This section aims to give you a better understanding of data in the security context so you can easily accomplish various use cases with security-related data available on Grail. To learn how DQL can help in your daily tasks, see DQL examples for security data.

Types of data in Grail

Data can be ingested in Grail from your monitored environment or from third-party sources.

Data that Dynatrace collects from your monitored environment and that can be currently queried in Grail consists of:

For details, see

Security-related data

Security-related data can be either generated by Dynatrace native capabilities and collected by OneAgent or ActiveGate, or ingested from third-party tools via log ingestion or OpenPipeline.

Security-related data on Grail can provide you answers with different granularity and from various perspectives. You can query, aggregate, visualize, and report data on multiple levels.

The Grail data lakehouse doesn't distinguish security-related data from observability information. You can use all your data in Dynatrace for your security use cases. For example, if you ingested your application authentication logs for business purposes, you can use the same logs to detect potential brute force attacks on your customer accounts. Below are some examples of how you can use data for security purposes:

Security events

This section has been updated to align with the new Grail security events table. For the complete list of updates and actions needed to accomplish the migration, follow the steps in the Grail security table migration guide.

Security events are a type of security-related data consisting of various generated events such as

Vulnerability events
Compliance events
Detection finding events

Storage

Security events generated by Dynatrace from your monitored environment are stored in the default_securityevents_builtin bucket for three years.
Security events ingested from third-party sources are stored in the default_securityevents bucket for one year.

The original (raw) data ingested is stored in dt.raw_data. You can query it with a parse command, for example:

fetch security.events
| parse dt.raw_data, """JSON:dt.raw_data"""
| filter isNotNull(dt.raw_data[vulnerability.title])
| fields dt.raw_data[vulnerability.title]

Permissions

storage:security.events:read (to query ingested security events)
storage:logs:read (to query ingested logs)

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 Davis Security Score and Davis assessments.
`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.

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.