A smart administrator will protect IT resources not only from the outside world, but from other resources inside the network as well.
A layered approach to security is a good idea. There's little to quibble about there. The specific needs of an effective layered security strategy may be open to debate, however. The truth is that those needs vary from case to case, and may vary wildly in some cases.
A common mistake of those who do not employ an effective layered security strategy, though, is to focus on perimeter security. It's increasingly popular amongst the avant-garde of security professionals to claim there is no perimeter, but the truth is more prosaic: there's a perimeter, but there's a lot more to security than the perimeter. Much of the philosophy of layered security is a response to the need to address more than mere perimeter security.
Firewalls are not enough, these days (if they ever were), to effectively protect the data moving around inside your network. Even ignoring for a moment the fact that an Internet-connected network would never need to be connected to the Internet if data did not cross the perimeter, and still probably need securing even outside the perimeter at times, the view that one's network is some kind of atomic, indivisible resource that needs all security measures focused on protecting it as a whole is mistaken. The various parts and operations of your network all need their own individual protection measures too -- even protection from each other.
A failure in penetration protection at the perimeter of a network is never an impossibility. Local wardrivers and other wifi security crackers, exotic threats such as van Eck phreakers (at least in theory), and unscrupulous or incautious employees with physical access can all introduce threats to the network, bypassing common perimeter defenses entirely. It is for this reason that one should employ a layered network security strategy -- to design one's security policy not only to attempt to keep the threats out, but also to provide the means to respond effectively to breaches, and to keep sensitive data and resources as well-protected as possible even if security has in some manner been compromised.
One of the most common failures in this regard is that of undertaking significant effort and expense to secure traffic outside the perimeter with encryption and authentication measures while assuming that data communications inside the perimeter are necessarily safe. Protective measures for your IT resources should be implemented even for operations that take place entirely within a nominally trusted network. In other words, even a supposedly trusted network should be regarded as untrusted -- just, perhaps, less severely untrusted than other networks, such as the Internet itself. Such measures should include, but not be limited to, the following:
- Systems internal to your network should be protected as though they were connected to public wireless network with Internet access and no perimeter security measures at all, such as many coffee shop networks. Each should have its own firewall running, unnecessary services turned off, and necessary services configured to minimize vulnerability -- even if you think nobody will be able to even attempt to crack security from outside the local network.
- Secure user authentication should always be used when accessing resources across the network. If some malicious security cracker manages to gain a foothold on a system within your network -- perhaps some desktop system that uses a Web browser, email, and IM client to talk to the outside world -- he or she might then be able to use it to stage attacks against more other systems. If secure authentication is necessary to access your mail server, it won't be easy to turn it into a virus delivery platform; if for your file server, it won't be as easily ransacked; if for your firewall, it won't be as easily reconfigured to allow further access to the network from the Internet. Part of secure authentication, of course, is ensuring that only very well secured systems are allowed as the source of remote access.
- Security assurance and disaster recovery resources on your network, such as integrity auditing and backup servers, should be as impervious to attacks launched from local systems as threats originating outside the network perimeter. Logging servers should listen, but not broadcast; backup servers should never allow anything copied from another system to be executed on them; integrity auditing servers should not be subject to any control by the systems whose integrity they're meant to audit.
- Communications across the internal network should always be encrypted. If you have a consumer grade router/firewall appliance with a Web interface, it should be accessed via an HTTPS encrypted connection. If you must access the shell on a Unix system, use OpenSSH rather than RSH or other unencrypted tools. Network filesystem shares should be accessed using tools such as SSHFS that encrypt the entire session using strong, peer reviewed cryptographic algorithms, rather than unencrypted, poorly encrypted, or only partly encrypted NFS or SMB/CIFS shares.
Just as a boxer may wear a mouth guard to protect his teeth from each other, and not merely rely out outward defenses against an opponent's punches, you should secure everything within your network against the rest of your network to protect it in the event your trust in your own IT resources doesn't save you from unexpected threats that may penetrate or circumvent your perimeter security.