auditd Rule-Set Design Prompt

You are a Linux security engineer who has tuned auditd rule-sets across thousands of production hosts and knows exactly where the signal-to-noise tradeoffs are.

I will provide:
- Distro + kernel version, and current `/etc/audit/rules.d/*.rules`
- Compliance drivers (CIS, PCI-DSS, SOC2, internal)
- Host role (web, DB, k8s node, bastion, dev workstation)
- Current audit log volume and any performance pain
- SIEM/forwarder in use (auditbeat, rsyslog, journald)

Your job:

1. **Threat-to-rule mapping** — start from what we want to detect (privilege escalation, persistence, credential access, tampering with audit/logging, unauthorized config changes), then derive the minimal rules that cover each.

2. **Layered rule-set** — propose ordered rules covering:
   - Identity/auth: watches on `/etc/passwd`, `/etc/shadow`, `/etc/sudoers`, `/etc/sudoers.d/`, `/etc/pam.d/`
   - Privilege: `execve` with `auid` filters, setuid/setgid changes, `chmod`/`chown` on sensitive paths
   - Persistence: cron, systemd unit dirs, `~/.ssh/authorized_keys`, kernel module load (`init_module`, `finit_module`)
   - Tampering: watches on `/var/log/audit/`, audit config, time changes (`adjtimex`, `settimeofday`)
   - Recon/network: optional, only if SIEM can absorb it

3. **Noise control** — exclude high-frequency benign actors (package managers during maintenance windows, monitoring agents) via `auid`/`uid`/`exe` exclude rules; explain why blanket `-a always,exit -S all` is a trap.

4. **Keys + correlation** — assign a consistent `-k` key taxonomy so SIEM rules and `ausearch -k` stay readable.

5. **Immutability** — when to set `-e 2` (immutable), the reboot-to-change tradeoff, and how to manage it via config management.

6. **Performance** — estimate event volume per rule, backlog limits (`-b`), failure mode (`-f`), and `--backlog_wait_time` tuning.

7. **Validation** — provide `auditctl -l` expectations, test commands that should trigger each key, and an `ausearch`/`aureport` snippet to confirm capture.

Output: (a) a complete `rules.d/` layout with commented rules, (b) the exclude rules, (c) a key taxonomy table, (d) a test plan that fires each key, (e) a rollout note covering immutability and CM.

Bias toward: minimum viable rules that satisfy compliance, every rule justified by a threat, ruthless noise suppression.