The Difficulties of Secure Networking

Considering that we as a community have been working at this problem for many, many years, understanding some of the reasons why we still don't have completely secure networks is useful. Security is not as simple as flipping the "secure" switch on a device, and it might never be. There are many reasons for this, and perhaps the most significant reasons have nothing to do with the technology directly. The following paragraphs outline the reasons that pertain directly to the topics in this book.

First, security management is hard. Because configurations for security tend to restrict traffic flows, there is very little room for error when you are trying to ensure that good traffic passes and bad traffic doesn't (assuming you are able to correctly identify the bad traffic, which isn't always the case). To compound the matter, to maintain your security system, you must receive log messages from all of your security technologies. Without log files, you won't easily be able to tell whether things are working. The volume of these messages can be very burdensome as networks increase in size. Also, patches are released for various vulnerabilities, but the vulnerabilities don't magically disappear. You still must find a way to test and apply the patches to all of your systems.

Second, network identity is hard to track. As a user of the network, you, or your host, can be identified by your Media Access Control (MAC) address, IP address, username, or a certificate. Because security systems make decisions at different layers of the network, it can be difficult to ensure consistent policy implementation across these boundaries.

Third, as networks increase in size, the performance limitations when adding certain network security technologies are significant. This is the result of not just the increased load on a network after adding security features, but also the impact of any necessary changes in network design to accommodate your security system.

Fourth, many standards for secure networking methods are either nonexistent or fairly new. Compounded with the wide variety of vendors that offer pieces of your network security system, it creates an environment that is difficult to maintain (see point 1).

Fifth, computers are complex systems. It is an amazing feat of engineering that computers work at all, let alone are relatively secure. Consider the components you have in a general-purpose PC: CPU, motherboard, network card, video card, hard drive, operating system (OS), and applications. In many computers, each one of these elements is made by a separate company. Recall from Chapter 1, "Network Security Axioms," that complexity is the enemy of security. By connecting several of these components into an overall network (which starts the vendor options over again), you can create an exceedingly complex environment.

Sixth, and this is a recurring theme in this book, since most all network systems are shipped in an insecure state out of the box, you must actively choose to make them secure. If you take this point in light of the difficulties associated with network management (point 1), dealing with securing these insecure systems is a very time-consuming process.

Finally, because of difficulties in management (point 1) and default device state (point 6), even if there is a security technology that would clearly benefit network security, there is no guarantee people will use it. Antispoof filtering is my favorite example: the technology is easy to understand, can be deployed without significant performance penalties with today's hardware, yet is still not ubiquitously deployed. This is despite the fact that the Internet Engineering Task Force (IETF) published a method for antispoof filtering in 1998. This gets to the notion of security being as much, if not more, about the people using a network as it is about issues with the technology.

All this being said, there is no reason to despair. As you learned in Chapter 2, "Security Policy and Operations Life Cycle," building your security system is a matter of matching your security policies against best practices and security technologies that give you the most benefit. These won't always be easy choices, but this chapter should help you make those selections.

The same table format and criteria are used throughout this chapter. Table 4-1 shows the summary information for host-based firewalls as an example.

The following list defines the nonobvious components of the table:

• Common example Refers to a commonly seen example of the referenced technology. Cisco gear is referenced when it exists.
• Attack elements detected Lists the attack elements and subclasses discussed in Chapter 3 that this technology helps detect.
• Attack elements prevented Lists the attack elements and subclasses discussed in Chapter 3 that this technology helps prevent. Attacks that can be prevented can generally also be detected and are not listed in both places.

NOTE

The detect and prevent sections are certainly up for debate. Different implementations of technologies do better or worse with specific attacks. I tried to select the attack elements that are most commonly detected or prevented by a particular technology.

Also, having an attack in the prevent or detect column doesn't mean the technology prevents all instances of an attack. A router, for example, can stop certain IP spoofing attacks with RFC 2827 filtering. The router can't, however, prevent hosts on the Internet at large from spoofing one another when they send traffic to your network.

Finally, it is worth mentioning that just because a technology can prevent an attack doesn't mean it should prevent the attack. Often, technologies have differing abilities to stop certain attacks, which affect how they are deployed. Also, there are examples in which a technique for stopping an attack might cause significant penalties (performance impact being the most common). In these cases, it is better to fall victim to the attack for a short time and then enable the function than to have it on all the time and risk connectivity problems. These concepts are discussed in more detail in the design sections of this book.

The remaining 10 table rows are numeric values; the final row shows an overall rating of the technology. Higher numbers are always better for you and worse for the attacker. The criteria are rated on a 1 to 5 scale, and the overall rating is derived from the following formula:

[(SUM(Threat values of detected threats)/3) + (SUM(Threat values of prevented threats)) + (Difficulty in attacker bypass * 5) + (Ease of network implementation * 2) + (User impact * 5) + (Application transparency * 2) + (Maturity of technology * 3) + (Ease of management * 4) + (Performance * 3) + (Scalability * 3) + (Financial affordability * 4)]/3 = Overall Value of Technology

This creates a weighted system in which the most emphasis is on the detection and prevention of attacks. Detection earns only 33 percent of the value that the same attack would if it were prevented. This part of the formula takes the actual attack values from Chapter 3. For example, host firewalls detect probe and scan attacks, which rated 37 in Chapter 3. Host firewalls also prevent direct access and remote control software attacks, which rated 39 and 37, respectively, in Chapter 3. Using these values and the numbers in the chart, you can formulate a rough overall value for host firewalls:

[(37/3) + (39 + 37) + (2 * 5) + (2 * 2) + (2 * 5) + (1 * 2) + (2 * 3) + (1 * 4) + (4 * 3) + (2 * 3) + (3 * 4)]/3 = 51 (rounded to the nearest whole number)

In the weighted values, difficulty in attacker bypass and user impact are given the most weight. Manageability and affordability are also weighted quite high.

This formula does not produce a fixed range because the number of threats a given technology can detect or prevent has no upper limit. Overall values are best compared to one another and are provided in summary form at the end of this chapter.

NOTE

As in Chapter 3, these ratings are subjective. You might find that you disagree with several ratings, and ratings can change as technology evolves. The preceding formula to calculate the overall rating can be easily modified based on the factors that are important to you.

The following describes the 10 table rows and the rating scale for each:

• Difficulty in attacker bypass Assuming reasonable attacker competence, refers to how hard this technology is to bypass (1 = seriously consider if it is worth deploying this technology; 5 = best of luck, script kiddie!).
• Ease of network implementation Given a moderately sized network, refers to how hard the technology is to integrate into the network; for example, does it create difficulties for the information technology (IT) staff and so on (1 = better staff up!; 5 = no worries).
• User impact Refers to the impact, if any, the technology has on users. For example, whether users complain about application failures, experience effects on their day-to-day functions, and so on (1 = are you sure you want to deploy this?; 5 = users won't notice).
• Application transparency Refers to whether any significant changes (code or configuration) are necessary to corporate applications or to the security technology in support of those applications to make effective use of this technology (1 = check your brakes before you get on the road; 5 = minimal changes necessary).
• Maturity of technology This is self-explanatory (1 = flash-in-the-pan technology; 5 = such technology as one-time passwords [OTP]).
• Ease of management Refers to all aspects of how the product is managed and the operational costs of deploying and managing the technology (1 = dedicated staff often required [high costs];, 5 = almost no management required [low costs]).
• Performance In a midsize network, compares the performance of the network as a whole or the device running the technology with and without the security technology (1 = significant impact; 5 = no one will notice).
• Scalability Refers to whether the technology becomes significantly harder to deploy, manage, and so on, as your network grows (1 = very difficult to scale; 5 = size of network has almost no impact).
• Financial affordability Refers to the affordability of the technology. This number assumes a midsize network and that the technology is deployed in the most relevant areas. For example, a host IDS (HIDS) might earn a 1 if you put it on every computer in your network, but it earns a 3 when you implement it only on key servers. Also, this rating is based on the capital expenditure of the product (how much it costs to buy). Operational expenditures are integrated into the rating for manageability (1 = probably too expensive for most networks; 5 = almost free of charge).

  TIP

  The financial affordability rating assumes purchase of commercial products when they are available. Open source alternatives to commercial products are becoming more viable every day, but be sure to consider support and management costs, which can be higher.

• Overall value of technologyThis rating is useful when comparing similar technologies or when prioritizing which technology to implement first. If you take the time to tune the attack ratings in Chapter 3, as well as the ratings in this chapter, you should have a good breakdown of which kinds of technologies to deploy first to improve your security system. Since the formula is a weighted sum including the values of the attacks it prevents or detects, the values are most useful in relation to each other rather than as absolute values.