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

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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7407
Published: 2014-10-22
Cross-site request forgery (CSRF) vulnerability in the MRBS module for Drupal allows remote attackers to hijack the authentication of unspecified victims via unknown vectors.

CVE-2014-3675
Published: 2014-10-22
Shim allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted DHCPv6 packet.

CVE-2014-3676
Published: 2014-10-22
Heap-based buffer overflow in Shim allows remote attackers to execute arbitrary code via a crafted IPv6 address, related to the "tftp:// DHCPv6 boot option."

CVE-2014-3677
Published: 2014-10-22
Unspecified vulnerability in Shim might allow attackers to execute arbitrary code via a crafted MOK list, which triggers memory corruption.

CVE-2014-3828
Published: 2014-10-22
Multiple SQL injection vulnerabilities in Centreon 2.5.1 and Centreon Enterprise Server 2.2 allow remote attackers to execute arbitrary SQL commands via (1) the index_id parameter to views/graphs/common/makeXML_ListMetrics.php, (2) the sid parameter to views/graphs/GetXmlTree.php, (3) the session_id...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.