Add HTTPS management console and response planning

docs/COMMAND_REFERENCE.md

@@ -210,6 +210,28 @@ Exit code:
 
 ## Evidence and Operator Commands
 
+### `respond`
+
+```bash
+enodia-sentinel respond plan <incident-id>
+enodia-sentinel respond plan <incident-id> --json
+```
+
+Builds a dry-run response plan from an incident's retained JSON snapshots. The
+plan may include evidence preservation, process freeze/terminate candidates,
+outbound IP blocks, systemd unit disablement, suspicious-file quarantine,
+package-restore lookup, and follow-up verification checks.
+
+This command is intentionally read-only: it prints commands for operator review
+and never executes them. The JSON schema is `enodia.response.plan.v1` and marks
+`apply_supported: false` until an audited apply workflow exists.
+
+Exit code:
+
+- `0`: plan generated.
+- `1`: unknown incident id.
+- `2`: missing incident id.
+
 ### `status`
 
 ```bash
@@ -235,6 +257,9 @@ enodia-sentinel web
 
 Starts the read-only dashboard. By default it binds to the Tailscale interface
 when available and uses bearer-token authentication for non-loopback binds.
+HTTPS is mandatory. If `web_tls_cert` / `web_tls_key` are not configured,
+Sentinel creates a self-signed pair under `log_dir`; add a browser exception for
+that certificate or replace it with a private/local CA certificate.
 
 Expected use: `enodia-sentinel-web.service`.
 
@@ -251,12 +276,14 @@ noise but never edits config automatically.
 ### `watchdog`
 
 ```bash
-enodia-sentinel watchdog --url http://100.x.y.z:8787 --token <token> --max-age 120
+enodia-sentinel watchdog --url https://100.x.y.z:8787 --token <token> --max-age 120
+enodia-sentinel watchdog --url https://100.x.y.z:8787 --token <token> --insecure-tls
 ```
 
 Polls a remote dashboard and alerts if the sensor is down, unreachable, or has a
-stale heartbeat. Run this from a separate host. A watchdog on the same machine
-does not prove the protected host is alive.
+stale heartbeat. Run this from a separate host. Use `--insecure-tls` only for
+the built-in self-signed certificate while you have no local/private CA trust
+path. A watchdog on the same machine does not prove the protected host is alive.
 
 Exit code:
 
@@ -283,9 +310,8 @@ does not require pip or a virtualenv.
 The roadmap reserves these command shapes:
 
 ```bash
-enodia-sentinel respond plan <incident-id>
 enodia-sentinel respond apply <plan-id>
 ```
 
-These should be introduced with stable JSON schemas and tests before they are
-documented as supported.
+State-changing response commands should be introduced with stable JSON schemas,
+audit logs, and tests before they are documented as supported.

docs/OPERATIONS.md

@@ -38,6 +38,10 @@ deliberately practical: what to run, what to expect, and what to check next.
    sudo systemctl enable --now enodia-sentinel-web
    ```
 
+   Open the `https://...` URL from the service log. The default certificate is
+   self-signed, so add a browser exception or configure `web_tls_cert` and
+   `web_tls_key` with your own local/private CA certificate.
+
 6. Configure one off-box notification or watchdog path. A local-only alerting
    path is not enough if the whole host goes silent.
 
@@ -76,29 +80,38 @@ When Sentinel fires:
    and parent process.
 3. Run `enodia-sentinel triage` to separate known benign listener noise from
    findings that need review.
-4. If the alert involves a binary, run:
+4. Build a read-only response plan from the grouped incident:
+
+   ```bash
+   enodia-sentinel incident list
+   enodia-sentinel respond plan <incident-id>
+   ```
+
+   Review the plan before acting; Sentinel does not execute containment
+   commands.
+5. If the alert involves a binary, run:
 
    ```bash
    enodia-sentinel fim-check --packages
    enodia-sentinel pkgdb-verify --sample 200
    ```
 
-5. If the alert involves hiding or tampering, run:
+6. If the alert involves hiding or tampering, run:
 
    ```bash
    enodia-sentinel rootcheck
    enodia-sentinel pkgdb-check
    ```
 
-6. Preserve evidence before changing state:
+7. Preserve evidence before changing state:
 
    ```bash
    cp -a /var/log/enodia-sentinel /tmp/enodia-sentinel-evidence
    ```
 
-7. Contain manually for now, following the matching playbook in
-   [RUNBOOKS.md](RUNBOOKS.md). Future response commands should produce a dry-run
-   plan first.
+8. Contain manually for now, following the matching playbook in
+   [RUNBOOKS.md](RUNBOOKS.md). The response plan gives reviewed commands, but
+   applying them remains an explicit operator action.
 
 ## Common Findings
 
@@ -129,6 +142,9 @@ Baselines are useful only if they represent a known-good state.
 
 - Keep the dashboard bound to Tailscale or loopback, not a public interface.
 - Set `web_token` explicitly for fully read-only service operation.
+- Keep HTTPS enabled. The built-in self-signed certificate is acceptable for a
+  single host after you add an exception; use a private/local CA for cleaner
+  browser trust.
 - Enable at least one push backend.
 - Run `watchdog` from another machine.
 - Consider `chattr +i` for Sentinel binaries, systemd units, config, baselines,

docs/ROADMAP.md

@@ -49,7 +49,7 @@ Exit criteria:
 
 Purpose: move from "tell me" to "help me act" without unsafe automation.
 
-- Add response plan generation:
+- ✅ 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

docs/RUNBOOKS.md

@@ -21,7 +21,15 @@ For any alert, before changing anything:
    alerts, when was the last.
 3. **Triage known noise.** `enodia-sentinel triage` separates likely false
    positives from findings that need a human.
-4. **Preserve evidence before you touch anything:**
+4. **Build a dry-run response plan.** Find the incident and review the proposed
+   actions:
+
+   ```bash
+   enodia-sentinel incident list
+   enodia-sentinel respond plan <incident-id>
+   ```
+
+5. **Preserve evidence before you touch anything:**
 
    ```bash
    tar -C /var/log -czf /tmp/enodia-evidence-$(date +%s).tgz enodia-sentinel
@@ -208,7 +216,7 @@ edited Sentinel is itself an alert.
 - From the **watchdog host** (never the protected host):
 
   ```bash
-  enodia-sentinel watchdog --url http://<host>:8787 --token <token> --max-age 120
+  enodia-sentinel watchdog --url https://<host>:8787 --token <token> --max-age 120
   ```
 
   Exit 1 means down, unreachable, or stale.

docs/THREAT_MODEL.md

@@ -75,7 +75,8 @@ Sentinel assumes:
   package signature policy.
 - `pacman -Qkk` trusts the local package database; it is useful but not an
   independent root of trust.
-- The dashboard is read-only by design; it is not a remote response console.
+- 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.
 
 ## Security Controls Already Present
@@ -90,7 +91,7 @@ Sentinel assumes:
 | Signed-package verification | Checks files against package manifests independent of the local DB. |
 | Rootcheck | Finds common hiding artifacts by comparing independent views. |
 | Heartbeat + watchdog | Makes a silent sensor observable from another machine. |
-| Read-only dashboard | Exposes evidence without adding a remote write path. |
+| HTTPS read-only dashboard | Exposes evidence and dry-run plans without adding a remote write path. |
 
 ## Response Safety