Firewall strategy for growing businesses

A firewall has been in place for eight years. It holds roughly three hundred rules. Perhaps forty of them are understood by somebody currently employed. The rest were added for a project, a supplier, a migration or an emergency, and nobody has removed one in years because nobody can prove it is safe to.

The business consequence is not that the firewall is misconfigured. It is that the firewall has stopped being a control and become an assumption. It permits more than anyone intends, nobody can say precisely what, and the one question it exists to answer — what is allowed to reach what — no longer has an answer the business can produce on request. Auditors ask for that answer. So do insurers, and so does an incident.

The engineering position that follows is the organising idea of this article. A firewall's value is not measured by what it blocks. It is measured by whether the policy remains something a person can read, reason about and change with confidence. Everything below is in service of keeping it that way.

What a firewall is for

Worth restating precisely, because the popular framing — a barrier that keeps attackers out — encourages exactly the design mistakes described below. NIST's own definition in SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy, is more useful: firewalls are devices or programs that control the flow of network traffic between networks or hosts employing differing security postures.

Two things follow. It is a policy enforcement point, not a barrier — it enforces a decision somebody made about what should be permitted, and it is only as good as that decision. And it operates between postures rather than between inside and outside, which is why the same reasoning applies to internal boundaries as to the internet edge.

That publication is from September 2009 and remains the current final revision. Its age is worth noting honestly: it predates the near-universal move to encrypted traffic, cloud-hosted applications and remote workforces. Its principles about policy, default posture and ruleset management have aged well. Its assumptions about where the traffic goes have not.

Deny by default, in both directions

This is the one principle with a formal name and a citation behind it, which is useful when the argument has to be made to somebody holding a budget. NIST SP 800-53 defines it as a control enhancement under SC-7 Boundary Protection: SC-7(5), Deny by Default — Allow by Exception, which calls for denying network communications traffic by default and allowing network communications traffic by exception.

The phrase that matters is by exception. Every permitted flow exists because somebody identified a need for it, which means every permitted flow has a reason that can be recorded, reviewed and eventually withdrawn. A policy that begins permissive has no such record — the permitted set is simply everything nobody has got round to blocking, and there is nothing to review because no decision was made.

The practical failure is always the same. A rule base is opened up during a migration or a go-live because something is not working and the deadline is today, with an intention to tighten it afterwards. It is never tightened, because by the time anyone returns to it nobody can prove which of the permitted flows are load-bearing. Permissive-then-tighten is not a slower path to the same place; it is a different and worse destination.

The control specifies both directions, and businesses reliably implement one. That asymmetry is significant enough to have its own section below.

Rule ordering is a correctness problem

Most material on this subject treats rule ordering as a performance question — put the busiest rules near the top so the firewall does less work. On modern hardware that is largely irrelevant. The reason ordering matters is that it changes what the policy means.

Firewalls evaluate rules top to bottom and stop at the first match. A broad permit placed above a specific deny does not merely rank higher; it makes the deny unreachable. The deny is still present, still visible in the interface, still listed in any export, and has no effect whatsoever. Nobody removed it and nobody disabled it — it was silently overridden by something added later.

The first row is the one that causes real harm, and the reason it survives is that nothing fails. A shadowed deny produces no error, no alert and no symptom. The policy reads as though the traffic is blocked, the diagram says it is blocked, and it is not. This is the single strongest argument for testing a rule base rather than reading it, which is the subject of the verification section below.

The last row is worth adopting even though the firewall already denies by default. An explicit final rule that denies and logs turns invisible silence into evidence, and that evidence is what makes the rest of this article possible.

Object management, and why the rule base becomes unreadable

A rule base written in literal addresses is legible on the day it is written and opaque within a year. A rule permitting one address range to reach another on a given port tells a reviewer nothing about what it is for, which means it cannot be judged and therefore cannot be removed.

Named objects are what make review possible. A rule permitting a named finance workstation group to reach a named accounts application on a named service is a sentence a non-specialist can evaluate. The same rule expressed in addresses and port numbers is a puzzle, and a reviewer facing a hundred puzzles will approve all of them.

1. 1

   Name objects for what they are, not where they are

   A group named for its function survives an address change, a site move and a subnet redesign. One named after an address range has to be renamed or, more commonly, becomes misleading.

2. 2

   One object, one definition

   The same server defined three times under three names is how a decommissioning misses two of them. Objects should be created once and referenced, not redefined per rule.

3. 3

   Keep groups shallow and purposeful

   Deeply nested groups make the effective permission of a rule impossible to determine by inspection, which defeats the point of naming things in the first place.

4. 4

   Define services explicitly rather than reusing broad ranges

   A service object covering a wide port range because one application needed one port inside it permits everything else in that range, permanently and invisibly.

5. 5

   Remove objects when the thing is removed

   Decommissioning a server should remove its object. Left behind, it is indistinguishable from a live one during review, and the address may later be reassigned to something else entirely.

This is unglamorous administrative discipline rather than security engineering, and it is the difference between a policy that can be reviewed in an afternoon and one that cannot be reviewed at all.

Egress filtering: the half that does not get done

Almost every business filters inbound traffic. Very few filter outbound. The default outbound rule in a large majority of rule bases permits internal hosts to reach anything on the internet, on any port, and it was never a decision — it is what the device shipped with and nothing has broken since.

What outbound-any costs is specific. A compromised workstation can reach an external command and control channel. Data can be moved out over ordinary protocols to ordinary destinations. An infected host can participate in outbound attacks that are attributed to your address space. None of these require inbound access, which is why a strong inbound posture provides no protection against any of them.

Anti-spoofing is the baseline, and it is standardised

The narrowest and least controversial form of egress control is ensuring that traffic leaving your network carries a source address that legitimately belongs to your network. The practice is standardised as RFC 2827, also designated BCP 38, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, published by Ferguson and Senie in May 2000 as a Best Current Practice.

The terminology is worth getting right, because it is frequently muddled. The document describes ingress filtering from the perspective of the provider receiving your traffic — the filter is applied where traffic enters their network. From your side of the same boundary it is egress filtering. The rule it states is simple: permit packets whose source addresses fall within legitimately advertised prefixes, and deny the rest. It costs nothing, breaks nothing legitimate, and prevents your network being used to launch spoofed attacks.

Beyond anti-spoofing

Full outbound control is a larger project and does not have to be attempted at once. The useful sequence works inward from the assets whose outbound behaviour is most predictable.

The order matters because it front-loads the value. Servers, appliances, devices and management interfaces have narrow and stable outbound requirements, so restricting them is low-risk and removes the outbound path from precisely the systems an attacker most wants to use. General user traffic is the largest and most variable category and the one most likely to generate complaints, which makes it the wrong place to start and the wrong place to stop.

Logging: what to keep, and what to stop keeping

Firewall logging usually fails in one of two directions. Either almost nothing is logged, so an investigation has no evidence, or everything is logged, so the volume is unusable and the retention cost drives someone to shorten it to a week.

The asymmetry that resolves this is that denied traffic is far more informative per record than permitted traffic. A denial is either a misconfiguration you want to find or an attempt at something that should not happen. A permit at the perimeter, on a busy network, is a record that something ordinary occurred — accurate, voluminous and rarely useful.

• Log all denies, including the explicit cleanup rule at the end of the base, because that is where the interesting refusals land.
• Log permits selectively: administrative access, anything crossing into a sensitive zone, and any rule that exists as a documented exception.
• Log every change to the policy itself, with who made it and when. This is the record that matters most during an audit or an incident and the one most often absent.
• Send logs somewhere other than the firewall. Logs held only on the device are lost precisely when the device is the problem.
• Set retention long enough to investigate something discovered weeks later, which is the realistic discovery timeline.
• Alert on categories rather than events: a spike in denies, a first-ever connection from a management interface, outbound attempts from a segment that should not originate any.

The third item deserves emphasis because it is the cheapest and most neglected. Traffic logs describe what the network did. Change logs describe what the business decided, and it is the second that answers who permitted this and when — which is invariably the first question asked after an incident.

Change management, and the rule nobody dares delete

Every long-lived rule base contains rules whose purpose is unknown. They persist because the cost of removing one that turns out to be load-bearing is an outage with your name on it, and the benefit of removing one is abstract. That asymmetry guarantees accumulation.

The fix is not archaeology. Reconstructing the purpose of a rule added six years ago is usually impossible and always expensive. The fix is metadata captured at the point of creation, so that future rules never become mysteries.

1. 1

   Record why, not what

   The rule already states what it permits. The comment should state why it exists and what business function depends on it. A comment reading 'allow port 8080' is worse than none, because it looks like documentation.

2. 2

   Name an owner

   A person or team who can be asked whether the rule is still required. A rule with no owner cannot be reviewed, only tolerated.

3. 3

   Reference the request

   A ticket or change number ties the rule to the decision that created it and to whoever approved it.

4. 4

   Set an expiry on anything temporary

   Temporary rules are permanent unless a date makes them fail closed. A rule created for a two-week migration should be dated at creation, because the person who would have remembered has moved on.

5. 5

   Treat the rule base as configuration under change control

   Exported, versioned, and changed through a process that leaves a record — the same discipline applied to any other production configuration.

There is also a compliance dimension worth knowing for businesses in scope for card payments. PCI DSS version 4 renamed the relevant requirement from firewalls to network security controls, and requires that configurations of those controls are reviewed at least once every six months to confirm they remain relevant and effective. Whatever the standard's applicability, a scheduled review with a named owner is the mechanism that stops accumulation, and six months is a defensible interval to adopt voluntarily.

Verification: you cannot review a rule base by reading it

Reading a rule base tells you what it says. It does not tell you what it does, because ordering, shadowing, group membership and object definitions interact in ways that are not visible line by line. A reviewer reading three hundred rules will not notice that rule two hundred and eleven is unreachable.

Verification means testing the boundary from the side that should not have access, and confirming that the traffic is refused. That is a different activity from configuration review and it is the only one that produces evidence rather than opinion.

• Attempt the flows the policy is supposed to prevent, from the segment that should not be permitted, and confirm both that they fail and that the denial was logged.
• Confirm every rule intended as a deny is actually reachable, rather than shadowed by something broader above it.
• Test outbound as well as inbound. Outbound policy is the half most likely to be assumed rather than verified.
• Re-test after every significant change, because a single broad permit added at the top can silently disable a great deal below it.
• Record the result. A test that was performed and not written down cannot be produced for an auditor or relied on by the next engineer.

The recurring principle across this programme applies here with particular force: a control that has been configured and never tested is a claim, not a control. Firewalls make that easy to forget, because a rule base looks like evidence of itself.

Where the firewall belongs

Placement is a segmentation decision rather than a firewall decision, and it is covered in full in the network segmentation article. Two points belong here because they are frequently decided by default.

The first is that a single firewall at the internet edge inspects only traffic entering and leaving the business. Traffic between internal systems does not pass it, which means the majority of traffic on most networks is never evaluated by the device the business regards as its principal security control. Extending enforcement to internal boundaries is where the remaining value is.

The second is that the firewall is itself a high-value asset. Its management interface should not be reachable from general user segments, its administrative credentials belong under the same handling as any other machine credential, and remote administrative access to it should follow the same architecture as any other privileged access. Those subjects are covered in the segmentation, secrets management and remote access articles respectively.

Common mistakes

A representative scenario

A composite of situations we see repeatedly; no client detail is included.

A business with two sites and a single edge firewall commissions a review after an insurer asks what outbound traffic is permitted. The honest answer is all of it. The rule base holds a little over two hundred rules, of which the current team can account for roughly fifty.

Testing rather than reading produced the findings. Eleven deny rules were unreachable, shadowed by a broad permit added three years earlier during a system migration and never withdrawn — including a rule the business believed prevented a particular internal segment from reaching the internet. Nine rules referenced hosts that no longer existed. Two permitted a supplier's address range for an engagement that had ended.

The remediation was sequenced by risk rather than by tidiness. The shadowing permit was narrowed first, which restored eleven controls the business had believed were already in force. Outbound denial was applied to servers, appliances and management interfaces — categories with predictable needs and no user impact — while user egress was observed for a fortnight before anything was enforced. Every remaining rule was given an owner, a reason and, where temporary, an expiry. A six-monthly review was scheduled with a named owner, and the tests were recorded so the next review starts from evidence rather than from the rule base.

No hardware was replaced. The appliance had been enforcing the policy it was given entirely correctly; the policy had simply stopped describing what the business intended.

Implementation checklist

• The default posture is deny, in both directions, with every permitted flow existing as a deliberate exception.
• An explicit deny-and-log rule sits at the end of the base so refusals produce evidence rather than silence.
• The base has been tested for shadowed rules, and every intended deny has been confirmed reachable.
• Outbound traffic with source addresses that are not yours is denied.
• Servers, appliances, devices and management interfaces are denied outbound by default, with named exceptions.
• User egress has been observed before being enforced, rather than enforced and then debugged.
• Rules reference named objects, and objects are named for function rather than location.
• Objects are defined once and removed when the underlying system is decommissioned.
• Every rule records why it exists, who owns it, and the change that created it.
• Temporary rules carry an expiry date set at creation.
• The rule base is exported, versioned and changed through a process that leaves a record.
• All denies are logged, permits are logged selectively, and every policy change is logged.
• Logs are shipped off the device and retained long enough to investigate a late discovery.
• A review is scheduled at a fixed interval with a named owner, and its results are documented.
• Boundary tests are re-run after significant changes and the results recorded.

Frequently asked questions

Conclusion

Firewall strategy is mostly not about firewalls. It is about whether a business can state what it permits, justify each permission, notice when one stops being needed, and prove that the ones it believes are in force actually are. Rule bases fail because those four things are administrative rather than technical, and nothing forces them to happen.

The practices that keep a policy healthy cost very little at the point of writing a rule and are extremely expensive to retrofit across a base that has been accumulating for years. Deny by default in both directions, named objects, a recorded reason and owner per rule, an expiry on anything temporary, denials logged, and a boundary tested from the wrong side rather than read from the right one.