01/23/2018 | Episode 14
Robert Lee is a fraud expert with experience at Twitter and Amazon.
Evan: Welcome to Trust & Safety in Numbers presented by Sift Science. I’m your host, Evan Ramzipoor. Fraudsters are innovative, which means fraud analysts, bug bounty hunters, and online fraud and security experts are constantly trying new techniques to stay one step ahead of them. In this episode, I’m sitting down with Robert Lee.
Robert: I’ve had a few different roles over the years including Chief Security Officer, product manager, and technical program manager.
Evan: And drawing on that expertise, Robert tells us how tried true fraud-fighting techniques are being updated or even overturned, but first, let’s warm up with a quick fraud fact. Did you know that last year between $7.2 billion and $16.4 billion were lost to mobile ad fraud? For more startling fraud trends from 2017, check out, “What Happened in the World of Fraud,” on the Sift Science blog. Now on to the episode. How would you characterize your fraud fighting philosophy?
Robert: Well, the first part of it would be, you know, realizing that these attackers are extremely motivated in conjunction with their peers and aggregate. They have more time invested and spent on this than your organization probably has. So with that in mind, I’ve put the beginning part of…any time that I start a program at a new organization, I try to put a heavy amount of emphasis in our ability to have complete logs and be able to detect what these user accounts are doing, you know, who is doing what and from where? And then just branch out from there.
Evan: And how has that philosophy evolved, if at all, during your tenure as a fraud fighter?
Robert: I’ve done this for a banking platform that was used by 10 million users. I’ve done this for online retail sales, you know, at Amazon, and I’ve done it for a tax platform, “Intuit” and I’ve done it for social media at Twitter. And so the basic concepts don’t really change as you go from one type of application to the next.
Evan: Robert says that on the internet, there are always constants, devices, IP addresses, user accounts. So at a high level, his fraud-fighting philosophy hasn’t changed. But like many fraud fighters, he’s always iterating on the nuances.
Robert: The iterative progress that I’ve made, I would say in the last couple of years, one of the more interesting ones is instead of having a preset list of how much assurance we believe that we’re getting from a specific authentication control, we are now able to measure the failure rates of that authentication control and have that dynamically be a feedback loop and help change our perspective on how much assurance an authentication control can get.
Evan: So one of the more recent innovations you’ve been working on has involved risk-based authentication. Can you explain what that is and why it’s so effective or important?
Robert: Sure. I’ve actually kind of changed my terminology around that. I know in the industry, we’ve called it a number of things over the years. You know, we’ve called it “dynamic authentication,” we’ve called it “risk-based authentication,” but it’s the basic premise that if I’m able to detect that something seems higher risk or different than what I would normally expect for this user, then I’m gonna want to do some sort of challenge to help me get higher levels of assurance that it is the authorized user and not somebody that’s taken over the account somehow.
Evan: It’s a dynamic system that’s constantly weighing different factors and coming up with solutions to mitigate risk. If it sees a user with a high-risk account trying to access the site, maybe it’s someone who’s committed fraudulent activity before, then a risk-based system might prompt the user to answer security questions before they continue. But a lower-risk account won’t have to pass the same roadblocks.
Robert: So an example that in a banking platform, could be if we see a financial transaction coming from a device that we don’t normally see the user coming from or from an IP address or a region of the world that we don’t normally see them coming from. We could deduce that that is an increased level of risk. Similarly, we could have something that is very basic level and just show that the amount is higher than a certain level. So if this account normally transacts…transactions in $1,000 to $5,000 range, and all of a sudden, we see a $10,000 wire, we could infer that that’s a higher level of risk. And so we need a higher level of authentication assurance before allowing that transaction to go through.
Evan: But you prefer to say risk-based authorization instead of authentication, why is that?
Robert: The problem with calling it authentication is most people still think of authentication at the front door. [inaudible 00:05:02] a session, you know, the standard username, password, maybe an OTP. Once you’re inside of an authenticated session, most people [inaudible 00:05:10] authentication as being done at that point. And so for a lot of my internal conversations, I’ve described this as risk-based authorization because we’re now talking about a user that’s already inside of an instantiated session.
Evan: And how do these risk-based authentication approaches challenge some of the assumptions that the industry may have about fraud?
Robert: One of the problems that we have on the risk side is, how do we measure risk? What is risky? And each different operation that you support in your application should probably have a different risk oracle, meaning a different machine learning sort of place where information is being collected and analyzed. And this should be done…aggregate and consulting other risk oracles for different operation types. And I think the problem that we see a lot in the industry is that we have a one-size-fits-all way of measuring risk. And so we try to apply a risk oracle from a sign-in operation to deducing risk for an operation that’s very much unlike a sign-in operation.
Evan: Robert says that the industry is plagued by a one-size-fits-all approach to risk. For example, we might try to apply a risk oracle for a sign-in operation to evaluate a transaction like making a purchase. Those are two fundamentally different actions, so they should be evaluated using different approaches. As our fraud-fighting methods start to become more and more sophisticated, do you see fraudsters innovating in parallel? And if so, how do you stay ahead of the game?
Robert: I think that we see fraud levels that are commensurate with the amount of security that an application currently has. One of the unfortunate problems in trying to explain this to sites that have not traditionally been targeted by the higher sophistication fraud rings is that… Yes, in fact, your username and password is insufficient. Yes, in fact, your one-time passcodes is insufficient as well in the face of man-in-the-browser technology.
Evan: That’s an attack that works like a Trojan horse, by taking advantage of browser security vulnerabilities to infect someone’s web browser. Once the browser has been infected, the fraudster can change a user’s transactions or create entirely new transactions. And these attacks are totally invisible to the user and the web application.
Robert: So if you’re thinking about from the application perspective, the transaction that we see would be coming from a device identifier that we would expect for that user, and it would be coming from an IP address that we would expect from that user because they are essentially using that user system. And depending on the level of sophistication of the malware, they could be in a hybrid mode where the user is conducting most of the application themselves. For example, I as an unsuspecting user who has this sort of malicious software running on my system, I could try to log into my bank. I log in with my normal credentials. I might even have to go through a one-time passcode challenge. Then let’s say that I’m a controller at a company and I’m trying to pay my rent for the month and it’s a $10,000 wire.
Evan: The malicious software lies in wait for the unsuspecting user to initiate a transaction, and then it changes it at the last minute.
Robert: So on my screen, it still shows that I’m sending $10,000 to my landlord, but on the backend, the transaction that the bank actually sees would be to empty the entire bank account and send all the money to a routing number, an account number that’s different than what I have instructed the system to do. And so at that point, the bank may rightly challenge that and I might even expect it. So when the screen asks me for a one-time passcode, but at that point, I have given some level of assurance to the bank that I’m involved in the transaction.
Evan: But here’s the key, there is no way for the bank to evaluate whether that transaction is actually what the user wanted to do. And since the malicious software was controlling what the user saw on their screen, they don’t even know that they should be suspicious. That’s the sort of attack Robert says that can circumvent a one-size-fits-all approach to fraud. As fraudsters evolve, so too should risk-based approaches to fraud-fighting. That was Robert Lee, Chief Security Officer. Thanks for joining me on Trust & Safety in Numbers. Until next time. Stay vigilant, fraud fighters.
Learn more about what sets Sift Science’s machine learning apart.
With billions of compromised credentials already in criminals’ hands, how do you protect your users’ accounts, your brand, and your bottom line?