Last week’s article looked at management consoles as the new front door. This week, the same idea is showing up in a different place: the network itself.
In July, more than 30 Minnesota water systems were targeted in a coordinated cyberattack. One plant went offline. Around the same time, The Hacker News reported that attackers were using a compromised third-party advertising script to swap cryptocurrency wallet addresses on customer sites. Different victims, different techniques, same weakness: organizations trusted the network path around a system more than the system’s own security.
For a small business, that should change the question from “Is the server patched?” to “What can move through our network, and who can make that happen?”
The network is where trust accumulates
Most companies still draw their environments as a few boxes: users, servers, cloud apps, and maybe a firewall in front. Actual traffic is messier. A laptop moves between home Wi-Fi and the office. A vendor gets remote access to a building-control system. A SaaS integration receives an API token. A managed service provider can log into half the environment from one console.
Each connection creates a trust decision. Those decisions pile up quietly because they usually work. The HVAC vendor can reach the controller. The accounting software can pull payroll data. The developer can access the build server. Nobody notices until an attacker inherits one of those permissions.
The Minnesota water-system incident is a useful warning even for companies nowhere near critical infrastructure. An attacker does not need to own every machine to cause an outage. Access to one operational system, one remote-management account, or one poorly separated network segment can be enough.
Network security is therefore less about building a taller wall and more about limiting the blast radius when somebody gets through.
The third-party path is often the shortest path
Small businesses depend heavily on outside providers. That is sensible. Few 100-person companies should run their own email, payroll, endpoint management, backup infrastructure, and building systems.
The problem is that vendor access tends to outlive the original project. A contractor receives a VPN account for a migration. The account remains active for years. A remote-management agent gets installed on every workstation. Nobody checks which technician can use it. A service account has broad permissions because narrowing them would take an afternoon that never appears on the calendar.
Recent incidents involving N-able N-central servers show why this matters. N-central is used by managed service providers to administer customer environments. The Hacker News reported that attackers were able to take over servers after an initial fix proved incomplete. A flaw in a central management layer can turn one compromise into a customer-by-customer problem.
The practical lesson is uncomfortable: your vendor’s security model is part of your network model. If a provider can reach your endpoints, domain controllers, backup systems, or firewall, that provider is effectively inside your security boundary.
Ask vendors four direct questions:
- Which systems can your staff access?
- Is access time-limited and individually attributed?
- Do you require phishing-resistant MFA for administrators?
- What happens when your management platform is compromised?
If the answers are vague, treat the access as a risk you own.
Segmentation beats hope
A flat network is convenient right up until ransomware arrives. Once an attacker lands on one workstation, every reachable system becomes part of the next move: file shares, identity services, backups, printers, cameras, and operational equipment.
Segmentation does not require a six-figure redesign. Start with a few boundaries that reflect business impact:
- Employee devices should not directly reach backup administration interfaces.
- Guest Wi-Fi should have no route to internal systems.
- Cameras, badge readers, printers, and building controls belong on their own networks.
- Vendor access should terminate in a restricted jump host or dedicated VPN group.
- Administrative interfaces should accept connections only from approved management devices.
The rule is simple: a device should be able to reach what it needs, not whatever happens to share the same switch.
Test those rules from the outside and from inside. A firewall diagram is a plan, not proof. A quarterly review of actual routes and firewall logs will catch the forgotten exception that a policy document will not.
DNS and browsers are part of the attack surface
Network security also includes the services users barely notice. DNS decides where a browser goes. Advertising and analytics scripts decide what code loads in a page. Wi-Fi decides which network a device joins.
Attackers keep exploiting those layers because they sit between a user and the application they think they are using. Recent reports of poisoned web scripts and hijacked hotel Wi-Fi pushing fake software updates show the same pattern in public and private networks: control the path, then let the victim do the clicking.
For SMBs, a few controls make a real difference. Use a managed DNS resolver with malware and newly registered-domain blocking. Prevent endpoints from silently changing DNS settings. Require browsers and operating systems to update through trusted channels, and train staff to treat browser pop-ups that demand an update as hostile until proven otherwise.
For public-facing websites, maintain an inventory of third-party scripts. Remove anything nobody can explain. Pin versions where practical, monitor changes to the site’s JavaScript, and avoid loading payment or authentication pages with unnecessary external code.
Five network changes to make this week
- Export your firewall rules and read them as a stranger would. Look for “any-to-any” rules, old vendor IP ranges, exposed admin ports, and exceptions with no ticket or owner.
- Review remote access accounts. Disable former vendors, require named accounts instead of shared logins, and set expiration dates for temporary access.
- Separate backups and administration. The backup console should not be reachable from ordinary employee endpoints. Protect it with phishing-resistant MFA and a separate admin workstation if possible.
- Scan your public footprint. Use Censys, Shodan, or an external vulnerability-scanning service to identify exposed VPNs, RDP, web panels, cameras, and forgotten test systems. Do not scan networks you do not own.
- Run a “one laptop is compromised” exercise. Pick a normal employee device and trace what it could reach. If the answer includes domain admin, backups, or building controls, that is your first segmentation project.
The network is no longer background plumbing. It carries identity, automation, vendor access, and the commands that keep the business running. The organizations that handle the next breach best will not be the ones with the longest security product list. They will be the ones that made compromise boring: one account, one device, one segment, and no easy route to everything else.
Sources
- The Hacker News, “Coordinated Cyberattack Targets 30+ Minnesota Water Systems as One Plant Goes Offline,” July 2026: https://thehackernews.com/2026/07/coordinated-cyberattack-targets-30.html
- The Hacker News, “N-able Says Attackers Take Over N-central Servers After Initial Fix Proves Incomplete,” August 2026: https://thehackernews.com/2026/08/n-able-says-attackers-take-over-n.html
- The Hacker News, “Hackers Poison Adform Script to Swap Crypto Wallet Addresses Across Customer Sites,” August 2026: https://thehackernews.com/2026/08/hackers-poison-adform-script-to-swap.html
- CISA, “CISA Adds One Known Exploited Vulnerability to Catalog,” July 29, 2026: https://www.cisa.gov/news-events/alerts/2026/07/29/cisa-adds-one-known-exploited-vulnerability-catalog
Reply with ‘post it’ and the images will be added and the article will go live.
