This is a true story where bad-guy data finds good-guy data—causing an unexpected dis-covery and resulting in a surprise outcome.
In the mid-1990s, riverboat gaming became legalized in many new jurisdictions, Louisiana being one of them. One of the challenges of a new gaming jurisdiction is the lack of avail-able local employee candidates with deep gaming experience. New jurisdictions must therefore train the local workforce in a wide range of specialty job categories, ranging from dealers to surveillance room operators. Bossier City, Louisiana is one such community that had to make the transition from no casino business to casino riverboat operations.
Today is like any other day in any other casino. The dealers are watching the players. The floor supervisors are watching the dealers and the players. The casino manager is watching the floor supervisors, the dealers, and the players. And the surveillance room is watching everyone—even the casino executives. The surveillance room has an obligation to watch gaming transactions, not only to protect the house but also to protect the customers. Sur-veillance focuses both on gambling transactions as well as evidence of other criminal activ-ity. For example, a purse-snatcher is bad for business because he interferes with the customer experience.
Surveillance is the last line of defense.
Hundreds of cameras (thousands in the Vegas mega-casinos) are piped into a remark-ably tiny surveillance room. Twenty, thirty, maybe forty monitors cover an entire wall like a scene out of CSI. So how is it that only a few operators cleared for access to this room make sense of this information overload? Answer: tripwires and attentive browsing.
108 C H A P T E R S E V E N
Tripwires come in many forms, ranging from a tip on a hotline to a floor supervisor asking for the surveillance room to evaluate the play of a customer (e.g., to determine whether she is counting cards).* On this day, the surveillance operator is browsing—performing what might be called a random audit—zeroing in on one table after another, watching a short while to see if anything seems out of place, and then moving on.
Wait! What is that? Can’t be. The attentive surveillance operator has just observed a player blatantly cheating on the roulette table. Today the observed scam is known as “past post-ing”—a player who is placing bets after the roulette ball has already landed in its number.
Past posting occurs when the player notices the ball has landed on a number (e.g., 32) and seeing this outcome, quickly places a late, sure-to-win bet on that number. Unlike card counting, which is legal but discouraged, “past posting” is actually cheating and is defi-nitely illegal.
What is so peculiar today is that the table has one dealer and one player. Usually the “past posting” scam involves a team of players—players working together to prevent the dealer from detecting the late bet. Such team activity might involve two or more “players” at the table who appear completely unrelated (e.g., acting like they don’t know each other).
After the ball finds its number, one player (e.g., a nice lady with a grandma disposition) will reach all the way across the board as if to place a bet. The dealer, of course, says,
“Madam, it is too late to place your bet.” Nonetheless, the reach across the table (toward a losing number) has enabled the other team member (say, a punk-rock-looking dude with a mohawk) to place a late bet on the winning number—hidden from the view of the dealer.
There is no such team on the table today. This is curious and warrants immediate inspec-tion. The tapes are rewound. There it is! The dealer seems a bit distracted and misses the past post event. At this point it would be common to start looking backward in time by reviewing the earlier moments of the game. (And at the same time, maybe another room operator will begin watching the game go forward live.) Bang! Again and again the player makes late bets, the careless dealer missing this each time—and each time, paying the cus-tomer for the win.
Security is notified. The troops mobilize. The player is confronted and detained for arrest by law enforcement. How could this happen?
The dealer is obviously quite embarrassed. Being in a new jurisdiction, this employee is also new to gaming and really only has had classroom training. The dealer makes it clear that she has only heard about this type of scam. She then points out that security has really done a good job today. She is very embarrassed and is quick to guarantee it will never happen again on her watch.
Enter “data finds data.”
* Notably, the role of casino surveillance is intelligence. They report their observations and findings, but perform no enforcement; enforcement is the role of the security department.
D A T A F I N D S D A T A 109 When the cheater is apprehended, he is required to identify himself. The cheater today,
like any other day, presents his name, address, phone number, and some other informa-tion. This information is collected on a standard form, with a signature if they can get one, and thereafter is data-entered into the corporate security arrest processing systems.
Of course, the cheater’s last name is not the same as the dealer’s; that would make life too simple. The address is also not that of the dealer. The phone number, however, happens to be the same as the phone number that the dealer used on her employment application! At this exact moment that the arrest information is presented to the arrest processing system, a secondary system performing data finds data*makes this vital discovery and produces an immediate alert that basically says, “Employee #5764 has the same phone number as Arrestee #44-00321!”
Long story short, the dealer is confronted, she confesses, and they are both processed and handed over to law enforcement for prosecution.
To be clear: the users did not take identity attributes (e.g., name, address, phone number) of the “past posting” cheater and attempt to search the wide array of operational systems (call this a federated search). The applicant, employee, loyalty club, and arrest processing systems, among others, cannot even be searched by address or phone number—they were not designed for that.
Using a “data finds the data” environment, the users do not have to proactively search or pose relevant questions. The users in the security department enter what they have learned into their system, and this new information is then assessed against other enter-prise information assets. The new information is found to relate to existing data, and this relationship meets a prespecified condition of interest: when a “bad” guy is related to an employee. Because this condition is met, an alert is triggered because the bad guy and the employee share a phone number (thus, bad guy knows employee). If the cheater arrest data had perhaps found an association with a hotel visitor of three years ago, this noninteresting discovery would not have resulted in an alert.
To drive this point home, let’s now imagine the phone number provided by the “past poster” had no relationship to that of the dealer. In this case, no alert would have been produced. The dealer may have been questioned with some suspicion, but there simply would not be enough evidence to make any claim. Might corporate security have opened an investigation of the dealer, or hired a private investigator to determine whether these two individuals were in fact close friends? Who knows?
But what if? What if the phone number does not match and no connection is made? The dealer continues to deal. Time marches on. What if, six months later, the dealer changes
* This technology, formerly known as Non-Obvious Relationship Awareness (NORA), was devel-oped by Systems Research & Development (a company founded by Jeff Jonas) for the Las Vegas gaming industry. SRD has since been acquired by IBM and is now part of IBM’s Entity Analytics group. Some additional information is available here: IEEE Paper: Threat & Fraud Intelligence – Las Vegas Style (http://jeffjonas.typepad.com/jeff_jonas/2006/11/ieee_paper_thre.html).
110 C H A P T E R S E V E N
her home address in the employment system—and the new information is the same as the cheater’s address? How would the organization know this? In truth, no organization will ever know this unless it can play this important game called “the data finds the data.” The moment this new information connects the dealer with the closed case, such a system detects an alert condition: bad guy related to an employee.
Alerts, by the way, do not necessarily mean there is criminal activity. Alerts do, however, play an important role in focusing an organization’s finite investigatory resources—in this case, a condition of sufficient interest to warrant a closer (human) look.
Other examples: this riverboat casino operation also found a scam involving a marketing person who figured out a system hack to cash-back comp (a marketing activity whereby the more you play, the more points you get, and points can be redeemed for cash!) his roommate. And in another case, it discovered that the person pulling out the “car a day”
winner ticket happened to “select” her sister (of a different last name), with the family members acting as if they had never met.
All three of these scams were revealed as the data became known using “data finds data”—and all three scams were detected in the first 90 days of operation!
The reason why data finds data is essential is that the order in which information arrives is uncertain. Systems and processes that take the order of events for granted have a fatal flaw: out-of-order facts may provide the organization with important knowledge that never gets acted upon. More about this later.
One large retailer with thousands of physical storefronts across the United States analyzed its historical data holdings and was shocked to discover that two out of every thousand employees had in fact already been arrested for stealing from them. Worse yet, these employees were caught stealing from the same store that hired them! Despite the order in which the data is presented, the moment the enterprise has such evidence there is no time to waste. The store should know this immediately.
Traditional remedies to address out-of-order data points are cumbersome. How can corpo-rate security take advantage of new enterprise data that reveals an employee may be a known shoplifter? When should updates to an employee record in the human resource system cause corporate security to reevaluate all its earlier investigations? How can the re-evaluation be structured so that the organization can’t miss instances when new or modi-fied records in the internal investigations database are related to employees? One strategy is to periodically test the investigations database against the entire employee database.
Another strategy is for corporate security to reinvestigate every employee on some recur-ring basis. But both of these strategies will miss important discoveries because timing is critical.
Even perfect algorithms running against perfectly reengineered operational systems (e.g., the human resources system and the internal investigations system) will still miss certain discoverable events. What if the data needed to determine that two people are the same or connected exists in an entirely unrelated system? For example, imagine a third record
D A T A F I N D S D A T A 111 arriving from an unrelated system, such as a loyalty club enrollment system, which reveals
a previously unknown linkage between a home address and a home phone number. What kind of enterprise systems would be required to detect this condition, a condition we will characterize as a nonobvious relationship?
Data finds data, including nonobvious relationships, requires that one first solve the prob-lem of “enterprise discoverability.”