Just disconnect the internet
Calls to “just disconnect critical systems from the internet” in the wake of outages and security scares run up against the reality that most modern software, tooling, and workflows assume constant connectivity. Commenters weigh the security benefits of air‑gapping, private sector networks, and tight network segmentation against their operational and maintenance costs, arguing instead for layered defenses, controlled update pipelines, and simpler, higher‑quality software. The thread highlights how incentives, complexity, and poor defaults make it hard for organizations to balance safety, usability, and economic pressures.
Airgapping vs Internet Connectivity
- Many agree fully offline (“just disconnect”) is impractical for most modern business systems, which derive value from interconnection (billing, records, coordination, remote admin).
- Others argue critical infrastructure (health, aviation, industrial control, MRI/lathe/CNC/PLC systems) should be as offline as possible, often only reachable via local or tightly firewalled OT networks.
- Strong view: some devices (e.g., safety‑critical medical equipment) should never use “internet‑native” practices (cloud CDNs, NPM at boot, etc.).
Security Models: Obscurity, Swiss Cheese, Zero Trust
- One camp calls “disconnect from the internet” a form of security through obscurity and insists the root problem is bloated, insecure software; only simple, minimal code with clear attack surface can be truly robust.
- Others say this misuses “security through obscurity”: airgapping, private networks, and fences are legitimate defense‑in‑depth slices in a “Swiss cheese” model.
- Debate over whether such models hold against nation‑state‑level attackers (e.g., Stuxnet) vs being appropriate for risk‑based protection against common threats.
- Zero trust is both praised and criticized: some see it as best practice; others see it as buzzword‑driven, shifting trust to vendors and giving a false sense of safety.
Sector-Specific and Private Networks
- Examples: Swedish and Danish healthcare networks, UK’s HSCN, Polish government networks, hamnet, DN42.
- Pros cited: reduced exposure to the public internet, dedicated availability, additional security layer.
- Cons: high cost, low bandwidth, complexity, “false sense of security,” and risk that participants under‑secure internal services.
- Note that many “private” networks are not truly air‑gapped (VPN access, accidental bridges, dual‑homed machines).
Software Complexity, Dependencies, and Updates
- Strong criticism of software culture: huge dependency trees, internet‑centric tooling, and multiple conflicting trust stores make offline or tightly controlled environments painful.
- TLS and CA handling on internal networks is repeatedly described as a major headache.
- Several argue better practice is:
- Block or strictly filter outbound flows.
- Host internal mirrors (packages, Docker images, OS and AV updates).
- Disable or stagger auto‑updates, with QA and gradual rollout.
- CrowdStrike outage is framed as a process/quality control failure; online connectivity mainly amplified blast radius.
IoT, Kiosks, POS, and Real‑World Lapses
- Many anecdotes of kiosks, parking machines, digital signage, and POS systems:
- Running full Windows or similar with internet access.
- Poorly locked down (kiosk mode disabled, browsers open, even card‑handling surfaces exposed).
- Split views on using Windows vs Linux: Windows often chosen for ecosystem and management tooling; others see specialized, minimal Linux images as better appliance platforms.
Human Factors, Incentives, and UX
- Recurrent theme: organizations are not incentivized to value security; features and speed win, and customers quickly forget breaches.
- Some argue engineers and orgs must take more responsibility; others say regulation with real penalties is needed.
- A side discussion critiques poor blog typography and readability as another symptom of neglecting fundamentals.