Server and Domain Isolation

Some years ago I discovered a product called Magic Shell--an ice cream topping that's a liquid when you pour it on ice cream but quickly hardens when it contacts the cold ice cream. The result is a crunchy chocolate shell that covers the soft ice cream center. The IT world co-opted the term magic shell to refer to networks in which all the protective measures are on the outside or perimeter.

Back in the old days, when all companies had to work with were mainframes, network access control wasn't a major concern because the only way to access computers was to enter a large, cold, glass-walled data center and sit down in front of a terminal. Things have certainly changed in the intervening 20 or 30 years, however; during the past 5 years or so, most network access control has crystallized around the use of firewalls.

Obviously, you can use firewalls to protect internal networks from outside attacks; they are also sometimes used to separate segments of internal networks. But using firewalls for internal network segmentation doesn't always work smoothly, as a detailed Microsoft white paper (see the URL below) about how to make Active Directory (AD) replication work properly across firewalls shows.
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerWhitepapers/C48C97E8-1C7B-4584-BC0D-59017DEEBE8A.mspx

Microsoft's Steve Riley advocates a sea change; his thesis is that the days of magic shell protective measures are nearing an end. Instead of depending solely on firewalls, modern networks need better protective measures to guard against attacks inside the perimeter. These attacks might come from malicious employees, compromised PCs running spyware or malware, or attackers who subvert other protective measures--including firewalls--to get to the soft, creamy center of the network.

A key component in this new world is the ability to enforce network security policies. Cisco and Microsoft are working toward delivering a comprehensive network access protection capability; in the meantime both companies advocate server and domain isolation techniques that use the IPsec extension set. These techniques use IPsec to segregate trusted machines into their own enclaves; trusted machines can always talk to each other, but machines that aren't trusted might be limited in the protocols and ports they can use or might not be able to communicate with trusted machines at all.

These changes obviously have big implications for Exchange. Where do your Exchange servers fit into a protected network? Which classes of machines and users should be able to access them, and what network policies should you apply to get those access controls into place? What about the all-important communication between Exchange and the domain controllers (DCs) and Global Catalogs (GCs) it uses? What about communication between front-end and back-end servers? These questions aren't trivial because their answers determine how well your Exchange servers work in an environment that has beefed-up security.

Next week I'll discuss what server and domain isolation means for Exchange and how you can start preparing to provide better Exchange security through the judicious use of IPsec. In the meantime, Microsoft's Web site contains many documents that cover server and network isolation and IPsec. I recommend that you look through them to get a feel for what server and domain isolation looks like from a design perspective.