Confidentiality and Security Are Not the Same

Summary

This chapter supplies some sample networks that have somewhat unique security needs. Each design results in topologies with nontrivial differences when compared to the basic designs shown in Chapters 13 through 15.

In the NetGamesRUs design, you saw two things. First, the basic Internet edge design can be modified to suit specific application needs (in this case, the management of the game servers). You also learned that internal security is less critical in small organizations with a high degree of trust among the different users.

In the University of Insecurity design, you saw how the network changes when traditional assumptions about campus network trust go away. UI needed to treat the main campus network almost as untrusted as the Internet at large. By creating "islands of trust" with critical systems, and security monitoring for the network as a whole, the functionality of the network remains high without risking the security of critical systems as defined in the security requirements.

Finally, you saw how the criticality of some data is so great that nothing less than complete physical separation between different trust boundaries is necessary. Although I expect networks like BHR's to be rare, it is helpful to understand what an ultrasecure environment might look like. BHR's secure network also utilizes emerging security technologies (smart cards, system-wide cryptographic protections, and so on) that are not yet manageable to deploy widely on larger networks. If you assume that the scalability and management of these technologies will eventually improve, you can use BHR as an example to see how your own network might evolve to take advantage of some of these techniques.

By examining case studies and working through security requirements and design options, you can hone your security design skills and help ensure that when it comes time to rework a network under your control, you've thought through most of the major issues. Be careful, though; case studies are helpful, but because they don't result in actual implementation changes on real networks, they are no substitute for actual design and implementation experience.