* The Complete angler: Phishing and identity
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?
The science of heuristics is deeply ingrained in the work of malware fighters. Heuristics can be thought of, in this context, as a way for software to learn from actions, observations and results. It’s one theory of how humans learn, and it can be applied to software services. I don’t know of anyone yet using this for controlling authorizations and access, but it is an area that could be explored.
Learning opportunity: A few weeks back I pointed you towards Christian Arnold’s “Visual Studio 2005 Toolbox for Windows CardSpace.” I’ve just had a note from Christian letting me know (and, in turn, letting you know) that he’s “…published a little video to show how easy it could be to integrate identity management inside Web applications.” It is an entertaining (well, if you’re a coder) session and it’s certainly informative. Head over and and take a look.
