By: Craig S. Wright
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 properly administering the system and the operation of the firewall.
Download the .pdf of the chapter here.
When you are auditing a firewall, the next thing to look at is how the operation of the firewall is being managed, continually tuned in, and monitored. Processes to be looked at are:
- The process of user administration (that is, who can access the firewall device and make changes to its configuration)
- The process of making changes to the configuration and firewall rulebase
- The process of updating and applying security patches to both the OS and the firewall
- The process of monitoring new bugs or weaknesses of the firewall software
- The process of determining whether all necessary firewall activities are being logged
- The process of determining whether rule activity, logs, and rules violations are monitored
- The process of determining whether continuity plans for firewalls are in place
Testing the firewall rulebase
The Firewall rulebase is the set of rules that dictate which packets are allowed or rejected (dropped) as they are encountered by the firewall. Packets can come from inside and outside sources, and the firewall's rulebase determines whether a packet is allowed to pass through, based on several criteria or rules.
Most firewalls come with default settings. However, it is not surprising to know that these settings do not provide even the most basic level of security that most organizations would like to have. For example, some of Checkpoint's firewall appliances allow, by default, unrestricted and unlogged Domain name system (DNS), Internet Control Message Protocol (ICMP) and Routing
Information Protocol (RIP) access both in and out of the firewall. These default settings leave the firewall open to Trojan horses, ping attacks (Ping of Death, smurfing, etc.), man-in-the-middle attacks, and others that exploit the open ports.
Testing the rulebase can bring to light certain misconfigurations and vulnerabilities that can affect the firewall's performance and the security of the network that it was installed to protect.
Rulebase management is certainly a problem area for many firewall administrators. It's easy for firewall rulebases to become riddled with incorrect, overlapping, and unused rules, even in the presence of a change management system. There has been a bit of academic research into this topic during the past few years, and researchers have identified a number of anomalies worthy of an administrator's attention.
- Overlapping/shadowed rules often occur when administrators create one high-priority rule that generalizes lower priority rules. For example, the administrator might create a rule that appears high in the rulebase, allowing all SMTP traffic. An older rule, lower in the base, might specifically allow SMTP traffic to a mail server. Because of its similarity and lower priority, however, this more specific rule will never be triggered. The situation could be made worse when the lower rule is intended to block traffic to a particular server. Since the generalized rule appears first, the block would never take effect.
- Orphaned rules occur when services or systems disappear from the network or other changes render a rule obsolete. All too often, these rules are never removed from the firewall, creating a potential security hole and adding to a firewall administrator's burden.
- Unused rules are similar to orphaned rules, except these rules were never used in the first place. Unused rules could be the result of change requests from projects that never materialized, or the unused rules could result from administrator errors when creating rules.
A number of commercial tools attempt to tackle these problems. Examples of these tools are FireMon from Secure Passage LLC and Firewall Analyzer from Algorithmic Security (AlgoSec) Inc. The true solution, however, is to keep your rulebase simple, limit it to a manageable size; and conduct regular audits.
Some areas to consider when assessing the firewall policy include:
- Has the design taken planned growth into account?
- Is the system patched and tested? (do not assume that all patches work)
- Does the policy provide defense in depth; does the architecture consider all layers of the Transmission Control Protocol / Internet Protocol (TCP/IP) stack?
- What is allowed into the network? What is allowed out? All traffic entering or leaving the network should have a justification. Some regulations and standards, such as the PCI Data Security Standard (DSS) require this justification for all traffic, but it is good practice, even when not specified by an adopted standard.
The SANS GIAC Certified Firewall Analyst (GCFW) GCFW gold paper repository and the reading room subsite are great places to find papers on firewall design and architecture (www.sans.org/reading_room/whitepapers/firewalls/).
Firewall vulnerability can be an error or a weakness in the firewall's design, implementation, or configuration that anyone with malicious intent can exploit to attack that which the firewall is believed to protect.
We can classify firewall vulnerabilities as:
- Validation error A validation error occurs when the program interacts with the environment without ensuring the correctness of environmental data. Three types of environmental data need validation: input, origin, and target. Input validation ensures that the input is as expected. This includes the number, type, and format of each input field. Origin validation ensures that the origin of data is actually what it is claimed to be, for example, checking the identity of the IP source. Target validation ensures that the information goes to the place it is supposed to. This includes ensuring that protected information does not go to an untrusted target.
- Authorization error An authorization error (authentication error) permits a protectedoperation to be invoked without sufficient checking of the authority of the invokingagent.
- Serialization/aliasing error A serialization error permits the asynchronous behavior of different system operations to be exploited to cause a security violation. Many time-of-check- to-time-of-use flaws fall into this category. An aliasing fl aw occurs when two names for the same object can cause its contents to change unexpectedly, and, consequently, invalidate checks already applied to it.
- Boundary checking error A boundary checking error is caused by failure to checkboundaries and ensure constraints. Not checking against excessive values associated withtable size, file allocation, or other resource consumption leads to boundary checking errors. Buffer overflow is a result of a boundary checking error.
- Domain error A domain error occurs when the intended boundaries between protectionenvironments have holes. This causes information to implicitly leak out.
- Design error Design errors can be traced to the system design phase. For example, a weak encryption algorithm falls into this category.
Following are the most common effects of the vulnerabilities described above:
- Execution of code Execution of unwanted code occurs when a vulnerability can lead tocode being illegitimately executed. This includes, but is not limited to, code written by anattacker.
- Change of target resource Change of target resource occurs when a vulnerabilityallows the state of a resource to be illegitimately changed by an attacker. A resourcecould be a host, a firewall rule table, or any entity that should be protected by the firewall.
- Access to target resource Access to a target resource occurs when a vulnerabilityallows an attacker illegitimate access to some resource. Again, a resource may be any entitythat is protected by the firewall. Examples of this vulnerability effect include allowing anattacker to read the firewall rule tables or to find out which services are available on aprotected host.
- Denial of service (DoS) DoS occurs when a vulnerability is exploited to disrupt a service provided to legitimate users. Services in this context may range from packet forwarding or network address translation to administration.
Firewall vulnerabilities are best identified by using automated tools called vulnerability scanners.
These scanners determine the firewall's vulnerabilities by comparing its configuration against known weaknesses and vulnerabilities. The following are the most common tools used in the industry:
- Active vulnerability scanners such as Internet Security Systems (ISS) Internet Scanner, Symantec NetRecon, and Nessus (see the chapter on scanning with Nessus)
- Host-based scanners such as Microsoft Baseline Security Analyzer (MBSA), ISS System Scanner, and Symantec Enterprise Security Manager (see the chapter on scanning with MBSA)
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.