Managed Firewall

What does a managed firewall service actually cover, end to end?

Plenty of arrangements described as managed cover two or three of those. The gaps are usually patching, backup and out-of-hours cover, which are precisely the three that only matter on the day they are missing.

The sequence we work through is the same each time. An assessment of what you already run, so we take over from a known position rather than a guess. Then hardening and remediation of whatever that surfaced, agreed with you before anything changes.

Then the platform goes on: monitoring, automated configuration backup and alerting tuned to how you actually want to be told about a problem. After that it becomes a routine rather than a project, with patching on an owned schedule, rule changes going through change control, and monthly reporting covering traffic, threats and compliance in plain terms rather than a raw log dump.

What does the onboarding assessment look for?

The things that have drifted, because a firewall in service for a few years has almost always drifted. We read the rule base end to end and look for rules with no owner and no comment, rules referencing hosts or subnets that no longer exist, rules created as a temporary exception years ago, permissive any-to-any entries, and management interfaces reachable from more places than they need to be.

We hand that back as a written picture before touching anything, separating what is genuinely urgent from what is untidy. Some of what we find is fine, and we say so rather than manufacturing work.

Where hardware is genuinely end-of-life we will tell you plainly and plan a replacement rather than selling you kit you do not need, and where it has life left we take over what you already own. The assessment also establishes the baseline the change log is measured against, which matters later: without a starting point, no audit trail can tell you what actually changed.

Why do firewall rule bases decay, and what does that look like?

Because rules get added under pressure and almost never get removed. A supplier needs access for a project, a new application needs a port opening this afternoon, someone is troubleshooting at eight in the evening and widens a rule to prove where the problem is.

Each of those is reasonable in the moment. What makes them a problem is that the project ends, the application is decommissioned and the troubleshooting finishes, and nobody goes back. Rules accumulate over years until the base is longer than anyone will read, which is when people stop reading it.

Three specific patterns cause most of the damage. Broad any-to-any rules, usually added to unblock something quickly and left in place because removing them feels riskier than leaving them: they defeat the point of a rule base by making everything below them irrelevant. Rules pointing at IP addresses that have since been reissued to something else entirely, so access intended for one system now reaches another.

And rules that only one person understood, who has since left, which is why nobody will delete anything. The cure is unglamorous: a scheduled review, an owner and a business justification recorded against every rule, and a written change history so removal is a decision rather than a gamble.

Why does outbound traffic matter as much as inbound?

Because most incidents involve traffic leaving, not arriving. Blocking inbound connections is the job everybody understands and most firewalls do reasonably well out of the box. What is far less often configured is egress filtering: controlling what your own network is allowed to talk to on the way out.

An intrusion that starts with a phishing email or a compromised laptop does not need an inbound rule at all, because the device is already inside. What it does need is a route out to command and control infrastructure, and then a route out for whatever data is being taken.

Default outbound-allow is the norm because it never causes a support ticket, which is exactly why it survives. Tightening it is genuine work: you have to know what your systems legitimately talk to before you can restrict them, and getting it wrong breaks things visibly.

Done in stages it is one of the higher-value changes available on a perimeter, particularly restricting which internal systems may reach the internet directly at all, and alerting on outbound traffic to destinations and at times that do not fit the pattern. It also converts the firewall from a device that only blocks known bad things into one that tells you when something unexpected is happening.

Who owns firmware patching, and what happens when nobody does?

In most DIY setups the honest answer is nobody, and it is rarely a decision anyone made. Firewall firmware updates carry real risk of disruption, so they get deferred until things are quieter, and things are never quieter.

Weeks become months, the appliance falls several releases behind, and the version running is one nobody would deliberately choose. A firewall running old firmware is not a cost saving. It is a known door left ajar, on the one device whose entire purpose is to be the door.

Out-of-band vendor advisories for actively exploited vulnerabilities get treated differently again, because those are the ones where waiting for the next comfortable window is the wrong call. The reason we can hold a schedule is that it is our job rather than the eleventh item on someone else's list.

What does change control on a firewall actually involve?

A request, a review, an approval, a record. Every rule change is raised with a stated business reason and a named requester, reviewed for whether the change is as narrow as it can be, approved by someone other than the person who wants it, implemented, and then logged with what changed, who asked, who approved and when.

That sounds bureaucratic for a small business until the first time somebody asks why a port is open, and the difference between an answer and a shrug is whether that record exists.

The records earn their keep in three specific situations. During troubleshooting, because the first question when something stopped working on Tuesday is what changed on Monday. During an audit, an insurance renewal or a customer security questionnaire, where evidence that changes are controlled is worth more than a description of your intentions.

And during an incident, when reconstructing what the perimeter looked like at a point in time is the difference between an investigation and speculation. Requests to add a rule with an expiry date are worth encouraging as well, because a rule created to expire is the only kind that reliably gets removed.

Why is configuration backup the part people most often miss?

In a typical DIY setup none of that exists anywhere except on the box itself. When the box fails, recovery is not a restore. It is a rebuild from memory, under pressure, while the business is offline, by whoever is available rather than whoever built it.

Automated backup off the device changes the shape of that day entirely: you replace the hardware, restore the last known-good configuration, and verify. It also gives you something a one-off export does not, which is a history.

Being able to compare today's configuration with last month's tells you what has changed, whether that change was approved, and lets you roll back a specific alteration rather than the whole device. Backups need to live somewhere separate from the network they protect, and they need to be restored occasionally rather than merely taken, because a backup nobody has restored is an assumption with a schedule attached.

On our managed service that backup runs weekly, alongside daily infrastructure checks and continuous monitoring, with firmware handled on a planned quarterly cycle rather than whenever a release appears. It is worth asking any provider for those numbers specifically, because the common answer is that it happens when somebody remembers, and that is not a schedule.

What does 24/7 firewall monitoring catch that business-hours checking does not?

The things that happen in the gaps, which is most of the week. Evenings, weekends and the small hours are not quiet on a network: they are when scheduled tasks run, when backups compete for bandwidth, when automated scanning is heaviest, and when an intruder would prefer to be working. A DIY setup where somebody reviews logs when they have a spare moment is not monitoring, it is sampling, and it samples exactly the hours when the least is happening.

Alerting is then tuned to how your team actually wants to be told, which is the point of having built the platform ourselves rather than reselling a generic product with somebody else's idea of an alert threshold.

What happens when licences, subscriptions and hardware quietly expire?

The firewall keeps passing traffic, which is the problem. Most modern appliances split their capability between the base device and subscription services layered on top, so intrusion prevention, content and web filtering, application control and threat intelligence feeds typically renew annually rather than being permanent.

When one lapses the device does not stop: it carries on forwarding packets, with a feature you are still describing in your security documentation now doing nothing, or running on signatures that stopped updating months ago. Nobody notices, because nothing broke.

Hardware end-of-life works the same way and matters more. Once a model passes its vendor support date there are no further firmware updates, which means the next vulnerability published against it is permanent.

That is not only a security position, it is a compliance one: Cyber Essentials requires software in scope to be within vendor support, so an unsupported appliance can fail an assessment you were treating as a formality, at the point a contract depends on it. Tracking renewal and end-of-life dates ahead of time is dull, unglamorous administration, which is precisely why it is one of the first things to fall off an in-house list.

How does the firewall fit into Cyber Essentials?

Inbound rules need a documented business case, and rules that are no longer needed have to be removed, which is where a decayed rule base and an absent change log both become audit findings rather than untidiness.

The theme most likely to catch a firewall out, though, is security update management, because it requires that software in scope stays within vendor support and that critical and high-severity updates are applied within fourteen days. Firmware counts. An appliance several releases behind, or a model past its end-of-support date, is a problem for that control regardless of how well the rules are written.

Cyber Essentials Plus goes further and tests rather than takes your word for it. Systech is an accredited Cyber Essentials provider and holds the certification itself, alongside ISO 27001 and ISO 9001, so this is a standard we are assessed against rather than one we only advise on.

Managed or DIY: where does the crossover actually sit?

Not at a headcount, and not at a site count. The threshold to watch for is the moment firewall upkeep stops being somebody's clearly-owned job and becomes nobody's, which is what quietly happens as a network grows.

A very small business, single site, simple network, with an IT person who genuinely has the time and the specialism to own the firewall properly, can run it themselves and the saving is real. That is a legitimate position, and we will say so. The risk is manageable when the ownership is genuine rather than assumed.

What tips it is that firewall management is not a monthly task, it needs attention every week, and it needs a specialism a generalist has to context-switch into. It is rarely anyone's full-time job, so it competes with everything more visible and loses. The real cost of DIY is not the time it takes while everything is working.

It is the outage, or the breach, that lands on the one week nobody was watching. That is the gap this service was built to close, which is also why plenty of our managed firewall clients have a capable in-house IT team and simply hand us this one piece.