The insurance company's pf estate
Somewhere in a repository that no longer exists is a CVS history of every firewall rule change made at an unnamed insurance company for about four years. What CVS-managed pf rulesets taught about configuration management at scale.
Somewhere in a repository that no longer exists is a CVS history of every change made to the pf ruleset at an unnamed insurance company over the course of approximately four years. The repository is gone — the machine it lived on was decommissioned in the usual way of machines, quietly and without ceremony — but the habits it built are not gone, because the habits of configuration management at scale are the kind that, once formed, persist.
The decision to manage firewall rules in CVS was not, at the time, an innovation. It was an application of the obvious insight that firewall rules are code, and code benefits from version control, and version control benefits from being treated as the authoritative record rather than as a backup. The decision was slightly unusual in the environment because most of the organisation's infrastructure was managed through a combination of institutional memory and text files on the relevant machines, neither of which supports audit trails.
What the CVS history showed
The CVS log for a production ruleset, read across four years, is a history of the organisation's security thinking — not as anyone would have written it down, but as it actually evolved in response to real events. Rules added after incidents. Rules commented out when they caused problems and never removed. Rules that were clearly the result of a specific conversation at a specific meeting, identifiable by the commit message and the date. Rules added by people who understood the network and rules added by people who did not, distinguishable by the specificity of the address ranges and the accuracy of the comments.
There is a category of technical history that is only visible in version-controlled infrastructure. The informal history — the conversations, the decisions, the reversals — is normally lost when the machine is decommissioned. Version control preserves at least the shape of it: the dates, the changes, and whatever the committer chose to write in the commit message. Four years of weekly rule changes, read as a continuous record, tell you more about the organisation's security posture than any point-in-time review could.
What it got right
Treating firewall rules as code produced several practical benefits that were visible immediately. Change review: a proposed rule change could be shown to a colleague as a diff rather than a description. Rollback: when a rule change caused unexpected traffic to be blocked, reverting to the previous version took minutes rather than the investigation of what had changed and when. Accountability: the log showed who made each change and when. These are the ordinary benefits of version control applied to an unusually concrete artifact.
The less obvious benefit was the visibility it gave to the accumulation of complexity. Firewall rulesets, like all infrastructure configuration, tend to grow in one direction: rules are added; they are rarely removed. The CVS history made the growth rate visible in a way that the current ruleset alone did not. Reading the growth curve suggested conversations about pruning that would not otherwise have happened.
What it did not get right
The change management process around the version-controlled rules was not as disciplined as the version control itself. Rules were committed with commit messages that ranged from specific and useful to "update" over a diff spanning forty lines. The automation to generate the current ruleset from the repository and deploy it reliably to the firewall was fragile and occasionally out of sync with the deployed version. The tooling that would make this truly robust — the infrastructure-as-code pipelines that are now standard — did not yet exist in a usable form.
What existed was the right instinct: that the rules should be in a repository, that the repository should be the truth, and that changes should be traceable. The instinct was right and the execution was imperfect, as execution generally is. The discipline of treating configuration as code is the thing that lasted from that estate. The specific tooling was a product of its time.
The CVS repository is gone. The firewall it controlled has been decommissioned. But the insight that infrastructure configuration is code, and code should be versioned, and the version history is the audit trail — that still holds. The PING sent into the CVS log still returns something, if you know how to read the response.