Installing the device is the easy part. The hard part is leaving behind a rule base that is still readable two years later, whose reasons are known and which can be changed with confidence.
Done Dynamics does firewall installation and rule set management: bringing new devices into service, taking over and documenting existing rule bases, periodic rule hygiene and change management. What we see in the field is consistent — most organisations have a firewall, it works, and nobody dares touch the rule base. Some rules have no known reason for existing, some never match, some shadow each other. Long before this becomes a security gap it is an operational cost: a simple access request stretches over weeks, replacing a device turns into a project, and during an investigation nobody can say which rule blocked what.
Our approach rests on turning the rule base into a document readable independently of the device. Once every rule has a rationale, an owner and a date, removing a rule becomes as ordinary as adding one. The work can run as part of a wider network infrastructure engagement or entirely on its own.
The questions to answer before writing a single rule. A badly placed device stays incomplete even with the best rule base.
Link speed, concurrent session count and whether encrypted traffic will be decrypted decide this. If a virtualisation platform is already in place, a virtual firewall is cheap and fast to deploy — but if the hypervisor goes down, the door to the network goes with it. On critical links we prefer dedicated hardware.
The edge device separates the internet from the organisation. A second layer between internal segments does the harder work: letting you write rules for traffic between accounting and production, or between servers and guests. One device can do both, but the interface and VLAN plan has to be drawn for it from the start.
Two devices run active-passive or active-active; when one fails, sessions move to the other without dropping. Failover time, the synchronised session table and which device management traffic reaches are all tested during deployment — redundancy that has never been exercised on site is not redundancy.
A second internet line is useless if it is merely plugged in. Which traffic leaves through which line, how failover is triggered and what happens to VPN tunnels during the switch all get written down. Automatic failover is configured against measured link quality, and the switch itself raises an alert.
Device management is reachable only from a separate segment with multi-factor authentication; no management interface is left facing the internet. Configuration is backed up automatically after every change and kept under version control, so a bad rule can be rolled back in minutes.
The new device is installed alongside the existing link first, traffic is passed through with test users, and the full cutover happens in a planned window. Rollback steps are written before the change; the old device is kept with its configuration for a while afterwards.
The quality of a rule base is not measured by how many attacks it stopped, but by which rule the person looking at it two years from now can safely close. The eight principles below are the minimum standard we apply to every base we take over.
What they share is a single sentence: the story of the rule is kept alongside the rule itself.
Rule bases do not break in a day. They break through hundreds of small additions, each correct on the day it was made.
A broad rule above stops a narrower rule below from ever matching. The lower rule sits in the base, shows up in reports and nobody touches it — while doing nothing at all. We find these and either remove them or fix their order.
Two rules, one permitting and one denying the same traffic. Which one wins depends on order, and usually the side nobody expected wins. Conflicts are listed and the correct intent is settled with the business owner.
Hit counters reveal rules that have sat at zero for months. These are not deleted outright: they are disabled first, one review cycle passes, and if no complaint arrives they are removed. Disabling before deleting makes the rollback free.
Every new requirement adds a rule; no requirement ever removes one. A base of several hundred rules is not only a security risk but an operational cost: every change takes longer, every mistake is harder to find, and replacing the device turns into a project.
A review produces not a list but a decision table: which rule stays, which is disabled, which is consolidated and why in each case. The table stays with the organisation and becomes the starting point for the next cycle.
Alongside the allow-or-block decision, how traffic is translated and how it is recognised is also part of the configuration.
How internal services appear from outside, which address translates to which, and keeping source NAT and destination NAT rules from undermining each other. Every port exposed outward is justified individually; where an alternative exists, VPN is preferred.
Looking at port numbers is no longer enough — most applications now travel over 443. Application awareness distinguishes what the traffic actually is. Whether encrypted traffic gets decrypted is a separate decision, discussed together with its personal-data implications.
A system serving only Turkey has no reason to accept connections from everywhere on earth. Country-level restriction cuts the noise substantially, particularly for management panels and remote access services.
Known exploit signatures, scanning behaviour and abnormal session counts. Signature sets are kept current, and which signature blocks versus which only alerts is tuned — a false positive can stop a production line.
Category-based access policy and blocking of known malicious domains. Policy can differ by working hours and user group; exception requests are handled on the record and time-limited.
When a rule is bound to a person or a group rather than an IP address, a user changing devices does not require a new rule. Directory integration is part of the deployment.
The first question in an investigation is almost always the same: which rule saw this traffic and what did it do. Whether an answer exists at all comes down to a handful of small decisions made at deployment.
Taking over a base of several hundred rules with no known owner takes order, not courage. Five steps, each of them reversible.
A full backup of the existing configuration is taken, along with device version and licence state. Before anything is touched, there is a point to return to.
Rules are read one by one; source, destination, service and hit counters go into a table. Which rule has never matched in six months, which one carries most of the traffic — the table shows it.
For rules with no known owner we talk to the business units. Some rules produce no answer; those are not deleted but flagged for monitoring, with a disable attempt planned.
Rationale, owner and date fields are filled in for every rule. The output of this step is a rule document readable independently of the device — the next administrator does not start from zero.
Shadowed and conflicting rules are corrected, similar rules are consolidated under object groups, unused ones are disabled in stages. Each step runs in its own window with a rollback plan.
Rule bases do not decay through bad intent but through good intent that keeps no record. The six steps below are kept short enough that they are not skipped even when a request is urgent.
Installation takes a day; rule management never ends. The two are planned separately.
The existing link, device inventory, traffic profile and any current rule base are examined. The output is a report: what stays, what has to change and which risk comes first.
Interface and VLAN plan, rule blocks, NAT scheme, log architecture and redundancy layout are written into a document and approved before installation.
The device is brought up, the high availability pair is tested, and rules are written block by block with each block verified separately.
Traffic moves to the new device in a planned window. Test users verify first, rollback steps stay ready.
Quarterly or half-yearly rule hygiene work: unused rules, shadowed rules, expired temporary rules and the trend in rule count are reported.
Installation and takeover is a fixed-price project whose scope the discovery report sets, with device count, existing rule count and segment count as the main variables. Rule management runs as a monthly service: change requests, periodic hygiene work, configuration backup and incident support. We separate the two for a simple reason — installation is work that finishes, a rule base is work that does not. Hardware and licence costs are passed through at cost, with no margin added. The quote is a single page, and what is not included is written on the same page.
Usually the existing device is fine. Most of the problems we see in the field come from configuration, not capacity. In discovery we look at three things: the throughput the device can handle against the link speed, the concurrent session count, and whether the vendor still supports it. If those three are sound, the device stays and the work concentrates on the rule base. If it is out of support and no longer receiving security patches, we recommend replacement and put the reasoning in writing.
Applying it usually takes minutes; the time goes into what comes before. Clarifying the request, impact analysis and the shadowing check typically complete within half a day to a day. For urgent cases we define a fast path: the rule is opened temporarily with an expiry date and is either made permanent or closed at the next review. Keeping the fast path temporary matters, because urgent rules that quietly become permanent are the number one cause of rule base sprawl.
You do. Configuration backups, the rule document, the object list and management credentials are handed to the organisation; we do not operate a model that holds them hostage. If you decide to change provider you have a readable rule document and a current backup in hand, and the new team does not start from scratch. This is not a promise so much as a by-product of how we work: we keep that document for our own use anyway.
There is no absolute number; the measure is what share of the rules has a known reason. A base of fifty rules where twenty have no known justification is too large; a base of three hundred where every rule has an owner and a date is manageable. In practice the warning sign is this: if you have to read the existing rules before adding a new one, and that reading takes more than half an hour, it is time to simplify.
Retention follows three inputs: any legal obligation, disk cost and how far back you want to be able to look during an investigation. Businesses offering public wireless access have a separate record-keeping obligation to discuss. In practice the common arrangement keeps detailed records for a short period and summarised records for longer — cost stays controlled while retrospective trend analysis remains possible. The period is written down at deployment and added to the contract.
The aim is that it does not. The new device is installed alongside the existing link, configured fully, and traffic is passed through with test users first. The full cutover happens in a planned maintenance window — for most organisations an out-of-hours slot, and typically under half an hour. Rollback steps are written before the change and the old device is kept with its configuration for a while. On lines running around the clock, the cutover can also be arranged without interruption using link redundancy.
Two items are written separately. Installation and takeover is a fixed-price project whose scope the discovery report sets — device count, existing rule count and segment count are the main variables. Ongoing rule management is a monthly service: change requests, periodic review, configuration backup and incident support fall under it. Hardware and licence costs are passed through at cost, with no margin added. The quote is a single page and states what is not included as well.
You start by not deleting. The first stage is pure reading: take a backup, put the rules into a table with their hit counters, flag the ones that never match. The second stage is talking to business units and collecting rationale. Only in the third stage, and gradually, does a rule get disabled — disabled, not deleted. If no complaint arrives during a review cycle, it is removed. With this approach the worst case is that a rule gets re-enabled; the feared scenario, breaking something nobody understood, does not happen.
No. A firewall inspects traffic crossing the edge; what stops lateral movement inside is segmentation, and what stops malware on a machine is endpoint protection. Even with a perfect rule base, a single compromised computer on a flat internal network reaches everything. That is why we plan firewall installation together with network security work.
Related services
Segmentation, cutting off lateral movement and isolating devices that cannot be patched — where a firewall stops short.
Network design, router and switch configuration, VPN deployment, wireless infrastructure and continuous monitoring.
An independent assessment of how the rule base looks from outside, with retesting after remediation.
Ongoing support covering firmware and patch schedules, configuration backups and outage response.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.