xcept that which is needed is also the right thing to do, but it can be an administrative hassle. Here is a prime example of convenience outweighing security. On the plus side, if you implement this rule, you'll know that peer-to-peer file sharing services probably won't work, and you'll have a better handle on what's going on when users com- plain that their newly installed instant messenger clients don't work. The downside is that unless you have a documented security statement, you'll spend a lot of time arguing with people about what's allowed and what's not. The default behavior of many firewalls, including the Cisco PIX and ASA, is to allow all outbound traffic. Restricting outbound traffic may be a good idea based on your environment and corporate culture, though I've found that most small and medium-size companies don't want the hassle. Additionally, many smaller com- panies don't have strict Internet usage policies, which can make enforcing out- bound restrictions a challenge. Everything that's not yours belongs outside the firewall This is another simple rule that junior engineers often miss. Anything from another party that touches your network should be controlled by a firewall. Network links to other companies, including credit card verification services, should never be allowed without a firewall. The corollary to this rule is that everything of yours should be inside the firewall (or in the DMZ, as described in the next section). The only devices that are regularly placed in such a way that the firewall cannot monitor them are VPN concentrators. VPN concentrators are often placed in parallel with firewalls. Everything else should be segregated with the firewall. Segregation can be accomplished with one or more DMZs. Firewalls get blamed for everything. It seems to be a law of corporate culture to blame the firewall the minute anything doesn't work. believe there are two reasons for this. First, we naturally blame what we don't understand. Second, a firewall is designed to prevent traffic from flow-