itpp-infrastructure/audit/phase-one/findings/indep-review.md

Independent Severity Review (Indep) - ITPP Phase One Audit

Reviewer: Indep (claude-sonnet-5), independent QA pass Scope: Re-score every Critical/High finding in the nine findings files and cross-check against report.md Sections 3 and 7. Read-only. No infrastructure was touched to produce this review; all conclusions are drawn from the raw findings files already on disk. Method: Read all 9 findings files (neteng-a, neteng-b, sec-a, sec-b, sys-a, sys-b, sys-c, git-a, docs-w) and report.md in full, then independently judged each Critical/High rating against its own stated evidence, without deferring to the conductor's synthesis.

---

1. Severity re-score table

ID	Finding (short)	Conductor rating	My rating	Verdict
D1 / Sys-B H1	Standby watchdog pings "wrong" IP 152.53.192.33	Resolved as false positive (conductor)	False positive	FALSE-POSITIVE (agree)
D2 / Sys-B C1	Gitea/Hudu/UNMS/UniFi "no effective backup"	Downgraded to High (conductor)	High for Hudu/UNMS/UniFi; not-a-finding for Gitea	DOWNGRADE-to-High, with the added correction that Gitea should be dropped from this finding entirely
Report C1 (NetEng-A)	Docker/UFW bypass, ~20 consoles public	Critical	Critical	AGREE
Report C2 (NetEng-B NETB-1)	No network segmentation anywhere	Critical	Critical	AGREE
Report C3 (NetEng-A APP1-1 + Sec-B-01)	Wazuh public + zero enrolled agents	Critical	Critical	AGREE
Report C4 (Sec-A-01, Sys-A F-2, Sys-B C2/C3, Docs-W #1)	Plaintext credentials estate-wide	Critical	Critical	AGREE, but see "under-weighted" note on Git-A Finding 1 below, which is thin in this writeup
Report C5 (Sys-A F-1)	LiteLLM Postgres never backed up	Critical	Critical	AGREE
Report C6 (NetEng-B NETB-3)	app3 single shared MySQL, ~24 sites	Critical	Critical	AGREE
Report C7 (Sec-B-02 + NetEng-A CORE-1)	Grafana default admin/admin, public, no MFA	Critical	Critical	AGREE
Report C8 (Sys-B C4)	wphost02 backup gap, 6 of 8 DBs unprotected	Critical	Critical	AGREE
Report C9 (Sys-B C5 / Sys-C SYSC-01)	Warm standby not data-ready	Critical	Critical	AGREE
Sec-A-02	Single SSH key = root on 5 of 6 hosts, passwordless sudo on top	Critical in sec-a.md, silently downgraded to "High findings (representative)" in report Section 3.2, no Section 7 entry	Critical	UPGRADE-to-Critical (restore original rating; also flag the undocumented downgrade as a process gap)
NetEng-B NETB-6	Same underlying fact as Sec-A-02, stated as High in neteng-b.md itself	High	Critical	UPGRADE-to-Critical (same reasoning as Sec-A-02; this is one finding described twice, not two findings)
Sec-B-03	Technitium DNS DNS_SERVER_ADMIN_PASSWORD=changeme in container env	Critical in sec-b.md, silently shown as High in report Section 3.2, no Section 7 entry	High, with an explicit evidence caveat	DOWNGRADE-to-High (agree with the report's de facto number, disagree with doing it silently)
Sys-C SYSC-02	Duplicate/conflicting auth-api-backup cron jobs	Critical in sys-c.md; not mentioned anywhere in report Section 3	Medium/High	DOWNGRADE-to-Medium-or-High, and separately flag as omitted from the consolidated report
Sys-C SYSC-04	WISP tower router (DR-017) has zero backup coverage at all	High in sys-c.md; not mentioned anywhere in report Section 3	High	AGREE with sys-c's rating, but flag as MISSED from the consolidated report
Git-A Finding 1	scripts repo: hardcoded MSP-backdoor admin password reused across client onboards	Critical in git-a.md; report's C4 write-up only names the downstream public re-leak (Finding 2/D3), not this original Critical	Critical	AGREE with git-a's rating; flag that report C4's evidence bullets omit this specific item and should name it explicitly, since rotating it is required independent of the D3 policy call on the public repo
Git-A Finding 2	Same password re-leaked inside a PUBLIC repo (itpp-infrastructure)	High in git-a.md; treated as Critical-tier in report's C4/D3 framing	Critical	UPGRADE-to-Critical (agree with the report's implicit escalation over git-a's own High rating; public exposure of a live, reusable credential is worse than the private-repo case, and the severity legend the report itself uses supports Critical here)
Git-A Finding 3	hermes-recovery (private): live MySQL password + a live Gitea API token in history	High	High	AGREE

---

2. False positives

1. Sys-B H1 (confirmed false positive - this is D1, see Section 4). The claim that the standby watchdog targets the "wrong IP" is wrong. 152.53.192.33 is Core's real public IP per sys-a.md's own host profile table (Core Public IP row) and per report Section 2.1. 152.53.36.131 is app1, not Core. Sys-B conflated the two hosts. The watchdog is correctly configured.

2. Sys-B C1, as applied to Gitea specifically (this is part of D2, see Section 4). Sys-B's claim of "no effective backup, a loss would be unrecoverable" for Gitea is contradicted by sys-c.md's live evidence: Gitea's backup was restore-tested PASS on 2026-08-10 (117 DB tables, 52 repos, 3 sampled repos restored with valid git history). "Unrecoverable" is factually wrong for Gitea. This part of C1 should be dropped, not just downgraded.

No other Critical/High finding in the nine files was found to be factually wrong on re-read. The rest of C1 (Hudu/UNMS/UniFi backups being untested, see below) is a real gap, just not the "Critical, unrecoverable" framing Sys-B originally gave it.

---

3. Under-weighted or missed

1. Sec-A-02 / NetEng-B NETB-6 (single SSH key = root on 5 of 6 hosts). Sec-A rated this Critical in its own file. Report Section 3.2 lists the same fact under "High findings (representative)" with no corresponding Section 7 disagreement entry explaining the downgrade. Using the report's own severity legend ("Critical = ... single-compromise = estate-wide blast"), a single key that unlocks passwordless root on 5 of 6 servers, with no MFA and no network segmentation to contain it, meets that bar. I recommend restoring this to Critical. Separately, the fact that it was downgraded without being logged as a disagreement (the way D1/D2/D3 were) is itself a process gap worth naming to Germaine: any time the conductor changes a source auditor's severity, it should show up in Section 7, even if the conductor believes the change is obviously correct.

2. Sys-C SYSC-04 (WISP tower router, zero backup coverage, DR-017 still open). Rated High in sys-c.md with clear evidence (s3://mikrotik-ccr-backups/wisp-backups/configs/tower* returns zero objects, versus 30+ dailies for the home gateway at the same prefix pattern). This does not appear anywhere in report.md Section 3 (Critical or High), and is not folded into any of the C1-C9 themes since it is a standalone network-device gap, not a Docker/backup-script issue. This is a genuinely missed High finding: an operational device with a total absence of configuration backup, not just an untested one.

3. Git-A Finding 1 (scripts repo, hardcoded MSP-backdoor admin password used across client onboards). Rated Critical in git-a.md, correctly. Report's C4 write-up (the Critical bucket for plaintext credentials) lists key-inventory.md copies, app1-bu's .env, systemd units, app3's MySQL password, and the itpp-infrastructure public re-leak, but never names this specific finding, the one that is arguably the most consequential of the group because it is a live password reused across production client machines, not just infrastructure secrets. It is mentioned only indirectly through D3 (which covers the re-leak, not the original). Recommend the report name Finding 1 explicitly in C4's evidence list.

4. Sys-C SYSC-02 (duplicate/conflicting auth-api-backup cron jobs). Rated Critical in sys-c.md. On re-read, I think this is overstated: the working 03:15 job succeeds every night, and the second 04:35 job is a leftover that fails visibly. The real risk here is alert fatigue (a failing job that nobody investigates because "the cron always shows an error") rather than a live data-loss condition today. I would score this Medium, with a note that it could become a real gap if the good job silently breaks later. Separately, whatever its severity, it is not mentioned anywhere in report.md Section 3 and should be, since it currently reads as fully resolved (it is not).

5. Sec-B-03 (Technitium DNS DNS_SERVER_ADMIN_PASSWORD=changeme). Rated Critical in sec-b.md. I think Critical overstates the confidence level here. Technitium (like many similar tools) typically only applies an admin-password environment variable on first bootstrap of its config; once a config already exists, subsequent container restarts do not necessarily re-apply that env var to the live credential. Sec-A's own file explicitly says it "could not confirm the live in-app credential value without an authenticated read." Sec-B's own rationale acknowledges this too ("Even if the operational credential has since been changed inside the app's own database..."). Given that acknowledged uncertainty, I would score this High rather than Critical: the finding (a default-credential string persisting in a live container env, on the estate's authoritative DNS) is a legitimate and important hardening signal regardless of whether it is literally the current password, but "Critical" implies a confirmed, exploitable credential, which this audit did not verify. The report's own Section 3.2 already lists this as High, so the net number matches what I'd recommend, but again, that downgrade from sec-b.md's own Critical rating was made silently, with no Section 7 entry.

---

4. Verdict on D1, D2, and D3

D1 (Sys-B H1, watchdog "wrong IP"): I agree with the conductor's resolution. Core's public IP is confirmed as 152.53.192.33 in sys-a.md's host profile table and in report.md's Discovery Summary (Section 2.1). 152.53.36.131 belongs to app1. Sys-B's H1 conflated the two hosts and its underlying claim is false. This is a clean false positive, not a judgment call. No action needed beyond correcting Sys-B's file for the record.

D2 (Sys-B C1, Gitea/Hudu/UNMS/UniFi "no effective backup"): I agree with the direction of the conductor's resolution (downgrade), and I'd go slightly further on the details. Sys-C's live S3 evidence shows all four services have current, on-schedule backups running through a different mechanism than the one Sys-B checked (Core-side scripts scheduled via Hermes's own cron system, not the app2-local scripts Sys-B examined, which genuinely are missing). That distinction matters: Sys-B's observation that the specific scripts referenced in app2's own /root/backup.sh do not exist is accurate and worth keeping as a hygiene finding (a redundant, broken, misleading logging path), but the conclusion that these four services have "no effective backup" and "a loss would be unrecoverable" is not supported by the live evidence. For Gitea specifically, there is a passing restore test, so I would remove it from this finding entirely rather than just downgrading its severity. For Hudu, UNMS, and UniFi, the accurate framing is "backups exist and are current, but have never been restore-tested," which is a real gap, appropriately High, not Critical. This also overlaps with Sys-C's own broader Critical finding (SYSC-03: 94%+ of all backup targets estate-wide have never been restore-tested), so Hudu/UNMS/UniFi's specific gap is really a subset of an already-Critical estate-wide pattern rather than its own independent Critical.

D3 (Git-A public repo credential re-leak, Germaine deferred remediation): I do not have grounds to disagree with the underlying finding, and deferral is Germaine's call to make, not mine to override. The finding itself is factually solid: git-a.md independently confirmed the same admin password sits in git history in a public repo, verified against live Gitea API data. Where I'd add value here is on severity, not on the remediation decision: git-a.md itself rated this specific finding (Finding 2) as High, but the report's consolidated C4 treats it as Critical-tier alongside the other plaintext-credential findings. I agree with the report's implicit escalation, a live, reusable credential sitting in a searchable public repository is a worse exposure than the same secret in a private repo, so Critical is the more defensible rating even though the source auditor called it High. Germaine's decision to leave the repo alone for now is a risk-acceptance call made with full knowledge of the finding; I have no evidence that the decision was made on a mistaken understanding of severity, so I am not overriding it, I am only flagging that the underlying risk is live and, if anything, slightly under-stated by git-a.md's own severity label.

---

5. Overall confidence statement

Confidence in this review is high for the two flagged disagreements (D1 is unambiguous, D2 is well-supported by Sys-C's independent live S3 check) and reasonably high for the severity re-scores involving the shared SSH key and the Technitium default-credential finding, since those turn on the report's own stated severity legend and on an explicit evidence gap the source auditors themselves called out, not on speculation. Confidence is lower, and explicitly flagged as such, on SYSC-02's exact severity (Medium vs High is a closer call than Critical vs Medium) and on whether Sec-B-03's live Technitium credential is actually still the default, since neither this review nor any of the nine original findings files could confirm the live value without an authenticated read, which was correctly out of scope for a read-only audit. Where evidence was insufficient to fully confirm or refute a claim, I have said so explicitly rather than guessing, consistent with the audit's own read-only, no-assumption rules. I found no evidence of systematic severity inflation or deflation across the nine files; the two confirmed issues (D1, D2) and the additional items surfaced here are individual scoring errors and one process gap (severity downgrades happening without a corresponding Section 7 entry), not a pattern that should cast doubt on the audit's other 50+ Critical and High findings, which were consistently well-evidenced with specific file paths, command output, or cross-referenced live checks.