This is an early draft of a chapter from the book Managing Cyber Threats: Issues, Approaches and Challenges, edited by Vipin Kumar, Jaideep Srivastava, Aleksandar Lazarevic, Kluwer Academic Publisher, 2004.
We describe a type of data mining system designed to screen events, build profiles associated with the events, and send alerts based upon the profiles and events. These types of systems are becoming known as alert management systems (AMS). We give some examples of alert management systems and give a quick introduction to their architecture and functionality.
In this note, we give an overview of systems designed to screen events, build profiles associated with the events, and send alerts based upon the profiles and events. These types of systems are becoming known as alert management systems (AMS). In this paper, we give some examples of alert management systems and give a quick introduction to their architecture and functionality.
Section 2 contains the key definitions. Sections 3 and 4 describe the functionality and architecture of alert management systems. Section 5 describes several examples. Section 6 contains the conclusion. Skimming the examples in Section 5 first may make the paper easier to understand.
Alert management systems usually work with two types of data: transactional data and summary level data. A simple example is provided by credit card transactions. Each credit card transaction is associated with an account owner. Given a stream of credit card transactions, statistical characterizations of the corresponding account holders can be assembled by aggregating and analyzing information from the different transactions associated with the same account holder. This is a very common situation. In other words, one can think of a stream of transactions and imagine building summaries which statistically pull together information from those multiple transactions.
More generally, transactions are examples of what are called events and the statistical summaries are examples of what are called profiles. Profiles are distinguished using profile IDs. In the simplest model, each event is associated with a profile ID, either explicitly or implicitly. For example, a credit card transaction (an event) always contains the account number (the profile ID).
Processing events to produce scores usually use what is sometimes called the event loop:
To summarize: transactional data are modeled by events; profiles summarize state information derived and aggregated from their associated events; and events update profiles. The update action captures the aggregation and computation of derived attributes which is usually involved when one or more transactions are used to update their corresponding profile. Profiles are scored using statistical models and then processed using rules or an alert model to produce alerts.
It turns out that events and profiles have a nice mathematical structure. Profiles can be thought of as the states of a dynamical systems and events can be thought of as actions which move profiles along orbits.
Although different alert management systems can have quite different functionality, many of them share the following core functionality: scoring, matching, routing, and linking. In this section, we give brief descriptions of each of these.
Scoring. Scoring has already been mentioned and consists of applying a statistical or data mining model to a profile to produce a numerical or categorical score. A slight variant of a profile is sometimes known as a signature. A signature is an update rule in which the old profile or score is averaged with the new profile or score. Signature based methods are commonly used in alert management systems since signatures "smooth" or blend new event information with historical information stored in the profile, something which in practice is quite helpful.
Matching. Sometimes associating a profile ID with an event is straightforward and sometimes it can be quite challenging. For example, given a credit card transaction or call detail record if the profile ID is the account number or the calling number, then the profile ID is immediately and unambiguously available from the event data. On the other hand, if the profile ID must be matched against another list, such as list of customers, this can be more difficult. For example, is John Smith, 121 Oak Road, San Francisco, CA the same as J. Smithe, Oak Avenue, San Francisco, CA 94701. As the amount of data grows, this problem becomes computationally challenging. Even more difficult is the problem of associating a profile ID to an individual who is deliberately trying to make this task difficult, such as an individual engaged in fraud or other inappropriate activities. In this case, multiple variants of names, addresses and phone numbers may be used.
Alert management systems using matching to normalize names, addresses and similar information and to check names, addresses and related information against various lists. Alert management systems often contain both bad and good lists, i.e. lists containing individuals which must be check more carefully (bad lists) and individuals which are known to the system and have already been vetted (good lists).
Workflow. Often after events and profiles have been scored and checked against good and bad lists, additional work is required. Further investigation may be warranted, checks against additional lists may be formed, various alerts may be sent, etc. For this reason, alert management systems often contain a workflow component containing rules describing the various types of further processing that is required. For example, workflow rules may be used to assign further investigative work to analysts based in part on the analysts current work load and area of expertise. In many cases, the impact of an alert management system is fundamentally dependent upon the quality of the workflow component. Even if the scoring component is extremely accurate with a very low false positive rate, nothing is gained unless the alerts produced by the score get to an individual analyst who can take the appropriate action at the appropriate time after having examined the appropriate auxiliary data.
Linking. Events and profiles can often times be linked by common shared attributes or by attributes which have some suspicious relationship with each other. A few examples will make this clearer. For example fraud rings sometimes stage a number of different accidents in order to collect insurance payments. The accidents, although seemingly unrelated, may share a common cell phone number (with different addresses), may all occur within a small physical region, may all use the same body shop, or the same doctor, etc. Of course, two accidents, neither of which are fraudulent, may also share common links or attributes. The goal of linking analysis software is to identify linkages which are suspicious in some way so that further investigation may be done. Sometimes link analysis software is also known as forensic software.
In this section, we describe a common architecture for an alert management system. See Figure 1. In practice, actual alert management systems are usually much more complex. The functionality for an alert management system can be divided into three general areas. First, functionality which extracts, transforms, cleans, and loads the data. Second, functionality, for the off-line (i.e. non-real time) analysis of data. This includes data analysis, data mining, link analysis and related types of forensic activities. Third, functionality for the on-line or real time analysis, routing, and workflow.
The off-line analysis usually contains a data warehouse or data mart and various data analysis, data mining, and forensic analysis tools. From this off-line analysis, data mining models and profiles are often produced for the on-line system. In addition, the off-line analysis may involve extensive checking against various internal and third party databases, checking which may be too time consuming to take place on-line.
The on-line analysis usually contains one or more databases containing various watch lists which incoming events and profiles are compared to. In addition, scoring may be done using the data mining model produced from the off-line analysis. Finally, workflow and routing is usually done producing various alerts and reports.
Part of the complexity of alert management systems is that the extraction, transformation, cleaning and loading must be consistent for the both the off-line and on-line components. There is usually reporting which is part of both the off-line and on-line components of the system.
Figure 1. A typical architecture for an alert management system.
In this section, we give some examples of alert management systems. In most of the cases discussed below, there is a natural way to label a data set of events. For example, events may be labeled "good" or "bad"; "intrusion" or "no intrusion"; "normal" or "abnormal"; "threat" or "no threat"; "fraud" or "no fraud"; or "red" or "blue". For simplicity, we often refer to the labels simply as "bad" or "good," with the understanding that the particular meaning of these terms is dependent upon the particular example.
A labeled set of events can be used to label profiles in different ways. A common rule is to assume that profiles are initially labeled good until an event labeled bad is associated with them, after which they are labeled bad. Notice that this makes sense for credit card transactions and similar types of event data: a given credit card account can have a mixture of good and bad transactions. The goal is to detect when there are bad transactions and thereafter stop all transactions. Given a labeled set of events, we can use a variety of classification algorithms to construct a scoring function, which is simply a numerical function on state space indicating the likelihood that a profile is bad.
Credit Card Transacations. One of the best examples of transactional data is provided by credit card transactions. The data in a credit card transaction is broadly based upon the ISO 8583 standard and includes the account number, the date and time of the transaction, the amount of the purchase, etc. By aggregating transactional data by account number, a profile can be built for each account number. A fraud model uses transactional data to update profiles and then scores each profile for the likelihood of fraud.
Perhaps the best known alert management system for detecting credit card fraud is the Falcon System developed by HNC.
Call Detail Records. A Call Detail Record (CDR) contains data about telephone calls, including the date and time of the call, the duration of the call, the calling number, the called number, the telephone number of the billed party, which may be different then the calling number (for example, with 800 numbers), and related data. By aggregating CDR data by the calling number, a profile can be created. A variety of models can be built using these profiles. As before, a fraud model can be built which updates profiles using CDR data and then scores the updated profiles for the likelihood of fraud. As another example, models can be built predicting the likelihood of customer attrition or churn, or predicting the lifetime value of a customer. For the latter two examples, models may be built based upon a single calling number, or by aggregating all calling numbers associated with a given individual, household, or business.
Alert management systems for detecting telephone fraud have been developed by several of the large telephone companies, for example by AT&T.
Passenger Name Records. A third example is provided by passenger name records or PNRs. The transactional data in a PNR includes the originating city, connecting cities, if any, the destination city, flight numbers, name and address of the passenger, frequent flyer number, and related information. Giving a collection of PNRs, profiles can be built for each passenger. Using these profiles, a risk assessment can be done for each airline passenger.
An example of an alert management system for PNRs is the Computer Assisted Passenger Screening System (CAPS) used by the TSA to screen airline passengers at airports.
Network Intrusion Systems. Another example is provided by network intrusion systems employing statistical methods. Network intrusion systems monitor events derived from system logs and other sources. These are used to update various internal feature vectors, which are used as the inputs to statistical models, whose outputs trigger alerts.
Today, the most common network intrusion detection systems, such as SNORT, look for specific patterns in the data (which are also called signatures, but different than the signatures described above) and do not employ event-profile based techniques.
Suspicious Activity Reports. The Financial Crimes Enforcement Network or FINCEN, which is part of United States Department of the Treasury, collects reports from financial institutions about various types of suspicious financial transactions. These reports are called Suspicious Activity Reports or SARs. There are a number of criteria used for deciding whether or not to file a SAR. In addition, financial institutions are precluded from doing any business with certain individuals or business which have been placed on various watch lists. Larger financial institutions use alert management systems for comparing new accounts to the watch list, as well as for scoring transactions in order to decide whether or not it is necessary to file a SAR.
Automated Manifest System. The Automated Manifest System (AMS) is a system operated by the US Customs which provides inventory control and release notification for cargo entering the US. Carriers, port authorities, service bureaus, freight forwarders, and container freight stations can use the AMS to provide digital processing of manifest and waybill data. The AMS in turn can use manifest and waybill event data to build profiles about the users of their systems. Alert management systems associated with the AMS can score both event data (manifest and waybill data), as well profiles summarizing activities about carriers and other users of the system. Particularly important for systems like this is improving scoring by overlaying third party data over internal event and profile data.
Interagency Border Inspection System. The US Customs Service and Immigration and Naturalization Service (INS) use the Interagency Border Inspection System (IBIS) to screen individuals at ports of entry to the US. IBIS data is collected from a variety of sources and profiles generated by IBIS are shared by a over 20 US federal agencies. IBIS is used at ports of entry to clear expeditiously the majority of the traveling public, while allowing attention to be focused on a relatively small number of individuals. IBIS contains data on suspect individuals, businesses, vehicles, aircraft, and vessels.
In this note, we have provided a quick introduction to alert management systems. We have introduced the primitive concepts of events, profiles, and updates. We have also given six examples of these types of systems; many more could be given. There are four key functions usually present in an alert management system: scoring, matching, linking, and workflow, which we have briefly described. Finally, we have given a brief description of a common architecture used by alert management systems. With the increased focus on homeland defense, alert management systems will no doubt grow in importance.
For more information, please contact Open Data Partners www.opendatagroup.com.
Robert Grossman is the President of Open Data Partners, which provides consulting services, outsourced data services, and litigation support services related to data. He is also the Director of the Laboratory for Advanced Computing at the University of Illinos at Chicago, which develops internet-based technologies. He has written over 100 papers and edited four books in data mining, business intelligence, direct marketing, e-business, high performance computing, and related areas. He has a Ph.D. from Princeton and a A.B. from Harvard.
This article is copyrighted by Robert L. Grossman, 2003.