postinstall, a field log

The most important hour in a system’s life is the one right after you finish installing it. Every choice made before that machine sees the network is a choice that sticks, and a choice made correctly will save you from a thousand smaller choices later. That hour is what this site is about.

“postinstall” is the moment after the package manager finishes, after the installer reboots, after the vendor’s default configuration is in place and before anyone has started actually using the thing. It is also, not coincidentally, the moment where almost every documented security failure could have been prevented. Not with a new tool, not with a new control framework, but with a handful of deliberate decisions made in the right order while the system is still quiet.

This is a personal research log. I work on one control or configuration at a time, in a lab I can rebuild from scratch, and I write up what actually happens. The threat model, the implementation, the validation method, the rollback, and the parts that surprised me. Nothing here is theoretical. If I have not tested it, I say so.

Threat model

Every article about a security control will lead with a threat model, because the alternative is checklist writing, and checklists without context are how people break unrelated workflows and then roll everything back without learning anything. For each control I study, I name the attack, I map it to MITRE ATT&CK where that fits, and I am explicit about what the control does not defeat.

The threat model for this site itself is simpler. I want a place to publish research under my control, with no database to patch and no plugin surface to worry about. Static markdown in, static HTML out, deploy on push to main. The only thing facing the internet is a CDN and a DNS record.

Prove it

postinstall is not a vulnerability disclosure blog or a vendor comparison site. It’s a research log focused on what an SMB or MSP can actually do about the threats they face, in the time and budget they actually have.

A typical post takes one vulnerability or misconfiguration, walks through the threat model, the implementation, the validation, and the rollback. The threat model assumes an average SMB, not a federal agency, and the controls are sized accordingly.

The weekly Dispatch is the companion feed: five to six items from the prior week that I think SMBs should pay attention to, with the same short-items, clear-actions, no-vendor-pitch posture as the longer work.