Application Security

Application Security helps secure cloud-native and on-premise applications at runtime with intelligent automation. This includes visualizing, analyzing, and monitoring security vulnerabilities in your environment and blocking detected attacks on your applications.

Runtime Vulnerability Analytics (RVA)

Dynatrace Runtime Vulnerability Analytics enables you to detect, visualize, analyze, and monitor the remediation of third-party and code-level vulnerabilities in your environment.

Third-party vulnerabilities

Third-party vulnerabilities can arise when your application uses a specific library or language runtime containing vulnerabilities.

Code-level vulnerabilities

Code-level vulnerabilities can arise when Dynatrace Application Security detects a vulnerability in your code by evaluating the requests passing through your applications.

RVA: Billing and granularity

The unit of measure for Runtime Vulnerability Analytics is GiB hour (also referred to as "memory-gibibyte-hour" in your rate card). Dynatrace is built for dynamic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for GiB hour consumption is calculated in four 15-minute intervals per hour. When a host or container is monitored for fewer than 15 minutes in an interval, GiB-hour consumption is rounded up to 15 minutes before consumption is calculated.

RVA: GiB-hour calculation for physical hosts and virtual machines (VMs)

Each instance that Runtime Vulnerability Analytics runs on consumes GiB-hours based on the monitored host's physical or virtual RAM, calculated in 15-minute intervals (see the diagram example below).

The RAM of each VM or host is rounded to the next multiple of 0.25 GiB (which equates to 256 MiB) before monitoring consumption is calculated.** A 4 GiB minimum is applied to GiB-hour consumption for physical and virtual hosts.

For example, a host with 8.3 GiB memory is counted as an 8.5 GiB host, being the next multiple of 0.25 GiB, while a host with 2 GiB memory is counted as a 4 GiB host (no rounding needed, but application of the 4GiB minimum).

RVA: GiB-hour calculation for application-only container monitoring

In cloud-native environments, services and hosts are often short-lived. Therefore calculating monitoring consumption in 15-minute time intervals, rather than full hours, better reflects your actual usage. Containers, which are an essential mechanism in cloud-native environments, are typically smaller in memory size than hosts. Therefore, the minimum memory threshold for containers is 256 MiB, rather than 4 GiB, the minimum memory threshold for hosts. The same rounding as for hosts, to the next multiple of 0.25 GiB, also applies for containers. For example, a container with 780 MiB memory is counted as a 1 GiB container (780 MiB, which equals 0.76 GiB, being rounded up to the next multiple of 0.25 GiB).

RVA: Consumption calculation example

In the example above, each interval is divided by 4 in order to reach the GiB-hour consumption unit of measure.

Host 1
Runs in the first interval with 2 GiB memory (counted as 4 GiB due to the Host Minimum) = 1.0 GiB/h

Container 1
Runs from in the first and second interval with 780 MiB memory (rounded to 1 GiB) = 0.5 GiB/h

Host 2
Runs from in the first, second, and third interval with 8.3 GiB memory (rounded to 8.5 GiB) = 6.375 GiB/h

Container 2
Runs in the third and fourth interval with 100 MiB memory (rounded to 0.25 GiB) = 0.125 GiB/h

Total 8.0 GiB/h

RVA: Memory calculation

Memory-size calculations for containers monitored in an application-only approach are based on each container's used memory.

Memory-size calculations based on a container's used memory require OneAgent version 1.275+ (for Kubernetes containers) or OneAgent version 1.283+ (for other serverless containers).

Older OneAgent versions use the customer-defined memory limit. If no memory limit is set, the memory of the underlying virtual machine is used instead.

Exceptions

RVA: Analyze consumption via built-in usage metrics

Dynatrace provides the following built-in usage metrics that help you understand and analyze your organization's consumption of Runtime Vulnerability Analytics:

(DPS) Runtime Vulnerability Analytics billing usage

Key: builtin:billing.runtime_vulnerability_analytics.usage

Dimension:

Resolution: 15 min

Description: Total number of host hours consumed by Runtime Vulnerability Analytics.

(DPS) Runtime Vulnerability Analytics billing usage per host

Key: builtin:billing.runtime_vulnerability_analytics.usage_per_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: The total number of host hours consumed by Runtime Vulnerability Analytics, split by host.

RVA: View usage

There are several ways to view usage:

For details on how to troubleshoot Runtime Vulnerability Analytics consumption issues, see Identify and resolve DPS consumption issues: Runtime Vulnerability Analytics.

RVA: Monitor memory-GiB-hour consumption

You can monitor the total memory-GiB-hour consumption aggregated across all Runtime Vulnerability Analytics monitored hosts for different intervals (15 min, hour, day, or week) for any selected timeframe using the metric (DPS) Runtime Vulnerability Analytics billing usage. The example below shows memory-GiB-hour consumption in 1-hour intervals. Between 11:00 and 14:00, 6.84 memory-TiB-hours were consumed each hour.

You can split the total host-hour consumption using the metric (DPS) Runtime Vulnerability Analytics usage per host. The example below shows the list of all hosts that reported consumption.

Runtime Application Protection (RAP)

Dynatrace Runtime Application Protection leverages code-level insights and transaction analysis to detect and block attacks on your applications automatically and in real time.

RAP: Billing and granularity

The unit of measure for Runtime Application Protection is a GiB hour (also referred to as "memory-gibibyte-hour" in your rate card). Dynatrace is built for dynamic cloud-native environments where hosts and services are rapidly spun up and destroyed. Therefore, billing granularity for GiB-hour consumption is calculated in four 15-minute intervals per hour. When a host or container is monitored for fewer than 15 minutes in an interval, GiB-hour consumption is rounded up to 15 minutes before consumption is calculated.

RAP: GiB-hour calculation for physical hosts and virtual machines (VMs)

Each instance on which Runtime Application Protection is enabled consumes GiB-hours based on the monitored host's physical or virtual RAM, calculated in 15-minute intervals (see the diagram example below).

The RAM of each VM or host is rounded to the next multiple of 0.25 GiB (which equates to 256 MiB) before monitoring consumption is calculated. A 4 GiB minimum is applied to GiB-hour consumption for physical and virtual hosts.

For example, a host with 8.3 GiB memory is counted as an 8.5 GiB host, being the next multiple of 0.25 GiB, while a host with 2 GiB memory is counted as a 4 GiB host (no rounding needed, but application of the 4 GiB minimum).

RAP: GiB-hour calculation for application-only container monitoring

In cloud-native environments, services and hosts are often short-lived. Therefore calculating monitoring consumption in 15-minute time intervals, rather than full hours, better reflects your actual usage. Containers, which are an essential mechanism in cloud-native environments, are typically smaller in memory size than hosts. Therefore, the minimum memory threshold for containers is 256 MiB, rather than 4 GiB, the minimum memory threshold for hosts. The same rounding as for hosts, to the next multiple of 0.25 GiB, also applies for containers. For example, a container with 780 MiB memory is counted as a 1 GiB container (780 MiB, which equals 0.76 GiB, being rounded up to the next multiple of 0.25 GiB).

Because Runtime Application Protection is based on code-level insights, Runtime Vulnerability Analytics must run concurrently in the background. Even if you configure a host to only run Runtime Application Protection, your environment will consume GiB-Hours for both Runtime Application Protection and Runtime Vulnerability Analytics.

RAP: Consumption calculation example

In the example above, each interval is divided by 4 in order to reach the memory-gibibyte-hour consumption unit of measure.

Host 1
Runs in the first interval; 2 GiB memory (Minimum of 4 GiB applies) = 1.0 GiB/h RVA; 1.0 GiB/h RAP

Container 1
Runs in the first and second interval; 780 MiB memory (round to 1 GiB) = 0.5 GiB/h RVA; 0.5 GiB/h RAP

Host 2
Runs in the first, second, and third interval; 8.3 GiB memory (round to 8.5 GiB) = 6.375 GiB/h RVA; 6.375 GiB/h RAP

Container 2
Runs in the third and fourth interval; 100 MiB memory (round to 0.25 GiB) = 0.125 GiB/h RVA & 0.125 GiB/h RAP

Total Runtime Vulnerability Analysis
0.5 GiB/h + 0.5 GiB/h + 6.375 GiB/h + 0.125 GiB/h = 8.0 GiB/h

Total Runtime Application Protection
0.5 GiB/h + 0.5 GiB/h + 6.375 GiB/h + 0.125 GiB/h = 8.0 GiB/h

RAP: Memory calculation

Memory-size calculations for containers monitored in an application-only approach are based on each container's used memory.

Memory-size calculations based on a container's used memory require OneAgent version 1.275+ (for Kubernetes containers) or OneAgent version 1.283+ (for other serverless containers).

Older OneAgent versions use the customer-defined memory limit. If no memory limit is set, the memory of the underlying virtual machine is used instead.

Exceptions

RAP: Analyze consumption via built-in usage metrics

Dynatrace provides the following built-in usage metrics that help you understand and analyze your organization's consumption of Runtime Application Protection.

(DPS) Runtime Application Protection billing usage

Key: builtin:billing.runtime_application_protection.usage

Dimension:

Resolution: 15 min

Description: The total number of host hours monitored by Runtime Application Protection.

(DPS) Runtime Application Protection billing usage per host

Key: builtin:billing.runtime_application_protection.usage_per_host

Dimension: Host (dt.entity.host)

Resolution: 15 min

Description: Total number of host hours monitored by Runtime Application Protection, split by host.

RAP: View usage

There are several ways to view usage:

For details on how to troubleshoot Runtime Application Protection, see Identify and resolve DPS consumption issues: Runtime Application Protection.

RAP: Monitor memory-GiB-hour consumption

You can monitor the total memory-GiB-hour consumption aggregated across all Runtime Application Protection monitored hosts for different intervals (15 min, hour, day, or week) for any selected timeframe using the (DPS) Runtime Application Protection billing usage metric. The example below shows memory GiB-hour consumption in 1-hour intervals. Between 11:00 and 14:00, between 59.3 memory-GiB-hour and 67 memory-GiB-hour were consumed.

You can split the total host hour consumption by using metric (DPS) Runtime Application Protection usage per host. The example below shows the list of all hosts that reported consumption.

Security Posture Management (SPM)

Security Posture Management (SPM) provides ongoing monitoring and automated assessment for Kubernetes® environments. With insights into configuration, compliance issues, and risk management, customers can maintain a strong security posture.

Kubernetes Security Posture Management (KSPM)

Kubernetes Security Posture Management (KSPM) focuses on identifying and mitigating security risks in your Kubernetes clusters.

KSPM: Billing and granularity

The unit of measure for Kubernetes Security Posture Management is a host-hour. In Kubernetes environments, each node that is scanned during an hour is counted as a host-hour, regardless of how many times it was scanned. You can enable Kubernetes Security Posture Management on a per-cluster basis.

KSPM calculation example

KSPM: View usage

There are several ways to view usage: