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

Frame Sentinel as IDS IPS and EDR

Browse source
This commit is contained in:
Luna 2026-06-13 05:59:03 -07:00
parent 1a5b6f1d8d
commit 6a09fbb7f9
10 changed files with 47 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

9
docs/ROADMAP.md
View file

@ -1,15 +1,16 @@
# Enodia Sentinel Roadmap
This roadmap moves Enodia Sentinel from single-host endpoint detection and
response into a fuller host security platform: detect, verify, investigate,
respond, and assure. Dates are intentionally not promised here; the sequence
matters more than calendar precision.
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. |

17
docs/SPECIFICATION.md
View file

@ -1,12 +1,12 @@
# Enodia Sentinel Specification
This document defines Enodia Sentinel as an endpoint detection and response
system, not only a signature IDS. The current implementation is a local Linux
sensor with evidence capture, integrity monitoring, anti-rootkit checks, a
dashboard, alert delivery, and dry-run response planning. The intended product
is a defensive control plane for a host or small fleet: detect compromise, prove
what changed, preserve useful evidence, guide response, and make sensor
tampering visible.
This document defines Enodia Sentinel as an IDS, IPS, and EDR system, not only a
signature IDS. The current implementation is a local Linux sensor with evidence
capture, integrity monitoring, anti-rootkit checks, a dashboard, alert delivery,
and dry-run prevention/response planning. The intended product is a defensive
control plane for a host or small fleet: detect compromise, prevent or contain
known-bad behavior through explicit operator workflows, prove what changed,
preserve useful evidence, guide response, and make sensor tampering visible.
## Product Definition
@ -15,11 +15,12 @@ as a local daemon, observes high-signal host behavior, records forensic context
when something suspicious happens, and exposes the result through local files,
JSON, a read-only dashboard, push notifications, and command-line tools.
The long-term product should combine five functions:
The long-term product should combine six functions:
| Function | Purpose |
|---|---|
| Detection | Find active compromise behavior: reverse shells, fileless execution, new listeners, suspicious egress, persistence edits, and privilege-escalation artifacts. |
| Prevention | Recommend and, after explicit review, apply containment actions such as stopping malicious processes, blocking C2 peers, disabling persistence, or quarantining files. |
| Integrity | Prove whether important files, packages, baselines, and Sentinel's own footprint changed. |
| Evidence | Capture enough context for incident response without forcing the operator to reproduce a live state after the attacker is gone. |
| Response | Provide safe, explicit operator workflows for triage, containment, and recovery. |

4
docs/THREAT_MODEL.md
View file

@ -80,12 +80,16 @@ Sentinel assumes:
- The dashboard is read-only by design; it can display dry-run response plans
but does not execute containment commands.
- The current product does not perform automatic containment.
- Sentinel's IPS scope is explicit prevention workflow: posture hardening,
containment planning, and future reviewed `--apply` actions. It is not an
inline network appliance and does not silently rewrite host state.
## Security Controls Already Present
| Control | Purpose |
|---|---|
| Hardened systemd unit | Limits daemon write surface and runtime privilege where possible. |
| Explicit IPS workflow | Turns detections into reviewed prevention/containment plans without automatic remediation. |
| Cooldown deduplication | Prevents alert storms from one persistent condition. |
| Snapshot retention | Preserves evidence while bounding local disk growth. |
| FIM self-watch | Detects changes to Sentinel's own files and service definitions. |