# Enodia Sentinel Roadmap

This roadmap moves Enodia Sentinel from a single-host IDS/IPS/EDR agent into a
fuller host security platform: detect, prevent, verify, investigate, respond,
and assure. Dates are intentionally not promised here; the sequence matters more
than calendar precision.

## Release Tracks

| Track | Goal |
|---|---|
| Sensor | Better host telemetry, event capture, and detection coverage. |
| Prevention | Safe containment and recovery actions that start as dry-run plans and require explicit review before any state change. |
| Integrity | Stronger proof that files, packages, baselines, and Sentinel itself were not silently modified. |
| Incident | Group alerts, build timelines, and export evidence. |
| Response | Add safe, auditable containment and recovery workflows. |
| Fleet | Let multiple hosts report to a small controller without making the local agent dependent on it. |
| Assurance | Move trust anchors off-box or below user space. |

## v0.8: Documentation, Posture, and Incident Shape

Purpose: make the current agent easier to operate and create the data model for
work that is bigger than single alerts.

- ✅ Add `incident_id` grouping around related alerts (process-lineage first,
  time-window fallback) while preserving the existing alert JSON — `incident_id`
  is added at snapshot-report level.
- ✅ Add an incident timeline generator: `incident show` builds a time-ordered
  view across an incident's member snapshots (time, severity, signatures, PIDs).
  Richer sources (package transactions, dedicated FIM-diff lines) can follow.
- ✅ Add `enodia-sentinel incident list/show/export`.
- ✅ Add host posture checks (`enodia-sentinel posture check`):
  SSH root/password/empty-password login, passwordless and writable sudoers,
  world-writable PATH components, loose sensitive-file permissions, and disabled
  package signatures. Still to come: unexpected enabled services and unsafe
  systemd unit settings.
- ✅ Add a machine-readable `status --json` command for automation.
- ✅ Update the red-team harness so every current detection has a named drill and
  expected `sid` (`sentinel-redteam --list`), with a PASS/MISS verification pass.
- ✅ Document incident response runbooks for reverse shells, persistence, trojaned
  binaries, hidden listeners, and sensor tampering ([RUNBOOKS.md](RUNBOOKS.md)).
- ✅ Add Gonzalo/Peopleswar-style behavior coverage: input-device keylogging,
  credential-store/private-key access, SCTP/DCCP/raw/packet-family traffic, and
  raw ICMP/special-protocol rootcheck detection.
- ✅ Add process-hiding and memory-obfuscation coverage: `/proc` vs `ps`
  cross-view checks plus memory-map scans for hide libraries, RWX memory, and
  executable anonymous/memfd/deleted mappings.
- ✅ Add event-driven memory telemetry for short-lived `mprotect`/`mmap` RWX,
  `memfd_create`, `ptrace`, seccomp, cross-process memory access, and memory
  locking syscalls.

Exit criteria:

- One alert can become one incident artifact.
- Operators can answer "what changed around this alert?" without reading every
  raw snapshot manually.
- Posture checks report reviewable findings but do not block daemon startup.

## v0.9: Response and Recovery

Purpose: move from "tell me" to "help me act" without unsafe automation.

- ✅ Add response plan generation:
  `enodia-sentinel respond plan <incident-id>`.
- ✅ Persist CLI-generated dry-run plans under `response-plans/` and append
  `response-audit.log` records for review/handoff.
- ✅ Add dry-run first actions for evidence freeze, process freeze/terminate,
  outbound IP block, systemd stop/disable, suspicious-file quarantine,
  package-owner lookup, and follow-up verification.
- Add package reinstall/restore planning after trusted-media and package-manager
  semantics are designed for pacman, dpkg, and rpm.
- Require explicit `--apply` for changes; default to read-only plans.
- Extend response audit logs to any future state-changing `--apply` workflow.
- Add baseline reconciliation:
  accept legitimate FIM/package/listener/SUID changes with a recorded reason.
- Add richer false-positive suppression suggestions that can emit TOML snippets
  but never modify config automatically.
- Add recovery checks:
  "verify package", "re-run rootcheck", "confirm no persistence diff", and
  "confirm heartbeat/dashboard visible from watchdog".

Exit criteria:

- An operator can go from alert to reviewed response plan with one command.
- Any state-changing action is explicit, logged, reversible where possible, and
  testable in a safe fixture.

## v1.0: Stable Local Platform

Purpose: define a stable single-host product.

- Commit to stable JSON schemas for alerts, incidents, status, and response
  audits.
- Add compatibility tests for schema evolution.
- Add documentation versioning and manpage-style command reference.
- Harden packaging for Arch first, then document Debian/RPM install paths.
- Add signed release artifacts and checksums.
- Improve dashboard from alert browser to local console:
  incidents, posture, integrity state, response plans, and watchdog status.
- ✅ Add a local dashboard Settings menu with persistent themes for dark
  console, light evidence review, high-contrast operation, LGBTQ, Trans,
  Dracula, Solarized Dark/Light, and Twilight palettes.
- ✅ Add dashboard theme contrast/visual smoke checks so readable text and
  meaningful status colors are preserved across every palette.
- Keep the dashboard read-only unless a separate authenticated write path is
  designed and reviewed.

Exit criteria:

- The local agent can be installed, operated, upgraded, and integrated without
  reading source code.
- JSON and command contracts are stable enough for downstream automation.

## v1.1: Event Coverage and Correlation

Purpose: reduce blind spots and connect related signals.

- Generalize the exec-rule engine into a typed host-event rule engine:
  `exec`, `tcp_connect`, `bind`, `listen`, `accept`, `file_write`,
  `chmod/chown`, `setuid/setgid`, `capset`, and module-load events.
- Keep rules declarative and Snort-like:
  `sid`, `msg`, `severity`, `classtype`, `event`, and match fields such as
  process name, parent process, argv regex, path prefix, peer IP/port, UID/GID,
  package ownership, and lineage.
- Add eBPF event sources:
  `tcp_connect`, `bind`, `accept`, module load, privilege transitions, and
  writes to watched persistence paths.
- Build process lineage across polling and event sources.
- Correlate multi-stage behavior:
  web service spawns shell, shell downloads payload, payload adds persistence,
  listener appears, and FIM changes.
- Add configurable correlation windows and severity escalation rules, including:
  - `exec_rule.web-rce` + suspicious egress + persistence within 10 minutes →
    CRITICAL multi-stage intrusion.
  - `new_listener` + `new_suid` in the same lineage/window → CRITICAL backdoor
    with privilege-escalation artifact.
  - `fim_modified` or `pkg_signature_mismatch` + `pkgdb_tamper` → CRITICAL
    suspected trojaned binary with checksum cover-up.
  - web/database service spawning shell + tool transfer (`curl|wget|sh`) →
    CRITICAL likely RCE payload staging.
- Add high-signal living-off-the-land detections:
  `curl|wget | sh`, Python/perl/bash reverse-shell argv variants,
  `systemctl enable` from unusual ancestry, `chmod +s` outside package
  transactions, interpreter egress to unusual public ports, and execution from
  writable directories.
- Add first-seen and rarity tracking for local network behavior:
  first public destination per process name, first listening port per binary,
  interpreter connections to non-standard ports, and long-lived low-byte
  connections when socket sampling can support it.
- Keep polling as the oracle and fallback.

Exit criteria:

- Short-lived network and persistence actions are visible.
- Related alerts collapse into one incident with a readable timeline.
- Multi-stage correlation raises one higher-confidence incident without hiding
  the underlying raw alerts.

## v1.1.1: Detection Quality and Rule Operations

Purpose: make detection coverage easier to audit, tune, and extend without
turning Sentinel into a noisy rules dump.

- ✅ Add `enodia-sentinel rules list` and `rules show <sid>` for built-in and
  configured rules.
- ✅ Add `enodia-sentinel rules test <event-json>` so operators can validate
  custom event rules against captured or fixture events.
- ✅ Generate rule documentation from source defaults: SID, signature, classtype,
  event type, match fields, expected false positives, and drill coverage.
- Require a fixture or safe red-team drill for every built-in SID, including
  event-only and correlation SIDs.
- Add compatibility tests for rule JSON/event schema evolution.
- Extend triage so false-positive suggestions are tied to SID/classtype and can
  emit TOML snippets for allowlists, correlation windows, or severity overrides.
- Add post-alert enrichment consistently across detections:
  package owner, executable hash, parent/ancestor chain, remote IP
  classification, file mode/owner, recent writes by same lineage, and current
  FIM/package/rootcheck status.

Exit criteria:

- Operators can inspect, test, document, and tune detection rules without
  reading Python source.
- Every shipped detection rule has reproducible fixture/drill coverage and stable
  operator documentation.

## v1.2: Fleet Mode

Purpose: support several personal or small-business Linux hosts without turning
the agent into a heavy enterprise platform.

- Add an optional collector service.
- Agents push signed JSON events and heartbeats over HTTPS or a tailnet.
- Collector stores host status, alerts, incidents, and package/integrity state.
- Add host enrollment with per-host tokens.
- Add fleet-wide views:
  stale sensors, repeated signatures, hosts missing package signatures, and
  integrity drift.
- Preserve local autonomy: detection and evidence capture must continue if the
  collector is down.

Exit criteria:

- A small fleet can answer "which host is compromised or silent?" from one
  console.
- The agent still works as a standalone local tool.

## v1.3+: Assurance and Hardening

Purpose: make tampering harder to hide from an attacker with high privileges.

- External baseline anchor:
  mirror FIM and package DB fingerprints off-box with append-only semantics.
- Hash-chain `events.log` and snapshots.
- Optional snapshot signing with a host key.
- Investigate Linux IMA/EVM and TPM-backed attestation for supported machines.
- Replace bcc with a libbpf + CO-RE agent if the event layer becomes core to
  the product.
- Explore minimal kernel-side enforcement hooks for response actions, while
  keeping the default product inspect-only.

Exit criteria:

- A local root attacker has to tamper with both the host and an external or
  hardware-backed trust anchor to hide compromise.

## Backlog

Useful ideas that need design before implementation:

- Policy-as-code for host posture.
- YARA-compatible scanning for selected paths.
- Sigma-like host event rules.
- SBOM and package provenance reporting.
- Offline evidence bundle for outside analysis.
- Dashboard import of exported incident bundles.
- Support for non-pacman package managers in signed-package verification.
- Dedicated Debian/RPM packaging.
- Installer preflight checks and health diagnostics.

## Roadmap Rules

- Do not add dependencies to the base daemon without a specific security or
  operator value that cannot be achieved with stdlib.
- Prefer read-only detection and dry-run response until the command contract is
  tested and documented.
- Every new detector or response action needs a safe drill or fixture.
- Do not build stealth or self-hiding behavior.
- Keep the local agent useful without a dashboard, collector, or network.