RSA 2009 - Security Ergonomics & back-office anti-fraud protection techniques

Posted by Gunter Ollmann on March 06, 2009 at 5:52 PM EST.

Over recent months I’ve been giving a number of public talks and having educational discussions with clients concerning the complexities of contemporary security solutions – focusing in on how Web developers have generally failed to understand the users of the applications they produce. In particular, how the emphasis has been on pushing ‘protection’ down to the client-side and delegating the responsibility of ‘security’ to the end user themselves.

Now, before you leap to conclusions that this sounds like a poorly veiled attempt to pimp IPS and deep content inspection, I’ll point out that deployment of those protection technologies within Web environments are more of a symptom of current Web application security inadequacies rather than a one-size-fits-all solution – there are smarter ways of securing a transactional application.

For what it’s worth, I’m going to be speaking on the topic of “Security Ergonomics” at the RSA Conference in San Francisco (Thursday 23rd April at 2:10pm). The long session abstract follows:

Have you ever had to contend with a popup alert message requiring you to "Allow, Disallow or Cancel" something you're trying to do based upon some bothersome security or configuration setting? As engineers and security experts we're capable of making informed decisions about what to do next in these security situations - and we still manage to get it wrong way too often. So why do we blame the average Joe when they make security mistakes? If we're the experts, why are we shifting the security burden to them? Decision alerts like this exist because the 'expert' that wrote the application didn't actually know what to do - and has delegated the responsibility in what could best be called a CYA message.

As we make our applications more sophisticated and feature rich, the security threats and attack vectors keep on mounting. What steps can we take to reduce this threat landscape without delegating more security responsibilities to the users that "just need to the job done"? As we advance forward, we need to take in to account the security ergonomics of the application we design and deploy.

The industry has increasingly shifted the security burden down-stream to the user with elaborate client-side security strategies. With careful consideration, many of these protection strategies can be relocated to backend systems - less vulnerable to tampering, less invasive to the user, and less likely to "false positive" or "false negative". This ergonomic application design strategy will become more crucial as organizations battle newer threats that see their own users and customers becoming the greatest risk to their business continuity.

A premise for some of this discussion is that a sizable percentage of online customers/users are (and will continue to be) infected with malware that makes it difficult to trust the integrity of their transactions. The previous philosophy of trying to secure the customer’s computer (e.g. “here’s a free AV program for you to install” or “here’s a multi-factor authentication token for you to carry”) hasn’t worked – and frankly, today’s malware is smarter and more efficient than most organizations give credit to.

I wrote a short white paper on the topic late last year - "Continuing Business with Malware Infected Customers", and a blog entry too.

While there are many, many aspects to the discussion of Web application security ergonomics, I figured that it would be worthwhile examining a particular example of what I’m talking about. For this blog entry I’ve chosen one that affects most of us – Online banking (something that’ll only skim over with the RSA Conference talk – so there’ll still be lots of new and exciting material concerning other Web application types for San Francisco).

Examining Online Banking

For the last decade I’ve had the opportunity to work with just about all the major international banking and financial services organizations in some capacity, so the analysis and protection advice I’m listing here shouldn’t be ground-breaking for anyone with an ounce of common-sense (and the foresight/budget to implement them).

In general, if you assume that the end user or customer can either be socially engineered (i.e. tricked and deceived) in to handing over authentication and transaction authorization credentials – or that malware already exists on the host that they’re using (which is likely in 25-33% of Internet cases) – then, no matter what you do at the client-side, it can (and will) be defeated. In fact, I’d even go on to argue that each time an organization thinks they have a client-side ‘solution’, what they have instead done is increase the complexity of the application for their customers which actually increases the probable vectors for future compromise and fraud. As such the only real course of action is to migrate as many protection and detection technologies/algorithms to the back-office.

What are some of the techniques that can be used?

1. Look at the HTTP REFERER. The initial inbound connection from the customers Web browser had to have come from somewhere. While it is possible to configure a Web browser to not send the REFERER information, in most cases they don’t (as it will often break a lot of context-aware Web applications). If the REFERER information looks weird or likely to have come from somewhere dangerous, then treat the customers interaction with the Web application as suspicious and place a watch on the account for a week or two.
   Why? In a lot of Phishing fraud cases, a customer will have visited a counterfeit site that steals a copy of their account authentication information (perhaps pretending to “reset their locked account”) and, once captured, automatically redirects the customer’s Web browser to the legitimate Web site. The REFERER URL information can be a vital clue to identifying victims.
2. Track Web browser version information. Each time a customer authenticates themselves to the online application, record their Web browser type and version information. By keeping track of (say) the last 5 logins and their browser type information, it becomes easier to identify anomalies in banking behavior.
   For example, if the customer normally uses Internet Explorer to login, it could be suspicious that they have now switched to Firefox (and later switch back?) – so extra watches on any subsequent transfers that online session could be warranted. Or, if they login with a Web browser that has an earlier version number than previous login’s (e.g. last time they used Internet Explorer 7, but this time they’re using version 6) this would also hint at something strange going on (such as the phisher conducting a fraudulent transfer from their own host).
3. Geographical IP information. GeoIP information is particularly handy. If you’re a US bank, and your customer lives in the US, and normally does their online banking from a DSL connection in Atlanta, then you’re going to be able to tell that from their IP address. If you now see the customer authenticating from an IP address somewhere else (like South Korea), you’ll probably want to take extra care watching what’s happening with any new fund transfers. If you combine this GeoIP information with time/date info of last successful login information – you can further refine any watch conclusions based upon whether it’s physically possible for the customer to have changed geographies.
4. Spam/Phishing Activity Monitoring. By tracking spam and phishing email campaigns targeted at your organizations customers, increases in volume and mail sophistication will typically correlate to increases in fraudulent customer deception. Therefore, as a new campaign kicks off (or volume increases substantially) increased monitoring and vigilance of customer transactions is warranted. This additional transaction monitoring should continue throughout the phishers campaign and 2-5 days after it appears to terminate (since some customers may not check their emails regularly).
5. Transaction Timing. Many of the sophisticated banking Trojans currently in circulation can be detected by monitoring the time delta between new financial transfers in a single authenticated session – as it becomes rather easy to identify an automated fraudulent transfer that may have been inserted by the Trojan software.

The techniques above are not meant to be a comprehensive suite of solutions (I could go on for weeks with tweaks and alternatives – and you’re welcome to reach out to me via email for more detailed discussions on the topic), and each Web application will of course be different. More importantly, they’re not going to be a single silver-bullet in stopping the threat – however, they can provide the vital clues in protecting a customer from becoming a fraud statistic – without having to push ever more complexity down to the customer.

What I’m trying to do is depict a few “better practices” for securing transactional online banking applications and really get developers to think outside of the box… and move away from the “our customers are dumb” kind of mentality which seems to prevail in the Geek world of application design.