4 minutes
To evaluate the effectiveness of fraud models, auditors need to test the underlying rules.
Assessments of the effectiveness of fraud detection models need to keep pace with the maturation of the algorithms powering those tools, suggests Chris Nickerson, CEO of Lares, a business security consulting firm based in Denver.
At the foundation of rules built into payment fraud detection is the identification of anomalies, such as a sudden jump in spending or geographical trending, which flags transactions that happen outside the region the cardholder typically frequents. Over time, that latter algorithm has become more sophisticated to differentiate between online purchases and “land speed violations” where, for example, one in-person transaction happens in Denver and another in Louisville, Kentucky, 30 minutes later.
Machine learning and AI are also working their way into fraud detection systems, facilitating analysis of the different facets of a transaction, including payment system, monetary systems, location and cardholder profiler, Nickerson explains.
“So, when we come in for testing, we look for ways to get around those fraud algorithms. Can we manufacture situations where we can defeat the controls themselves?” he says.
That testing goes beyond phishing drills to see how many employees click on a link in a bogus email to simulate assuming an employee’s or member’s identity through personal information gleaned through these scams, Nickerson says. Hackers can use that information to apply for credit cards and perpetrate other forms of fraud.
In testing the chain in which fraud might occur, Lares adopts the same open source intelligence gathering that criminals use to find details of people’s lives, such as the high school they attended and their kids’ names. That information could be the second stage of the security inquiry, as those answers are often supplied for password resets.
“It’s not as simple as five or 10 years ago, where getting the card was the only barrier to entry,” he notes. “We’ve all met a level of frustration when we enter our own information incorrectly and a transaction is denied. Scammers need to get more information so they can complete those transactions.”
Exposing and Exploiting System Flaws
Testing fraud security measures also involves trying to find and exploit openings in a credit union’s mobile or online channels, core system or other software inadvertently left outside of security measures or programs that have not been patched with updates. Those openings could give hackers “a level of control inside those systems where they might find ways to instruct systems to ignore a rule for a specific transaction, or they could directly create a threat by extracting money or transferring funds into other accounts,” Nickerson says.
One identified flaw in some applications is known as “horizontal privilege escalation.” Hackers who work their way into authenticating one account then may be able to gain access to other account by presenting themselves as other users. If the first user number is 1005, for example, a hacker inside the system could request access to the accounts for user 1006, 1007 and down the line until the system grants access to another account.
How can credit unions fend off these increasingly sophisticated cyber threats? First, “make sure the doors aren’t wide open,” Nickerson advises.
That means asking in-house and third-party developers the right questions to make sure they’re fully securing their systems. What security testing are they doing? How fast are they fixing problems within their systems? What security controls do they apply? How can they demonstrate that they’re creating secure codes and secure functions so members don’t fall victim to poor coding practices or failure to secure software?
“Criminals default to the path of least resistance. They clearly don’t want to work for their money, so oftentimes their efforts will end up flowing into the space where applications may not be well protected or there may not be detection mechanisms in place,” he says.
Searching for Root Causes
Fraud prevention and detection audits can go beyond identifying flaws in systems, Nickerson says. Tracing the root cause back into the development life cycle can help developers correct those problems and perhaps prevent a repetition of coding errors. An added impetus is that fixing flaws before software goes into production is much cheaper than patching in fixes after distribution.
How often should credit unions test fraud security measures built into systems? “There’s one school of thought that says test as much as you can and another that says you can spend yourself into oblivion testing and still never be 100% secure,” Nickerson says. “I think there’s a balance of being able to have enough security built in for a good solid state. It would be great to test every release but at least test major releases.”
It’s on the credit union community to persist in asking software developers how they’re building protection and detection into their products. “Since there are no teeth in regulations requiring developers to build security into their software, we end up with this myriad of software where some are quite secure and others are horribly insecure,” he contends. “We’ve got to do our due diligence and ask what these companies are doing to make their software more secure and how deeply security is embedded in their products.”
Karen Bankston is a longtime contributor to Credit Union Management and writes about membership growth, operations, technology and governance. She is the proprietor of Precision Prose, Eugene, Oregon.
