The sardine and the register
A commercial kitchen now runs on IP. Temperature probes, display screens, smart ovens, a walk-in's inventory sensor — and the point-of-sale terminal that takes cards. Too often they share one flat network.
That flat network is the whole problem. The cheapest, least-patched device on it — the sensor counting tins of sardines — sits one hop from the register. Compromise the sensor and nothing structural stops you reaching the POS. There was never a rule that said it couldn't.
kitchen-microsegmenter writes that rule. You give it an inventory with trust
tiers; it emits a default-deny nftables ruleset where the only traffic allowed is traffic
you sanctioned. A flow from a low-trust zone into a high-trust one is rejected before any
rules are generated:
ERROR uptier-flow iot->pos:443 lets a lower-trust zone reach a higher-trust one —
a compromised iot device could pivot into pos.Two design choices worth stating. It fails closed: an invalid policy produces no ruleset, not a partial one. And it never applies anything — it prints configuration for you to read and deploy deliberately. A tool that silently rewrote a live kitchen's firewall mid-service would be its own kind of outage.
Zero trust is not a product you buy. It is the refusal to assume that because two things can reach each other, they should.
— technika11y