luna/enodia-sentinal
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
enodia-sentinal/docs/ROADMAP.md
Luna a56d72edd6 Add incident grouping (roadmap v0.8: incident list/show/export) 
Collapse related alerts into one incident, process-lineage first with a
time-window fallback. Each alert batch's flagged PIDs are walked up the
/proc PPid chain into a lineage set (excluding pid 0/1 so everything
doesn't correlate through init); batches whose lineage sets intersect —
sharing a process or a common ancestor like the web server or SSH
session — join the same incident. PID-less batches (FIM drift, package
tamper, hidden modules) fall back to the most recently active open
incident within incident_window.

snapshot.capture now computes lineage and records each snapshot into a
JSON incident index (incidents.json), writing incident_id into both the
report JSON (report level, so the per-alert schema is untouched) and the
text header. New commands:

  incident list              incidents newest-first, with signatures
  incident show <id>         summary + time-ordered snapshot timeline
  incident export <id>       JSON bundle: record + inlined snapshots

The lineage/assign cores are pure functions; record() serializes the
index under a lock (capture runs from sweep + eBPF threads) and is
best-effort so an index problem never loses a snapshot. 17 new tests
(lineage, assign, record, and an end-to-end capture→group→CLI path).
Config: incident_tracking / incident_window / incident_lineage_depth.
Docs + sample config updated; closes the last v0.8 roadmap item.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 17:52:42 -07:00

7.4 KiB
Raw Blame History

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

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.