Network security is a system. It's not a firewall, it's not intrusion detection, it's not virtual private networking, and it is not authentication, authorization, and accounting (AAA). Security isn't anything that Cisco Systems or any of its partners or competitors can sell you. Although these products and technologies play an important role, network security is more compre-hensive. It all starts, as has become almost cliché in the industry, with a security policy. From there, it branches out to include the people charged with conforming to that policy and those that must enforce it. Then it finally results in changes to the actual network infrastructure.
Consider the resurgence of network worms that occurred in 2001 and that shows no sign of slowing. Never mind that network worms are a problem as old as Robert Morris's Internet worm from 1988; these worms cause massive damage. Code Red, for example, infected over 340,000 hosts in its first 24 hours of existence (source: http://www.caida.org). This is important because a large number of those hosts were protected by firewalls. Unfortunately, most firewalls don't do deep-packet inspection, and even if they did, no one knew what to look for when Code Red hit. The firewalls simply recognized that the packet was arriving on port 80, and they let it pass through. Once inside, Code Red was free to infect the entire internal network, which was often deployed without network security controls. A system could have mitigated the effects of Code Red, but a single firewall doesn't stand a chance.
But what is a system when it comes to network security? Broadly defined, a network security system is as follows:
A collection of network-connected devices, technologies, and best practices that work in complementary ways to provide security to information assets.
The key word in that definition is complementary. Having basic router access control lists (ACLs), stateful firewall ACLs, and host-based firewall ACLs gives you lots of basic access control, but it isn't a system. For a true network security system, you need complementary technology that applies to a specific threat pattern. Some in the information security industry call this "defense-in-depth." A practical method of determining the quality of your system is to break down the quantity and makeup of the various deployed threat mitigation techniques: protect, detect, deter, recover, and transfer. This kind of evaluation is helpful in the early stages of network security system development. As you move toward implementation, you must delve to a deeper level. The easiest way to do this is to reverse your thinking by considering how different threat categories will be mitigated by the system you have put in place.
As an example, let's return to the port 80 worms just discussed. What are some different system elements that will mitigate the threat of an HTTPbased worm to a public web server? The following list summarizes these system elements, which are explained in more detail in Chapter 3, "Secure Networking Threats":
All of the preceding system elements work together to mitigate the threat. Although each element isn't 100 percent effective at stopping HTTP-based worms, basic mathematical probability shows that the more complementary system elements you have in place to counter a given threat, the greater the likelihood that the threat will be neutralized.
Testing the true mettle of your network security system doesn't come when you are under attack by the known but rather the unknown. Although script kiddies are predictable in their lack of creativity, a determined and skilled attacker will likely have a stash of unique techniques.
Pick your favorite security incident from the past, whether it is the Morris worm from 1988, root kits and IP spoofing in the 1990s (more information is given in Chapter 3), distributed denial of service (DDoS) attacks in 2000, HTTP worms in 2001, or the SQL Slammer and MS Blaster worms in 2003. It is easy to point out the failings of your network security after your systems are affected by an attack. It is through this "learning through pain" process that many seemingly apparent security issues are suddenly brought to light.
There is no way to avoid this kind of learning, but you can try to minimize it by designing your security system to deal with broad categories of attacks rather than specific ones. In fact, one of the many metrics used to gauge the success of your security system is to count how many times you've had to make significant modifications to adapt to the latest threats. Ideally, it is an infrequent occurrence.
Network security is a system. If you remember nothing else from this book, I did a very bad job of writing it. But if you remember only a few things, I hope one is the preceding simple statement.
Part I. Network Security Foundations
Network Security Axioms
Security Policy and Operations Life Cycle
Secure Networking Threats
Network Security Technologies
Part II. Designing Secure Networks
Device Hardening
General Design Considerations
Network Security Platform Options and Best Deployment Practices
Common Application Design Considerations
Identity Design Considerations
IPsec VPN Design Considerations
Supporting-Technology Design Considerations
Designing Your Security System
Part III. Secure Network Designs
Edge Security Design
Campus Security Design
Teleworker Security Design
Part IV. Network Management, Case Studies, and Conclusions
Secure Network Management and Network Security Management
Case Studies
Conclusions
References
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Password Policy
Guidelines on Antivirus Process
Index