Copyright © 2012 Splunk, Inc.

Splunk for Banking Fraud DetectionSean White, Sr Information Security Engineer, UMB Bank

Who ARE You?

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

Tl;Dr

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…• 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

* Citation needed…

Customer Success – Bank Makes even MORE $$$ !

6

Customer logo here

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 systemsReport output capable of providing required fieldsAPI allows custom interaction and data gathering routines

Who, What, When…?

Who / What / WhenWhat 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

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

How?

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

Pushing the Data –Secret Sauce, part 2An 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

Results and PerformanceAt 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

The End! (Questions? )

Thank You