Service provider takeaway: Regulatory and standards compliance can provide several challenges from both a business and a technical perspective. This section of the chapter excerpt from the book The IT Regulatory and Standards Compliance Handbook:: How to Survive Information Systems Audit and Assessments
will focus on testing the firewall and dealing with complex compliance requirements.
Download the .pdf of the chapter here.
In this chapter we will introduce the concepts of auditing or testing firewalls.
First we need to define a firewall. A firewall is an application, device, system, or a group of systems that controls the flow of traffic between two networks based on a set of rules, protects systems from external (internet) as well as internal threats, separates a sensitive areas of a private network from less sensitive areas, encrypts internal and external networks that transmit sensitive data (when used as a VPN endpoint), or hides internal network addresses from external networks (network address translator). A firewall picks up where the border router leaves off and makes a much more thorough pass at filtering traffic. Firewalls come in different types, including static packet filters (for example Nortel Accelar router), statefull firewalls (for example Cisco PIX), and proxy firewalls (for example Secure Computing Sidewinder).
Similar to routers, a firewall uses various filtering technologies or methods to ensure security.These methods include packet filtering, statefull inspection, proxy or application gateway, and deep packet inspection. A firewall can use just one of these methods, or it can combine different methods to produce the most appropriate and robust configuration.
A good way to start to test a firewall is to gather information from individuals that have some responsibility for it. These people may be members of the audit team, system administrators, network administrators, members of the policy team, and information security personnel. The idea is to gather and collate each person's perceptions of what the firewall's functionally should be and what it is configured to provide for the network and systems. Obtain any existing firewall documentation and network diagrams to verify the information gathered from the interview. Ideally, the firewall is a control designed to reflect policy. This means that policy must be in place before the firewall is configured. Sadly, this is seldom the case.
After the information detailed above has been collected, the auditor can develop an understanding of the firewall architecture, and determine whether the firewall is configured to correctly segment networks and defend information. The next step is to evaluate the operating system (OS) configuration. This is the configuration of the firewall platform itself. All firewalls have an OS. Do not be fooled by vendor assertions that firewalls have an appliance. A firewall appliance typically will just have an OS that has been hardened. The appliance could in fact be running a scaled down version of Unix or, in some cases, be running a customized OS written by the firewall company, as in the case of the Cisco Adaptive Security Appliance (ASA). Firewalls and routers are all software driven; all they do is make it more difficult to see the code.
Next it is important to ensure that system administration follows best practice: user management, patch updates, change control, and configuration backups. If the firewall is not patched it will eventually be compromised. Just because it is a security device, it is not automatically secure. Finally, it is necessary to validate that the firewall rulebase matches the organizational policy.
Testing the firewall should be coordinated with testing the other components of the organization's defense-in-depth methodology. The organization should not rely only on a single line of defense; if it does, raise a red flag. Firewalls are not the panacea for all security ills. They mainly slow attackers and log activity.
The overall result of the testing or audit of the firewall would be the identification of any security vulnerabilities, as well as an assessment of whether the firewall is fulfilling its function in relation to the security policy of the company. Assess whether the setup, configuration, and operation of the firewall are secured sufficiently to protect the information or services that the firewall is intended to guard, considering the risks that were identified and the likelihood of occurrence. The Center for Internet Security provides benchmarks for several specific brands of firewalls devices. The benchmarks (available at www.cisecurity.org) greatly aid in developing an audit program for firewalls. These benchmarks are the source of our checklist frameworks.
When auditing the firewall, the auditor must look at the platform or the OS on which the firewall is running. An auditor needs to check on whether the OS on which the fi rewall is installed is stripped to contain only the minimum functionalities or services that are required to provide the functions it runs. The firewall should be an isolated system dedicated to one purpose only, which is filtering traffic based on defined rules. The less complex the installation, the simpler its administration will be. Fewer features equates to less patching and fewer vulnerabilities.
To verify this, commands can be used for determining what services and ports are available to the OS.
Many operating systems have a number of built-in tools that may be used to determine which ports are listening. Some examples are listed here with more in the chapters associated with specific operating systems:
- UNIX : lsof --I, netstat --a, and ps --aef
- Windows the Service Microsoft Management Console (MMC), netstat --a and fport
When first determining the open ports and services, the firewall should be turned off (disabled or running with a policy that allows all traffic). This is done to test only the operating-system-specific ports and services. It is important to do this on a secure network and not connect the firewall to the Internet at this point. Remember, the firewall is a router in this mode.
In addition, the security settings and vulnerabilities of the OS that is installed should be analyzed. Every OS includes a set of security features and vulnerabilities, which varies from vendor to vendor and even between versions. For instance, the default security settings of the OS may not be modified during the installation and such settings may not meet the desired level of security that is consistent with the security policy. Some of the most common security settings that can be evaluated are the access rules, password rules, and logging rules. Other OS/version-specific settings and parameters should also be verified.
Centre for Internet Security also provides benchmarks for several OS. Those benchmarks (available at www.cisecurity.org) can greatly aid in determining whether the OS is configured based on the general industry best practices.
After looking at the firewall platform's OS, the next stage involves the validation of the
firewall configuration. All firewalls have both a configuration and policy. These should not be
The configuration is the set of base settings associated with the firewall software and installation. Changes to the configuration of the firewall will change its behavior, and, hence, how it processes in accordance with the policy.
Again the auditor must check on whether the firewall sits on an isolated system dedicated to one purpose only, which is filtering packets (and logging, of course). For instance, DNS, e-mail, or server load-balancing functions should not be installed on the same host or be processed by the firewall platform. The sole exception here is that load-balancing the firewall itself is a function of a high-availability firewall and is allowed.
Since the fundamental purpose of the firewall is to manage the flow of information between two networks, the auditor must look at how it serves such a function by looking at the firewall's configuration. We need to verify whether the traffic that the firewall allows to pass through is consistent with the security policy. Testing the rulebase is discussed in the latter part of the chapter, but critical things to look at are that:
- The access rules (authentication, authorization, and accounting) for the firewall are in line with the security policy and best practices
- Access to the firewall system for management and maintenance is provided using an encrypted channel
- Physical access to the device is restricted
- The firewall is configured to hide internal restricted DNS information from external networks
- The external firewall restricts incoming SNMP queries
- The firewall is configured as fail closed
- The firewall hides internal information from external sources
- The firewall is configured to deny all services, unless explicitly allowed
- All security-related patches are applied to the firewall system
- Configuration settings are properly backed up and accessible to authorized personnel only
Figure 11.1 illustrates an example of a firewall's standard policy rules. In this example, the standard policy rules detail the default settings that will be merged with the policy before being installed. Thus, the configuration and the policy when applied together make the rules that are enforced at the firewall.
The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments
Working with firewall builder
Packet flow from all networks
Creating your checklist and Summary
About the book
The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments provides detailed methodology of several techincally based and professional IT audit skills that lead to compliance. Purchase the book from Syngress Publishing.
Printed with permission from Syngress, a division of Elsevier. Copyright 2008. "The IT Regulatory and Standards Compliance Handbook: How to Survive Information Systems Audit and Assessments" by Craig S. Wright. For more information about this title and other similar books, please visit www.elsevierdirect.com.
This was first published in August 2008