The in's and out's of undergoing a firewall audit: an experts viewpoint of getting though a firewall audit by Michael Hamelin, chief security architect, Tufin Technologies.

Author:Hamelin, Michael

In this article you'll be given tips on two parts of undergoing a firewall audit: the review of the change process, and the review of the rule base. In my experience, these two steps are the most important. I'll go over many of the technical details you need to check if you are pre-auditing your firewall before the audit team arrives, or if it is your job to audit the firewall.

Auditing the Change Process

The first technical step in a firewall audit is normally an examination of the firewall change process. The goal of this step is to make sure that requested changes were properly approved, implemented and documented. You can accomplish this in a few different ways - depending on whether you have a tool to assist you or you are doing it manually.

You will need to pull, at random, around 10 change requests since the last audit. The basic questions you should be asking when you audit a firewall change are:

* Is the requester documented, and is s/he authorized to make firewall change requests?

* Is the business reason for the change documented?

* Are there proper reviewer and approval signatures (electronic or physical)?

* Were the approvals recorded before the change was implemented?

* Are the approvers all authorized to approve firewall changes (you will need to ask for a list of authorized individuals)?

* Are the changes well-documented in the change ticket?

* Is there documentation of risk analysis for each change?

* Is there documentation of the change window and/or install date for each change?

* Is there an expiration date for the change?

If you are doing this manually, the first thing you need to do is match each of the changes up with a firewall device and with a policy. Now match the change requests up with the firewall rule(s) that implemented the requested traffic. Already stumped? Then you know where you need to improve. The comment on each rule should have at least 2 pieces of data: the change ID of the request and the initials of the engineer who implemented the change.

There are more automated ways to do this. For example, Tufin SecureTrack shows you who added the rule and when, as well as if s/he added anything else to the policy at the same time. You can put the change ticket number in the comment field, so that the rule will have a hyperlink back to the change ticket to simplify looking up the audit trail. You can even run a rule history report over time to see how this rule has changed with other change tickets since it was...

To continue reading