Since firewall rules define the allowed or denied data packets traveling across your network, your documentation provides you insight into your firewall settings so you can ensure they work as intended. As your network environment becomes more complex, gaining insight into your network topology and data flows becomes increasingly challenging. For organizations manually managing documentation, the process becomes overwhelming and error-ridden.
To effectively and efficiently manage firewall documentation, you should understand how to configure firewall rules and what the documentation should contain so you can maintain security, compliance, and service availability.
What is the importance of firewall documentation?
Firewall documentation details the devices and configs that control network traffic. Proper documentation typically includes the following:
- Device details: model, serial number, software/firmware version, maintenance details
- Rules: allowed and disallowed traffic, including ports and protocols like UDP, ICMP, and TCP
- Network topology: data and traffic flows across the network
Ths firewall documentation enables improved:
- Vulnerability remediation: identifying and fixing security weaknesses in devices and configs
- Security: limiting access according the principle of least privilege to reduce attack surface
- Availability: understanding network topology to improve incident response and troubleshooting
- Compliance: documenting configs and monitoring network security to comply with regulations and frameworks, like PCI DSS, GDPR, and NIST
Understanding Basic Firewall Rule Configurations
Each firewall rule consists of the following config components:
- Traffic direction: incoming or outgoing traffic
- Numerical priority: order for when to apply the rule
- Action on match: firewall rule activity, like allow or deny traffic
When creating firewall rules, you should specify detailed parameters for both inbound and outbound traffic.
Inbound Traffic
Ingress firewall rules control incoming connections from a defined source to a target destination IP address. Often, a firewall uses a default deny all rule for inbound traffic.
The firewall configurations for incoming traffic rules typically define and controls connectivity for:
- Trusted zones: internal network IP address ranges and subnets allowing communication between known and secure devices
- Internet zones: public IP address ranges to restrict traffic from the public internet, configured for both IPv4 addresses and mimicked to reflect configurations for IPv6 addresses
- Types of traffic: traffic for network functionality
A best practice for inbound rules is to deny all connectivity then create specific allow rules that contain at least one of the following:
- Port number or port range used by applications and services, like destination port for VPNs
- Protocols, like ICMP for IPv4 and the corresponding protocol number for IPv6
Outbound Traffic
Egress firewall rulesets control outgoing traffic from target sources to a defined destination. They typically are the reverse of the inbound firewall rules, defining how internal resources connect to the internal networks or the public internet. In some cases, a firewall uses a default allow all rule for outbound traffic.
Priority
Firewall policies are hierarchical, meaning that the firewall processes the rules in the order you place them. The highest priority rule has the lowest number. If a rule lower in the list conflicts with the earlier firewall rule, then the firewall will only process the higher priority one.
Best Practices for Firewall Rule Documentation
Firewall rule documentation includes device and config information, so you should consider the following best practices to ensure you have everything you need.
Endpoint information
For physical firewalls, you should incorporate the following information into your documentation and asset inventory:
- Manufacturer with model and serial number
- Hostname
- Install date
- Network interface name, like WAN, LAN, VLAN, IP addresses, MAC addresses
- Firmware or software version
Device Connections
Every firewall connects to at least one or more devices, including:
- Switches
- Modems
- Routers
The documentation should detail the connected endpoint and its purpose, like WAN connection. Maintaining an organized record of device connections assists in
- Troubleshooting
- Setup verification
- Recovery processes
Access Control Lists (ACLs)
Stateless firewalls compare a packet’s attributes against predefined rules called ACLs. Your ACL needs an inbound and corresponding outbound rule. The ACL defines the criteria for allowing or denying packets. If you use ACLs, your documentation should include the following criteria:
- Source IP address
- Destination IP address
- Allow/deny statement
You should also consider that many cloud service providers (CSPs) offer ACLs to improve cloud security. Some examples include:
- Microsoft Azure: Network Security Groups (NSGs) work at the subnet and level and network interface card for resources, using IP addresses, service tags, or application security groups (ASGs) to define source and destination.
- AWS: Security Groups and Network Access Control Lists (NACLs) define the network traffic allowed to and from resources attached to them, with NACLs working at the subnet level and consisting of rule number, protocol, port range, source IP address, destination IP address, and allow/deny actions.
Security Policies
Stateful firewalls, like next-generation firewalls (NGFW), use network security policies to manage network traffic, determining whether a packet belongs to an established connection. Since these firewalls focus on a network connection’s context, they can differentiate between legitimate and potentially malicious packets.
Your security policy rules should contain configs about:
- Access controls: defining authentication requirements and role-based access controls (RBAC) to limit access according to the principle of least privilege
- Allowed services: defining approved applications or resources, like source ports and destination ports
- Allowed protocols: detailing protocols for services and other uses, like TCP, UDP, ICMP, and FTP
In some cases, you may have security policy templates that make this process easier.
Change Management Documentation
Whenever you add a new rule or make a change to an existing one, you should have a documented process for designing, testing, and deploying them. These processes should include:
- Assigning responsibility: ensuring the right people engage in the appropriate build, test, and risk review processes
- Assessing risk: reviewing or receiving a notification about a rule change’s or new rule’s impact on overall network security prior to implementation
- Justifying exceptions: documenting a firewall rule’s business use case to help identify outdated, unnecessary, or shadowed firewall rules
Tufin: Continuous Firewall Rule Documentation for Enhanced Security and Availability
Tufin’s Orchestration Suite consolidates all firewall rules in a single console for robust, continuous ruleset documentation. With Tufin’s Unified Security Policies (USPs), you can standardize firewall rules across various vendors, including Fortinet, Cisco, and Palo Alto.
Using our network topology maps, you gain visibility into and control over network traffic for faster troubleshooting and improved security incident response times.
To take a walk through how Tufin can streamline your firewall rule documentation process, contact us today for a demo.
Don't miss out on more Tufin blogs
Subscribe to our weekly blog digest
