Rmagent So

rmagent-so — The Security Observatory

The witness-question half of the RMAgent security observatory: ask a small set of allowlisted named questions, track the identities that matter, and never copy the log home.

This is the Security Observatory engine, split out of rmagent-windows so the question half can be reasoned about (and loaded) on its own. rmagent-windows remains the complete, runnable skill; rmagent-fr is the Flight Recorder (tracing) half. The three skills share one constitution.

Non-negotiables

• Watch only. No actuate. No systemctl stop, no usermod, no firewall edits.
• Allowlisted questions only — never an arbitrary shell.
• Capped answers (32 KB) — oversized pulls become holes, never a lake.
• Your estate only. No box you do not administer.
• No tight retry on a silent host.
• Credentials never in the inventory file — env or ~/.rmagent/creds.json.
• Never trust a "no findings" result until you have confirmed the witness can see.

The questions

canary — the patient-zero tripwire (Rev 15)

A canary is a decoy identity that exists only to be touched. Any authentication attempt against it is critical by definition — there is no legitimate reason to log on as honeyadmin. This turns patient-zero detection from a graph walk into a tripwire: near-zero false positive, no correlation needed.

• Declare canaries in the inventory: canaries: [honeyadmin, svcbackup2]
• With none declared, the payload falls back to decoy-name heuristics (canary, honey, decoy, tripwire, …) so an estate that planted decoys without updating the inventory still gets coverage
• A hit surfaces as a critical canary_tripped finding in both drift and correlate, carrying the source IPs — the shortlist for actuate.py block_ip

The scripts

The signal-aware cap (Rev 15)

The flat 32 KB cap was an evasion surface: a noisy host (or an attacker flooding events) pushed the signal past the window and the whole answer became a hole — the loudest box got ignored.

Now an over-budget answer is triaged, not dropped: low-signal rows are shed first, and rows carrying critical event IDs (4648, 4672, 5861, 1102, 4104, 4698, 7045, 4732, 4688) always survive the trim. The cap is never raised — we only choose what survives it. Still no lake.

An answer that was trimmed carries capped: true and a cap_note, so the operator knows the window was narrowed rather than being silently deceived.

Security Trace Context (STC) — context propagates, data does not

The W3C traceparent analog, but the unit is a principal's walk across an estate, not a request across services:

stc: case=CASE-20260825-143022; principal=Administrator;
     window=2h; origin=jh1; depth=2; ticket=PAY-4419;
     apptrace=4bf92f3577b34da6a3ce929d0e0e4736

• Context travels; event data never does. When a hunt moves from WS1 to WS2, WS2 receives "I'm looking for Administrator, case X, depth 2" — not WS1's logs. Each host answers from its own local tools.
• depth is the distributed circuit breaker. The walk budget (≤ 8) applies across the WHOLE trace, not per-host — this is what stops a distributed hunt becoming a worm.
• ticket is the business join (a payment id, incident number) — the Flight Recorder link.
• apptrace (v2) is the application trace id — an OTel trace_id or W3C traceparent observed on a witness. It lets ONE case serve both lenses: "who walked?" (principal) and "which request was slow?" (app trace). Identity-led and request-led correlation on the same tape.

Start a hunt joined to an application request:

python3 hunt.py --inventory estate.yaml --since 2h \
  --ticket PAY-4419 --app-trace-id 4bf92f3577b34da6a3ce929d0e0e4736

Every emitted OTel span then carries rmagent.app_trace_id, so in Grafana/Jaeger the security walk and the application request appear as correlatable traces — one waterfall for "the request was slow", one for "and here is who was walking the estate at that moment".

Injection-hardened: the STC is a delimiter format, so a crafted value like X; depth=9; principal=root could rewrite the walk budget. Values containing ; or = are rejected at construction AND at decode, and duplicate keys are rejected at decode. test_stc_v2.py asserts all of it.

Triage (Rev 15)

With 50 findings across 10 hosts, an operator needs to know what to actuate FIRST. Every correlate finding now carries a triage_rank, a triage_why, and recommended_actions (drawn only from the actuate allowlist):

The blind check (standing rule)

Found live on WS2: the Logon audit policy was Failure-only, so edges returned zero logons while an Administrator session was connected. Every "clean" report from that box was a silent false negative.

Every attest now carries raw_4624_24h (unfiltered 4624 count), blind_check (per-subcategory ok/BLIND/unknown for the sources the questions depend on), and blind_count (must be 0). drift treats a growing blind_count as critical.

Rev 17 hardens the check itself:

• Locale-invariant. auditpol is parsed by SUBCATEGORY GUID (the {0CCE...} column in the CSV), not display name — a non-English Windows no longer reports every entry as unknown, which used to make blind_count=0 and the box look sighted.
• Two new sources the questions depend on: Process CmdLine (4688 command-line inclusion — without it lolbin_spawns.c is null and the LOLBin detection is decorative) and ScriptBlock Logging (4104 — without it pslogs is ALWAYS empty). These are the two an attacker is most likely to switch off.

Standing rule: never trust a "no findings" result until you have confirmed the witness can see. An empty answer is not a clean answer — and (Rev 17) neither is an unparseable one: a payload that fails to emit JSON is a hole, not ok with a raw blob.

Relationship to the other skills