Algeria AgencySecurity & surveillance
March’s temporary rule: rereading a firewall six months later
A rule added for a week is never removed. How to reread a rule set in two hours, and how to take one out without breaking anything.
The companion article asks, in its section 7, that a firewall’s rules fit on one page. That is the right requirement and it is verifiable on installation day.
This page is about what happens to that sheet eighteen months later. It becomes four, and none of the three that were added was decided: each is an exception opened on a Tuesday to unblock somebody.
The problem is not negligence, and a page explaining it as negligence would be no use. It is an asymmetry nobody defeats through discipline: removing a rule might break something visible today, and leaving it never breaks anything visible at all.
So the answer is a dated reread, two hours once a year, with a method that allows removal without risk. That is the whole content of this article, and the hard part is section 6.
The temporary rule, and why it is permanent
The scenario is always the same and it is entirely reasonable at every step. A supplier needs to reach a machine for a migration. The migration takes a week. A rule is opened on Monday and it works.
On Friday the migration is not finished. The following week it is. Nobody closes the rule again, because the end of a migration is not an event: there is no moment at which somebody declares it over and reviews what has to be undone.
Three years later the rule is still there. The supplier has changed trade, the machine has been replaced, and the address in the rule may today belong to somebody else.
What makes this story important is not that it is common — it is — but that it has no culprit. Every person involved did the right thing at the right moment, and the result is a permanent opening nobody ever decided to create.
A rule set is therefore not a document: it is a sediment. It records the history of a business’s emergencies, and it contains no mechanism for forgetting. That is the one thing to understand before reading on.
The asymmetry discipline does not defeat
It is worth naming precisely why rules accumulate, because the wrong explanation leads to the wrong solution.
The wrong explanation is laziness, and it leads to an instruction: "remember to remove temporary rules". That instruction is issued in every business and it has never worked anywhere.
The right explanation is a calculation everybody makes without putting it into words. Removing a rule might break something today, in front of everyone, and whoever removed it will be identified in thirty seconds. Leaving it breaks nothing, ever, and nobody will know it is there.
An immediate personal risk against a diffuse anonymous one: no reasonable person chooses removal. That is not a character flaw, it is a correct response to the incentives as they stand.
The consequence is that the incentives have to change rather than the exhortations. Two things suffice and they are in sections 3 and 6: a rule carries an end date written at the moment it is created, and a procedure exists that removes it without risking anything. The rest of this article implements those two ideas.
The rule nobody can explain
The question that sorts a rule set is not "is this rule dangerous". That needs expertise, takes time per line, and produces disagreements.
The question that works is weaker and far more useful: who asked for this rule, when, and what for? It needs no security knowledge at all, and it is answered in ten seconds or not at all.
A rule nobody in the room can answer for is not necessarily dangerous. It is indefensible, which is different and sufficient: you cannot decide to keep it, since you do not know what you would be keeping.
That is what makes the reread possible for an owner rather than a specialist. You are not assessing technical risk, you are checking that a reason exists, and the person with the expertise is brought in only for the lines that remain.
One qualification that prevents an excess: an unexplained rule is not deleted on the spot. It goes through the procedure in section 6, which exists for exactly this case — removing something whose purpose is unknown without discovering that purpose the worst way.
The comment field: four pieces of information
Every serious device allows a comment beside each rule. It is the least-used field in this whole pillar and it is the one that decides next year’s reread.
Four pieces of information suffice, in a fixed order: who asked, the date, why in five words, and until when. The fourth changes everything, and it is written even when the answer is "permanent" — because the word "permanent" written by somebody is a decision, while an empty field is an oversight.
That comment is written at the moment the rule is created, never afterwards. A retroactive documentation campaign across forty rules is a two-day project nobody finishes, and it produces comments reconstructed from memory, which are worse than nothing since they look reliable.
The working rule that makes this sustainable is simple: whoever does not have time to write four words does not have time to add a rule. That sounds severe and is in fact a protection for them — that comment is what will stop somebody, two years from now, removing their rule and breaking their work.
If your device has no such field, which happens on the simplest models, the comment lives in the one-page file from section 5. The medium hardly matters; what matters is that the line and its explanation are in the same place.
Remote accesses are rules with names
The neighbouring article treats remote access as this equipment’s real purchase, and covers the shared account. We reopen neither; we add only that in a reread, an account is treated exactly like a rule.
The list of accounts allowed in is a list of openings, just as the rule list is, and it ages the same way for the same reasons. The previous provider is on it. The 2024 developer is on it. The former technical manager is on it.
Section 2’s question applies unchanged: who is this person, who asked for their access, and are they still working with us? It is answered faster than for a rule, because a name says more than an address.
Two extra checks are worth making while going through the accounts. The last connection date, where the device keeps it: an account unused for eight months is an answer in itself. And whether a second factor exists, which is the neighbouring article’s subject and which a reread is a good moment to observe.
An account is disabled rather than deleted, exactly like a badge — disabling is reversed in ten seconds if somebody speaks up, and it preserves the record of who they were.
The reread: two hours, once a year
The method fits in a morning and requires connecting to nothing: it begins with a printout.
Print the rule set. On paper, in full, in the order it executes. The reason is practical and real: on screen you scroll and judge rules one at a time, on paper you see them together, and it is together that the redundancies and dead lines in section 7 appear.
Add three columns by hand to the right of each line: who asked, still useful, to remove. Two of them are ticked and the first is written in three words. That is the whole of the instrumentation needed.
Do it in pairs, and the choice of the two people matters more than their technical level. Somebody who knows the business — who knows there has been no supplier for that software for a year — and somebody who knows the device. The first explains half the lines in one sentence the second could not have produced.
Date the sheet and keep it. Next year’s reread starts by comparing against this one, which takes ten minutes and turns a one-off exercise into a series. It is the same reasoning as the register in the maintenance review article: the value is in the comparison with yourself.
Removing a rule without breaking anything
Here is the section that makes everything else possible, because without it a reread produces a list of lines to remove that nobody will dare remove.
The procedure has four steps and takes two calendar weeks for five minutes of work. Step one: enable logging on the suspect rule, and only on it. That changes nothing for anybody and it answers the question.
Step two: wait. Two weeks cover the monthly cycle of accounting systems, one person’s leave, and roughly everything that runs in a business of this size. A rule that has logged nothing in two weeks is not a rule in use.
Step three: disable rather than delete, and wait another two weeks. The difference is decisive and it is what makes the manoeuvre acceptable — a disabled rule is restored in ten seconds by whoever takes the call, while a deletion means reconstructing a line nobody knows any more.
Step four: delete, and record the deletion on the dated sheet. The full cycle has cost a few minutes spread over a month, and it has removed the risk that stopped anybody starting. A useful variant for rules that are too broad rather than useless: do not delete — narrow. One address instead of a network, one port instead of a range, then let it run two weeks before narrowing again.
Execution order, and the rule never reached
A firewall reads its rules in order and stops at the first match. That sentence is well known and its consequence for a reread is not.
The consequence is that a rule placed under a broader one never executes. It exists, it is visible, it looks as though it does something, and it is dead. It is the commonest discovery of a reread done on paper.
That produces two symmetrical errors and one of them is dangerous. The first: somebody adds a restrictive rule and believes they have closed something that stays open through a line further up. The second: somebody removes a useless rule that was in fact unreachable, which changes nothing at all — the benign case.
The check is done by eye on section 5’s printout, reading top to bottom and asking at each line whether something above would already have caught it. Two people do it correctly across forty lines in half an hour.
And a general rule about order that avoids creating the problem: specific rules go above general ones, always. A new line added at the end for convenience is a line with a good chance of never executing, and nobody will notice since everything keeps working.
What the reread finds every time
Four findings recur in almost every reread we run, and knowing them saves an hour on the first one.
The first is a maintenance opening for a supplier who is no longer a supplier. It is the easiest to settle and it is almost always present.
The second is the rule that authorises a machine by its address, and that machine has not existed for two years. The address has been reassigned to something else by the address server — which means the rule today authorises a device that asked for nothing, often a printer or some workstation.
The third is the broad rule opened during an outage. It often carries a comment like "test" or "temporary", the one time the comment field was filled in, and it stayed because after the outage nobody wanted to touch anything.
The fourth has to be looked for deliberately because it does not show: the rule that authorises an outbound connection for a device with no reason to go out — a camera, a recorder, a controller. The neighbouring article explains why outbound is the half nobody configures; in a reread it is the line that repays the most attention for the least work.
The rules to keep and document
A reread that keeps nothing is a badly done reread, and it is worth saying because the exercise naturally pushes towards pruning.
A good share of the rules nobody can explain are entirely legitimate. They open a trade application’s access to its server, they authorise a payment terminal to report in, they let the backup out. Nobody remembers them because they have worked for years without ever asking for anything.
The correct outcome for those lines is not deletion, it is the comment. A rule that receives its four pieces of information during the reread will never go through this conversation again, and that is what makes the second reread take an hour rather than two.
One particular case deserves naming, because it recurs and is badly settled: the rule useful to a single person — the owner’s remote access from home. It is legitimate and it is also the most attacked entry point. The right outcome is neither keeping it as it is nor removing it, it is narrowing it under section 6’s variant.
Write down what you decided to keep as well, not only what you removed. A sheet listing only deletions gives the impression, next year, that the previous reread never examined the rest.
When the page can no longer hold
An honest reread sometimes ends with a rule set that still does not fit on one page, with no line superfluous. That is important information and it is not about the firewall.
A high number of legitimate rules means many things need to talk to many other things. In other words the network is not segmented: everything is on one plane, and every authorisation has to be written individually instead of following from a separation.
The practical consequence is that the next effort is architectural rather than documentary, and it belongs to the network article — separating what has no business being together. Three well-placed separations remove more rules than a day of rereading.
The commonest case among our clients is numerous chatty devices: cameras, the recorder, access points, controllers. Put on their own segment, they go from fifteen individual rules to two, and those two are explicable by anybody.
It is also the best argument we know for funding a segmentation, because it is checkable: count your rules before, count them after. A rule set is the most honest measure of a network’s real complexity, precisely because nobody designed it to be a measure.
What we do, and what we refuse to do
What we refuse first: deleting rules we do not understand on a first visit. It is the quickest way to make a network look "clean" and to cut a business flow nobody could describe to us. The four-step procedure exists for that and takes two weeks, which is the price.
We also refuse to add a rule without section 3’s four pieces of information, including when the request is urgent — and especially then, since that is exactly the moment March’s rules are born.
And we refuse to invoice an annual reread as a security audit. It is not one: it is two hours with a paper printout and three columns, and saying so costs us a billing line that would sell without difficulty.
What we do fits in a morning: the printout, the three columns filled in with somebody from your side, logging placed on the doubtful lines, the appointment two weeks later to disable, and comments written on everything that stays.
And one thing to do this week without us, in ten minutes: print your rules and count them. Then ask section 2’s question about the first five. You will know immediately whether this page concerns you.
Frequently asked questions
Why do rules accumulate?
Because of an asymmetry discipline does not correct: removing a rule might break something today, in front of everyone, and its author will be identified in thirty seconds; leaving it never breaks anything visible. No reasonable person chooses removal. So the solution is not an instruction but two mechanisms — an end date written at creation, and a removal procedure with no risk.
How do we know whether a rule is still used?
Enable logging on that rule only and wait two weeks. That is the span covering the monthly cycle of accounting systems, one person’s leave, and roughly everything that runs in a business of this size. A rule that has logged nothing in two weeks is not a rule in use.
Can a useless rule be deleted straight away?
Disable it instead, and wait another two weeks before deleting. The difference is what makes the manoeuvre acceptable: a disabled rule is restored in ten seconds by whoever takes the call, while a deletion means reconstructing a line nobody knows any more. For a rule that is too broad rather than useless, do not delete — narrow it, then wait.
Who should do the reread?
Two people, and the choice matters more than the technical level: somebody who knows the business — who knows there has been no supplier for that software for a year — and somebody who knows the device. The first explains half the lines in one sentence the second could not produce. Allow two hours the first time, one hour thereafter.
What should be written beside a rule?
Four things, in a fixed order: who asked, the date, why in five words, and until when. The fourth changes everything and is written even when the answer is "permanent", because that word written by somebody is a decision while an empty field is an oversight. Write them at creation, never retroactively — a comment reconstructed from memory looks reliable and is not.
Our rules do not fit on a page even after the clear-out. Is that bad?
It is information, and it is not about the firewall. Many legitimate rules means many things have to talk to many others: the network is not segmented. Three well-placed separations remove more rules than a day of rereading — the commonest case being cameras, the recorder and access points, which go from fifteen rules to two.
Where we come in
How many rules your firewall holds, and who asked for the first five, say in ten minutes whether anybody still knows why they exist.
- We fill the three columns with somebody from your team, in one morning.
- We log the lines nobody remembers before removing any of them.
- We call it a review, not a security audit, because it is not one.
On a first visit we cut nothing whose purpose escapes us: blind, a single line removed stops a company.
Read next
Firewalls and VPNs: what goes out matters more than what comes in
What arrives unrequested is already blocked by any router. The useful half is the other one, and it is the half nobody configures.Security and surveillance: the order matters more than the product
It is the only family in the pillar bought against a fear rather than a need. And fear buys in the wrong order: what can be seen, first.What the insurer asks for: declaring, proving, being paid
The only third party that will ever examine your security does it once, after the loss. What it will ask for, and what has to exist beforehand.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.