Fraud Detection And DAM

FINRA recently fined Citigroup $500,000 for failing to supervise a sales associate who misappropriated customer funds. From the details provided, it sounds like Citigroup had evidence of the attack and just failed to take notice.

But the point here is not to discuss blame, but clarify some misconceptions about how software is commonly used to detect this type of fraud, and address some of the comments make in Ericka Chickowski article on database controls. There have been notable cases -- such as Global Crossing -- where fraud was detected by database monitoring and auditing, but it requires special considerations on how it is implemented.

1. Database Activity Monitoring platforms don't monitor across databases.

It's not that they can't, it's that they are not usually set up that way. It is difficult to create fraud detection policies because there are so many different ways to commit fraud. And effective policies require cross-database monitoring, which carries a performance penalty due to the way data is stored and policies checked. Note that Citigroup has an effective database activity monitoring platform in place; they have for many years. It monitors intra-database security and compliance checks according to the defined audit, security, and operations policies. But the type of fraud being described cannot commonly be detected with intra-database analysis: multi-database analysis is needed. And it requires several months of transactional data be available in order to check for anomalous transactions.

Inter-database fraud detection requires polices linking specific transaction types together, and to audit stored events over a window of time. Most DAM customers deploy as real-time statement level analysis, not auditing and not to provide referential integrity-checking. Once again, DAM can provide this type of analysis, but there are usually other fraud detection systems in place to detect cross-system anomalies, or customers dump database logs to SIEM systems for correlation and audit reports.

2. Identity is not particularly important with DAM.

That may sound heretical, but the fact is most database queries come over services accounts, and user identity is anonymized at the application layer. Yes, there are many methods to add identity to queries, and tools to attach a federated identity to database access. But a principle use of DAM is to detect malicious queries, so the tool looks for specific attack patterns in the FROM and WHERE clauses. For attribute based detection --- who, which database, time of day, application, etc. -- the user identity is not all that important when you don't care if it is a malicious insider or a hacker who hijacked an account.

You simply need to recognize and stop bad queries regardless of who the actual user is. Customer demand for real-time user identification has historically been low, and is viewed as important forensic investigations, not real-time analysis.

3. Internal audit may not use security tools.

They may use some of the data DAM and SIEM product, and they may even help define the policies for controls and quarterly reports, but they don't actively use databases and security tools. My experience with internal auditors and external auditors from the big four is they use tools they are comfortable with. I most commonly witnessed auditors using Excel spreadsheets and custom macros to root around event data looking for anything weird or unexplained. It's surprising how effective a simple spreadsheet can be for quickly identifying outliers.

Remember, not matter what the tool, it's only as effective as the person who reviews the output. The low-and-slow fraud described by FINRA is difficult to detect, but if you don't diligently review logs and alerts, you're never going to catch it.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.