Custom rules

Overview

The Custom Rules capability in the ARMO Platform allows security engineers to define and manage their own detection logic for runtime threat detection.
Custom rules extend ARMO’s built-in detection library, enabling organizations to tailor security coverage for their unique workloads, compliance needs, and threat models.

Custom Rule Fields

FieldDescription
Rule NameA unique name identifying the rule.
Rule DescriptionA short explanation of what the rule detects or its purpose.
SeverityDefines the impact level if the rule triggers.
MITRE TacticMaps the rule to a MITRE ATT&CK Tactic.
MITRE TechniqueMaps to a specific MITRE ATT&CK Technique ID.
Validation messageUse it to describe the violation or provide guidance for investigation
Trigger eventDefines which eBPF event type trigger this rule, such as process execution, DNS, file I/O, or network activity
Rule Expression EditorThe logic engine for the rule. Supports CEL (Common Expression Language).
Templates Drop-downQuick-start CEL templates for common scenarios (e.g., detecting credential access, privilege escalation).
Rule InputDefines the event source(s) the rule applies to (e.g., process, file, network).
Rule OutputDefines the result or action of the rule (e.g., true/false, match object).
Validate Rule ButtonRuns syntax validation and test simulation.

What are the supported trigger event types and when to use them?

Supported Event Types

  • Capabilities - Triggered when a process requests or uses Linux capabilities (such as CAP_NET_ADMIN, CAP_SYS_ADMIN). Useful for detecting privilege escalation, container breakout attempts, or processes that exceed their intended permission boundaries.

  • dns – Captures DNS query and response events from workloads.
    Enables detection of suspicious or unauthorized domain lookups, data exfiltration via DNS tunneling, or communication with command-and-control servers.

  • exec – Triggered on process execution events (e.g., new processes starting).
    Used for rules that inspect parent/child relationships, command arguments, or process ancestry — for example, detecting a shell spawned by a web server or encoded command execution.

  • hardlink – Captures creation of hard links between files.
    Useful for identifying stealthy file persistence or evasion attempts, such as linking to sensitive binaries or configuration files.

  • http – Records HTTP request and response metadata from containers or applications.
    Ideal for detecting suspicious outbound web requests, indicators of exfiltration, or abnormal API interactions.

  • network – Triggered on TCP/UDP connection events, including outbound and inbound flows.
    Used to monitor traffic to unknown or restricted IP ranges, cryptomining pools, or external services outside of approved CIDRs.

  • open – Fires when a process opens, reads, or writes a file descriptor.
    Critical for detecting access to secrets, credentials, tokens, or sensitive configuration files such as /etc/passwd or /var/run/secrets/.

  • ssh – Observes SSH session activities initiated within a container or host.
    Enables rules for spotting unauthorized SSH connections, lateral movement, or embedded SSH clients used for data exfiltration.

  • symlink – Captures symbolic link creation or modification events.
    Can be used to detect symbolic link attacks (e.g., pointing a benign file to a sensitive system file) or persistence techniques leveraging filesystem links.

  • syscall – Provides raw visibility into system calls invoked by processes (e.g., clone, setns, mount, chmod).
    Useful for detecting low-level privilege manipulations, container creation, or direct kernel interactions that bypass standard monitoring layers.

How to create a custom rule?

  1. Navigate to Policies → Threat Detection → Rules → Add Custom Rule.
  2. Fill in all required fields using the guided form.
  3. Optionally use a template or the Learn CEL link to speed up authoring.
  4. Validate the rule using Validate Rule before saving.
  5. Save the Rule → The new rule appears in the Rules Table, where it can be enabled, disabled, cloned, or edited.
  6. Create a policy and select the created rule

Error Handling

  • All required fields must be filled before saving.
  • Invalid CEL expressions block saving until corrected.
  • Validation feedback is displayed inline with clear error messages.
  • Duplicate Rule Names trigger a unique name error.
  • Maximum character limits are enforced automatically.