This Proofroom server
Proofroom files your own server’s patch report as monthly evidence. It reads the report written by the server’s patch report timer, so it needs no credentials and makes no calls to any other system.
What it collects
| Collector | Kind | Default cadence | What it shows | Suggested controls |
|---|---|---|---|---|
| Patch status | snapshot | monthly | A patch latency report for the month: every security update published or installed, with when each was installed and the days it took; every update still open at the end of the month with its age; late ones marked. Beneath it, the server’s summary (operating system, kernels, automatic updates, pending reboot) and the daily history. | PCI DSS 6.3.1, 6.3.3; SOC 2 CC7.1 |
Your deadline
An update is late when it took longer than your patch deadline to install, or is still open after it. The deadline is yours to set: Admin → Server health holds the number of days and, optionally, the policy evidence item that states it. The evidence names both, so an assessor sees the rule you held yourself to. The default is 30 days.
How it works
The server runs proofroom-host-report on a systemd timer, daily. It only reports: it reads the package manager’s
state and history and writes a JSON file that Proofroom reads. It installs nothing and changes no settings (it refreshes the package lists, as apt-get update does).
proofroomctl init, init --refresh and update start the first report as they install the timer. If the report is
missing, run sudo proofroomctl init --refresh on the server.
Only updates to packages already installed count. A package an upgrade would add new is not a pending update, and installing it is not late: the server never had an older, vulnerable version of it.
Check now. Admin → Server health has a Check now button, for admins. It writes one empty file into the server’s
request folder (/srv/proofroom/host-request, the only folder the app can write to) and nothing else; a systemd path
unit runs the report, usually within a minute, and the page refreshes until the new report arrives. It runs at most
once every 5 minutes. After patching, press it, or run sudo systemctl start proofroom-host-report.service on the server.
If no new report comes within 5 minutes, or the server has no request folder yet, the page shows that command.
In the public demo the page, the dashboard alert and this connector show a made-up sample server for the demo company, never the server the demo runs on. Check now there moves the sample’s report time to now and writes nothing.
When a run fails
The collector files nothing rather than a partial report, and the next tick tries again. It fails when:
- there is no report yet: run
sudo proofroomctl init --refreshon the server; - the report is unreadable: the error says what is wrong with the file;
- the report is more than 48 hours old: on the server, run
systemctl status proofroom-host-reportto see why the timer has stopped; - the report could not read the patch state:
apt-get updatefailed (so the counts come from old package lists), the update simulation failed (so the counts are carried forward from an earlier report, or unknown), the system is not supported, or the update ledger could not be read. The error lists what the server reported. A report written before 1.8.0 is judged by the same errors in its error list;proofroomctl updateandinit --refreshstart a fresh report as soon as they install the new script, so the old format does not linger until the night’s run.
Other errors in the report are notes and do not stop the run: for example a changelog that could not be fetched, which means that update’s published date is the date the server first saw it (the report says so on that row). They are listed under the server summary.
The connection test shows the same messages, or when the report was written and how many security updates are pending.