The biggest issue with most remote user validation designs revolves around trust - with quarantine-type scenarios, you are relying on the client to tell you it's running a valid configuration. For example, Microsoft's Quarantine feature centers around a client-executed script that verifies config settings (e.g. DAT files, patch levels - it's pretty customizable). Of course, this idea of trusting the data source is an issue in many client-side attempts at security (think JavaScript input validation). Also, I don't think this problem is as easily solvable because you can't rely on traditional tools like PKI and certs to prove client integrity, since an attacker could have complete control of the client that is being validated (and any private keys could have been compromised). So, I generally see these tools as being able to verify the configuration of a friendly (uncompromised) client. This alone solves many problems associated with remote access security. However, these solutions fail to address the problem of compromised systems remotely accessing the network. Thus, the problem of rampant and automated malicious code (e.g. worms, Blaster, virii) entering the network via remote access is mostly addressed, but the issue of a directed attacker (with compromised credentials/system) entering your network (to steal IP, further ransack systems, etc.) is not solved (not that this is a trivial problem). Plus, the problems of platform compatibility and unmanaged clients raised by Derek and Joe are still issues. Jason
This archive was generated by hypermail 2b30 : Fri Mar 05 2004 - 17:40:07 PST