False Positives – Bane to Users and Admins Alike
Ever see an old friend on the street you haven’t seen for a while? You call out or approach the individual only to find you were mistaken. That’s a classic example of “false positive” in our day-to-day lives, and the same thing happens in our technical lives. How often have you found an email from a legitimate contact sitting idly in your SPAM folder?
With regards to security software, false positives create ambiguity that is confusing in its most benign form and dangerous in its most malevolent. It creates more work for administrators who must determine if a legitimate user made an access attempt. At a minimum, it is inconvenient for the end-user who is either required to take additional steps to authenticate or is blocked from access altogether. When legitimate, how does the administrator allow the user access this particular time and prevent the false positive in the future? Changing rules can result in fewer false positives, but could this open their environment to other genuine threats? When malicious, the admin is grateful their software has done its job and move on to determining the scope of the attack.
There are grey areas – nothing is purely black and white; although, this is ultimately the realm in which computers must operate. They do their best to approximate other models using concepts like fuzzy logic, but yesterday’s walled garden has been replaced with intrepid, data hungry users with a multitude of access scenarios.
PortalGuard’s PassiveKey can help eliminate false positives. It is a one-time passcode implementation where users do a one-time enrollment after install and from that point forward, their browser requests contain an HTTP session cookie that helps uniquely identify them to PortalGuard. Using other server-based approaches like IP geolocation or time of day access can still result in false positives. According to WhatIsMyIPAddress.com, even the user’s country can still have up to a 5% margin of error – completely unacceptable! With PassiveKey, no matter where the user goes, the identifying cookie will be automatically generated and sent to help identify them – grey areas need not apply.