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.

Nothing here represents the views of any employer, client, or organization I am affiliated with. Personal research, personal time, personal tools. The goal is to teach myself, to build reusable artifacts, and to leave a written record that other practitioners can learn from.

How to verify it works

You are reading this, which means the whole pipeline is wired up correctly. The Astro build read the markdown from the published folder, the content collection schema validated the front matter, the lint script enforced the house rules (no em-dashes, no banned phrases, threat model and validation sections present), the Cloudflare deploy pushed to the CDN, DNS resolved, TLS terminated cleanly. Every one of those was a thing worth verifying before the first real article landed, and the fact that you are seeing this page means the whole chain is green.

Next in the queue: Windows LAPS in a hybrid environment, the parts nobody explains. Then Linux auditd rules for credential access detection. Then Conditional Access session controls for the most common SMB misconfigurations. The research folder already has stubs for each.