Most security incidents at mid-size Indian organisations are not the result of a sophisticated adversary. They are the result of two ordinary decisions made without much thought: buying a firewall on the wrong number, and leaving everything behind it on one flat network.
Both are fixable, and neither requires an enormous budget.
Part one: why the datasheet number misleads
Firewall datasheets lead with a large, appealing figure — "10 Gbps firewall throughput". That number is measured with large packets, simple stateful rules, and every security feature switched off. It describes a mode nobody actually runs the device in.
The number that matters is threat-prevention throughput: capacity with IPS, anti-malware, application control and SSL/TLS inspection enabled. On the same device, that figure is frequently one-fifth to one-tenth of the headline.
SSL inspection is the heaviest single component, and it is not optional in any meaningful sense — the overwhelming majority of web traffic is encrypted, so a firewall not inspecting TLS is largely inspecting nothing.
What to size against
- Internet bandwidth — and what you plan to upgrade to in three years, not what you have today
- Concurrent users, including remote workers on VPN
- VPN tunnels — site-to-site and client, with their own throughput cost
- Features you will actually enable — be honest; if you buy a next-generation firewall and run it as a packet filter, you bought the wrong device
- Growth headroom — target roughly 50% utilisation at peak, so bursts and future growth do not push you into replacement early
A useful rule of thumb: take your peak internet utilisation, double it for growth, and require that figure to sit under 60% of the device's threat-prevention throughput with SSL inspection enabled.
The high-availability question
A single firewall is a single point of failure for your entire internet connectivity. Whether that justifies an HA pair depends entirely on what an hour of downtime costs you. For a manufacturing plant or a hospital, the answer is usually yes. For a 25-person office, often not. Make it an explicit decision rather than an accidental one.
Part two: segmentation is where the real gain is
A firewall protects the boundary between you and the internet. It does nothing about lateral movement once something is already inside — and on a flat network, "inside" means everything can reach everything else.
This is how a compromised laptop reaches a file server, how a vulnerable IP camera becomes a foothold, and how ransomware that lands on one machine encrypts every share in the building.
A practical segmentation model
You do not need a full zero-trust architecture to get most of the benefit. A sensible VLAN structure for a mid-size organisation:
| Segment | Contains | Should reach |
|---|---|---|
| Servers | File, application, database servers | Specific ports from user segment only |
| Users | Staff desktops and laptops | Internet, defined server ports |
| Management | Switch, firewall, AP, server management interfaces | Nothing outbound; reachable only from admin workstations |
| CCTV / IoT | Cameras, recorders, access control, sensors | Recorder only — no internet, no business systems |
| Guest | Visitor devices | Internet only, fully isolated |
| Voice | IP phones | Voice gateway only, with QoS priority |
The rule between segments should be deny-by-default with explicit, documented allowances. If you cannot say in one sentence why a particular flow is permitted, it should not be.
Start with the two that matter most
If a full redesign is not feasible right now, do these two:
- Isolate CCTV and IoT. These devices are rarely patched, frequently shipped with weak defaults, and almost never need to reach anything except their recorder. This is the highest-value, lowest-disruption segmentation you can implement.
- Isolate guest Wi-Fi. Guest traffic should reach the internet and nothing else. Verify this rather than assuming — a surprising number of "guest" networks are simply a second SSID on the same VLAN.
Part three: the rule base
Firewall rule bases decay. Rules get added during an incident and never removed, temporary permits become permanent, and after a few years nobody knows what half of them are for.
When we replace a firewall, we rebuild the rule base rather than migrating it. Migrating an inherited rule base carries its accumulated mistakes into the new device and wastes most of the benefit of the upgrade.
Practices worth adopting:
- Every rule carries a comment: why it exists, who requested it, when
- Any rule created as temporary has a review date recorded
- Rule usage is reviewed periodically — unused rules are candidates for removal
- The final rule is an explicit deny-all with logging enabled
- Any rule with "any" in both source and destination is treated as an incident to be corrected
Part four: the things that get skipped
- Default credentials. On switches, access points, cameras, recorders, UPS management cards and printers. Every one of them.
- Management plane exposure. Device management interfaces should never be reachable from the user segment, let alone the internet.
- Logging with no retention. Logs that are overwritten in three days are useless during an investigation that starts three weeks after the event.
- MFA on remote access. A VPN protected only by a password is a password away from being an attacker's VPN.
- Firmware currency. Edge devices are the ones facing the internet. They are the ones that most need to be current.
A reasonable starting point
If you are unsure where you stand, a short assessment answers it quickly: what is exposed, how is the rule base structured, what is segmented, where are default credentials still in place, and what is the practical remediation order. That is usually a few days of work, and it converts a vague anxiety into a prioritised list.
Most organisations discover that the first three items on that list are inexpensive and remove the majority of their real exposure.