Any network contains vulnerabilities. It is important to understand how these vulnerabilities arise and what to watch out for. At a high level, vulnerabilities can be broken down into the following categories:
The first two are more concrete, the last three categories are harder to quantify.
Various software-engineering methodologies and academic studies have sought to identify and improve the rate of errors found in every 1000 lines of computer program code. Depending on the software and the organization doing the measurement, these numbers can vary widely, but estimates of between 5 and 15 errors for every 1000 lines of code are common. If you look at today's modern applications and operating systems, many have millions of lines of code. (Microsoft Windows XP contains about 50 million lines.) Even if just a small percentage of those flaws are security related, and even if just a small percentage of that group of flaws are exploitable, there are thousands of security flaws waiting to be discovered.
On top of that, software code is changing all the time. Sometimes fixes for one part of a large program can introduce problems into another part. Also, two independent pieces of software might be security bug-free, but when they are run on the same system, they might introduce a new problem. A quick survey of the software vulnerabilities on mailing lists such as BugTraq shows just how many defects are found and the wide range of products in which they are found.
In addition to application bugs, correct implementation of a flawed protocol or design can also cause problems. Because the end result is a software mistake, no matter the reason, these are also called software vulnerabilities.
As a secure network designer, software vulnerabilities are part of the reason you have a job in the first place. In many cases, the network is augmenting the security of an application. If software could be counted on to operate without error, application security could be relied on more, and elements such as firewalls and intrusion detection systems might not be as necessary.
Hardware vulnerabilities are less common but are increasing in significance primarily because of the increase of programmable hardware in the market. Vulnerabilities in the system basic input/output system (BIOS), network processors, and CPUs could do potentially more damage because a hardware vulnerability is often not easily remedied by a software patch. Finding out you must replace your computer because of a hardware vulnerability is not a happy day. Although not specifically related to security, Intel had to offer customers free replacement Pentium processors in 1994 because of a floating-point error in the hardware.
Despite the best intentions of network operators, misconfigurations are very common on a network. In a firewall with a complex access control policy, hundreds of entries permitting and denying different traffic types can exist. The chances are high that someone eventually will make a mistake. This concept was explored in the section about the "Strive for operational simplicity" axiom in Chapter 1, "Network Security Axioms."
In addition to inadvertent misconfigurations, the problem of RTFM often rears its head. For a definition of RTFM, consult your friendly neighborhood search engine. The basics of the problem are this: if the individual responsible for deploying a technology doesn't know much about the technology, the chances of it working as intended decrease significantly. As a result, it is critical that organizations set aside part of the budget to allocate for employee training.
One of the easiest ways to avoid configuration errors is to ensure that your security technologies are easy to manage. For example, when deciding on a firewall, features, performance, and cost are second, third, and fourth on my list of criteria after manageability.
In addition to software, hardware, and configuration vulnerabilities, you might encounter policy vulnerabilities. Policy vulnerabilities occur when an attack is made possible by a poor choice in the development or implementation of a security policy. Since your network security system is only as good as the security policy to which it adheres, policy vulnerabilities can cause widespread problems. This is one of the main reasons Figure 2-1 shows a circular process in which the security system is improved over time through modification of the system and the policies.
The distributed denial of service (DDoS) attacks that occurred in 2000 are examples of policy vulnerabilities. Clearly, changes could have been made to IP to reduce the chances of these attacks succeeding, but at the time most organizations had not planned for such attacks or even considered the remote possibility of them. As such, organizational security policies had not defined standards for how systems should deal with DDoS attacks. Today, if you look at the security policy of any large e-commerce organization, you will probably find standards and guidelines around protecting systems from DDoS.
Just because a system can be used in a secure way, it doesn't mean a user will use it in a secure way. Usage vulnerabilities occur when a user (usually through inexperience, not malice) violates the security policy and causes a vulnerability in the network. One common example is when a user adds a modem to his computer so he can dial up after hours to do work. The user probably personally installed the remote control software and, in doing so, most likely did not enable any of the security features. Therefore, an attacker can use that same modem as a launching point to attack the rest of the network.
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
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
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Guidelines on Antivirus Process