ADR Policies

ADR policies help security teams detect and respond to threats in application and runtime environments, including Kubernetes workloads, containers, hosts, and VMs.

Use ADR policies to control where runtime activity is monitored, which detection rules are applied, and how detections are handled. Policies can be configured to report incidents for review, send alerts to external systems, open tickets in integrated ticketing tools, or apply supported response actions.

An ADR policy includes:

• Scope — the clusters, namespaces, workloads, labels, or other runtime assets the policy monitors.
• Criteria — additional conditions that refine when the policy applies, such as workload risk factors or specific CVEs.
• Detection rules — the runtime threat behaviors the policy detects.
• Actions and notifications — how detections are handled, including dashboard reporting, alerts, ticket creation, and supported response actions.

When to use ADR policies

Use ADR policies when you want to monitor runtime environments for suspicious or malicious activity and control how those detections are handled.

ADR policies are useful when you need tailored detection coverage for specific environments, workloads, teams, or risk levels.

Common use cases include:

• Applying tailored detection coverage to production environments, critical workloads, sensitive namespaces, or high-risk assets.
• Detecting suspicious runtime behavior, such as unexpected command execution, privilege escalation, or lateral movement.
• Routing detections to the right teams, alerting channels, or ticketing systems.
• Applying supported response actions when active threats need to be contained.

Create an ADR policy

Create an ADR policy to define where runtime activity is monitored, which detection rules are applied, and how detections are handled.

To create an ADR policy:

1. In the ARMO platform, go to Policies > Threat Detection.
2. Click Add Policy.
3. Select Add ADR Policy.

Step 1: Add policy details

Enter the basic policy details:

• Policy name — a unique name that helps identify the policy.
• Description — an optional description that explains the policy’s purpose or intended scope.

Use a clear name that describes where or why the policy is used, such as Production runtime monitoring or Critical workloads ADR policy.

Step 2: Define the scope

Define the scope to control which runtime assets the policy monitors.

You can scope an ADR policy by selecting one or more resource attributes, such as cluster, namespace, workload, or labels. Use scope filters to apply the policy broadly across an environment or narrow it to specific workloads.

To define the scope:

1. Expand the Scope section.
2. Select a scope type, such as Cluster, Namespace, or Workload.
3. Select one or more values from the available resources.
4. Add additional scope filters to narrow the policy further.
5. Add another scope if you want the policy to apply to more than one independent set of resources.

Conditions within the same scope narrow the match. Multiple scopes are evaluated independently, so the policy applies to resources that match any configured scope.

For example, you can create a scope that applies only to workloads in a specific production namespace, or add another scope for a separate cluster or team-owned environment.

Step 3: Configure criteria

Use criteria to further refine when the ADR policy applies.

Criteria add conditions on top of the policy scope. While scope defines which assets are monitored, criteria help determine whether the policy should apply based on workload context, such as risk factors or known vulnerabilities.

You can configure criteria based on:

• Risk factors — workload attributes such as external exposure, privileged access, secret access, data access, or host access.
• CVEs — specific vulnerability identifiers associated with the workload.

For example, you can scope a policy to a production namespace, and then use criteria to apply it only to workloads that are externally exposed or affected by a specific CVE.

If you do not configure criteria, the policy applies based on the defined scope and selected detection rules.

Step 4: Configure actions and notifications

Configure how detections are handled when the policy conditions and selected rules match.

ADR policies can report detections to the main dashboard, send alerts to external systems, create tickets in integrated ticketing tools, and apply supported response actions.

You can configure the following options:

• Incident classification trigger — select which incident classifications should trigger the configured actions.
• Response — choose how the policy responds when a detection occurs.
• Quarantine — optionally apply additional isolation controls to the affected workload.
• Notifications — send alerts or create tickets through configured integrations.

Response actions

Select one of the available response actions:

Response actions apply only to supported assets. If a response action is not supported for a specific asset, the policy still reports the detection.

Quarantine

Quarantine options provide additional containment controls for affected workloads.

Available quarantine options may include:

• Apply Network Policy — isolates the workload using a network policy.
• Apply Seccomp Profile — restricts the workload’s system calls using a seccomp profile.

Notifications and tickets

Select one or more configured integrations to notify the relevant teams when detections occur.

Depending on the integration type, the policy can send alerts to notification channels or create tickets in integrated ticketing systems.

Step 5: Select rules

Select the rules that should be included in the ADR policy.

Rules define the runtime threat behaviors the policy detects, such as suspicious command execution, privilege escalation, lateral movement, or other potentially malicious activity.

Use the rules table to review and select the relevant rules for the policy. You can use filters to narrow the list by attributes such as severity, rule name, MITRE tactic, rule type, or tags.

To select rules:

1. Expand the Rules section.
2. Review the available rules.
3. Use filters to find rules relevant to the policy.
4. Select one or more rules.
5. Use Show selected only to review the selected rules before saving.

Each rule includes details such as severity, name, description, MITRE ATT&CK tactic, type, and tags.

Step 6: Save the policy

After configuring the policy scope, criteria, actions, notifications, and rules, click Save.

Newly created policies are enabled by default and apply to new detections moving forward. A policy does not evaluate data that was collected before the policy was created.

After the policy starts matching detections, incidents are reported to the main dashboard for review and tracking. Depending on the configured actions and notifications, detections may also trigger external alerts, create tickets, or apply supported response actions.

Manage ADR policies

You can manage ADR policies from the Threat Detection Policies page.

From the policies table, you can:

• Enable or disable a policy — control whether the policy applies to new detections.
• Edit a policy — update the policy scope, criteria, actions, notifications, or rules.
• Filter policies — find policies by name, type, response, cluster, namespace, or other available filters.

Disabling a policy stops it from applying to new detections. Existing incidents that were already reported remain available in the main dashboard for review and tracking.

ADR policy notes

Keep the following in mind when working with ADR policies:

• Criteria can refine when a policy applies based on workload risk factors or specific CVEs.
• Response actions apply only to supported assets.
• If a response action cannot be applied, the detection is still reported to the main dashboard.
• Quarantine options, such as network policy or seccomp profile, are available only where supported.
• Notification and ticketing integrations must be configured before they can be selected in a policy.