Splunk has enabled a large regional bank to collect log data from many disparate systems, normalize the data, and generate reports to meet requirements for a commercial fraud prevention service. The bank can now identify fraud risks, meet audit guidelines, and increase fee revenue from credit card transactions. Splunk aggregates log data, runs searches to extract relevant fields, and uses APIs and custom code to reformat the data and transmit it to the fraud prevention vendor on a scheduled basis. This system processes up to 11 million events per hour and finds 6,000-10,000 potential fraud events during peak periods.

1. Copyright © 2012 Splunk, Inc.
Splunk for Banking
Fraud Detection
Sean White,
Sr Information Security Engineer,
UMB Bank

2. Who ARE You?

3. Sean White – Security Dude
• B.S. in Computer Science from University of Kansas 1994.
• Background in large telecom environments initially as a unix system
administrator and webmaster, SS7 network C&C and performance, engineering
and now information security.
• In the last 15 years, have worked information security for 3 of the top 4 US
wireless carriers (at the time).
• Previously on teams charged with things ranging from incident response, firewall
policy, IDS, vulnerability scanning, anti-virus, web proxy filtering, secure web
content delivery and enterprise unified logging among other things.
• Currently Information Security Engineer for a large regional bank.
• In short, I am awesome. 
3

4. Tl;Dr

5. Use Case: Fraud Analysis / Detection / Prevention
Federal law allows a higher per-transaction fee collection when “fraud
prevention” mechanisms are in place.* IANAB…
• Even a jump from $0.22 to $0.23 per transaction is a >4.5% increase in fee-
based revenue. Yum for that BU!
Also, Fraud Prevention saves banks big .. “bank” by actually preventing
loss. Go figure. Let’s Do That!
Devil in details… * Citation needed…
• Collection from various layers of the stack…
• Collection from disparate application stacks or delivery mechanisms…
• Lots of 3rd party applications don’t log what you wish they would. (Go figure.)
• Time and context correlation is paramount!
• Retention considerations…
5

6. Customer Success – Bank Makes even MORE $$$ !
Splunk has become an enabling
technology for UMB in order to work
with partners to identify and manage
fraud risk and meet expected audit
guidelines, with direct bottom-line
effect.
Log collection able to receive from many disparate systems
Report output capable of providing required fields
Customer logo here API allows custom interaction and data gathering routines
6

7. Who, What, When…?

8. Who / What / When
What and when went together for us:
• Purchased a commercial fraud prevention service and then told to “make it
work.” Typical.
• This service did not perform any log collection or normalization and specified
generic event types, to be formatted in their XML format.
• Everything else left as an exercise for the reader…
• We had to work out our own method of disparate system collection and
aggregation, normalization, and provide some kind of report mechanism
to be able to produce a flow of events, in chronological order and format
them in their XML.
• I said I had heard of a product that might do this…
8

9. Defining Event Types and Fields
• Event types are broken out by various
source systems and all required and
potential fields enumerated.
• Not *all* involved systems’ logs are
collected by Splunk…
• Disclaimer: You will not be able to stop
fraud on your financial network after
seeing this presentation.
• “Log Source” in this context is an
abstract application-level.
9

10. How?

11. Pulling the Data –Secret Sauce, part 1
• This search gets the events, from specific sourcetypes, with added
caching lookups implemented in Python LDAP lookups.
• index=* ( sourcetype="NAM_idp_mfa_guardian" OR sourcetype="was_mfa_guardian" OR sourcetype="WAS_MPT_Guardian" OR sourcetype="WAS_MFAAdmin_Guardian" OR
sourcetype="WAS_ACHCustomer_Guardian" OR sourcetype="guardian_bt_extractor" OR ( ( sourcetype="NAM_AG_reverse" OR sourcetype="NAM_AG_ics_dyn" ) AND
g_eventName=* ) ) | lookup ldapUserLookupPrd cn OUTPUTNEW gcid as umbGcid, uid, guid as umbGuid, userType | lookup ldapUserLookupPrd guid as GUID OUTPUTNEW gcid as
umbGcid, cn, uid, guid as umbGuid, userType | lookup ldapUserLookupPrd guid as oboGuid OUTPUTNEW gcid as oboGcid, uid as oboUid, cn as oboCn, guid as oboGuid, userType as
oboUserType | lookup ldapUserLookupPrd guid as umbGuid OUTPUTNEW gcid as umbGcid, cn, uid, userType | lookup ldapUserLookupPrd cn as uid OUTPUTNEW gcid as umbGcid,
guid as umbGuid, cn, userType | search ( userType="Employee" OR userType="Contractor" OR userType="Vendor" OR userType="Temporary" OR userType="Commercial" ) | eval
eventName=coalesce(eventName,g_eventName,actType) | `guardian_field_filter` | reverse
• That search contains a macro to pull the specific fields:
• guardian_field_filter fields timestamp, eventName, uid, cn, umbGuid, umbGcid, sourceSystem, clientIp, clientUserAgent, clientPersistentId, contactInfoType,
oldEmailAddress, newEmailAddress, mfaOptionType, mfaLockoutType, mfaAuthenticationType, mfaResponseCorrect, activityChannel, accountType, accountNumber, transferType,
destinationType, amount, amountPrenote, destAcctNumber, destAcctRouting, destAcctType, sourceAcctNumber, sourceAcctRouting, fromAcctType, clientDeviceInfo, oboCn, oboGuid,
oboGcid, alertType, alertClass, alertLoadClass, alertEventId, alertRecipients, alertDate, documentType, documentId, searchCriteria, adminType, newName, newAddress, newPhone,
phoneType, roleName, roleDescription, batchId, batchType, bankCode, bankRouting, entryClass, entryDescription, originatingCompany, totalCreditsAmount, totalCredits,
totalDebitsAmount, totalDebits, totalPrenotesAmount, totalPrenotes, totalPrestart, totalExpired, totalHolds, totalZeroDollar, approvalNumber, itemId, itemType, achCompany,
serviceClassCode, transactionType, transactionCode, toCompanyName, toIndividualName, toIndividualId, companyId, companyName, companyFullName, debitAmount,
fromSerialNumber, toSerialNumber, statusDescription, status, errorDescription, totalErrors, totalIssues, totalIssuesAmount, totalRecordCount, totalVoids, checkNumber, ivFlag,
checkMemo, checkPayeeName, checkVoidDate, backOutFlag, childRecordCount, returnDecisions, paidDecisions, updateDecisions, bankReasonCode, clientReasonCode, decision, din,
issueAmount, paidAmount, issueDate, paidDate, processDate, updatedCheckNumber, updatedCheckAmount, adminFlag, userName, userGroup, functionCode, typeCode, actionMode,
entryMethod, restrictionType, restrictionColumn, dependencyColumn1, dependencyColumn2, dependencyColumn3, value1, value2, processOrder, reportId, action, achFileId,
immediateOriginId, totalItemCount, totalBatchCount, splunk_server, index, _cd, userType, oboUserType
11

12. Pushing the Data –Secret Sauce, part 2
An in-house-written java program* connects as an API user to Splunk on
a specified interval.
Runs that hellacious query, paginates and receives the results. Has other
logic to add smarts* (prevent attempt to query for too much data,
prevent multiple queries from running at once, keep state on which
records have / have not been pulled (by time), etc…)
Reformats that data in XML per the vendor’s guidelines* and spits out a
file* which gets transmitted* to the vendor.
* Some complexity omitted for clarity
12

13. Results and Performance
At peak times, we run approx 11 million events per hour. Query results
come to around 6-10,000 events of interest per hour at peak.
Querying for 15 minutes of data takes approx 3 minutes.
13

14. The End!
(Questions? )

15. Thank You