Perimeter
8/23/2011
01:28 PM
Adrian Lane
Adrian Lane
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Fraud Detection And DAM

DAM can be used for fraud detection, but you need to review your alerts

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. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web