A supplier requests access to a new system. A firewall rule is added, the system is tested and everyone moves on. Later, the system is replaced, but the rule remains. This illustrates how settings that once made sense can remain in place without a clear ongoing need.
A firewall follows the rules configured on it. It does not automatically know that a supplier has changed, a server has been retired or temporary access should have expired. Someone therefore needs to check whether its settings still fit the business.
Every exception needs a reason
A periodic review begins with the services: which systems need to be accessible, who needs access and from where.
An access rule should be tied to a known need and someone authorized to approve it. Where broad access is allowed, establish why it was configured that way and whether the same access is still required. Sometimes there is a genuine dependency during a transition. Sometimes a setting simply remained after the work was finished.
A label such as 'temporary' is not an expiry date, and an old rule is not necessarily redundant. A lack of traffic during the review does not prove that the rule can be deleted: it may support a monthly activity or an emergency scenario. The decision combines technical evidence with an understanding of the work.
A useful review ends with a decision: retain the rule for a defined reason, narrow it to the actual need, or remove it after checking dependencies. Any exception that remains should have an owner and a review date.
Beyond traffic passing through the firewall, its administrative access also needs review. Who can change rules? Are accounts from previous service providers still present? Is management access available from sources that do not need it?
Individual accounts, source restrictions and additional authentication are different ways to reduce access. Their suitability depends on the system and how it is managed. All administrative accounts need to be checked, as a forgotten account can leave a broad access path open.
Software updates are also part of maintenance. Check which version is installed, whether it is supported and which vendor guidance applies. Updating does not replace a permissions review, and reviewing permissions does not replace updating.
What actually changed?
Before restricting access, prepare a configuration backup and a rollback plan, and coordinate with the people using the service. Changing several mechanisms at once can make it harder to identify the cause of a problem.
After the change, verify that the authorized business activity still works and that the access intended to be restricted is actually blocked in a controlled, authorized test. A message saying the setting was saved does not prove either result.
The business owner should receive a short, clear summary: what was reviewed, what changed, which exceptions remain and what still needs attention. This makes it possible to revisit those decisions at the next review.
If you do not know when your firewall settings were last reviewed against your current business needs, Suntech can help assess them and plan appropriate changes.