Vulnerability scanning NAC - Thats why it is the wrong tool at the wrong time

This weeks Tim Greene NAC newsletter (Tim actually writes the most consistent NAC column there is, thanks Tim!) deals with an age old problem with NAC.  That is the case of the wrong tool at the wrong time.  Tim highlights a recent release of a new version by one of the smaller NAC vendors. The vendor is seeking to make lemonade out of lemons.  Because they use traditional vulnerability testing in place of true NAC policy tests, the testing takes a long time to complete, by their own admission.  Therefore they are advocating letting people on the network and scanning them in the background.  If they fail they can then be dealt with.  Of course this still leaves you open to a user coming on the network and doing something bad before they are discovered.  In the case of this vendor, they say to only do it with "trusted" devices.  That would work if you could say for sure who and what a trusted device is. In today's world there are no trusted devices, same as there are no trusted networks.

The problem with vulnerability scanning is it is hard to do quickly before someone logs onto a network. That is the fundamental problem here and the same with other agent-less tests from other NAC vendors (think used car sales guys).  In certain verticals, such as the edu space they are comfortable with testing a device once a semester or so and not testing again for a few weeks or months. That is a question of what your risk tolerance is though.  Also don't be fooled by millisecond response times.  The clock doesn't start until the vulnerability or malicious behavior is actually detected.  By than it could be too late.

Purpose built NAC products that don't just re-use vulnerability scanners provide superior solutions to this problem and should be what you look for.