Firewall change modeling ensures application and firewall engineers are in sync around rule changes
With Athena's newest release, stakeholders involved in network access can tap operational intelligence to cut down the number of change requests that are directed to firewall engineers. Application engineers and/or IT Help Desk use a web-based UI to input a change request and receive back a response based on a virtual packet test. The test provides information to ensure the change is necessary and specified correctly.
Top 3 reasons to add Athena's Change Advisor to your firewall change process
Kill unnecessary and incorrect change requests to firewall engineers!
Give application engineers basic operational intelligence without compromising secure data
Perform sophisticated packet tests using the same parameters contained in a simple change request form
A simulated model of network access (derived purely from configuration data) provides application engineers the ability to ask if existing policies already cover the change. The web-based UI enables the question to be asked while preventing access to sensitive configuration data directly. For firewall engineers with authorized access, rich configuration data provides the context for determining the optimal places to implement rule changes.
Making changes to network device configurations can be difficult to accomplish. Network change requests typically specify a source IP address, a destination IP address, and a service to allow. In networks of any reasonable size, it is quite likely that the specified packet will traverse mulitple network devices along its path from source to destination. Identifying the path and knowing which devices will need to be touched along the path requires significant knowledge of and experience with the network in question. Using traditional tools like ping or traceroute, the network engineer would only be able to identify the first device along the path that is blocking the packet. He would then have to identify the change required in that device, then continue pinging or tracerouting to the next blocking device and so on. This can be a very time-consuming and potentially error-prone process.
Athena's Change Advisor automates the change process, taking advantage of Athena's core technology for understanding how packets would traverse the network, based on connectivity, routing and the firewall devices involved in the change request. An application engineer initiates a change request by entering the parameters of the request into a web form. Change Advisor issues a packet tracer query based on the parameters from the change request to determine the path the requested packet would take through the network and identifying the firewalls and routers involved. The result is an answer to the application engineer that shows whether or not the change is needed. Since no data is injected into the network, and the application engineer does not view or access the configurations directly, this is a secure process.
If the packet tracer query shows that the change is required, the request is then forwarded to a network engineer for fulfillment. The packet tracer query issued from the change request parameters identifies the routable path through the network from the specified source to the specified destination. This process determines whether or not the packet can be routed to its proper destination. If NAT'ing is involved, the packet tracer will calculate the proper translated address ranges. Then if there are any devices along the path that can apply security rules, the packet tracer determines whether or not the packet will be filtered from reaching its destination.
One of four possible outcomes is identified:
- A routable path is found and all devices along the path allow the packet to reach its intended destination.
- A routable path is found that ends in the packet destination, but one or more devices ACL or NAT rules block the packet at some point along the path.
- There is no routable path for the packet to the destination because of a routing conflict, no default route in a device along the path, routing to a disabled interface, or a routing loop.
- There is no routable path for the packet to the destination because of a missing gateway.
When presented to the network engineer, this analysis result shows precisely where in the network the packet will travel, which devices along the path will need to be modified to allow the requested service, and even which rules in those devices need to be changed.
The network engineer then has all of FirePAC's extensive capabilities for exploring firewall configurations, understanding firewall behavior, and modeling the effects of change on firewalls and routers and can design and verify the change prior to deployment out to the network. Following deployment to the network, FirePAC's Change Impact Monitor can validate that the correct change has actually been deployed.
