.NODE

Strive for Operational Simplicity

Network designers make decisions regarding operational complexity every day. Most don't call it that, though; they tend to think along the lines of the difficulty and burden that specific technology places on administrators or users. This section gets to a key aspect of your network security system: achieving operational simplicity can mean the difference between a security system that works for you and a security system that you work for.

Some hard and soft metrics to measure your system include the following:

  • How many INFOSEC engineers does it take to maintain the system?
  • When tensions are elevated when you are under real attack, how easy is it for a security operator to make a mistake?
  • When searching for attack details, how much logging data must you sift through to find the pertinent information?
  • When turning over forensic evidence to law enforcement, how easy is it to collate the relevant information?

Don't take the notion of operational simplicity too far, however. For example, operational simplicity is often not improved by topological simplicity. I've heard designers associate topological simplicity with such terms as "elegance." Unfortunately, as any fashion designer will tell you, elegance often flies right in the face of utility, which is a critical aspect of any security system. If you can't respond to the threats you encounter in an easy and obvious way, any amount of "elegance" you achieve through topological simplicity is meaningless.

As an example, let's look at the traditional design of Internet edges. I've seen many network edges that resemble the network shown in Figure 1-4.

Figure 1-4. Traditional Internet Edge Design

Often the network edge looks this way not because it was the best way to design the network, but because the company's security policy dictated that all traffic flow through a single "choke point." Although the design is topologically simple, it has lots of problems. The one on which I focus in this discussion is the potential for human error, or operational complexity. Human error is one of the biggest root causes of configuration problems, especially at 2 a.m. when security administrators find themselves troubleshooting an issue.

Although the design shown in Figure 1-4 might seem simple, in fact it is needlessly difficult because of its operational complexity. The configuration on the firewall and attached switch in this example are so complex and prone to operator error that the slightest mistake causes the entire security deployment to be compromised.

To remedy this problem, create a network that at first glance introduces much more topological complexity, as shown in Figure 1-5.

Figure 1-5. Design with Operational Simplicity

The topology in Figure 1-5 shows an implementation that is easy to understand and much harder to misconfigure. Although it has more devices and doesn't look as "elegant" as the previous example in Figure 1-4, the paths of communication and the insecure and secure parts of the network are much more apparent and securely segmented. In this amended design, outbound Internet access is handled by one firewall, and inbound virtual private network (VPN) access is handled by another firewall with a VPN device. In addition, separate L2 switches are deployed as opposed to relying on a single switch with multiple VLANs. In the heat of the moment, the access rules and potential configuration changes are much simpler.

To ensure operational simplicity, you must constantly evaluate the level of complexity you are comfortable with to ensure that your security is both simple to deploy and straightforward to maintain. Throughout this book, I offer many alternate designs for secure network architectures. Although often some level of topological complexity is introduced to solve a particularly hard problem, all the designs strive toward simplicity of planning, design, implementation, and, most important, operation.

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

show all menu





Network Security Architectures
Network Security Architectures
ISBN: 158705115X
EAN: 2147483647
Year: 2006
Pages: 249
Authors: Sean Convery
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net