Dynatrace Application Security terminology

See below for a list of basic security concepts and how they apply in the context of Dynatrace Application Security.

Attack

An attack is any request (call) from a certain client IP on your application code with malicious intent (for example, to access or delete protected information). For details on how to manage attacks, see Manage attacks.

Code-level vulnerability

A code-level vulnerability is a security problem based on a flaw in your application code, created when an attack is detected.

To understand how Application Security identifies code-level vulnerabilities and how it determines their priorities, see How vulnerabilities are evaluated.

For details on how to manage code-level vulnerabilities, see Manage code-level vulnerabilities.

Muted vulnerability

A muted vulnerability is a vulnerability that has been silenced by request. If you decide that a vulnerability isn't relevant in your environment, you can mute it so it doesn't appear in the list of vulnerabilities. You can mute (silence) vulnerabilities that are

• Open, if you don't consider them important
• Resolved, if you don't want to deal with them if they get reopened

To display the list of Muted - Open and Muted - Resolved vulnerabilities, you need to filter for Status: Muted.

Similarly, you can mute affected entities (process groups or Kubernetes nodes). By muting an entity, you hide third-party vulnerabilities for that entity. Muted entities aren't taken into consideration in any context, such as Davis Security Score or Application Security metrics. For details, see Remediation tracking.

Public exploit

A public exploit is known malicious code that exploits a vulnerability.

Public internet exposure

Public internet exposure is true when a vulnerability affects at least one process that is exposed to the internet. This is analyzed based on the traffic that hits the process directly (source IP) or indirectly (via a header set by an intermediary service, like _X-Forwarded-For_).

Reachable data assets

Reachable data assets are database services accessed by affected processes containing an identified vulnerability, based on the Dynatrace entity model (Smartscape).

Related vs. affected entity

The process groups or processes that contain a vulnerable component (library or runtime) are directly affected by the vulnerability. Details about affected entities are displayed on the details page of a vulnerability. For more information, see Manage third-party vulnerabilities: Process group overview.

Related entities are entities (applications, services, hosts, databases, Kubernetes workloads, or Kubernetes clusters) that are somehow connected to these affected process group instances:

• Applications: Applications that call a vulnerable service, or applications that call a non-vulnerable service that calls a vulnerable service.
  • Limitations: When determining related applications, the Dynatrace PurePath® distributed traces are not analyzed.
• Services: Services that directly run on a vulnerable process group instance.
• Hosts: Hosts on which the vulnerable process runs.
• Databases: Databases that run on the vulnerable process.
• Kubernetes workloads: In Kubernetes environments, the workloads to which the vulnerable process belongs.
• Kubernetes clusters: In Kubernetes environments, the clusters to which the vulnerable process belongs.

Resolved vulnerability

• A third-party vulnerability is closed automatically when the root cause (for example, loading a vulnerable library) is no longer present. When no process group has been reporting any vulnerable components, such as libraries for more than two hours, the vulnerability is marked as Resolved. There are several reasons why this can happen:

  • The vulnerability was fixed in the code

  • The vulnerable component was upgraded or removed

  • The vulnerable component is no longer used by the application

  • The application hasn't received any traffic after a restart, therefore the vulnerable component hasn't been loaded (is inactive)

  • The affected process has been stopped

    Note: As long as the affected process is down, a vulnerability isn't considered relevant or impacting the environment. When the process is up again, Dynatrace checks on it immediately and, if the process is affected, the vulnerability is reopened.

• A code-level vulnerability is closed automatically one year after the last occurrence of a related attack.

Risk assessment

The risk factors taken into consideration when determining the final score of a vulnerability are as follows:

• Public exploit
• Public internet exposure
• Reachable data assets
• Vulnerable functions in use
• Reduced accuracy, for related hosts running in Infrastructure Monitoring mode, as opposed to a full assessment that can be performed on vulnerabilities that have all related hosts under Full-Stack Monitoring. For details, see Monitoring modes.

For details on how Dynatrace determines external exposure and affected data assets, see How vulnerabilities are evaluated: risk assessment.

Runtime Application Protection

Runtime Application Protection (RAP) is a functionality that enables Application Protection globally in your environment. For instructions, see Get started with Application Protection.

Note: For OneAgent to start reporting attacks, you need to also enable the Java code-level attack evaluation OneAgent functionality.

Runtime Vulnerability Analytics

Runtime Vulnerability Analytics (RVA) is a functionality that enables Application Security to start generating vulnerabilities for security issues on your applications. For instructions on how to enable it, see Enable Vulnerability Analytics.

Third-party vulnerability

A third-party vulnerability is a security problem detected in the third-party libraries loaded in your environment.
To understand how Application Security identifies third-party vulnerabilities and how it determines their priorities, see How vulnerabilities are evaluated.

Notes:

• One vulnerability in Dynatrace can have multiple CVEs (for example, if different vendors release their own CVEs).
• There can be different vulnerabilities for one component (library).
• One security problem can generate multiple Dynatrace vulnerabilities, one for each affected technology.

For details on how to manage third-party vulnerabilities, see Manage third-party vulnerabilities.

Vulnerable component

A vulnerable component is a software component (library) or runtime component (for example, a Kubernetes package) that has a vulnerable function causing a vulnerability. To find out how Dynatrace evaluates components, see How vulnerabilities are evaluated: Third-party vulnerabilities.

Vulnerable function

• From a vulnerability perspective, a vulnerable function is the exact class (example: com.fasterxml.jackson.databind.jsontype.impl.SubTypeValidator) and function (example: validateSubType) causing a vulnerability. Based on whether your application uses the vulnerable function, you can determine how impacted your environment is. The usage of a vulnerable function is calculated on the process level and is aggregated to the process group level, which results in a count of affected process groups per function. For details on the function usage, see Vulnerability details.
• From an attack perspective, a vulnerable function is a function that consumes a part of the attacker's payload, which resulted in the exploitation of the vulnerability. For more context, see Attack details.