Fraud detection software – Security Testing Handbook for Banking Applications

4: Security Testing Repository
182
Fraud detection software
Fraud detection software, also called ‘transaction
monitoring software’, is used to spot potentially fraudulent
transactions. This software uses sophisticated algorithms to
analyse transactions and predict if they are fraudulent or
not.
The fraud detection software is integrated into other
banking systems that perform transactions. When these
systems perform a transaction, they consult the fraud
detection software to verify if the transaction is authentic.
Based on its analysis, the fraud detection software gives a
risk score signalling how risky the transaction is. The bank
defines thresholds for risk scores: very high-risk
transactions could be blocked, high-risk transactions could
be marked for manual review and low-risk transactions may
be allowed to go through.
The fraud detection software keeps a record of past
transactions of the user and uses this to perform the risk
analysis for each transaction. Commonly used data about
the user and their transactions are:
amounts frequently transferred
time of performing transaction
beneficiaries most frequently transferred to
geographical location
browser and operating system type.
Thus, when a user logs in from a different country and
suddenly adds a new beneficiary and transfers a large
amount to them, the fraud detector raises a flag. Similarly,
if a user suddenly uses a different browser and transfers a
very small amount, the software might signal a warning.
4: Security Testing Repository
183
Let us now look at the fraud detection software architecture
in a little more detail. It has four components – namely case
management, rule administration, rule engine and a
database. The case management is used for monitoring and
resolving frauds detected by the system. Every
suspicious/malicious transaction is listed as a case. The rule
administration module is used for setting up fraud detection
criteria (rules). The administrative user is the one who
manages and keeps these rules up to date. The rule engine
works behind the scenes and checks transactions against
rules and criteria. It also decides whether the activity is
fraudulent, creates cases and assigns them to operators.
When the rule engine detects a fraud, it then notifies the
respective authority about its decision and the action that it
takes. Notification can be through real-time response to the
requesting application, or e-mail, SMS, pager or fax. The
case management operator then takes a look at every
potentially fraudulent case and takes a decision to accept or
reject it. The fraud detection software keeps a history of all
events which help in analysis of the trends of banking
frauds and reducing them over a period of time. Fraud
detection can work offline as well as in real time. Once the
rules are created it is possible to activate the fraud detection
software to attempt to uncover inconsistencies in older
transactions. In the future one might begin to see similar
applications which make decisions not just by matching
signatures but also based on the transaction behaviour of
specific users.
Quite clearly this is one of the most important detective
controls that a bank can use in attempting to make the
Internet a safer place for their customers. It operates at a
layer which is not protected by a firewall, IDS or even a
4: Security Testing Repository
184
web application-layer firewall. It is hence imperative that
this powerful tool is not misused by an attacker.
The attackers of the fraud detection software are of two
types:
the fraudster who wants to evade detection
the administrative user of the fraud detection software
who has malicious intentions.
Threat profile
An attacker updates a fraudulent high-risk record as a
non-fraudulent, low-risk one.
An attacker adds fake fraud detection rules without
authorisation.
An attacker modifies the threshold for a case to be
declared as a risky one.
An attacker modifies existing fraud detection rules
without authorisation.
An attacker modifies the alerting mechanisms of the
fraud detection software.
An attacker modifies user data which the fraud rule
checks.
An attacker predicts the detection rule set and uses the
information when they attempt fraudulent transactions.
An attacker deletes event logs/cases.
An attacker uploads malicious content to bring down the
system.
An attacker modifies the logic that the rule engine uses
to make decisions.
4: Security Testing Repository
185
Test plan
An attacker updates a fraudulent high-risk record as a
non-fraudulent, low-risk one:
o Check if a user can change the category of a risk
record using parameter manipulation.
o Check if a user can change the categories of all the
risk records using SQL injection.
An attacker adds fake fraud detection rules without
authorisation:
o Check if a user can add fake rules using parameter
manipulation.
o Check if a user can manipulate SQL queries made to
the application and add fake rules in the process.
An attacker modifies the threshold for a case to be
declared as a risky one:
o Check if a user can modify the case threshold using
parameter manipulation.
An attacker modifies existing fraud detection rules
without authorisation:
o Check if a user can bypass authorisation using SQL
injection.
o Check if a user can modify existing rules using
parameter manipulation.
An attacker modifies the alerting mechanisms of the
fraud detection software:
o Check if a user can modify alerting mechanisms using
parameter manipulation.
An attacker modifies user data which the fraud rule
checks:
4: Security Testing Repository
186
o Check if a user can bypass checking by obfuscating
data.
o Check if a user can bypass checking using parameter
manipulation.
An attacker predicts the detection rule set and uses the
information when they attempt fraudulent transactions:
o Check if a user can bypass detection by obfuscating
live transactions.
An attacker deletes event logs/cases:
o Check if a user can delete cases using parameter
manipulation.
o Check if a user can gain access to the cases or logs
stored in folders on the disk due to weak permissions.
o Check if a user can manipulate SQL queries using
SQL injection and delete content from the database
directly.
An attacker uploads malicious content to bring down the
system:
o Check if malicious files can be uploaded using the
case upload feature.
An attacker modifies the logic that the rule engine uses
to make decisions:
o Check if a user can gain access to changing rule order
using privilege escalation.
o Check if a user can gain access to the source code on
the application server exploiting weak permissions on
folders.