In my last post I talked about preparing for a firewall audit and all the control points that an auditor will want to check in order to understand if your firewall operations are auditable and repeatable. A firewall audit is a process that provides visibility into your firewall's existing access and connections, identifies vulnerabilities, and reports on firewall changes.
Today I want to focus on two parts of the firewall audit: the reviewing of the access policy change process, and the reviewing of the firewall 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're pre-auditing your firewall before the audit team arrives, or if you've been tasked to audit the firewall yourself.
Auditing the Change Process
The first technical step in a firewall audit is usually a review 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'll first need to randomly pull around 10 change requests since the last audit. Here are the basic firewall policy rule checklist questions you should be asking when you audit a firewall change:
- Is the requester documented, and are they authorized to make firewall change requests?
- Is the business reason for the change documented?
- Are there proper reviewer and approval signatures (digital or physical)?
- Were the approvals recorded before the change was implemented?
- Are the approvers all authorized to approve firewall changes (you will need to request 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're performing this audit manually, the first thing you need to do is match each of the changes with a firewall device and with a policy. Now, match the change requests up with the firewall rule that implemented the requested traffic. Already stumped? No worries. Now you know where you need to improve. The comment on each firewall security policy rule should have at least two 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 type of firewall security audit. For example, Tufin SecureTrack shows you who added the rule and when, as well as if they 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 include a hyperlink back to the change ticket to simplify your view of the firewall 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 implemented. The most comprehensive solution would be to use a security change automation product like the Tufin SecureChange workflow. It will show the rule request along with firewall audit signoff, risk analysis, and implementation into the rule-base, so that the entire lifecycle, from request to implementation, is documented and auditable.
Auditing the Firewall Rule Base
The second technical step in a firewall audit is generally a review of the rulebase (also called a policy). The methodology for this step varies widely among auditors because it has traditionally been difficult to do, and it's heavily technology-dependent.
For each of the questions listed below, you should have a ranking based on the type of firewall and it's placement in your infrastructure. For example, a firewall not connected to the Internet does not have the same risk as one that is connected to the Internet. This is because internal firewalls tend to be more permissive than external firewalls.
The first list of questions that should be asked about the firewall security rulebase are related to basic policy maintenance and good design practices that grant minimal access for each device. To answer these questions, you'll need to look at each rule in your rulebase, as well as a year's worth of logs that will tell you which rules are being used. This part of a firewall security audit has always been a lengthy manual process, until recently, with tools such as SecureTrack that can be used to answer these questions programmatically, and automatically.
- How many rules does the firewall security policy have? How many did it have at the last audit? Last year?
- Are there any uncommented rules?
- Are there any redundant rules that should be removed?
- Are there any policy rules that are no longer used?
- Are there any services in the rules that are no longer used?
- Are there any groups or networks in the rules that are no longer used?
- Are there any firewall rules with ANY in three fields (source, destination, service/protocol) and a permissive action?
- Are there any rules with ANY in two fields and a permissive action?
- Are there any rules with ANY in one field and a permissive action?
- Are there any overly permissive rules, e.g. rules with more than 1,000 IP addresses allowed in the source or destination? (you might want a number smaller than 1,000. It's best practice to keep it around 25.)
The second list of questions that should be asked about a firewall security rulebase concern risk and compliance. These rules are more technically challenging to answer. You must understand the technology of your firewall to understand what traffic is actually passed by each rule, and if there is a group of services called "allowed services," then, understand which ports and protocols actually pass though that rule. The advantage of a tool like SecureTrack is that it can understand each security policy and automate deep technology questions like these. SecureTrack can answer all of these questions with its integrated Security Risk Report and Customized Compliance Checks capabilities:
- Are there any rules that violate our corporate security policy?
- Are there any rules that allow risky services inbound from the Internet? While you may have a different list of what is considered "risky" for your company, most start with protocols that pass login credentials in the clear like telnet, ftp, pop, imap, http, netbios, and others
- Are there any rules that allow risky services outbound to the Internet?
- Are there any rules that allow direct traffic from the Internet to the internal network (not the DMZ)?
- Are there any rules that allow traffic from the Internet to sensitive servers, networks, devices or databases?
There you have it, my top two steps for how to perform a firewall audit. If you take the time to master these two steps, you'll find that it is much easier to pass firewall audits. These questions are much easier to answer with the help of automation technology. And having responded to hundreds of firewall audits over the years, you can understand why I'm quite passionate about ensuring Tufin has the tools and know-how to help administrators answer often challenging audit questions, quickly.
Recommended: How to Clean Up a Firewall Rulebase – Tufin Firewall Expert Tip #6
