If you’ve been watching the NEA mailing list lately, you’ve probably seen a rather long thread discussing privacy concerns with NAC technology. While the thread had the usual IETF silliness–and I was unable to resist throwing my own thoughts in as well–it does raise some important points.
With NAC and a single policy domain you have no issues; both the network operator and the client machines themselves are owned by the same entity. So as an example, if FedEx wants to scan a FedEx asset before it connects to the FedEx network, we have no issues. Where the problem comes in is if the network and the machine are owned by different entities. This is common with contractors, vendors, and guests that have their own client machines but are connecting to a network which is controlled by another entity. With contractors this isn’t as big of an issue but for an unaffiliated guest (such as someone attending a training class) it is.
For an extreme example of this, imagine a FedEx machine connecting to the UPS network as a guest: perhaps FedEx is hosting some shipping-industry user-group onsite. The FedEx machine has sensitive FedEx data and configuration information and is controlled by policies defined by FedEx. When it connects to the NAC-enabled UPS network the FedEx machine will be asked to provide client security information to the UPS network. This client security information could include OS patch levels, AV signature levels, registry settings, or the presence or absence of specific data or applications. While this information is being used, in theory, for noble purposes (to evaluate the risk in letting the FedEx asset connect) the check itself is providing the same sort of information that a piece of spyware code might.
Since there are no widely deployed and standards-based NAC solutions, some organizations have deployed NAC interrogation software which relies on downloading a Java or ActiveX applet to the client machine which runs the scan. This could quite understandably violate the security policy of the client machine’s owner. Likewise, without the scan, the network operator’s own security policy may be violated because there is no visibility into the risk level of the connecting asset.
There are two elements in the solution to this problem. First is some ability for the client machine to understand what it is being asked to provide, and who it is being asked to provide it to. This could be done through authorizations in the OS configuration itself or through providing a pop-up to the user informing them that the network the are connecting to is requesting certain information. The key to this disclosure is that it be made by the client machine itself and not some downloadable applet which may not be trusted by the client machine’s owner.
This leads directly to the second element: standards. In order to facilitate this disclosure we need standards for how information is requested and authorized to be sent. NEA can hopefully help here and requirements around these disclosure authorizations are already being explored on the NEA mailing list.
In the meantime, I expect users to comply unknowingly to detailed scans of their systems and that those performing these scans will have good intentions. I don’t see it as unrealistic, though, to expect that malicious forms of this interrogation will be seen in the future. Another short-term option is to not perform client checks on guest systems at all but rather segment them to a partitioned VLAN within the network which runs their traffic through some sort of inline IPS solution. You could still check the guest’s identity at point of connect to enable the segmentation. Then the guest could establish a VPN link to their home network for confidentiality while remote.