I had a fascinating conversation with SonicWall’s Senior Product Manager Andrew Klein last week. He came to the company through its acquisition of MailFrontier, where he managed the “threat center,” an ominous sounding place but which actually tracks various types of malware (phishing, Trojans, even ordinary spam).

I’d known of MailFrontier because of its “phishing IQ” test (which Network World’s Paul McNamara profiled a while back) and which SonicWall is continuing to support. Try it and see how many phishing documents you can correctly identify.

And, of course, it’s that word “identify” that brought Klein and me together.

He’s always looking for ways to correctly identify phishing attempts - which can be described, of course, as “identity theft” attempts - as well as scams and spam. But he’s also on the lookout for ways to correctly track back the attempts to the perpetrators. In other words, he wants to identify people (the perps), things (the originating sites) and instruments (the actual malware e-mails). He does this through a combination of Bayesian filters, psychological profiles, Internet routing maps and other automated techniques coupled with panels of human investigators who evaluate specifically selected documents as well as randomly selected ones to find new instances of malware.

A lot of the work of these humans, which SonicWall’s programmers try to automate, could be described as context-based investigation. Similar to the context-based access (i.e., authorization) that’s been featured in this newsletter numerous times. Most of the context-based access systems extant are based on sets of rules, created by one or more data security people and enforced at either authentication time or access time – or both. It does require that people consider many possibilities for the potential authentication context (i.e., the Who, Where, When, How and Why of an authentication event) so that the person authenticating can be given the appropriate access – no less and certainly no more. But since we should always err on the side of caution, the rules will tend to be adjusted only when someone is denied access to something they should have, a “false negative” you might say. The “false positives” - people getting access to something they shouldn’t - is reported much more rarely. But couldn’t some antispam and antiphishing practices be applied here?