Intelligent Information Security

Selecting the Right Fraud Event Management Solution By Jeff Goldenberg, CISSP, ISSAP, CSSLP – Security & Fraud Prevention Architect – AsTech Consulting

There are many different tools available to help manage the growing Internet based fraud problem. This paper will help differentiate various current options and explain the key components and desired features to be aware of when selecting a solution that is most appropriate for your organization.

AsTech Consulting, Inc. 71 Stevenson St., Suite 1425 San Francisco, CA 94105 Telephone: 415.291.9911 Toll Free: 888.777.5995 www.astechconsulting.com

August 2012

__________________________________________________________________________________________________

Selecting the Right Fraud Event Management Solution By Jeff Goldenberg, CISSP, ISSAP, CSSLP Security & Fraud Prevention Architect AsTech Consulting

There are many different tools available to help manage the growing Internet-based fraud problem. This paper will help differentiate various current options and explain the key components and desired features to be aware of when selecting a solution that is most appropriate for your organization.

Introduction Online fraud is not a problem that is going to go away any time soon. According to the Cybersource 2012 Online Fraud Report1, after trending downwards from 2008 through 2010, 2011 showed an increase of 21% up to $3.4B in online fraud losses from $2.7B in 2010. Finding the right solution for your needs can be difficult since many vendors claim to be the only solution needed to detect and prevent fraud. Unfortunately, there is no single solution to completely stop fraud. To come as close as possible to reducing your fraud rate to zero, you will need to employ a combination of the most appropriate aspects of multiple solutions. Before selecting any

There are a significant number of products and services currently on the market being described as:     

solution, you must be aware of and understand

“fraud detection” “fraud prevention” “fraud analytics” “transaction anomaly detection” “fraud management”

at least the main types of fraud you are facing.

While some of these solutions have been around for years, others have appeared only recently. In recent years there has been some consolidation in this solution space, and there are new solutions entering the market as awareness (and losses) increases. Before selecting any solution, you must be aware of and understand at least the main types of fraud you are facing. For some entities this will be relatively straightforward. For example, consider an e-commerce web site that only sells physical goods. The types of fraud that can be performed are much more limited than for a company that operates in a wider variety of business verticals. Financial services companies that offer banking,

1

http://forms.cybersource.com/forms/NAFRDQ12012whitepaperFraudReport2012CYBSwww2012

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

1

__________________________________________________________________________________________________ money transfers, credit card processing, and payroll services to small businesses face much more extensive and complex fraud scenarios. It is important to note that effective fraud management cannot typically be achieved with a single technology solution. Fraud management must be seen as a program, which consists of multiple technology solutions, processes, and training for both customers & employees. Even at the technology level, a multi-layered approach should be followed. Different types of technical solutions all contribute to effective fraud management, such as strong authentication, customer protection, good web application security, logging and monitoring, incident management, and what we at AsTech call Fraud Event Management. This paper focuses on tools applicable to managing fraud events. These tools are systems that detect and/or prevent fraud by analyzing transaction event data. Events may be analyzed in real-time (application flow stops until event data is analyzed) or in near-real time as soon as the event is recorded and transmitted to the fraud system.

Effective fraud management cannot typically be achieved with a single technology solution. Fraud Management must be seen as a program

Fraud event management solutions consist of multiple components that work together to deliver a comprehensive solution. The following component diagram depicts the key components in a best-of-breed solution:

Figure 1 – Key Components of a Fraud Event Management Solution

The following sections will discuss the key components depicted above. Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

2

__________________________________________________________________________________________________

Types of Fraud Event Management Tools For the sake of this paper, Fraud Event Management solutions will be broken into two categories: detection and prevention. Fraud detection solutions are only capable of detecting when something fraudulent has occurred or is about to occur. They will not prevent the fraud from occurring. The result of a detection system is usually the creation of an alert that must be handled by a human analyst. A prevention system can take action to prevent the fraud from occurring. Detection systems tend to be easier to integrate in that they monitor a data stream such as a log file, web traffic, a message queue, or a database. Any data that the application exports can be monitored and analyzed without having to change the application’s code. For this reason, both types of solutions are often employed.

Why bother with a detection solution when a prevention system can be used?

First, solutions that can prevent fraudulent transactions require programmatic integration with the application at every transaction point.

Second, false negatives (rejected

Detection Methods

transactions) create a negative user experience

and are bad for business (lost sales). For fraud detection systems to work, they need data. Different tools have varying requirements or capabilities in how they can obtain the necessary data. Some distinct approaches include: log files, message queues, database tables, web/network traffic, and direct integration into the application (via API or web services).

For solutions that rely on logs, the system should be able to source events from at minimum any type of log file, including custom formats from in-house-developed applications, and at best from a variety of other sources as well (databases, message queues, etc.). Some fraud detection solutions that rely on logs have evolved from (or are simply repurposed) security products such as log collectors and SIEM (Security Information and Event Management) tools. This works well as long as the product is capable of parsing custom log formats. Many SIEM products are designed to only work with common log formats as well as popular commercial and open-source products. A “fraud SIEM” can definitely benefit from automatically being able to make sense of such event logs, but it must also be able to parse custom application logs as this is usually where virtually all fraud-relevant event data will be found. It is important to note that not all standard SIEMs can parse custom logs. This is a critical capability for the “must-have” feature list when selecting a product.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

3

__________________________________________________________________________________________________

A “fraud SIEM” must be able to parse custom application logs as this is usually where virtually all fraud-relevant event data will be found. It is important to note that not all standard SIEMs can parse custom logs. This

Sourcing data from event logs is usually the easiest method to implement because the logs already exist and little to no development is required by the application owner. Minor development or reconfiguration may be necessary to enhance existing logging capabilities or enable logging of events that are not currently being logged. Obtaining event data from message queues and database tables takes a bit more effort. Some system integration work is usually required (setting up listening ports, configuring credentials, installing MQ or SQL clients, etc.), but typically no application modification is necessary. Other solutions work by obtaining the data via API integration. With this method, the application producing the event must be modified so that it actually sends the event programmatically to the event detection system.

is a critical capability for Finally, solutions exist that detect fraud by analyzing all of the communication traffic between end-users and the application, typically web list when selecting a browsers and web servers. These solutions involve decrypting the encrypted product. session by providing the solution with a copy of the server’s TLS (SSL) keys so that the solution can see the traffic that is supposed to be secret between the browser and the server. This approach can also be used to monitor traffic between applications and databases or even between two applications.

the “must-have” feature

The following diagram is a very high level component architecture for a fraud detection system. All of the key components listed previously are depicted. All other elements portrayed are described in the upcoming sections. For comparison, the corresponding high level component architecture diagram for a fraud prevention system will be shown in the Interdiction section.

Figure 2 - Fraud Detection System High Level Architecture

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

4

__________________________________________________________________________________________________

Pre-Filtering To improve performance and reduce the amount of disk space used by the tool to store events, it is sometimes necessary to filter the raw events being imported into the Fraud Event Management system. This is particularly true of deployments that receive their data from log files. It is common to start by importing all events and to later filter out unnecessary events as part of costcutting measures as storage requirements increase. Having all fraud-relevant logs delivered to Applications typically don’t have separate log files one centralized log repository can make that contain only fraud-relevant events. Some event integration with a fraud event detection logs may use category markers such as “security” or system much easier. Furthermore, some “transaction” to help identify events of a certain type, but it is highly unlikely you will encounter a “fraud” products are licensed by the number of category. Also, events useful for fraud detection will event sources being monitored. With the typically span multiple categories. Often times the single event repository approach, one application will write all events to a single log file or could argue that there is only one event event table in a database. By analyzing the event catalog (or whatever documentation exists) for an source. application it should not be too difficult to determine which events are of value for fraud detection. The Fraud Event Management system should then be configured to only import the identified fraud-relevant events. If performance and disk space are not primary concerns, importing all events provides maximum visibility. However, since it is likely to be a concern at some point, one should make certain the selected solution supports custom filters for event importing. Some solutions offer limited or no filtering. Some products are licensed based on events processed in a given time frame, so not importing events that are of no use will Some products are help lower cost of ownership when such licensing is in play. licensed based on events processed in a given

Centralized Log Repository

time frame, so not Although not a pre-requisite for fraud event analysis, having all importing events that are fraud-relevant logs delivered to one centralized log repository can make integration with a fraud event detection system much easier. of no use will help lower Especially if the applications producing events are situated in a cost of ownership when different network than where the fraud management system is. such licensing is in play. Instead of potentially having to create multiple firewall rules to route from one network to another, there could be a single route from the log repository to the fraud management system. This makes on-boarding new event sources easier since their events are all obtained from the same location.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

5

__________________________________________________________________________________________________ Furthermore, some products are licensed by the number of event sources being monitored. With the single event repository approach, one could argue that there is only one event source. Mileage may vary on using this argument with different vendors.

Interdiction Interdiction is a term frequently used with fraud prevention solutions (even when they are only implemented in detective mode). As previously mentioned, for fraud prevention systems to work they must be able to interact in real-time with end-user, transaction, authentication, and possibly other applications. This interaction is usually done via a programmatic API or web service. The fraud prevention system interdicts or prevents the transaction from being completed until it has reviewed and approved it. Essentially, this process requires that calls to the fraud prevention system be inserted into the logic flow for a given transaction (including authentication) after the user executes the transaction but before it is approved/committed. The application sends all pertinent data about the transaction and waits for a response from the fraud prevention system, which will typically be along the lines of “approved”, “blocked”, “challenge”, or “hold”. Pertinent data includes not only information about the specific transaction being attempted, for example, “transfer $10,000 to John Doe”, but also includes all available authentication and session data for the user attempting the transaction (PC profile cookie, browser headers, IP address, whether 2-factor authentication has been performed or if the user is enrolled in such a service, etc.). An “Approved” response means the transaction can be completed with no additional action required. “Blocked” means the transaction is denied and no recourse is provided to the user to continue. This type of response is typically delivered when the fraud prevention system is certain the attempted transaction is fraudulent. Attempts to log in from blacklisted countries, IPs or devices will often prompt this response. “Challenge” means the transaction is considered risky, probably because there is a low level of confidence that the user is who they claim to be (perhaps they are logging in from a new PC and new location). This response instructs the application to perform supplemental authentication and then to resubmit the request again with the result of the extra level of authentication. The supplemental authentication (2-factor token, out-of-band one-time-password, challenge questions, etc.) may be integrated with or offered as part of the fraud prevention solution or may be a completely separate service. When packaged together with a fraud prevention product, the terms Adaptive Authentication or Risk-based Authentication are frequently used. The fraud prevention system itself will typically not invoke the extra authentication challenge - the application must make the call. Finally, the “Hold” response may be used when the transaction looks suspicious and is best reviewed by a human analyst. In this case, the relying application may indicate to the user that the transaction is being held for review, or not.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

6

__________________________________________________________________________________________________ The following 3 diagrams provide some insight into how interdicting fraud prevention systems work, beginning with an overview of the major components of a typical fraud prevention system with interdiction capabilities.

Figure 3 - Internet Fraud Prevention System with Interdiction Capabilities

Compare this diagram with the one of the fraud detection system in Figure 2. Note that the individual components of the Fraud Prevention package are (potentially, not every implementation will have all of these features) the same, but the components between the application and the Fraud Prevention system differ. Note as well that data only travels one way between the application and the Fraud Detection system, whereas communication is bidirectional with a Fraud Prevention system. The following activity diagram illustrates some typical flows through an online business banking application without any fraud prevention interdiction:

Figure 4 - Sample Online Banking Application Without Fraud Prevention Interdiction

The next activity diagram shows the same application with fraud prevention interdiction points integrated:

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

7

__________________________________________________________________________________________________

Figure 5 - Online Banking Application with Fraud Prevention Interdiction

Note that now, after login but before the system will even show the account summary, there is a check done with the fraud prevention system to determine if there is a high enough level of confidence in the user being who they say they are. This is an evaluation of “authentication risk”. The application will transmit all authentication-relevant data (which may include current IP address, browser headers, a device fingerprint, and more) to the fraud prevention system for evaluation. If the fraud system does not find a high enough degree of certainty about the user, it invokes (directly or through the application, depending on implementations) a second or supplemental authentication process. This may be a 2-factor token challenge, challenge questions or something else. If the system is satisfied with the outcome of this extra authentication step, the user is allowed to proceed to the account summary page. Otherwise, they are blocked (probably logged out with a message telling them to call customer service) and an alert may be generated.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

8

__________________________________________________________________________________________________

If the customer makes it to the point in the application where they can perform a money movement transaction (conveniently from the account summary page in our sample application), before the transaction is approved, it is evaluated by the fraud prevention system for “transaction risk”. All relevant details about the transaction are transmitted to the fraud prevention system. The system will then analyze the data using rules, models, and possibly prior customer history to determine if the risk level of the transaction is within acceptable limits. If so, the transaction will be processed. If not, it will be blocked, either absolutely or possibly put in a pending state to be reviewed by an analyst. An alert will likely be created. The user may or may not be provided with a message indicating the blocked or held status.

User Rules A good Fraud Management solution should allow the user/owner to create custom rules. Most do, but there are some systems where rules can only be implemented by the vendor. The best solutions provide a user-friendly, intuitive, graphical user interface for rules definition. In these systems, A good Fraud Event Management rules can be created by selecting operators and data elements that can also be moved around and combined by mousesolution should allow the dragging. user/owner to create custom

rules. The best solutions provide a user-friendly, intuitive, graphical user interface for rules definition. The rule creation language should be natural language, typically English, and should not require custom or difficult to understand syntax for most operations.

The rule creation language should be natural, typically English, and should not require custom or difficult to understand syntax (i.e., regular expressions) for most operations. The best systems support a rich set of Boolean operators (such as AND, OR, NOT, and parentheses) and advanced matching functions (such as Time, Day, IP-Country, etc.) for creating rules. The rules engine should be able to evaluate text fields with operators such as “is” and “contains”. Numerical values should be able to be evaluated with operators such as “=, , >=, $2000 More than 2 payments within 24 hours to a new payee

Score +100 +200 +500 +10 +100 +100 +200 +100

+200 +500 +200 +250

Figure 6 - Example Partial Risk Scoring Model

Let’s say a legitimate American customer of the bank is on vacation in Italy (not a country of concern) and they access their online banking account from their own laptop in a hotel. They pay their credit card and electric bill to known payees. They will trigger the following rules:   

Access from outside home country (+100) Access from new IP address (+10) Access from new ISP (+100)

Their total risk score for the bill pay transaction is 210. Since the pre-determined threshold for alerting is 500, no alert would be created and no investigation would ensue. Now assume the customer on vacation leaves their laptop in their hotel room along with the login information to their banking account. An unscrupulous member of the cleaning staff notices this and decides to steal from the guest. They aren’t that greedy and decide to only steal $100, hoping it will go unnoticed and unreported. When they login to the victim’s bank account and transfer $100 to their account, they will trigger the following rules:   

Access from outside home country (+100) Bill pay or funds transfer to a new unknown payee (+100) Bill pay or funds transfer to a foreign country (+200)

This totals 400. When the fraudster doesn’t detect anything having gone wrong or been detected, they decide to return for an additional payment of $1000. This triggers the following rules: Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

11

__________________________________________________________________________________________________    

Access from outside home country (+100) Bill pay or funds transfer to a new unknown payee (+100) Bill pay or funds transfer to a foreign country (+200) More than 2 payments within 24 hours to a new payee (+250)

Which total 650. This sequence of events should create an alert and an investigation should be triggered. None of these individual events or triggering of rules indicate fraud, but the combination of enough of them likely indicate something undesired is happening and should be investigated. This combination of events is sometimes known as aggregation or correlation. While these terms are technically correct, when it comes to fraud detection, correlation typically has a slightly different meaning.

Correlation Sometimes a single logical event is systematically made up of multiple log events. Furthermore, the separate application events needed to reconstruct the single logical event may exist in different log files and may be in completely different formats. The act of locating, parsing and combing all of these disparate events into a single logical event is known as correlation. Fraud event management systems must be able to perform correlation.

Pattern & Anomaly Detection Writing rules to look for specific events, using a cumulative risk scoring model to better assess transaction risk, and correlating events are all necessary tools for managing fraud. Another great capability to have is the ability to detect patterns and anomalies, both for a single customer and across a group of customers or even the whole customer base. Fraudsters often script their attacks, to maximize their take in a Anomalies in customer minimal amount of time. Such scripts frequently produce behavior are sometimes the patterns, even if they are too subtle to be detected by human analysis.

only clue to fraudulent

Anomalies in customer behavior are sometimes the only clue to fraudulent activity, especially if the victim’s computer has been compromised and the fraudster is using it to commit fraud. All authentication checks will pass. Consider a business banking customer who normally only performs 2 wire transfers a month that has just performed 5 transfers today. That is abnormal behavior and should be flagged as an anomaly with a high alert. The customer should probably be contacted immediately to determine if the transactions are fraudulent or not. Selecting the Right Fraud Event Management Solution

activity, especially if the

victim’s computer has been compromised and the fraudster is using it to commit fraud.

© 2012 AsTech Consulting. All Rights Reserved.

12

__________________________________________________________________________________________________

Visual Analysis & Data Representation While not necessarily critical to detecting fraud, strong visual analysis capabilities can be a truly useful feature of a Fraud Event Management platform. A capable solution should include a variety of meaningful, easy to understand graphical dashboards for reporting on the current period and state, and reports for reporting on past periods and states. Ideally the dashboards and reports should be completely and easily customizable by the endusers. This single feature can distinguish the best solutions from the contenders. Visual representation of Visual representation of event data can often be used to spot issues, patterns an anomalies that have not been addressed by a pre-defined rule. The following is an example of visual link analysis from a fraud detection system. It illustrates 5 rules being triggered across 4 different applications (and 3 different business units) by a single IP address. The triggering of any one of these rules by a single IP address probably is not a strong indicator of fraud, but the single IP address causing 5 rules to trigger in different applications certainly merits investigation.

event data can often be used to spot issues, patterns and anomalies that have not been addressed by a pre-defined rule.

Figure 7 - Example of Visual Link Analysis

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

13

__________________________________________________________________________________________________

Case Management Effective fraud management requires good case management. A system capable of storing and organizing all of the data supplied by both systems and people related to a particular case is very useful. The system should include some basic workflow capability if more than one person may ever work a case. The system should also include adequate authentication and authorization controls, as well as audit logging, time stamping, and the possibility to encrypt all or selective parts of its data store. It is very likely that at least some of the data contained within a fraud case management will be sensitive in nature and must be adequately protected. If law enforcement ever needs to get involved, the security controls listed above are a must. Most fraud detection and prevention products have some sort of built-in case management. In some cases the functionality is very complete. In others it is very primitive. Since in most large environments there will be more than one fraud management tool in use (and there is likely already a robust, standalone case management system) it is usually desirable for the Fraud Event Management system to be able to automatically export cases to other case management systems. If there are 3 different fraud management products in use, a fraud analyst should not have to look at 3 different cases in 3 different systems when he could be looking at a single system (and ideally a single case with three associated events).

Data Security To perform their task, fraud management solutions may need access to data that your organization (or regulations) deem sensitive. These may be (for example) - credit card numbers, account numbers or customer names and addresses. The information is probably stored and transmitted securely within the source application. Make sure the same security controls are implemented for your fraud management tools as any other application that creates or accesses sensitive information. Make sure the same security controls are implemented for your fraud management tools as any other application that creates or accesses sensitive

information. A best practice

At the very least, ensure that access to your fraud management systems is tightly access controlled (least privilege). A best practice is to also encrypt the data store used to accumulate events and case information. Although no known solutions provide this option out of the box, it is possible and relatively easy to implement with common third party solutions, especially if the data store is a common commercial database.

is to encrypt the data store used to accumulate events and case information.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

14

__________________________________________________________________________________________________

Important Non-functional Factors While functionality is typically the most important criteria when selecting a fraud management solution, there are other factors to consider:

Ease of integration Some solutions are very easy to integrate. They require no modification to the application or infrastructure at all. Solutions that read log files usually fit this mold. Some require minor modifications at the infrastructure level. Solutions that need to integrate into an existing communication stream are an example. Then there are the solutions that are integrated at the API level. These can take a significant amount of time and effort to incorporate. This is largely due to the requirement to modify the application’s code and go through a build-andrelease cycle. These types of solutions can add significant time and costs to deploying fraud management - not only initially, but each time changes are required.

Cost of integration In addition to the cost to purchase the solution, there are often numerous additional hidden costs to deploying and maintaining the solution. Some common but not always obvious costs are:      

Hardware costs Development costs if integrating via API Disk storage for events Vendor or VAR consulting to deploy system and/or build necessary functionality (rules, alerts, dashboards, reports, etc.) License fees related to number of users that can use the system, number of events that can be processed in a given period, number of event sources, etc. Maintenance costs

Keep all of these in mind when budgeting for or selecting a solution.

Ease of use The functionality provided by two given competing products might be equal or very similar, but there may be significant difference in how easy it is to uses versus the other. This may not be of great importance if the users are very technical but, if they are not, it could have a huge negative impact on the perception and utilization of the solution. For example, some solutions require writing rules in a programmatic manner using languages like Perl and regular expressions. Others allow the user to build the rule visually by pointing-and-clicking on icons or using simple English words.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

15

__________________________________________________________________________________________________ Some solutions require significantly more effort or technical expertise to create custom reports and dashboards.

The functionality provided by two given competing products might be equal or very similar, but there may

Even if the users of the system are highly technical, nobody wants to spend more time doing something that can be done in less time using an easier method or a better interface.

be a significant difference in how easy it is to use one versus the other. It is highly recommended to spend a fair amount of time evaluating the

It is highly recommended to spend a fair amount of time evaluating the usability of any potential solution before purchasing it. Performing a real-world proof of concept of at least 30 days duration is strongly recommended.

usability of any potential solution before purchasing it. Performing a real-world proof-of-concept of at least 30 days duration is strongly recommended.

Using Non-fraud-specific Tools Specialized fraud management tools are currently very expensive. Commoditization will occur eventually, but so far has not set in. It has already been mentioned that many fraud detection tools have evolved from other logparsing and data analysis tools such as SIEMs. While using these tools will likely require more work (in that all rules, reports, dashboards, etc. will likely have to be created from scratch to meet fraud management needs), they can be used in a pinch. Free monitoring tools can be used for monitoring log events, if you are comfortable writing complicated regular expression rules. SIEM products that are flexible enough to parse custom application logs may also be usable. Finally, there are always shell scripts and data analysis tools that can be used on logs that end up in databases. There are plenty of options. Not being able to afford a dedicated fraud management system should not deter one from implementing some sort of automated detection. Just be prepared to have to work harder at it and possibly get inferior results. Consider those two points when determining or soliciting budget for a fraud management solution.

Owned/Managed or FMAAS Finally, the last thing to consider when selecting a fraud management solution is whether to own and manage the application in-house or to use a third-party FMAAS (“Fraud Management as a Service”). When making this decision, consider the following:  Availability of internal resources (skills and numbers) Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

16

__________________________________________________________________________________________________ 

Concern about sensitivity of exposure (raw data, events, and incidents)



Costs

If going down the FMAAS road, there are a few different options. Here are some examples:  Send all events to the third party (securely!) where the solution is hosted at their premises and their employees do all of the rule writing and monitoring 

Send all events to the systems hosted at the third party but your employees use the system, perhaps supplemented by the third party’s staff, to create the rules and perform the monitoring



The systems are hosted at your premises but used by skilled resources at the third party to write rules, monitor, etc.

There are other options. By working with a reputable vendor you should be able to design and implement a solution that will best meet your needs and constraints.

Conclusion There is no single correct approach to fraud management. It is somewhat unique for every organization. Fortunately, with the wide array of available solutions, implementation models, and the information in this white paper, you can custom-build a solution that will work best in your organization. Please keep the following things in mind when selecting and implementing your fraud event management solution: 

It is not necessary to implement all functionality simultaneously. It is much more manageable and common to implement bits of functionality at a time. It is best to start small and get it right before moving on to the next piece. If you have multiple business units and multiple applications, start with a single application. You may be surprised to find out how much work is involved to properly on-board a single application and put in place meaningful rules, alerts, dashboards, reports and incident handling processes. By taking extra time to get the first application correctly implemented, you will probably save time on all subsequent on-boarding efforts.



Implement detection before prevention. If you are implementing a prevention solution, set it up so that it only alerts and reports but does not block or otherwise interact with the customer initially. Run in this mode for some time until you have a sizeable data set to analyze. Review and analyze each alert that would have resulted in an interdiction and determine the adequacy of the results. Adjust as necessary if there are too many false positives. When comfortable with the results being observed, enable the prevention (interdiction) capability.



All fraud event management solutions require continuous tuning. Event sources, fraud patterns, performance requirements, reporting requirements, workflows and use cases all tend to change over time. These systems should not be viewed as “install and forget”. Make sure that sufficient resources are dedicated to continued engineering, process improvement and operational support of the solution. Ideally, these resources should not be the same resources that act as the analysts who review and respond to alerts.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

17

__________________________________________________________________________________________________ 

Make sure that the fraud management team is properly staffed with roles and responsibilities clearly defined. Do not overload individual resources with too much or widely differing types of responsibilities. The application and the people who use it must be properly plugged in to the overall fraud management program. This may include integration with other processes, organizations and even systems. As an example, in larger organizations it may be expected that when fraud is detected and confirmed, that it gets documented in a case management system maintained by a Corporate Security department - even if a case has already been created in the fraud event management solution.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

18

__________________________________________________________________________________________________

About AsTech Consulting AsTech Consulting helps organizations discover and understand risks to their Information Systems. Since 1997, AsTech has delivered security services that result in our clients’ ability to manage these risks effectively – security planning, vulnerability discovery and analysis, application security (training, assessment, and remediation) and secure architecture design to build in confidence from the ground up. Our primary goal is to maximize our clients’ ability to conduct business securely while meeting relevant compliance pressures. We apply AsTech’s 15 years of security experience to assist in developing effective risk management programs designed to evolve to meet emerging challenges. For information please visit www.astechconsulting.com.

Selecting the Right Fraud Event Management Solution

© 2012 AsTech Consulting. All Rights Reserved.

19