Assume the Endpoint Is Hostile
Lakhs of government PCs can reach the core, each one trusting whoever sits in front of it. Borrow Apple's closed system — on open foundations — and make the wrong move unavailable.
At the end of the last post I slipped in a line and kept walking: the highest-risk work happens inside managed development environments, not on someone’s laptop. That line deserves its own post. Because it is not just about developers, and it is not just about the highest-risk work. It is about every laptop, desktop, and server the government runs.
There are lakhs of them. Ministries, district offices, schools, counters. Most can reach the core — the same identity, payments, and records systems the rest of this series was about. And most are administered the way my first server was: by hand, by whoever is around, with the best of intentions and no real system.
I learned to harden a server the hard way. Default-deny firewall, fail2ban, SSH closed to the open internet, access only over a private Tailscale network, intrusion prevention watching the rest. The machine became boring, which is the highest compliment you can pay a server. But here is the thing I had to accept while doing it: the most dangerous account on that box was not some hacker in another country. It was me — tired, at 2 a.m., with root.
So stop building government endpoints that assume the person using them will always do the right thing. Assume the opposite. Assume the endpoint is hostile by default, the network access is hostile by default, and the safest thing the system can do is make the wrong move simply unavailable.
This is not an insult to the people doing the work. It is the opposite. It is refusing to make their job depend on perfect vigilance, every day, forever, against threats they were never hired to spot.
Key Takeaways
- The most hardened platform in the world is only as secure as the lakhs of general-purpose machines that log into it. The endpoint is the soft underbelly.
- Borrow the closed-system property, not the foreign vendor. Make the wrong move unavailable with an immutable OS, one signed app store, no local admin, an allowlisted network, and 802.1X, all on open foundations so the state holds the keys.
- Lockdown handles the known-bad. Behavioral baselines catch the allowed-but-wrong (a clerk pulling 10,000 records, a 3 a.m. login from a new state) with step-up or freeze, monitored for security and never for productivity.
- A closed system is only as good as its steward. Unfunded, it rots into an out-of-date monoculture where every machine is identically vulnerable — fund the body that owns it, or do not lock anything down at all.
Why is the endpoint the weakest link?
You can build the most beautiful federated, HTML-first, breach-resistant platform in the world. None of it matters if the machine logging into it is a shared desktop with a decade-old browser, local admin rights for everyone, and a USB port that takes anything.
The endpoint is where the assumptions break. Think about what actually happens on a government workstation today:
- Someone installs a “free PDF converter” that turns out to be adware.
- Someone plugs in a personal phone to charge it, and now an untrusted device is on the network.
- Someone copies a sensitive file to a personal USB drive to finish the work at home.
- Someone installs a VPN to reach a blocked site, and quietly punches a tunnel straight out of the secure network.
- Someone clicks the thing. Everyone, eventually, clicks the thing.
None of these need a sophisticated attacker. They need a normal person, on a normal day, on a machine that lets them. That is the soft underbelly of the whole stack — the layer where the platform’s careful guarantees meet a general-purpose computer that will do whatever it is told.
A platform is only as locked as the machine logging into it.
So the defense is not one thing. It is two layers, and they catch different failures. Layer one makes the wrong move unavailable. Layer two catches the allowed-but-wrong move that gets through anyway. Get the first one right and most of this list never happens. Get the second one right and the rest gets a second look before it gets access.
What can government borrow from Apple’s closed system?
Apple’s reputation was built on a closed system. You installed from one store. Apps were signed, reviewed, and sandboxed. You did not get root on your own phone. People complained, and on a personal device, fair enough — it is your phone.
But notice what that closed system bought: a billion devices that are remarkably hard to brick, infect, or quietly turn into a botnet, used by people who never think about security once. The control is the feature. The wrong move is not punished after the fact. It is simply not available.
That is the model government endpoints need. Not because the people using them are careless, but because the cost of one wrong click on a machine that can reach a citizen database is far too high to leave to vigilance.
The good news: you do not need Apple, and you should not want a single foreign vendor holding the keys to the state’s computers. You borrow the property, not the company. The same closed-system guarantees rebuild on open foundations, where the state holds the keys. Here is the first layer.
A closed system, built right, is not a cage. It is a gate that only opens for what belongs inside.
What does a locked-down endpoint actually look like?
This is layer one: make the wrong move unavailable. Five mechanisms, all on open foundations.
An immutable, locked-down base OS. Start from an enterprise or immutable Linux base — RHEL or Ubuntu LTS for the conservative route, or a transactional system like openSUSE MicroOS where the OS image is read-only and updates apply atomically with clean rollbacks. SELinux or AppArmor enforce mandatory access control, so a compromised app cannot wander outside its box. The person using the machine does not get admin rights. The system drifts toward its known-good state, never away from it.
One app store, no sideloading. Software comes from exactly one place: a managed, allowlisted repository — the government’s own app store. Packages are signed; unsigned or unknown software simply will not install. Need a new tool? You request it, it gets reviewed, and it appears in the store. This is the honest lesson from every “decentralized app store” experiment I looked at: you can decentralize the catalog and even the payments, but the last mile of trust — signing, malware scanning, revocation, deciding what is actually allowed to execute — has to be owned by whoever owns the platform. On a government fleet, you want that control, not in spite of it.
Centralized management, fully open source. This is the Landscape-shaped hole, filled without the proprietary lock-in. A device-management layer like OPSI for software distribution and patching, plus a configuration engine like Puppet or Salt to enforce policy continuously and quietly undo drift. One console patches the fleet, audits it, and proves its state. The machine becomes install-and-forget for the person using it — boring, again, on purpose.
Network access on a need-to-reach basis. DNS, proxies, and destinations are allowlisted at the gateway. VPN and tunneling packages are removed and blocked at the policy layer, so no one can quietly route around the controls. Kernel-module loading is restricted. The endpoint reaches what its role needs, and nothing else.
The hardware has to prove itself too. Software control is half the job. The other half is the network refusing to talk to a device it does not recognize. Network access control — the 802.1X family — means only enrolled, attested, healthy machines get onto the network at all. Plug in a personal phone or an unknown laptop and it lands in a quarantine segment, not the core. USB mass storage is disabled or tightly allowlisted, so a personal drive is just an inert lump of plastic.
Map each open-desktop threat to the control that kills it, and the shape of the layer gets clearer:
Notice what every row has in common. The wrong move is not detected and logged and escalated. It is removed from the menu. That is the whole point of layer one: you make the safe path the only path.
When should “out of pattern” mean “stop”?
Layer one handles the known-bad. The harder problem is the unknown-bad, the action that is technically allowed but wrong for this person, right now. That is layer two.
A clerk who has only ever opened ten records a day suddenly pulls ten thousand. An account that always signs in from one district office logs in at 3 a.m. from a new device in another state. Someone starts exporting files they have never touched. None of these trip a simple rule. All of them are out of pattern.
This is where behavioral analytics earns its place. Not to surveil people, but to learn the normal shape of each role and notice when reality stops matching it. Out of pattern does not have to mean “banned.” It can mean step up: re-authenticate, confirm with a supervisor, throttle, or freeze the risky action until a human checks. It is the same conditional-access logic banks and large enterprises already run, pointed at protecting public data instead of profit.
Four behave the same; one throws itself wide open. Layer two's job is to notice, and ask for a second look before it gets access.
I want to be careful here, because this is also the part that can go badly wrong. So let me come back to it.
Where could this go wrong?
This is a lot of control to hand a system, and control is exactly the thing that gets abused. So, honestly:
Lock it down too hard and people route around it. This is the oldest law of IT security. If the managed machine cannot do someone’s actual job, they will do that job on their personal laptop over their phone’s hotspot, and now you have zero visibility instead of partial control. The closed system only works if it is genuinely usable, with a fast, respected path to request the app or the access you need. Control without a release valve just manufactures shadow IT.
Armor the managed machine past the point of usefulness and the real work just walks to a phone. That is not control. It is shadow IT with a gold padlock on it.
Behavioral monitoring is surveillance, and it is surveillance of government workers. A system that watches every action to spot anomalies is also a system that watches every action. That demands hard limits: monitor for security, not productivity; collect the minimum; be transparent with staff about what is logged; and never quietly repurpose the data. Anomaly detection aimed at protecting citizens is defensible. The same pipeline aimed at ranking employees is not.
A closed system is only as good as its steward. This is the thread running through the whole series. A locked-down fleet with no one funding the patches, curating the app store, and answering the alerts does not stay secure. It freezes into an out-of-date monoculture — every machine identically vulnerable. Same lesson as the platform and the commons: the architecture is load-bearing, but so is the body that owns it.
Open source, or it is just someone else’s closed system. If you solve all of this by buying one proprietary management suite, you have rebuilt the vendor lock-in the rest of this series argues against, on the most sensitive machines you own. The whole point is a closed system on open foundations, where the state holds the keys.
Assume the endpoint is hostile
The first four posts were about concentration. A leak, where trust collapsed into one exam. A meltdown, where it collapsed into one portal. An architecture built to stop pouring everything into one place. And a way of buying it that traded the single multi-year vendor for an open commons. One machine, four times, failing at the single point where everything had been piled.
The endpoint is the inversion. It is the same blind trust — that the thing in the middle will always behave — but instead of concentrated into one place, it is replicated across lakhs of points. Each machine on its own is a small door. Together they are the largest attack surface the state owns: lakhs of general-purpose computers, each one trusting whoever sits in front of it to never once have a bad day. Same disease, opposite topology.
Lakhs of locks, each one trusted. The same disease as one bucket or one contract, just spread thin across a field instead of piled into a point.
So we stop trusting that. Not the people — the assumption. Build the endpoint so the wrong move is unavailable, the unknown device is turned away at the gate, and the strange behavior gets a second look before it gets access. Make the safe path the only path, and you stop asking a clerk in a district office to be a security expert on top of the actual job.
A closed system sounds like a cage. Built right, on open foundations, it is the opposite. It is the seatbelt — the thing that protects you automatically, on the one day you needed it and weren’t thinking about it.
So assume the endpoint is hostile. It is the kindest thing you can do for the person using it.
Frequently asked questions
Why should a government treat its own endpoints as hostile? Not the people, the assumption. The most dangerous account on a server is rarely a foreign hacker; it is the tired, logged-in human with too much access on a bad day. Treating the endpoint as hostile by default means refusing to make the job depend on perfect vigilance, every day, forever, against threats the person was never hired to spot. The hostility is aimed at the machine’s defaults, not at the worker.
What does “make the wrong move unavailable” mean in practice? It is the five-mechanism lockdown layer: an immutable, locked-down base OS with SELinux or AppArmor and no local admin; one signed, allowlisted app store with no sideloading; centralized open-source management like OPSI plus Salt or Puppet; network access allowlisted at the gateway with VPN and tunneling packages removed; and 802.1X network access control with USB mass storage disabled. The wrong move is not detected after the fact. It is removed from the menu.
Can you get Apple-style security without locking the state into a foreign vendor? Yes. You borrow the closed-system property, not the company. Rebuild the same guarantees on open foundations: RHEL or Ubuntu LTS or openSUSE MicroOS for the base, OPSI with Salt or Puppet for management, a curated signed store for software, and 802.1X at the network edge. The state holds the keys, and nothing depends on one company continuing to sell you the lock.
Isn’t behavioral monitoring just surveillance of government workers? It can be, which is exactly why it needs hard limits. Monitor for security, not productivity. Collect the minimum. Be transparent with staff about what is logged. Never quietly repurpose the data. Anomaly detection that freezes a 3 a.m. bulk export until a human checks is defensible; the same pipeline pointed at ranking employees is not. The line is the use, and it has to be drawn before the system is built.
What’s the one thing this approach cannot survive without? A funded steward. A locked-down fleet with no one funding the patches, curating the app store, and answering the alerts freezes into an out-of-date monoculture where every machine is identically vulnerable. Same lesson as the platform and the commons: the architecture matters, but so does the body that owns it.
Sources and further reading - SELinux mandatory access control (Red Hat) · openSUSE MicroOS (immutable, transactional) · OPSI open-source device management · Configuration management with Salt / Puppet · Apple’s closed-system app code signing · F-Droid: a curated, open app repository
What’s next?
This is part of a series on why India’s government software keeps falling over, and how I’d build it so it doesn’t:
- Stop Fixing India’s Exams — why you can’t patch a high-stakes exam into honesty, and the continuous competency profile that replaces it
- BTS of CBSE’s Infra Meltdown — why the result-day “cyberattack” was almost certainly just demand, and why the portal was built to fall over
- How I’d Actually Build Government Software That Doesn’t Fall Over — a federated core, HTML-first frontends, and storage you can’t make public
- GitHub for Government Work — trading the multi-year, single-vendor RFP for an open commons paid per merged pull request
- Assume the Endpoint Is Hostile (you are here) — locking down the lakhs of devices that reach the core, with a closed system on open foundations
One machine, five layers: the exam, the meltdown, the architecture, the procurement, and the endpoint.
