d-and-r-rules

name: d-and-r-rules description: Working with Detection & Response rules in LimaCharlie — AI-assisted generation, validation, unit testing, historical replay, deployment, FP rules, stateful rules, behavioral detection patterns, suppression, alternate detection targets, and response actions. Use when creating, testing, modifying, or managing D&R rules, false positive rules, or understanding detection patterns. allowed-tools: - Bash - Read

D&R Rules

How to work with Detection & Response rules in LimaCharlie. This covers rule generation, validation, testing, deployment, stateful rules, behavioral detection patterns, suppression, alternate targets, and response actions.

Critical Rule: NEVER Write D&R Rules Manually

D&R rule syntax is validated against organization-specific schemas. Manual YAML will fail validation. Always use AI generation commands.

Rule Generation

Generate Detection Component

limacharlie ai generate-detection --description "Detect NEW_PROCESS events where the command line contains '-enc' and the process is powershell.exe" --oid <oid> --output yaml

Generate Response Component

limacharlie ai generate-response --description "Report the detection with priority 8, add tag 'encoded-powershell' with 7 day TTL" --oid <oid> --output yaml

Common Response Actions

Validation

Always validate before deploying. Write YAML to temp files, then validate:

cat > /tmp/detect.yaml << 'EOF'
<detection_yaml>
EOF
cat > /tmp/respond.yaml << 'EOF'
<response_yaml>
EOF
limacharlie dr validate --detect /tmp/detect.yaml --respond /tmp/respond.yaml --oid <oid>

Unit Testing

Test rules against crafted sample events:

# Write combined rule file
cat > /tmp/rule.yaml << 'EOF'
detect:
  <detection>
respond:
  <response>
EOF

# Write test events
cat > /tmp/events.json << 'EOF'
[
  {
    "routing": {"event_type": "NEW_PROCESS"},
    "event": {
      "COMMAND_LINE": "powershell.exe -enc SGVsbG8=",
      "FILE_PATH": "C:\\Windows\\System32\\powershell.exe"
    }
  }
]
EOF

limacharlie dr test --input-file /tmp/rule.yaml --events /tmp/events.json --trace --oid <oid> --output yaml

Create both positive tests (MUST match) and negative tests (MUST NOT match).

Historical Replay

Test rules against real historical data. The rule must be deployed first (use a temporary name):

# Deploy as temporary rule
limacharlie dr set --key temp-test-rule --input-file /tmp/rule.yaml --oid <oid>

# Calculate time range
start=$(date -d '1 hour ago' +%s) && end=$(date +%s)

# Estimate volume first (dry run)
limacharlie dr replay --name temp-test-rule --start $start --end $end --dry-run --oid <oid> --output yaml

# Run replay
limacharlie dr replay --name temp-test-rule --start $start --end $end --oid <oid> --output yaml

# With selector
limacharlie dr replay --name temp-test-rule --start $start --end $end --selector 'plat == "windows"' --oid <oid> --output yaml

# Clean up temporary rule
limacharlie dr delete --key temp-test-rule --confirm --oid <oid>

Deployment

Create/Update a Rule

cat > /tmp/rule.yaml << 'EOF'
detect:
  <validated_detection>
respond:
  <validated_response>
EOF
limacharlie dr set --key <rule-name> --input-file /tmp/rule.yaml --oid <oid>

List Rules

limacharlie dr list --oid <oid> --output yaml

Get a Rule

limacharlie dr get --key <rule-name> --oid <oid> --output yaml

Delete a Rule

limacharlie dr delete --key <rule-name> --confirm --oid <oid>

Rule Hive Namespaces

D&R rules are stored across three hives:

When listing or auditing rules, check all three for the full picture.

False Positive (FP) Rules

FP rules suppress known benign detections without modifying the original detection rule. FP rules operate on the detection output, not the raw event — the paths reference detection fields, not event fields.

Create FP Rule

cat > /tmp/fp-rule.yaml << 'EOF'
detection:
  op: and
  rules:
    - op: is
      path: cat
      value: suspicious_process
    - op: is
      path: routing/hostname
      value: SCCM-SERVER
EOF
limacharlie fp set --key <fp-rule-name> --input-file /tmp/fp-rule.yaml --oid <oid>

FP Rule Paths

FP rules operate on detection output. Key paths:

List / Delete FP Rules

limacharlie fp list --oid <oid> --output yaml
limacharlie fp delete --key <fp-rule-name> --confirm --oid <oid>

Detection Logic Operators

Stateful Rules

Stateful rules track and remember the state of past events to detect patterns over time. Unlike stateless rules (which evaluate events in isolation), stateful rules detect patterns like "process A spawning process B" or "5 failed logins within 60 seconds."

Events in LimaCharlie have well-defined relationships via routing/this, routing/parent, and routing/target. Stateful rules leverage these relationships.

Detecting Children / Descendants

Use with child (direct children only) or with descendant (children, grandchildren, etc.) to detect process tree patterns:

# Detect cmd.exe spawning calc.exe
event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: cmd.exe
case sensitive: false
with child:
  op: ends with
  event: NEW_PROCESS
  path: event/FILE_PATH
  value: calc.exe
  case sensitive: false

This detects cmd.exe → calc.exe but NOT cmd.exe → firefox.exe → calc.exe. Use with descendant to match at any depth.

Complex Child Patterns with and/or

Stateful rules support full operator nesting. Detect outlook.exe spawning a browser AND dropping a PowerShell script:

event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: outlook.exe
case sensitive: false
with child:
  op: and
  rules:
    - op: ends with
      event: NEW_PROCESS
      path: event/FILE_PATH
      value: chrome.exe
      case sensitive: false
    - op: ends with
      event: NEW_DOCUMENT
      path: event/FILE_PATH
      value: .ps1
      case sensitive: false

Detecting Proximal Events (Repetition)

Use with events to detect event repetition on the same sensor within a time window:

# 5 failed login attempts within 60 seconds
event: WEL
op: is windows
with events:
  event: WEL
  op: is
  path: event/EVENT/System/EventID
  value: '4625'
  count: 5
  within: 60

Counting Events in Process Trees

with child and with descendant also support count and within:

# Outlook writing 5+ .ps1 files within 60 seconds
event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: outlook.exe
case sensitive: false
with child:
  op: ends with
  event: NEW_DOCUMENT
  path: event/FILE_PATH
  value: .ps1
  case sensitive: false
  count: 5
  within: 60

Choosing Which Event to Report

By default, stateful detections include the initial parent event. Use report latest event: true to include the most recent matching event instead:

event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: outlook.exe
case sensitive: false
report latest event: true
with child:
  op: ends with
  event: NEW_PROCESS
  path: event/FILE_PATH
  value: chrome.exe
  case sensitive: false

Note: non-report actions (like task) ALWAYS observe the latest event, regardless of this flag. So <<routing/parent>> in a task action references the latest event's parent.

Flipping Back to Stateless

Within a with child/with descendant context, all operators are stateful (matching across multiple events). To force a sub-operator to match a single event, use is stateless: true:

event: NEW_PROCESS
op: ends with
path: event/FILE_PATH
value: outlook.exe
case sensitive: false
with child:
  op: and
  is stateless: true
  rules:
    - op: ends with
      event: NEW_PROCESS
      path: event/FILE_PATH
      value: evil.exe
      case sensitive: false
    - op: contains
      path: event/COMMAND_LINE
      value: something-else
      case sensitive: false

With is stateless: true, BOTH conditions must match the SAME event (a single NEW_PROCESS that is evil.exe AND contains "something-else").

Stateful Rules Caveats

• Forward-looking only: stateful rules track state from the moment they are deployed. Changing a rule resets ALL state tracking — the parent event must re-occur for the rule to start watching for children again.
• FIFO processing: events from a single sensor are processed first-in-first-out, in order. One slow rule (e.g., with wait or external lookup) blocks processing of all subsequent events from that sensor.

Behavioral Detection Patterns

LimaCharlie supports behavioral detection using D&R rules and the suppression system. These patterns detect anomalous behavior without external analytics infrastructure.

Suppression System

Suppression is the mechanism for frequency control. It is supported on every response action, not just report. Every action can have its own suppression parameters.

Suppression Parameters

Three Suppression Modes

1. Frequency limit (max_count only): fire at most N times per period per key
2. Threshold activation (min_count + max_count): suppress until min_count reached, then fire once
3. Variable count (count_path + min_count/max_count): increment counter by event value, not by 1

Key Template Namespaces

Gotcha — metadata key naming: the .mtd key name is derived from the resource name with special characters replaced by underscores. lcr://api/ip-geo becomes .mtd.lcr___api_ip_geo. hive://lookup/my-list becomes .mtd.my_list.

Gotcha — key is an AND: all keys together form the uniqueness key. Missing a key component creates separate suppression buckets. Adding a constant string to keys (e.g., 'my-rule-name') prevents cross-rule suppression collisions.

Suppression Limitations

• Fixed time windows that reset on expiry (not rolling/sliding)
• Maximum period: 30 days (720h)
• Static thresholds only — no adaptive baselines
• No statistical comparison — detects "above N" or "first occurrence," not "unusual vs baseline"

First-Seen Detection

Suppression with max_count: 1 fires exactly once per unique key combination per window — a first-seen detector.

First time a host resolves a domain (within 30 days):

detect:
  event: DNS_REQUEST
  op: exists
  path: event/DOMAIN_NAME

respond:
  - action: report
    name: new-domain-for-host
    suppression:
      max_count: 1
      period: 720h
      is_global: false
      keys:
        - 'first-domain'
        - '{{ .event.DOMAIN_NAME }}'

First time a user logs in from a new country (using GeoIP lookup):

detect:
  event: USER_LOGIN
  op: lookup
  path: event/SOURCE_IP
  resource: lcr://api/ip-geo

respond:
  - action: report
    name: first-login-from-country
    suppression:
      max_count: 1
      period: 720h
      is_global: true
      keys:
        - 'first-country'
        - '{{ .event.USER_NAME }}'
        - '{{ .mtd.lcr___api_ip_geo.country.iso_code }}'

First time a threat-intel-matched hash appears on a host:

detect:
  event: NEW_PROCESS
  op: lookup
  path: event/HASH
  resource: hive://lookup/threat-intel-hashes

respond:
  - action: report
    name: first-ti-match-on-host
    suppression:
      max_count: 1
      period: 720h
      is_global: false
      keys:
        - 'first-ti-hash'
        - '{{ .event.HASH }}'
        - '{{ .mtd.threat_intel_hashes.category }}'

Cardinality Detection (Two-Rule Chaining)

Detect when an entity accumulates too many unique values. Requires two rules:

1. Rule 1 (dedup): reports once per unique value using max_count: 1
2. Rule 2 (count): targets the detection from Rule 1 using the detection target and counts with min_count: N

Detect a host resolving 100+ unique domains in 1 hour (DGA/C2):

# Rule 1: Deduplicate — one report per unique domain per sensor per hour
detect:
  event: DNS_REQUEST
  op: exists
  path: event/DOMAIN_NAME

respond:
  - action: report
    name: dns-domain-observed
    suppression:
      max_count: 1
      period: 1h
      is_global: false
      keys:
        - 'dns-dedup'
        - '{{ .event.DOMAIN_NAME }}'

# Rule 2: Count — fire when unique domains exceed threshold
detect:
  event: dns-domain-observed
  target: detection
  op: exists
  path: detect

respond:
  - action: report
    name: excessive-dns-diversity
    suppression:
      min_count: 100
      max_count: 100
      period: 1h
      is_global: false
      keys:
        - 'dns-diversity-count'

Detect a user accessing 5+ unique hosts in 6 hours (lateral movement):

# Rule 1: Deduplicate per (user, host) — global because user moves across sensors
detect:
  event: USER_LOGIN
  op: exists
  path: event/USER_NAME

respond:
  - action: report
    name: user-host-access-observed
    suppression:
      max_count: 1
      period: 6h
      is_global: true
      keys:
        - 'lateral-dedup'
        - '{{ .event.USER_NAME }}'
        - '{{ .routing.hostname }}'

# Rule 2: Count unique hosts per user
detect:
  event: user-host-access-observed
  target: detection
  op: exists
  path: detect

respond:
  - action: report
    name: possible-lateral-movement
    suppression:
      min_count: 5
      max_count: 5
      period: 6h
      is_global: true
      keys:
        - 'lateral-count'
        - '{{ .detect.event.USER_NAME }}'

Volume Detection

The count_path parameter increments the counter by an event value instead of 1. Alert when a host uploads more than 1 GB to external IPs in 24 hours:

detect:
  event: USP_NETFLOW
  op: is public address
  path: event/dst_ip

respond:
  - action: report
    name: high-egress-volume
    suppression:
      min_count: 1073741824
      max_count: 1073741824
      period: 24h
      is_global: false
      count_path: event/bytes_out
      keys:
        - 'egress-volume'

Multi-Signal Aggregation

Multiple rules can feed into a shared suppression counter. When independent detections report the same name, the counter accumulates across them:

# Rule A: Suspicious DNS
respond:
  - action: report
    name: indicator-hit

# Rule B: Sensitive process access
respond:
  - action: report
    name: indicator-hit

# Aggregation rule — fires when 5 indicators on one host in 1 hour
detect:
  event: indicator-hit
  target: detection
  op: exists
  path: detect

respond:
  - action: report
    name: high-risk-host
    priority: 1
    suppression:
      min_count: 5
      max_count: 5
      period: 1h
      is_global: false
      keys:
        - 'risk-aggregation'

Alternate Detection Targets

D&R rules run against edr events by default, but there are 7 other targets:

Detection Chaining (target: detection)

Run rules on detections generated by other rules. The event: field refers to the name of the detection from the original rule's report action.

# Run when virus-total-hit detection occurs on a VIP host
target: detection
op: and
rules:
  - op: is
    path: cat
    value: virus-total-hit
  - op: is
    path: routing/hostname
    value: ceo-laptop

Double-Underscore Reports (Internal Only)

Prefixing a report name with __ makes the detection visible to chained D&R rules but NOT sent to outputs:

- action: report
  name: __intermediate-signal

This is useful for multi-stage detection pipelines that shouldn't generate external alerts at intermediate stages.

The publish Flag

publish: true (default) sends the detection to outputs. publish: false keeps it internal — visible to detection chaining but not stored or forwarded.

Deployment Target

Detect sensor lifecycle events: enrollment, sensor_clone, sensor_over_quota, deleted_sensor.

# Auto-fix cloned sensors on Windows
target: deployment
event: sensor_clone
op: is windows

Artifact Target

Run detection logic against parsed artifact content (logs, PCAP, WEL). Only supports the report action.

Special parameters: artifact type (txt, pcap, zeek, wel, auth), artifact path (path prefix match), artifact source (source hostname match).

target: artifact
artifact type: txt
artifact path: /var/log/auth.log
op: matches
re: .*(authentication failure|Failed password).*
path: /text
case sensitive: false

Schedule Target

Timed events triggered at intervals per-organization or per-sensor. Useful for periodic checks (sweeps, health probes, starting a scheduled AI agent).

The event: is a cadence token, not an edr event type: <interval>_per_org or <interval>_per_sensor, where interval is one of 30m, 1h, 3h, 6h, 12h, 24h, 168h. The detect must still carry an op — a schedule detect with no op is rejected with missing op. Use op: exists against path: / to match every firing:

# Fire once per org every hour (e.g. to start a supervisory AI agent)
target: schedule
event: 1h_per_org
op: exists
path: /

respond:
  - action: start ai agent
    definition: hive://ai_agent/my-fde
    debounce_key: fde-my-fde

A scheduled rule does NOT take a tests block (there is no event payload to simulate) — unlike per-event rules, where tests is mandatory.

Billing Target

Billing and quota events. Useful for usage threshold alerts (e.g., alert when extension usage exceeds a budget).

Response Actions Deep Dive

Report Action

- action: report
  name: my-detection-name
  publish: true       # defaults to true — set false to keep internal
  priority: 3         # integer, added to detection as `priority`
  metadata:           # free-form, added as `detect_mtd`
    author: security-team
  detect_data:        # free-form, added as structured IOCs
    hash: '{{ .event.HASH }}'

The name, metadata, and detect_data parameters support template strings. The template context is the detection itself, so use .detect.event.USER_NAME, not .event.USER_NAME.

Tag Actions

- action: add tag
  tag: vip
  ttl: 300            # optional, seconds until tag expires
  entire_device: true  # optional, applies to ALL sensors sharing Device ID

Gotcha: entire_device: true applies the tag to every sensor with the same Device ID, not just the current sensor. Useful for cross-sensor coordination (e.g., start full PCAP on all sensors on a device).

Sensor Variables (add var / del var)

Variables are per-sensor key-value stores that allow D&R rules to share state across different rules on the same sensor. See the sensor-variables documentation for patterns.

- action: add var
  name: recently-seen-paths
  value: <<event/FILE_PATH>>
  ttl: 300

Read variables in detection rules using [[variable_name]] syntax:

op: is
path: event/FILE_PATH
value: '[[recently-seen-paths]]'

Limits: 16 variable names per sensor, 32 values per variable.

Network Isolation

isolate network is persistent — survives reboots. Sets a cloud flag that re-isolates the sensor on reconnect. Only allows traffic to LimaCharlie cloud.

segregate_network (sensor command via task) is stateless — resets on reboot.

Always prefer isolate network (D&R action) over segregate_network (sensor command) for reliable isolation.

Wait Action

- action: wait
  duration: 10s

Gotcha: wait blocks processing of ALL events from that sensor for the specified duration. D&R rules run at wire-speed and in-order, so a 60-second wait means 60 seconds of events queue up.

Extension Request

- action: extension request
  extension name: dumper
  extension action: dump
  extension request:
    sid: '{{ .routing.sid }}'

The extension request parameter is a template transform. Use based on report: true to base the transform on the latest report action's output instead of the original event (requires a report action before it).

Managed Rulesets

Soteria EDR Rules

Professional detection rules covering Windows, Linux, and macOS with MITRE ATT&CK mapping. LimaCharlie acts as broker — Soteria never accesses your data. Rules cannot be edited.

Required events for Soteria EDR: CODE_IDENTITY, DNS_REQUEST, EXISTING_PROCESS, FILE_CREATE, FILE_MODIFIED, MODULE_LOAD, NETWORK_CONNECTIONS, NEW_DOCUMENT, NEW_NAMED_PIPE, NEW_PROCESS, REGISTRY_WRITE, REGISTRY_CREATE, SENSITIVE_PROCESS_ACCESS, THREAD_INJECTION

Community Rules

AI-converted rules from Sigma, Anvilogic, Panther, Okta. Searchable by CVE, keyword, or MITRE ATT&CK ID. Available from Automation → Rules → Add Rule → Community Library.

Naming Conventions

Rules: [category]-[description] (e.g., lateral-movement-psexec, ransomware-vssadmin-delete)

FP Rules: fp-[category]-[pattern]-[YYYYMMDD] (e.g., fp-suspicious-process-sccm-server-20250415)

Gotchas Summary