Risk management - Insider Trading

In 1992, a British bank sent an employee to Singapore to launch and manage its trading operations. The employee engaged in speculative derivatives trading which counted on the Japanese market remaining stable. Unfortunately for him, the Kobe earthquake in 1995 sent the Nikkei into a state of volatility. His risky trades led to $1 billion in losses for the bank.

The employee was Nick Leeson and his actions led to the fire sale of a household name in the British banking industry, Barings Bank, for just 1 GBP in 1995. The problem? Leeson simultaneously held roles as office manager, trader, and IT guy, which allowed him to hide his losses in old error accounts and avoid detection for four years.

Fast forward a decade to 2005. An employee of a global French bank is transferred from a middle-office role in compliance to a front-office role as a trader. In 2007 he begins using a bogus account portfolio to hide risky trades and significantly exceeds his trading limits. In 2008 the bank finally detects the problem but by then the losses exceed $7 billion.

The employee is the now infamous insider Jerome Kerviel who worked for Societe Generale, ranked 43rd on Fortune’s 2008 Global 500 list. The problem? While Kerviel used several ploys such as small trades in high frequency to avoid tripping alert thresholds, the fundamental problem was the same as in the Barings Bank case. Kerviel continued to have access to accounts from his previous role in the compliance and controls division which a trader should never have had.

Both incidents are classic examples of failure to enforce “separation of duties”, a common enabler of insider threats. When it comes to insider threats — or even other cyber threats -- you’ve probably heard over and over, “the clues were in the logs, if only they were picked up!”

Well, often the clues aren’t enough. Consolidation of logs is certainly the first step, but to use those clues and detect separation of duties violations or other insider threats, there are four other important technical challenges that must be addressed:

* Missing user context. Router logs may have shown traffic from Jerome Kerviel’s desktop to a server he was not supposed to access as a trader. However these logs would only contain IP addresses and the same is true for many other sources. To leverage such clues, the source IP address would need to be mapped back to Kerviel as the owner.

* Bridging user identities. As an IT manager Nick Leeson had direct access to backend servers. As a trader he had application accounts. The combination enabled him to create bogus accounts and hide his trades. In this case, accessing logs would only provide partial clues specific to each credential and the underlying application. Simply put, unless you can link log activity from separate credentials to an actual user, many insider threats will go undetected.

* Awareness of roles and privileges.
Logs probably captured Kerviel’s access to old accounts that were never de-provisioned after he transferred into the trading group. However, to detect a separation of duties violation, your log analysis solution would need to contextualize Kerviel’s actions with his current role and the associated privileges. Log analysis solutions must integrate with identity management and directory systems to make this connection.

* Infinite threat scenarios. Compliance folks often suggest that these threats could be stopped through better training and improved processes rather than relying solely on technology. But people, processes and most log analysis solutions (the relevant technology in this case) have limited success in tackling unknown threat patterns. The reality is that for every known insider threat, there are infinite variations. To overcome this limitation, log analysis needs to move past signature-based detection and into pattern-based analysis. Detecting variations and new threats is much easier if you can visualize user activity as patterns rather than in an unending list of log events.

So, as you evaluate solutions that claim to uncover the clues in your logs to curb insider threats, make sure they can connect the clues back to users, identities and roles. Solutions that can tackle those challenges while giving you visibility into user activity patterns and deviations might just prevent the next big insider threat.