luna/enodia-sentinal
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Add platform docs; reposition as host security platform

Browse source 
Add docs/ (SPECIFICATION, ROADMAP, OPERATIONS, COMMAND_REFERENCE,
THREAT_MODEL) describing the current v0.7 agent and the phased path from
local HIDS to a host security platform. Reframe README, package metadata,
and CLI/module descriptions from "intrusion-detection daemon" to "Linux
host security platform", and surface the v0.7 signed-package verify
(pkgdb_pkgverify*) and anti-rootkit (rootcheck_*) knobs in the sample
config. Also wrap the pacman.conf read in pkgdb.siglevel_alert in a
context manager to avoid a leaked file handle.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Luna 2026-06-10 04:03:06 -07:00
parent 1de5e86fed
commit 6ff2087329
11 changed files with 930 additions and 26 deletions
Download patch file Download diff file Expand all files Collapse all files

174
docs/ROADMAP.md Normal file
View file

@ -0,0 +1,174 @@
# 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:
SSH password login, root SSH login, permissive sudoers entries, unexpected
enabled services, world-writable PATH components, disabled package signatures,
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.