A firewall is deployed once, the rules grow for years
Deploying a firewall is a project. It has a start, an end, tests and documentation. Then everyday life begins, and rules get added one at a time, usually in a hurry and usually so that something finally starts working.
After a few years you end up with a rule set nobody has read from start to finish. Not because anyone was careless. Every single rule made sense on the day it was added. The problem is in the total, not in the individual entries.
The symptom is always the same. Nobody wants to remove anything, because nobody knows what will stop working. The configuration only grows in one direction, and every year it gets harder to touch.
Where the mess in the rules comes from
The reasons repeat themselves in almost every company:
- Rules added for a moment. Someone needed access for one day to finish a deployment. The access stayed for four years.
- Ports left open after projects that no longer exist. A shop moved to another provider, a test server switched off, an integration with a system the company no longer uses. The rule stays, because nobody reported it for removal.
- Access left after people. Former employees, former subcontractors, the company that installed the cameras five years ago and still has its address allowed in.
- Rules added during an outage. A night-time opening of everything to everything, just to find out where the problem is. The outage passed, the rule did not.
- No description. An entry with no record of who asked for it, why and for how long is, a year later, indistinguishable from an entry that is genuinely needed.
- Several hands in one device. Changes were made by someone inside the company, someone outside it and someone from a system vendor. Each with their own naming convention.
What you risk by leaving it unreviewed
The first risk is obvious. A rule that publishes a service to the internet is an invitation to everyone who scans public addresses, and they scan them constantly. Most often it is a remote desktop or an admin panel opened so that somebody could work from home, then forgotten once they came back to the office.
The second is less visible and costs more. A rule set nobody understands blocks change. A migration, a new branch, a new internet link, all of it takes longer and costs more, because every time you first have to guess why the existing rules are there.
The third one surfaces at audit time. Companies that handle card payments have an explicit obligation in the PCI DSS standard to review the configuration of their network security devices at least once every six months. The NIST guidelines on firewalls say the same thing as a recommendation, meaning periodic rule set reviews and changes introduced through a formal process rather than on the spot.
What a proper review looks like
A review is not about staring at the console and deleting whatever looks odd. The order is the other way round, from the inventory to the decision:
- An export of all rules into one list, together with address translation rules and any services published to the outside. Not from one device, if the company has several.
- An owner for every rule. A person or a department, a business reason and the date until which the rule is meant to apply. Without that you will be starting the next review from scratch in a year.
- Dead rules. Most firewalls can show when a given rule last matched any traffic. Entries with no hits for months are the first candidates for removal.
- Narrowing the scopes. A rule from any source to any destination becomes specific addresses and specific ports. This is usually the largest part of the work and the biggest gain.
- Closing what is not needed. Services published to the internet for no reason, access for companies that no longer work with you, accounts on the device itself, including vendor service accounts.
- VPN accounts and certificates. The list of people who can enter the network from outside ages faster than anything else in the configuration.
- Access to the firewall itself. Who can log in to it, from where, and whether it can be done straight from the internet. This question comes last, because the answer tends to be the most uncomfortable.
Configuration backups and change history
A review only makes sense if its result can be maintained. That takes three things, all of them technical and all of them dull.
The first is a configuration backup of every device, taken automatically and kept outside that device. A firewall can break like any other piece of hardware, and rebuilding several hundred rules from memory is not realistic.
The second is versioning, meaning a change history that lets you compare the state today with the state last week. When something stops working after a change, that comparison is the shortest route to the answer.
The third is writing changes down as they happen, in one place and in one convention. Date, author, reason, ticket number. A new rule with no description is a future problem, even if today everybody knows why it was created.
Why the review belongs in a service window
Removing rules is a production change, exactly like replacing an internet link. The difference is that the effect appears with a delay, often only when somebody tries to use something they have not used for a month.
That is why changes go in during a scheduled window, with the configuration saved beforehand and with a clear decision about what makes you roll them back. Rules get disabled first and deleted only after a few quiet weeks. A disabled rule can be switched back on in seconds, a deleted one has to be rebuilt.
It is also worth agreeing who is on the phone during the change and right after it. Most of the reports that follow such a review arrive in the first two working days, and they concern things nobody remembered rather than the firewall itself.
How often to do it
A full review twice a year is a sensible rhythm, and for companies handling card payments it is a requirement. Where the network changes a lot, every quarter works better.
Beyond the schedule there are moments that call for a review regardless of the calendar: the end of a project, the departure of a person with access, the end of a subcontractor contract, a change of operator, the rollout of a new system, and every outage during which something was opened up quickly.
What works best, though, is a habit rather than a campaign. If every new rule gets an owner, a reason and an expiry date the moment it is created, the review six months later is an hour of work rather than two days.
What to do about it
Finding out whether a review is needed takes a few minutes. Ask two questions of whoever looks after the firewall. How many rules are there, and who owns three of them picked at random. If there is no answer to the second question, the review is needed.
We configure and maintain firewalls and VPN concentrators, so a rule review is a normal part of looking after a network for us rather than a separate project. The scope of support, including any round the clock cover, is agreed in the contract.
If you do not know what state your configuration is in, an export of the rules and a short conversation is usually enough. After that you know whether it is an hour of tidying up or a subject for its own service window.