The NAS will have no logs, and that is a decision — record it as a residual when it lands

[Gerrrt]

ADR-0016
decided that the NAS on CasaBonita (40) is scraped, never pushed — metrics
come out over 99→40:9100, and nothing on that segment initiates anywhere. Loki
has no pull. Metrics survive that reversal; logs do not.

So the NAS will be the one host in the estate whose compromise is invisible.
Prometheus will show it alive, loaded and busy, and nothing will show what it
did. Jellyfin is a large codebase with a network-facing indexer, sitting on the
segment whose stated assumption is that everything on it is already
compromised — which is exactly the host you would want logs from.

Why the obvious fix is worse than the gap

A 40→99:3100 rule would collect the logs. It would also:

• Be the first upward path in the estate — the property ADR-0008 claims to
  keep ("nothing untrusted ever initiates upward") and ADR-0016 went out of its
  way to preserve.
• Let anything that reaches the NAS write to the log store the rest of the
  estate is judged by. Loki's ingest is unauthenticated by design
  (ADR-0012,
  #182), so this does not just
  move logs — it hands a low-trust host the ability to inject and delete them.
• Make a sentence in SECURITY.md false. The residual row for the ingest ports
  currently reads "Firewall default-deny is the whole control: only Hicks (50)
  and Winterfell (99) can reach the host at all, and never an untrusted
  segment." That last clause survives ADR-0016 only because the direction was
  reversed. This rule would retire it.

Trading a blind spot on one host for a write path into every host's logs is the
wrong way round, which is why ADR-0016 chose the blind spot. But it chose it —
it is not an oversight, and it should not be discovered later as one.

What this issue is for

Not to close the gap. To make sure it is recorded where residuals are
recorded, on the day the NAS exists:

• A row in SECURITY.md's Known exposure table, in the same
  "Accepted residual, not a fix in progress" form as the ingest-port and
  unencrypted-disk rows.
• A line in docs/security.md, near the tripwire paragraph — the tripwire
  is the control that still watches this segment, and it is worth saying
  that it is the only one.
• Decide whether TerminalSegmentReachedInternalNetwork is enough on its
  own for this host, or whether the absence of logs deserves something of
  its own. Note the trap: a rule that alerts on "no logs from zion" cannot
  exist, because there were never any logs to stop arriving. This is the
  SuricataStopped reasoning in security.rules.yaml:241-250 again —
  absence of a signal is indistinguishable from absence of the service —
  and it is why the answer here is probably "the tripwire, and honesty in
  the docs", not a new alert.

Nothing to do until the hardware lands under
#102. Filed now because the
reasoning is fresh and the ADR is the only place it currently lives.

Found writing ADR-0016 for #95.