One of the more interesting consequences of the current evolution in security is what it does to our notion of best practices. As both discovery and exploitation of vulnerabilities speed up, we want our infrastructure to be very responsive, and ideally fairly automatic: rotating keys across hosts, applying patches, and reacting to new disclosures without waiting for someone to find a free evening.
Tools like unattended-upgrades get us part of the way there. But they raise a harder question: what setup is actually net positive? An automated system that can log in and rotate keys across your infrastructure is itself a new and highly privileged point of compromise. We want responsiveness without that access becoming the weakest link.
Well-trodden paths
One heuristic that feels increasingly important is to stay on the well-trodden path. If your setup follows a simple, common structure — say, a minimal Ansible configuration that lots of other people are running in roughly the same shape — it seems much more likely that updates will arrive as expected and can be applied automatically without breaking things.
This was true with human operators as well. The difference is that a human administrator had the chance to learn the environment over time, and could absorb the quirks of a bespoke setup. Automation is far less forgiving of outliers, and the cost of being unusual goes up when the expectation is that changes land without someone watching.
What seems likely to remain true
A few practices seem robust to this shift:
- A clear separation between control plane and data plane. The control plane should normally not be reachable at all, or should require additional hardware credentials to access. This segmentation is worth enforcing deliberately.
- Offline backups. These remain one of the most important pieces of risk management, precisely because they sit outside the reach of anything automated.
Shrinking the public surface
Public services are becoming more dangerous to run. The safer posture is minimal exposed surface area — just SSH authentication or an equivalent — so that you only meaningfully talk with remote entities you already have reason to trust.
At the same time, you need to track feeds of threats, exploits, and updates so you can patch before someone uses a vulnerability against you. This is a tricky balance. Either you trust an authority to filter and provide a sanitized feed, at the cost of both speed and autonomy, or you take on the diligence yourself: working out whether an upstream package has been compromised, or whether reports in your feed are themselves malicious. That raises an uncomfortable question — do we trust our own infrastructure and evaluation to be up to par at identifying supply chain attacks automatically?
How do we keep offering public services?
If exposure is the problem, there are a few directions worth exploring:
- DMZ’d hosts, where compromise of a VM or host remains quarantined from everything else.
- “Dark forest” services that aren’t truly public, but are exposed only to an extended LAN, a tailnet, or a defined community. We aren’t very good at defining these trust boundaries today. The friction is high enough that we rarely get beyond authenticating individuals with SSH or GPG keys, or else we retreat into a platform silo like Discord or Telegram.
- Evolving what we mean by maintenance, so that unattended upgrades become something closer to a trustworthy, well-scoped process rather than a blanket grant of access.
None of these is a complete answer, and each trades independence for safety.
Leave a Reply