Access Control Lists, or ACLs, are simple in concept: permit what should be allowed and block what should not. In real networks, ACLs become difficult when rules grow without design, documentation or review.
Good ACL design is not about adding more rules. It is about making access intentional, understandable and maintainable.
Originally discussed on LinkedIn: Network security ACL post.
ACL purpose
An ACL controls traffic based on criteria such as source, destination and service. Depending on the platform, ACLs may be used on routers, switches, firewalls, wireless controllers, cloud networks or operating systems.
ACLs can support:
- segmentation between VLANs
- limiting management access
- protecting sensitive systems
- reducing unnecessary lateral movement
- enforcing approved traffic flows
- documenting access intent
The purpose should be clear before the rule is created.
Least privilege
Least privilege means allowing only what is needed. For ACLs, this usually means avoiding broad rules such as “any source to any destination” unless there is a justified and documented reason.
Ask:
- who or what needs access?
- what destination is required?
- which protocol and port are needed?
- is the access temporary or permanent?
- how will the access be reviewed later?
If the answer is unclear, the rule is probably not ready.
Source, destination and service
A useful ACL rule should make the traffic intent understandable. Source, destination and service should be as specific as practical.
For example, a rule allowing a monitoring server to query network devices is clearer than a rule allowing an entire user subnet to access all device management ports.
Specific does not mean fragile. The design should still be manageable through address groups, service objects and naming conventions.
Rule order
Rule order matters in many systems. A broad allow rule placed above a narrow deny rule may make the deny rule useless. A deny rule placed too early may break legitimate traffic.
Review ACLs from top to bottom and confirm which rule will match first. During troubleshooting, always check the actual matched rule rather than assuming the intended rule was used.
Explicit vs implicit deny
Many platforms have an implicit deny at the end of a rule set. That means traffic not explicitly allowed is blocked. Some teams also add an explicit final deny rule for logging and clarity.
The important point is to understand the platform behaviour. Do not assume that all devices log denied traffic in the same way.
Documentation and change control
Every important ACL should have enough documentation for another administrator to understand it later. Useful documentation includes:
- requestor or owner
- business reason
- source and destination
- service or port
- approval date
- review date
- expected removal date for temporary access
Change control helps prevent rules from becoming permanent mystery access.
VLAN segmentation and firewall policy
ACLs and firewall policies often work together. VLAN segmentation defines traffic boundaries; ACLs and firewall rules control what crosses those boundaries.
Avoid designing VLANs without considering access rules. Also avoid writing rules without understanding the segmentation model. The two should support each other.
Common mistakes
Common ACL mistakes include:
- overly broad allow rules
- missing rule descriptions
- duplicate or shadowed rules
- temporary access that never expires
- inconsistent object names
- allowing management ports from user networks
- not logging important denies
- no periodic review
These mistakes usually appear slowly. That is why review cycles matter.
Review cycle
ACL reviews do not need to be dramatic. A practical review asks:
- is this rule still needed?
- does the owner still exist?
- is the source or destination still correct?
- is the service too broad?
- has the system moved or been retired?
- is the rule being used?
- should logging be adjusted?
Practical checklist
- Start with the required traffic flow, not the rule syntax.
- Use least privilege for source, destination and service.
- Check rule order before and after changes.
- Document owner, purpose and review date.
- Use clear object and group names.
- Keep management access tightly controlled.
- Review temporary rules and remove them when no longer needed.
- Use logs to confirm actual matched rules.
Related reading
For network and firewall design support, see IOT SOLUTIONS services and FortiGate Training Malaysia. For BYOD segmentation context, read BYOD Security Best Practices.
Final takeaway
Good ACLs are intentional, specific, documented and reviewed. The rule set should explain the access model, not hide it.
Need practical help with cybersecurity or network operations?
IOT SOLUTIONS can help clarify the issue, review the context and shape a proportionate next step for your team.
Contact IOT SOLUTIONS