Skip to content
Talk to a Security Expert
CLOUD & INFRASTRUCTURE / NETWORK CONTROLS

Firewall & Configuration Review

Review security-relevant configurations to identify unnecessary exposure, weak access controls and configuration risks.

A firewall rule base is a historical record. Rules are added under pressure during incidents and migrations, and removing one later means being confident it is unused — which is difficult to prove. So rules accumulate, and the effective policy stops matching the intended one.

A configuration review reads that policy as it actually stands: what is permitted, what is exposed, what is no longer needed, and where segmentation exists on the diagram but not in the rule base.

// DEFINITION

What is a firewall and configuration review?

A firewall and configuration review examines the rule base as it stands, including what is redundant or overly broad, whether segmentation boundaries between zones actually hold, where administrative management interfaces are reachable from, services permitted beyond their intended audience, whether configuration reflects the policy it is meant to enforce, weak defaults and unnecessary features left enabled, how access to the devices themselves is granted, and where configuration could be tightened without breaking operations. Firewall rules are easy to add and hard to remove — every rule was added for a reason that is rarely documented, so policy grows monotonically into broad rules meant to be temporary, paths permitted for systems that no longer exist, and administrative access reachable from more places than anyone intends. Review is performed against configurations you provide for the devices in scope.

Who needs it? Organizations whose rule base has grown to the point where nobody is confident which rules are still needed, organizations where segmentation is claimed on a diagram but the rule base may not reflect it, organizations that carried rules across a migration and never revisited them, and organizations preparing for an audit or review where configuration needs to be demonstrably reasoned about.

How TMG Security helps. TMG Security reviews the rule base, segmentation, administrative access and configuration against the devices you provide, and delivers findings your team can act on.

// WHY IT MATTERS

Rules are easy to add and hard to remove

Every rule was added for a reason. The reason is rarely documented, the person who added it may have moved on, and nobody wants to be responsible for removing the rule that turns out to be load-bearing.

The result is a policy that grows monotonically: broad rules that were meant to be temporary, permitted paths for systems that no longer exist, and administrative access reachable from more places than anyone intends.

// ARCHITECTURE

The layers this assessment covers.

RULE REVIEW — ILLUSTRATIVE EXTRACT
RULESOURCEDESTINATIONSERVICEACTIONREVIEW
001ANYDMZ-WEBHTTPS/443ALLOWEXPECTED
014CORP-LANDB-TIERSQL/1433ALLOWREVIEW
027ANYMGMT-NETSSH/22ALLOWFLAG
041PARTNERAPP-TIERANYALLOWFLAG
058CORP-LANANYANYALLOWFLAG
072DMZ-WEBDB-TIERSQL/1433ALLOWEXPECTED
089LEGACY-VLANANYANYALLOWREVIEW
ILLUSTRATIVE EXAMPLE — NOT CUSTOMER CONFIGURATION
What the rule base actually permits

Each boundary should narrow what passes. A review establishes whether it does.

  1. INTERNETInternetEverything that can reach the perimeter
  2. FIREWALLFirewallThe rule base, and what it permits in practice
  3. NETWORKNetworkSegmentation between zones and environments
  4. SERVICESServicesWhat is reachable once inside a zone
  5. CRITICALCritical systemsSystems whose exposure carries real impact

Conceptual view of a layered network. Review scope depends on the environment and the configurations provided.

// WHAT WE ASSESS

What we review

Review is performed against configurations you provide for the devices in scope.

// METHODOLOGY

How a configuration review runs

  1. 01COLLECTObtain configurations for the devices in scope.
  2. 02BASELINEEstablish intended policy and the zones it is meant to separate.
  3. 03ANALYSERead the effective policy and identify where it diverges.
  4. 04EXPOSUREIdentify unnecessary exposure and overly broad permissions.
  5. 05PRIORITISERank findings by what they would actually allow.
  6. 06REPORTFindings with specific, actionable remediation guidance.
// WHEN THIS APPLIES

When Should the Rule Base Be Read Properly?

01SITUATIONRule base has grownNobody is confident which rules are still needed.
02SITUATIONSegmentation claimed but untestedThe diagram shows zones; the rule base may not.
03SITUATIONAfter a migrationRules were carried across and never revisited.
04SITUATIONAudit or review preparationConfiguration needs to be demonstrably reasoned about.
// WHAT YOU RECEIVE

Findings your team can act on.

Which of these apply depends on engagement scope.

SECURITY FINDINGS

Weaknesses identified across the environment in scope, with the reasoning behind each.

CONFIGURATION OBSERVATIONS

Settings that widen exposure or weaken a boundary, described precisely enough to locate.

RISK CONTEXT

What a finding means in your environment rather than against a generic scoring table.

TECHNICAL EVIDENCE

Supporting detail so findings can be verified rather than taken on trust.

REMEDIATION GUIDANCE

Practical direction on addressing each finding, including where the change belongs.

PRIORITIZED RECOMMENDATIONS

An order of work, so limited engineering time goes to what matters most.

RETEST / VALIDATION

Verification that addressed findings no longer reproduce, within the agreed retest scope.

// FREQUENTLY ASKED

Questions we get asked before an engagement.

Request a Configuration Review

Send us the shape of the environment — the zones you intend to separate and the systems that matter most.