# Enodia Sentinel Roadmap

This roadmap moves Enodia Sentinel from a host IDS into a host security platform:
detect, 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. |
| 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 while preserving existing
  alert JSON.
- Add an incident timeline generator:
  alert time, process ancestry, sockets, persistence writes, FIM diffs, package
  transactions, and rootcheck findings.
- 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`.
- Document incident response runbooks for reverse shells, persistence, trojaned
  binaries, hidden listeners, and sensor tampering.

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>`.
- Add dry-run first actions:
  kill process, stop/disable service, block remote IP, quarantine file, restore
  package-owned file by reinstalling its package, and freeze evidence.
- Require explicit `--apply` for changes; default to read-only plans.
- Write response audit logs under the normal log directory.
- 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.
- 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.

- 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.
- 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.

## 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.
- Rule documentation generated from source defaults.

## 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.