Had an opportunity to speak today with Rene Poot at NCP, about how endpoint security “pat-downs” work, using NCP’s Secure Enterprise client, gateway, and management system. This is slightly different from the process employed by other vendors, and quite different from the way an SSL VPN operates…
First, a network administrator creates a policy that stipulates which criteria the connecting must comply with before being permitted a VPN connection. The criteria may include:
- Which operating system versions are being used?
- Which service packs, patches, hot-fixes, etc. are installed?
- Which anti-virus scanner is installed? When was it last run, and what were the results?
This “pat-down” is done during the VPN connection negotiations, and is applied to the connection thereafter. If a machine complies to policy, it is allowed a “full connection” (as specified by the admin); if the connecting client does not comply, the VPN gateway will allow a connection to bes established, however the traffic will be “shunted” off to another section of the network, which will allow the user to pick up what they require (patches, upgrades, etc.) to be able to comply to the set policies.
By running this pat-down, the administrator can still leverage some form of policy enforcement on incoming connections, however, users that comply with policy will enjoy a fully transparent connection to the network’s resources, and users that do not comply will be able to take the necessary steps to reach compliance.
IPsec VPNs generally offer a full fledged ‘LAN emulation’ connection, something a power user will find very nice to use. However, there are instances where administrators will want to restrict what kind of traffic is permitted through the tunnel, and this can be done using firewall rules (enforced by the Administrator on all the traffic) and the Endpoint Security Enforcement outlined above. This gives the administrator very fine grained control over what traffic passes through the tunnel into the internal networks.