Broad rule scope
The sample report shows concrete rules where source, destination, and service are wider than the policy intent suggests.
Solutions
Firewall policy and segmentation review
Identify overly broad policy scope, weak network boundaries, risky service exposure, and the evidence engineers need to justify remediation.
Policy view
See risky rule patterns quickly
Capability
Example issue
Why it would be flagged
config firewall policy > 28 (LAN to Guest)
Source=any, destination=any, service=any
Flagged as ANY/ANY/ANY Rules because the policy is fully open across all three scope controls.
config firewall policy > 32 (Webserver Load Balancer)
Insecure or unencrypted protocol allowed
Flagged as Insecure Protocol Allowed because the service definition permits insecure traffic.
config firewall policy > 30 (Internet Access (No SSL Insp))
Broad internal-zone access
Flagged as Avoid broad east-west segmentation rules because the rule creates overly broad access between internal zones rather than a narrowly defined path.
What this page is really about
Policy review needs more than the rule line itself
Linked objects and services
Rule meaning depends on the related address objects and service definitions, so review has to follow those links instead of reading one line in isolation.
Evidence for cleanup
The useful output is not just that a rule exists, but why it is risky and what engineers need to narrow or remove safely.
Why this matters
Rules need context, not only line-by-line review
Manual rule review is slow because the real risk often depends on groups, services, interfaces, and business exceptions.
ConfigSentry helps engineers review the policy together with the linked objects, services, and logging behaviour.
- See rule quality and logging gaps together
- Catch stale or inherited access more consistently
- Support remediation planning with clearer evidence