A well-formed network change request typically specifies a source IP address, a destination IP address, and a service to allow.  Getting this request from the initial submitter to a final, validated deployment of a correct network device configuration can be a challenging task.

Although the change process will vary from organization to organization, there are several common roles and process steps.  The change process will typically involve many stakeholders who require different levels of access to information about the change and the network itself.  The request will be initiated by an end-user who desires access to particular services or specific devices.  A security auditor may review the security implications of the request.  A change manager may review the request for correctness and completeness.  A network engineer will design configuration changes based on the requirements in the request.  A change manager may review the proposed changes for impact on network behavior and compliance to network standards.  Once approved, a network engineer will deploy the changes to the network.  Finally, the actual change deployed to the network may be validated to ensure it was made correctly and corresponds to an actual change request.

In networks of any reasonable size, it is quite likely that a packet specified by a change request will traverse multiple 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.  Not all of the stakeholders will have access to this information, either for security reasons or simply that it’s irrelevant to their jobs.

The application developers and other end-users who request access to particular services or specific devices are frequently unclear on the nuts and bolts of the network architecture.  They are not likely to be familiar with the intricate details of IP subnetting or network address translations.  They may not even be sure of the exact port numbers used by their favorite services.  This all leads to change requests that may be ill-formed and even strewn with erroneous IP addresses or port values.

Another issue is that even if a change request contains the correct host and service parameters, the request may be spurious because the service is already available and accessible.  Even so, just determining that a request is spurious requires identifying the correct path through the network from source to destination and finding the network devices that could potentially block the packet.  In this case, the network engineer’s valuable time is wasted even just responding to the request because there’s nothing to be done.

Assuming the change request is accurate and non-spurious, the network engineer still has to identify the correct path through the network from source to destination and determine which, if any, devices must be touched in order to complete the request.

Using traditional tools like ping or traceroute, the network engineer can only identify the first device along the path that is blocking the packet.  He would then have to identify the change required in that device, deploy the change to the network, and then continue pinging or tracerouting to the next blocking device and so on.  Since the changes to each device are made individually, they can only be tested and validated individually as well.  This can be a very time-consuming and potentially error-prone process.

Finally, once the correct devices have been identified, the network engineer must determine which ruleset in each device has to be modified and where in the ruleset to make the change.  In many cases, even if the engineers understand the network well enough to know which devices need to be touched, the devices themselves are so complex that designing the correct change is a challenge all by itself.

With so many stakeholders having various and differing interests in changes to the network, a single change request can spend a lot of time going back and forth between different people.  Each additional step in the process introduces the possibility of error and represents more time taken before the change can actually be deployed into production.

Athena Security’s Change Advisor addresses these issues by automating the change process.  It takes advantage of Athena’s core technology of deep dataflow understanding of firewall and network device behavior to determine how packets would traverse the network, based on connectivity, routing and the firewall devices involved in the change request.  It moves analysis of the change to the front of the process and makes the results of that analysis available to the different stakeholders when and how they need it.  This can dramatically reduce the change cycle time and the incidence of errors while ensuring that sensitive information about the network configurations is made available only to those who need it.

Application developers and other end-users use a web form to submit change requests.  They can select the source and destination parameters from a list of known hosts, cutting down on potential errors at the point of entry.

Once a complete request has been entered, Change Advisor issues a packet tracer query based on the request’s source, destination and service parameters 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.

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.