Server and Domain Isolation vs NAC

When discussing network access control (NAC) products with customers, we usually define two clear goals. Firstly, ensure that all devices accessing the network are compliant with a set of policies defined by the administrator – and secondly, ensure that any unknown devices are prevented from communicating with those that are known.

Assessing known machines is usually relatively straight forward. We can use installed or web-based agents to ensure that these machines comply with our standards (are patched, have Anti-Virus etc), but how do we isolate other devices?

DHCP enforcement is great, and does a very good job of preventing the majority of unauthorised devices from obtaining an IP address. This is mainly because most unauthorised access is not malicious, and in fact is more likely to be a staff member/contractor/visitor innocently connecting to your network, and generally they’ll be configured to use DHCP.

The obvious problem with DHCP enforcement is that we’re assuming that all devices will request an IP address from our corporate DHCP server. So what if they don’t?

802.1x enforcement is one potential answer, and is a very effective way of protecting your network from unknown devices. There are a few complications with 802.1x though, which can often make administrators reluctant to go down this road. Obviously all switches must support the technology in the first place, and even when they do will need to be configured. This can seem quite daunting, especially to smaller businesses, and it’s often the case that 802.1x enforcement is placed on the “to do list”. Another way of dealing with this issue is to implement “Server and Domain Isolation” (SDI).

SDI is the term Microsoft use to describe the use of IPSec policies deployed via Active Directory. By assigning IPSec policies to your domain, you can create a barrier between members of your domain and all other devices.

When two devices on your domain wish to communicate, they first authenticate and all packets transferred between them are encrypted. When a non-domain member tries to initiate communication with domain members, the authentication fails and your domain member is protected. IPSec policies can be flexible enough to allow unsecured connections where necessary, and define different requirements for different network segments and devices.

I should stress, SDI is not a new technology and is not a security silver bullet. SDI provides a logical barrier between your trusted network and everything else, but of course it’s just as important to ensure that devices on the trusted network comply with the relevant security policies. This is where endpoint assessment comes into its own, and why combining technologies like SDI with NAC can be an incredibly efficient way of securing your network.

Microsoft have a few interesting whitepapers explaining SDI in more detail, which I’ve linked to below. For anyone interested in playing with SDI, Microsoft have also provided an excellent downloadable demo environment which I strongly recommend taking a look at.

As always, Microsoft themselves have demonstrated their total confidence in a solution by implementing it on their own network. They’ve also provided a comprehensive explanation of how they deployed SDI, which is well worth a read: http://technet.microsoft.com/en-us/library/bb735174.aspx

The video demo below is a brief demo of SDI in action. Initially SDI is not enabled, and a packet capture with Wireshark clearly shows clear text packets. Once SDI is enabled, IPSec policies encrypt all packets and the Wireshark capture shows only ESP (Encapsulating Security Payload) packets.


http://www.youtube.com/watch?v=nXhfEaUPZSI

Server Isolation Explained: Click
Domain Isolation Explained: Click
Demo Environment: Click

If you'd like to discuss SDI with us please leave a comment or get in touch via the normal routes (http://www.foursys.co.uk/)