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.

The new release of Athena FirePAC v4.2 adds several capabilities to the comprehensive firewall audit and operations tool you’ve come to know.  The most exciting of these is Rule Tracker.  This tool allows you to record the reason why individual rules exist and track the changes in documentation as the rules change and evolve over time.  Documenting the business purpose of firewall rules has become a pressing issue with compliance auditors, such as PCI QSAs, demanding to know the reason for each rule in the firewall.  Traditional change management systems keep track of change requests, but knowing which rules were modified because of a specific CMR ticket is virtually impossible.  Network engineers typically feel the need to deploy changes quickly and disdain cumbersome process-heavy change systems that get in the way of making it work now.  Documenting the change takes a distant second-place as the next fire comes along and needs to be put out.

Rule Tracker offers an easy way to set things right.  Unlike elaborate systems that may involve months of process re-alignment, Rule Tracker recognizes that teams collaborate far more easily with spreadsheets.  By using a spreadsheet approach and built-in intelligence to make the system highly user-friendly, Rule Tracker is flexible enough to be used in any change process.  It compares two versions of a configuration and identifies precisely what changed.  The changes can be exported to a spreadsheet format and the missing documentation can be added at any time, based on the changes that were made.  The resulting annotations can then be imported back into FirePAC from the spreadsheet format, where they will be automatically retained and are available for review and reporting.  While the system is designed to keep documentation current on a perpetual basis, consultants will also find the tool a handy way to bring clients up-to-date on regularly scheduled intervals.

I’ve recorded a video that shows how Rule Tracker works, which you can view here.  Check it out!

In an upcoming post, I’ll be describing another new feature in FirePAC v4.2, the NAT Browser.