enodia-sentinal/docs/ROADMAP.md

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.