So You Need to Conduct a Firewall Review

Firewall audits receive a lot of attention nowadays due to standards such as PCI-DSS, ISO 27001 and SOX and HIPAA for US companies. Even if you are not required to meet these standards at the present time, you may be required to show that your network is secure for business relationships with certain partners and customers.
However, setting aside compliance requirements, firewall audits have good reason to be considered good practice. They can improve your ability to locate weaknesses in your network security posture and allow you to find where your policies need to be changed. In addition, they can assist you in demonstrating due diligence in reviewing your network security and policies in the event of a lawsuit or other issue which may question your security standards.
Two of the key aspects of a firewall audit are reviews of the change process and rule base. If you are required to pre-audit your firewall before auditors arrive, or you are tasked with auditing the firewall yourself, there are some important technical details you will need to check.

1) Change Process Auditing

The initial technical step of a firewall audit is usually a review of the firewall change process. The aim of this step is to ensure that any requested changes were properly approved, implemented and documented. You can achieve this in several different ways depending on whether you have a tool to assist you or whether you need to do it manually.

You will need to randomly select approximately 10 change requests created since the most recent audit. The questions you should ask when you audit a firewall change are:

  • Is the requester recorded and do they have authorisation to make firewall change requests?
  • Has the business reason for the change been recorded?
  • Are the correct reviewer and approval signatures present (electronic or physical)?
  • Was the change only implemented after the approvals had been recorded?
  • Do the approvers have the authorisation to approve firewall changes?
  • Does the change ticket document the change well?
  • Is there risk analysis documentation for each change?
  • Had the change window and/or install date for the change been recorded?
  • Does the change have an expiration date?

If you are performing this process manually, the first thing you must do is match each change with a firewall device and a policy. Now match the change requests to the specific firewall rule or rules. If you get stuck on this then you already know where you need to improve. The comment with each rule should contain, as a minimum, the change ID of the request and the initials of who implemented the change.

Automated tools are readily available and, due to the quantity or rules on most modern firewalls, they are highly recommended to make the auditing process more manageable. They also allow greater visibility and control over your rule base.

For example, they show you when a rule was added and who added it, as well as if they added anything else at the same time. These tools also allow you to link to the change ticket in the comments field to make locating the audit trail much easier. They also allow you to run a rule history report to show how the rule has changed over time and locate the relevant change tickets. Tools with extended management capabilities will display the rule request as well as audit signoff, risk analysis, and implementation into the rule-base, documenting the whole lifecycle and making it auditable.

2) Firewall Rule Base Auditing

The second step in the audit is normally a review of the firewall’s rule base/policy. Procedure for this step varies between auditors as it is traditionally a difficult task heavily dependent on technology.
For each question you should have a ranking based on the nature of the firewall and its placement within your infrastructure. For example, firewalls that are connected to the internet are generally much more at risk than those that are not, and internal firewalls are often more permissive than external ones.Questions related to basic policy management and good design practice should be asked first. To answer these questions you should examine each rule in your rule base, as well as a year’s worth of logs to ascertain which rules are actually used. Until recently, this has been a lengthy manual process, however, with the development of tools which can be used to answer these questions automatically, it has become far easier.

  • How many rules are there compared to last audit/year?
  • Are there any rules without comments?
  • Are there any rules that are redundant and should be removed?
  • Are any rules unused?
  • Are any services within the rules no longer used?
  • Are there any unused groups or networks in the rules?
  • Are there any firewall rules with ANY in the source, destination and service/protocol fields with a permissive action?
  • Are there any rules with a permissive action and ANY in two fields?
  • Are there any rules with a permissive action and ANY in one field?
  • Are there any overly permissive rules, for example, rules with more than 1000 IP addresses allowed in the source or destination?

The second list of questions is related to the risk and compliance of your rule base. These rules are more technically challenging to answer. You must possess an understanding of the workings of your firewall to infer what traffic is actually being passed by a rule, and if there is an ‘allowed services’ group, which ports and protocols actually pass through that rule.

  • Are any rules in violation of the company’s security policy?
  • Are there any rules that allow inbound risky services from the internet, such as those that pass login credentials in the clear like telnet, ftp, pop, imap, http, netbios, etc?
  • Are there any rules that allow outbound risky services from the internet?
  • Do any rules allow direct traffic from the Internet to access the internal network (not the DMZ)?
  • Do any rules allow traffic from the Internet to networks, sensitive servers, devices or databases?

If you commit the time necessary to master these two processes it will become much easier to pass firewall audits. Automating the process as much as possible provides the information administrators need to perform the audit. However, if you are required audit large firewalls with difficult rule bases yourself, automating the process will prove to be cost-effective, as well as reducing your margin for error. If automation is not an option however, then focussing on these two areas is key to maintaining the effectiveness of your firewall policies.

Leave a comment