Monitoring rules - Third-party Vulnerability Analytics

Latest Dynatrace
How-to guide

What you’ll find on this page

Ways to define monitoring rules
How to set up new monitoring rules
How to set up classic monitoring rules deprecated
How monitoring rules influence coverage
Monitoring rule examples using attributes and labels
Frequently asked questions

To include or exclude specific entities from being monitored by Runtime Vulnerability Analytics, you can set up fine-grained monitoring rules for third-party vulnerabilities based on different criteria.

If you define custom monitoring rules, the global third-party vulnerability detection control mode applies to all entities that are not matched by a rule.

Monitoring criteria

There are currently two ways to set up monitoring rules:

Based on resource attributes and Kubernetes labels Recommended
- For details, see New monitoring rules.
Based on process group tag, host tag, and management zones
- For details, see Classic monitoring rules.

To start monitoring based on your rules, you need to activate the corresponding monitoring criteria. The two criteria cannot be in place at the same time. When one is activated, the other one is deactivated. You can switch between them at any time.

For environments created on Dynatrace version 1.313+, classic monitoring rules based on process group tag, host tag, and management zones aren't available; you can set up monitoring rules based on resource attributes and Kubernetes labels.

Activate the preferred monitoring criteria

To activate your preferred way to define monitoring

In Dynatrace, go to Settings > Analyze and alert > Application Security > General settings > Third-party Vulnerability Analytics.
Make one of the following changes:
- To activate the new rules, turn on Enable new monitoring rules.
- To activate the classic rules, turn off Enable new monitoring rules.

Your setting will persist until you change it again.

For environments created on Dynatrace version 1.313+, new monitoring rules are activated by default (no action is required from your side).

New monitoring rules

Recommended

With the new monitoring rules, you can define which processes and Kubernetes nodes and hosts should be monitored.

Process rules are based on resource attributes.
Kubernetes node and host rules are based on Kubernetes labels.

Kubernetes‑related resource attributes (for example, k8s.cluster.uid) apply to process groups, not Kubernetes nodes. To include or exclude Kubernetes nodes or hosts from monitoring, you must define Kubernetes label rules. If you only configure resource attribute rules, Kubernetes nodes may continue to be monitored and generate usage even when the related process groups are excluded.

Define rules

You can define new monitoring rules through the Dynatrace web UI or the Settings API.

In Dynatrace

In Dynatrace, go to Settings > Analyze and alert > Application Security > Rules for third-party vulnerabilities (New).
In the Resource attribute monitoring rules (…) tab, select Add new rule.
Follow the on-screen instructions.

A condition's key and value fields are free text fields. On-screen suggestions aren't mandatory.
Select Preview matching process group instances to verify if the condition matches the expected processes.

All conditions of a rule must match for the rule to apply.
Select Save changes.

To start monitoring based on your preferred monitoring criterion, make sure it's activated.

You can edit, disable, enable, or remove rules at any time.

Via Settings API

You can read or modify the rules using the Settings API.

To view a monitoring rule, use the GET an object request. Set the following parameters:

schemaIds=builtin:appsec.third-party-vulnerability-rule-settings
scopes=tenant

Example JSON response

{
"items": [
  {
    "objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ1YWYzOWNiZC0xM2I0LTNlZmItYTViYi1iYzljNTgyOTQxNze-71TeFdrerQ",
    "value": {
      "enabled": true,
      "vulnerabilityDetectionControl": {
        "monitoringMode": "MONITORING_OFF"
      },
      "resourceAttributeConditions": [
        {
          "resourceAttributeKey": "dt.entity.host",
          "matcher": "EQUALS",
          "resourceAttributeValue": "HOST-ABD42981B3D483AC"
        }
      ],
      "metadata": {
        "comment": ""
      }
    }
  },
  {
    "objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACQ4NDQ1OGRjNC1lM2Q2LTM2MGYtOWQyYy1lNmYwMTY1MzAwMza-71TeFdrerQ",
    "value": {
      "enabled": false,
      "vulnerabilityDetectionControl": {
        "monitoringMode": "MONITORING_ON"
      },
      "resourceAttributeConditions": [
        {
          "resourceAttributeKey": "attribute_2",
          "matcher": "EXISTS"
        }
      ],
      "metadata": {
        "comment": ""
      }
    }
  },
  {
    "objectId": "vu9U3hXa3q0AAAABADZidWlsdGluOmFwcHNlYy50aGlyZC1wYXJ0eS12dWxuZXJhYmlsaXR5LXJ1bGUtc2V0dGluZ3MABnRlbmFudAAGdGVuYW50ACRjNzk3M2I4YS1kYmFjLTMxMzAtYjdjMy0zYjYxNGMxOWU1NzK-71TeFdrerQ",
    "value": {
      "enabled": false,
      "vulnerabilityDetectionControl": {
        "monitoringMode": "MONITORING_OFF"
      },
      "resourceAttributeConditions": [
        {
          "resourceAttributeKey": "my.app.name",
          "matcher": "EQUALS",
          "resourceAttributeValue": "cool-app"
        }
      ],
      "metadata": {
        "comment": ""
      }
    }
  }
],
"totalCount": 3,
"pageSize": 100
}

To modify a monitoring rule, use the POST an object request.

Example JSON body

[
{
  "value": {
    "enabled": true,
    "vulnerabilityDetectionControl": {
      "monitoringMode": "MONITORING_OFF"
    },
    "resourceAttributeConditions": [
      {
        "resourceAttributeKey": "dt.entity.host",
        "matcher": "EQUALS",
        "resourceAttributeValue": "HOST-ABD42981B3D483AC"
      }
    ],
    "metadata": { "comment": "" }
  },
  "schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",
  "scope": "tenant"
},
{
  "value": {
    "enabled": false,
    "vulnerabilityDetectionControl": { "monitoringMode": "MONITORING_ON" },
    "resourceAttributeConditions": [
      {
        "resourceAttributeKey": "attribute_2",
        "matcher": "EXISTS"
      }
    ],
    "metadata": { "comment": "" }
  },
  "schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",
  "scope": "tenant"
},
{
  "value": {
    "enabled": false,
    "vulnerabilityDetectionControl": {
      "monitoringMode": "MONITORING_OFF"
    },
    "resourceAttributeConditions": [
      {
        "resourceAttributeKey": "my.app.name",
        "matcher": "EQUALS",
        "resourceAttributeValue": "cool-app"
      }
    ],
    "metadata": {
      "comment": ""
    }
  },
  "schemaId": "builtin:appsec.third-party-vulnerability-rule-settings",
  "scope": "tenant"
}
]

Monitoring rules evaluation

After you add, edit, or remove a rule, it can take up to 10 minutes for changes to take effect throughout the system. The configured monitoring rules are evaluated periodically (on internal worker runs) and on-demand (through calls to the REST API).

Exception: After an entity that was previously monitored is excluded from monitoring, it can take up to 70 minutes for changes to take effect throughout the system. For details, see How host coverage is calculated.

Regardless of the calling context, the rule evaluation stays the same: given a set of entities, the algorithm decides whether a specific entity should be monitored. The rules are processed in order until the first match.

If a rule matches a specific entity, the configured mode (Monitor or Do not monitor) is used and subsequent rules aren't evaluated for this particular entity.
If no rule matches a specific entity, the configured default mode (Monitor or Do not monitor) is used.

Classic monitoring rules

Although classic rules based on management zones and tags still work, they are scheduled for deprecation. We strongly recommend migrating to the new rules based on resource attributes or Kubernetes labels. Automatic migration isn't possible; for details, see FAQ.

Classic monitoring rules are based on process group tag, host tag, and management zones.

Define rules

You can define classic monitoring rules through the Dynatrace web UI or the Settings API.

In Dynatrace

To add a new rule

Go to Settings > Analyze and alert > Application Security > Rules for third-party vulnerabilities classic.
Select Add new rule to add a new rule.
Enter the requested information (mode, property, condition operator, and condition value).

The Process tag property applies to process groups, not processes.
Select Save changes.

You can edit, disable, enable, or remove rules at any time.

Via Settings API

You can read or modify the rules using the Settings API.

To view a monitoring rule, use the GET an object request. Set the following parameters:

schemaIds=builtin:appsec.rule-settings
scopes=tenant

Example JSON response

{
  "items": [
    {
      "objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkYTc4NjY0NGItZmVjNC0zNzliLWI0MWItNThmYzgzOWZmYWY5vu9U3hXa3q0",
      "value": {
        "enabled": true,
        "mode": "MONITORING_OFF",
        "property": "PROCESS_TAG",
        "operator": "EQUALS",
        "value": "super secret process"
      }
    },
    {
      "objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNDhkZGYxNDMtYzc2Mi0zYzIwLWI1ODAtNTNhODEwOGZlMDBivu9U3hXa3q0",
      "value": {
        "enabled": true,
        "mode": "MONITORING_ON",
        "property": "HOST_TAG",
        "operator": "NOT_EQUALS",
        "value": "Test"
      }
    },
    {
      "objectId": "vu9U3hXa3q0AAAABABxidWlsdGluOmFwcHNlYy5ydWxlLXNldHRpbmdzAAZ0ZW5hbnQABnRlbmFudAAkNmY1NjZkNmItYWMyNy0zOTg2LWE1OGItNTU2ZTI1NTE5NTcyvu9U3hXa3q0",
      "value": {
        "enabled": false,
        "mode": "MONITORING_ON",
        "property": "MANAGEMENT_ZONE",
        "operator": "EQUALS",
        "value": "Monitorme"
      }
    }
  ],
  "totalCount": 3,
  "pageSize": 100
}

To modify a monitoring rule, use the POST an object request.

Example JSON body

[
  {
      "value": {
        "enabled": true,
        "mode": "MONITORING_ON",
        "property": "HOST_TAG",
        "operator": "EQUALS",
        "value": "REST"
      },
    "scope": "tenant",
    "schemaId": "builtin:appsec.rule-settings"
  },
    {
      "value": {
        "enabled": true,
        "mode": "MONITORING_OFF",
        "property": "PROCESS_TAG",
        "operator": "NOT_EQUALS",
        "value": "Test-Process"
      },
    "scope": "tenant",
    "schemaId": "builtin:appsec.rule-settings"
  }
]

For Kubernetes environments, you need to add tags both on the host and on the Kubernetes node.

Monitoring rules evaluation

After you add, edit, or remove a rule, it can take up to 15 minutes for changes to take effect throughout the system. The configured monitoring rules are evaluated periodically (on internal worker runs) and on-demand (through calls to the REST API).

Regardless of the calling context, the rule evaluation stays the same: given a set of entities, the algorithm decides whether a specific entity should be monitored. The rules are processed in order until the first match. We recommend making each rule unique.
When you have a rule in place for a management zone or tag, and you add an entity to the same management zone or add the same tag to an entity, it can take up to 15 minutes (or longer for more complex environments) until the change is reflected in your monitoring rule.

For example, if you have a Do not monitor if host tag equals 'testsystem' rule, and you add the tag testsystem to a host, it can take up to 15 minutes until the newly tagged host stops being monitored.
If a rule matches a specific entity, the configured mode (Monitor, Do not monitor) is used and subsequent rules are not evaluated for this particular entity.
If no rule matches a specific entity, the global third-party vulnerability detection control mode is used.

Coverage impact

Monitoring rules directly influence host and process coverage. If a host or process group is excluded by a rule, it won't be monitored for vulnerabilities.

Latest Dynatrace To review how your monitoring rules affect overall coverage, see Assess coverage.

Use cases for new monitoring rules

Below are some common scenarios for defining monitoring rules for third-party vulnerabilities based on resource attributes and Kubernetes labels.

Monitor only the processes on specific hosts

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Find the host on which you want to monitor processes (for example, via Infrastructure & Operations).
Copy the hostname (for example, exchange.mycompany.local) from the overview.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Resource attribute key: host.name
  - Matcher: equals
  - Resource attribute value: hostname from step 3.
- Check the preview to see if the condition matches the expected processes.
- Save the rule.

Monitor only the Java processes on specific hosts

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Find the host on which you want to monitor processes (for example, via Infrastructure & Operations).
Copy the hostname (for example, exchange.mycompany.local) from the overview.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Monitor.
- To create a condition that matches the host, select Add new condition and enter the following data:
  - Resource attribute key: host.name
  - Matcher: equals
  - Resource attribute value: hostname from step 3.
- To create a condition that matches the technology, select Add new condition and enter the following data:
  - Resource attribute key: java.main.class
  - Matcher: exists
- Check the preview to see if the conditions match the expected processes.
- Save the rule.

Exclude .NET processes of specific hosts from monitoring

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Monitor.
Find the host on which you want to monitor processes (for example, via Infrastructure & Operations).
Copy the hostname (for example, exchange.mycompany.local) from the overview.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Do not monitor.
- To create a condition that matches the host, select Add new condition and enter the following data:
  - Resource attribute key: host.name
  - Matcher: equals
  - Resource attribute value: hostname from step 3.
- To create a condition that matches the technology, select Add new condition and enter the following data:
  - Resource attribute key: dotnet.dll.file
  - Matcher: exists
- Check the preview to see if the conditions match the expected processes.
- Save the rule.

Monitor only processes with a custom resource attribute

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Add a custom resource attributes (for example, {"stage":"production"}) to your entities.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Resource attribute key: key of the custom resource attribute from step 2 (for example, stage)
  - Matcher: equals
  - Resource attribute value: value of the custom resource attribute from step 2 (for example, production)
- Check the preview to see if the condition matches the expected processes.
- Save the rule.

Monitor only processes of a specific process group

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Find the process group on which you want to monitor processes (for example, via the Technologies & Processes Classic app).
Copy the process group ID (for example, PROCESS_GROUP-0123456789ABCDEF) from the URL.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Resource attribute key: dt.entity.process_group
  - Matcher: equals
  - Resource attribute value: ID of the process group from step 3.
- Check the preview to see if the condition matches the expected processes.
- Save the rule.

Monitor only processes running in a specific Kubernetes namespace

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Add a new resource attribute monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Resource attribute key: k8s.namespace.name
  - Matcher: equals
  - Resource attribute value: namespace name that should be monitored
- Check the preview to see if the condition matches the expected processes.
- Save the rule.

Monitor only Kubernetes nodes and hosts running a Linux-based OS for Kubernetes vulnerabilities

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Add a new Kubernetes monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Kubernetes label key: kubernetes.io/os
  - Matcher: equals
  - Kubernetes label value: linux
- Check the preview to see if the condition matches the expected Kubernetes nodes.
- Save the rule.

Monitor only EC2 instances for Kubernetes vulnerabilities

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Add a new Kubernetes monitoring rule:
- Set Third-party vulnerability control to Monitor.
- Select Add new condition and enter the following data:
  - Kubernetes label key: kubernetes.io/hostname
  - Matcher: ends with
  - Kubernetes label value: .ec2.internal
- Check the preview to see if the condition matches the expected Kubernetes nodes.
- Save the rule.

Exclude ARM-based nodes from monitoring of Kubernetes vulnerabilities

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Monitor.
Add a new Kubernetes monitoring rule:
- Set Third-party vulnerability control to Do not monitor.
- Select Add new condition and enter the following data:
  - Kubernetes label key: kubernetes.io/arch
  - Matcher: contains
  - Kubernetes label value: arm
- Check the preview to see if the condition matches the expected Kubernetes nodes.
- Save the rule.

Monitor all Java processes except the Java demo application process on the development hosts

In Dynatrace, go to Settings > Analyze and alert > Application security > General settings > Third-party Vulnerability Analytics and set Global third-party vulnerability detection control to Do not monitor.
Copy the fully qualified name (FQN) of the Java main class of your demo application (for example, com.example.my.DemoMain).
Find the development host on which you don't want to monitor the demo application process (for example, via Infrastructure & Operations).
Copy the hostname (for example, exchange.mycompany.local) from the overview.
Add a new resource attribute monitoring rule to exclude the demo application process on the development host:
- Set Third-party vulnerability control to Do not monitor.
- To create a condition that matches the development host, select Add new condition and enter the following data:
  - Resource attribute key: host.name
  - Matcher: equals
  - Resource attribute value: hostname from step 4.
- To create a condition that matches the demo application process, select Add new condition and enter the following data:
  - Resource attribute key: java.main.class
  - Matcher: equals
  - Resource attribute value: main class from step 2.
- Check the preview to see if the conditions match the expected processes.
- Save the rule.
Add a new resource attribute monitoring rule to monitor all remaining Java processes:
- Set Third-party vulnerability control to Monitor.
- To create a condition that matches the technology, select Add new condition and enter the following data:
  - Resource attribute key: java.main.class
  - Matcher: exists
- Check the preview to see if the condition matches the expected processes.
- Save the rule.

The order of the monitoring rules is important: As soon as a rule matches an entity, the entity won't be considered by any of the later rules. Consequently, specific rules should come before general rules.

FAQ

Does the order of the rules matter?

Can existing classic monitoring rules be automatically migrated to the new ones?

Automatic migration from the classic to the new monitoring rules isn't possible. You need to recreate the rules, or you can create new rules from scratch.

Is process restart required after enabling or disabling a monitoring rule?

Classic monitoring rules

No restart is required. For more information, see FAQ: Is restart required after enabling or disabling an Application Security feature or functionality?

What happens if a Do not monitor rule that applies gets added?

New monitoring rules Classic monitoring rules

New vulnerabilities for the processes that match the rule won't be created.
Existing vulnerabilities that only relate to matching processes are resolved.

What happens if a Do not monitor rule is deleted or doesn't apply anymore?

New monitoring rules Classic monitoring rules

New vulnerabilities for the processes that match the rule will be created.
Related resolved vulnerabilities are reopened.

Application Security FAQ

Monitoring rules - Third-party Vulnerability Analytics

Monitoring criteria

Activate the preferred monitoring criteria

New monitoring rules

Define rules

In Dynatrace

Via Settings API

Monitoring rules evaluation

Classic monitoring rules

Define rules

In Dynatrace

Via Settings API

Monitoring rules evaluation

Coverage impact

Use cases for new monitoring rules

Monitor only the processes on specific hosts

Monitor only the Java processes on specific hosts

Exclude .NET processes of specific hosts from monitoring

Monitor only processes with a custom resource attribute

Monitor only processes of a specific process group

Monitor only processes running in a specific Kubernetes namespace

Monitor only Kubernetes nodes and hosts running a Linux-based OS for Kubernetes vulnerabilities

Monitor only EC2 instances for Kubernetes vulnerabilities

Exclude ARM-based nodes from monitoring of Kubernetes vulnerabilities

Monitor all Java processes except the Java demo application process on the development hosts

FAQ

Does the order of the rules matter?

Can existing classic monitoring rules be automatically migrated to the new ones?

Is process restart required after enabling or disabling a monitoring rule?

What happens if a Do not monitor rule that applies gets added?

What happens if a Do not monitor rule is deleted or doesn't apply anymore?

Related topics