YESTERDAY: Firewall responsibility and placement
Learn key security risks and standards which should be considered while adopting a firewall or VPN; find out how to audit for firewall
activity; and read up on purchasing advice before buying your firewall.
Firewalls are essential since they can provide a single block point where security and auditing can be imposed. Firewalls provide an important logging and auditing function; often they provide summaries to the administrator about what type/volume of traffic has been processed through it. This is an important point since providing this block point can serve the same purpose (on your network) as an armed guard can (for physical premises).
Risks are threats to your objectives. A proper risk analysis should be done before making any technology decision. When considering adopting firewall/VPN technology, here are some key security risks and standards which should be considered:
To assess risk ask the following questions:
- What is at risk?
- What is its value?
- What are the threats?
- What is the probability of occurrence?
Some of the common security risks are as follows:
- Single point of failure
- Loose security policies
- Support protection
- Limitation of technology
- False sense of security
- Weak encryption
Here are some firewall/VPN standards to consider:
- Open architecture
- Packet filteration
- Default to denial
- Auditing capabilities
- Access control
- Logging capabilities
- Intrusion detection
- Extended user authentication
- Secured subnets
- Strong encryption
- Network management systems
- Secure back-up
- Statefull inspection
- Real-time traffic monitoring and alerting system
- Device management
- Secure tunnelling
- Application layer traffic inspection
We can only dream that once you've made it through the challenging phases of firewall selection and architecture design, you're finished setting up a DMZ. In the real world of firewall management, we're faced with balancing a continuous stream of change requests and vendor patches against the operational management of our firewalls. Configurations change quickly and often, making it difficult to keep on top of routine maintenance tasks.
Network security expert Michael Chapple takes a look at four practical areas where some basic log analysis can provide valuable firewall management data:
- Monitor rule activity: System administrators tend to be quick on the trigger to ask for new rules, but not quite so eager to let you know when a rule is no longer necessary. Monitoring rule activity can provide some valuable insight to assist you with managing the rulebase. If a rule that was once heavily used suddenly goes quiet, you should investigate whether the rule is still needed. If it's no longer necessary, trim it from your rulebase. Legacy rules have a way of pilling up and adding unnecessary complexity. Over the years, Chapple had a chance to analyse the rulebases of many production firewalls, and estimates that at least 20% of the average firewall's rulebase is unnecessary. There are systems where this ratio is as high as 60%.
- Traffic flows: Monitor logs for abnormal traffic patterns. If servers that normally receive a low volume of traffic are suddenly responsible for a significant portion of traffic passing through the firewall (either in total connections or bytes passed), then you have a situation worthy of further investigation. While "flash crowds" are to be expected in some situations (such as a Web server during a period of unusual interest), they are also often signs of misconfigured systems or attacks in progress.
- Rule violations: Looking at traffic denied by your firewall may lead to interesting findings. This is especially true for traffic that originates from inside your network. The most common cause of this activity is a misconfigured system or a user who isn't aware of traffic restrictions, but analysis of rule violations may also uncover attempts at passing malicious traffic through the device.
- Denied probes: If you've ever analysed the log of a firewall that's connected to the Internet, you know that it's futile to investigate probes directed at your network from the Internet. They're far too frequent and often represent dead ends. However, you may not have considered analysing logs for probes originating from inside the trusted network. These are extremely interesting, as they most likely represent either a compromised internal system seeking to scan Internet hosts or an internal user running a scanning tool -- both scenarios that merit attention.
Your firewall audit logs are a veritable goldmine of network security intelligence. Use them to your advantage!
First and foremost, consider the functionality of the firewall. The good news for those deciding between products is that mainstream firewalls all have the same core functions. Each performs statefull inspection packet filtering and allows the implementation of basic perimeter defences. Michael Chapple recommends honing in on functional requirements. Ask yourself: Do you need to emphasise network throughput or enhanced security features?
One major point of differentiation between firewalls is their ability to perform application-layer inspection. Many firewalls simply don't have application-layer inspection, while others implement basic functionality (such as URL filtering). Some products, like Secure Computing's Sidewinder G2 firewall and F5 Networks' BIG-IP Application Security Manager, have deep application inspection capabilities. These types of firewalls allow for complex application rule bases that limit the types of actions carried out over a connection. For example, you might limit inbound HTTP requests from the Internet to GET commands, while internal users might be able to issue POST commands. This functionality allows you to protect the enterprise against application-based attacks as well as network-based attacks.
Finally, consider the vendor itself. When investing in a firewall product, you're making a long-term decision. The financial commitment is only the tip of the iceberg; your firewall administrators will invest significant time and energy building and customising a rule base for that particular product. In general, rule bases are not portable between platforms, so any future platform change will require a substantial commitment of human resources, so it's wise to make sure the vendors on your short list are all stable companies with solid financials. You certainly don't want to get on board a sinking ship.