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.
|
Name |
|
|
Common example |
IPFilter |
|
Attack elements detected |
Probe/scan |
|
Attack elements prevented |
Direct access Remote control software |
|
Difficulty in attacker bypass |
2 |
|
Ease of network implementation |
2 |
|
User impact |
2 |
|
Application transparency |
1 |
|
Maturity of technology |
2 |
|
Ease of management |
1 |
|
Performance |
4 |
|
Scalability |
2 |
|
Financial affordability |
3 |
|
Overall value of technology |
51 |
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.
Continue reading here: Table 43 Radius and TACACS
Was this article helpful?