Nobody has money for the best firewall, full redundancy, and round-the-clock monitoring all at once. That's not a networking problem — it's a sequencing problem. Buy in the wrong order and you end up with a great firewall protecting a single point of failure. Taliferro sets that order before we spec any hardware.
Co-Founder Taliferro
Say you're a 40-person company with $15,000 to spend on your network this year. That's not enough for the best firewall, full hardware redundancy, and round-the-clock monitoring. Most guides pretend you'll eventually afford all of it, so they list everything with equal weight. That's not useful advice — it's a wish list. What actually matters when the budget is finite is the order you buy in. Get the order right and a modest budget covers the failures that actually happen. Get it backward and a big budget still leaves you exposed.
When cloud complexity starts slowing delivery, cloud design support shows how Taliferro turns cloud architecture into working execution, and the momentum system keeps the work tied to outcomes instead of activity.
Security has to be part of the network design from day one, not a line item added after something goes wrong. It also isn't a one-time purchase — the same firewall rule that was correct in January can be wrong by June because the threats it's defending against changed. Budget for the review, not just the box.
Protect against outside attackers, yes, but also design for the ordinary internal mistake: someone clicks a bad link, someone plugs in the wrong cable, someone's laptop leaves the building with access it shouldn't have. Most breaches start inside the perimeter, not outside it.
Routers, switches, load balancers, and firewalls all sit on the network, and all of them ship with a default password somewhere. "Secure the network" means securing each of these individually — not just the firewall at the edge. A hardened firewall behind an unsecured switch is a locked front door with an open window around back.
A firewall's job is simple to describe: decide what traffic gets in and out, and watch for patterns that look like an attack. In practice, that means writing rules that allow only what the business actually needs — not "allow everything, then figure out what to block."
A basic firewall solves most of what a small business needs. Distributed Denial of Service (DDoS) protection is a separate layer worth adding once you have something worth flooding — a public-facing app, a storefront, an API other companies depend on.
A VPN builds an encrypted tunnel across a network you don't control — home WiFi, a coffee shop, a hotel — so traffic inside that tunnel can't be read even if the network it's crossing is compromised. If anyone on the team works outside the office, this isn't optional; it's the difference between "our data crossed an untrusted network" and "our data crossed an untrusted network in the clear."
Intrusion Detection (IDS) watches and alerts. Intrusion Prevention (IPS) watches and blocks. IDS tells you something happened; IPS stops it from finishing. Neither one catches attacks it's never seen before — both work off known patterns — but tracking what they do catch tells you how an attacker's tactics are shifting over time, which is worth more than the alert itself.
Data Loss Prevention (DLP) is the mirror image: instead of watching for things coming in, it watches for things going out — a customer database attached to a personal email, a spreadsheet of records copied to a USB drive — and blocks the exchange if it doesn't match policy.
A load balancer spreads incoming requests across multiple servers so no single one gets overwhelmed. If one server's health check fails, the load balancer stops sending it traffic until it recovers — visitors never see the failure, they just get served by a different server. A proxy sits in front of that and adds filtering: caching content, blocking traffic that doesn't match expected patterns, absorbing some denial-of-service attempts before they reach anything real.
Pick hardware after you know what it needs to run, not before. A network built for a database-heavy application has different requirements than one built for a video-heavy one, and buying general-purpose gear "to be safe" usually means overpaying for capacity you don't use and underbuying the one spec that mattered. Test every new component before it touches production — a firewall or switch that fails during a live cutover is a worse outage than the one you were trying to prevent.
Redundancy means no single failure takes down the whole system. The way to find where you need it is to ask, for every component: if this one thing breaks right now, what stops working? A single server with a single internet connection is a single point of failure twice over — the box and the link.
You don't need to duplicate everything. You need to duplicate the handful of things where the answer to that question is "everything downstream of it." That's usually the internet connection, the core switch, and whatever holds your primary data — not the printer on the third floor.
A written security policy — device management rules, VPN requirements, firewall standards — matters less for what it says and more for the fact that it exists and someone owns keeping it current. And test your own internet connection periodically; a slow ISP link looks identical to a slow application from the user's chair, and misdiagnosing it wastes hours pointed at the wrong system.
Monitoring catches problems as they happen. Logging lets you reconstruct what happened after the fact. You need both — monitoring without logging means you get paged for outages you can never fully explain; logging without monitoring means you find out about the outage from a customer instead of a dashboard.
Backups only count if they're tested. An untested backup is a belief, not a plan. Store them in a different location and, ideally, a different format than the original — if the failure that destroyed your data was a ransomware attack or a fire, "the backup was on the same drive" or "in the same building" defeats the point.
Secure the devices you already have. Add the firewall rules and VPN that stop the common attacks. Find your real single points of failure and fix the two or three that matter, not all of them. Add monitoring so you find out about problems before a customer does. Test the backup. Buy the impressive hardware last, once the boring things are covered — it's the boring things that fail first.
This is the same sequencing work Taliferro walks through with clients before recommending a single piece of hardware: what breaks first, what breaks worst, and what actually fits the budget in front of you — not the one you wish you had.
Tyrone ShowersUse the article to frame the issue, then review cloud design support, connect it to the Momentum System, or book a cloud review.
Want this fixed on your site?
Tell us your URL and what feels slow. We’ll point to the first thing to fix.
Explore Taliferro's free tools: Ask TODD · Find · Email Signature Builder · SayIt · Lead Vault · Meet Maya — or become an affiliate.
More from the blog