Rules

A rule in LEA Platform describes one setting a host should have, how to read it, how the server judges the output, and optionally how to fix it. Rules reach hosts through groups.

LEA ships with 132 rules (94 Linux, 33 macOS, 36 Windows variants) across 12 categories, tagged to frameworks such as NIST SP 800-53, CIS Controls, ISO 27001 and PCI DSS.

Rule structure

1. Validation

The command the agent runs to read the current state. Use read-only commands and send raw output; for example cat /etc/ssh/sshd_config, not grep. Each validation can be either:

• a shell command (sh on Linux/macOS, PowerShell on Windows), or
• an internal agent function.

2. Expect (judged on the server)

The checks the output must pass for the rule to count as compliant. The expect block stays on the server; the agent never sees it.

• re: regex that must match stdout or stderr
• not_re: regex that must not match
• returncode: expected exit code
• md5: checksum of the whole output

3. Remedy (optional, opt-in)

The command that fixes a failed setting. If validation fails and the rule has a remedy, the server sends it; the agent runs the remedy, runs the validation again, and reports both. Remedy attempts are kept in the result history. 40 of the 132 shipped rules include a remedy.

Rule editor

Basic fields:

• Rule name and Description
• Category (for example integrity, security, compliance)
• Active: turn the rule on or off
• Interval (seconds): the check cycle, e.g. 3600 = hourly
• Severity
• Command Info Key (tag): store the output as a dynamic tag on the host

Actions: Save, Import JSON, JSON Tools, Delete. The sidebar counts validations, verifications, remedies and parameters.

Multi-OS and multi-distribution

One rule can hold several validations, each for a system (Linux, Darwin, Windows) and optionally specific distributions (Ubuntu, Rocky, Oracle Linux, Alpine, openSUSE, ...). Each agent runs only the validation that matches its own OS and distribution.

Example, "offensive tools not running":

Dynamic tags

Set Command Info Key (tag), e.g. hostname, and the rule's stdout is stored on each host under that name. Use tags to filter hosts (see Search & filters) and to build dynamic groups with JSONPath (see Groups).

Parameters and secrets

Rules can use parameters in their commands:

Secret values are masked in the console. Hosts in probation after a re-enrollment never receive rules that use secret parameters.

Regex builder

Click the regex icon next to an expect field to test a pattern against sample text, check its syntax, and insert it into the rule. Patterns are Python-compatible.

Tips:

• Use word boundaries: \bnmap\b.
• Avoid ^ and $ on multi-line output unless you need them.
• Escape special characters: . * + ? ^ $ { } [ ] ( ) | \.

JSON tools

View (highlighted), edit or copy the full rule as JSON. Use it to keep rules in version control, share them between LEA servers, or clone a rule.

{
  "name": "Offensive tools not running",
  "category": "integrity",
  "active": true,
  "cycle": 3600,
  "cmd": {
    "validation": [
      { "command": "cat /proc/*/comm", "system": ["Linux"], "distribution": [] },
      { "command": "ps -ax", "system": ["Darwin"], "distribution": [] },
      { "command": "tasklist", "system": ["Windows"], "distribution": [] }
    ]
  }
}

Rule tags and filtering

On the Rules page, click Tags to filter by tag, combining tags with AND (all must match) or OR (any).

Example: high-risk Linux password rules mapped to NIST SP 800-53: risk:high + cat:password_policy + env:linux + std:NIST... with AND.

std: tags also decide which rules go into each framework's evidence snapshot (see Compliance evidence & reports).

Rules that need root

Rules that need elevated rights are tagged priv:required. On Linux, run those commands through lea_priv_wrapper.sh (see Agent) instead of giving the agent broad sudo rights.

Tip: test a validation command by hand on a target host (or with Live Execution) before you put it in a rule.