Hacker
Professional
- Messages
- 1,041
- Reaction score
- 852
- Points
- 113
The content of the article
The anti-fraud systems used in the banking sector and guarding the interests of credit institutions and their clients' money attract a completely healthy interest from both information security specialists and blackheads. But here's the bad luck: all these systems operate on the black box principle, and the creators are in no hurry to reveal the principles of their work. As always in such cases, the magazine "Hacker" rushes to the rescue!
Fraud becomes possible due to insufficient security of technologies and end devices of users, phishing, social engineering and the like. Antifraud systems try to detect fraud (fraudulent transactions) based on the attributes and characteristics of transactions. There are a lot of such systems on the market, including the Russian market. These are, for example, NICE Actimize, Eye4Fraud, SecureBuy Phoenix FM, RSA Adaptive Authentication, IRIS Analytics (IBM), Fraudwall and many others. And good solutions are expensive solutions. Vendors get a lot of money for their products, and their unwillingness to disclose the algorithms of the systems is understandable. The most advanced solutions use machine learning algorithms.
In a series of articles, you and I will consider the principles of operation of one widely known in narrow circles of the anti-fraud system, which is used in many banks. Let's get acquainted with the architecture of the system in relation to Internet banking, transaction processing mechanisms, as well as algorithms for risk assessment and decision-making to identify fraud. At the end of the cycle, we will try to assess what problems arise when working with this system, and identify the common weaknesses of the anti-fraud systems as a whole.
Anti-fraud system architecture
In general, the architecture of the remote banking system (RBS) is as follows.
Usually, the bank provides the user with several channels for managing the bank account remotely. The most common access is via a browser or using mobile applications. The user performs an action in his browser or mobile application, the transaction is delivered to the Frontend server, which already sends it to the RB Backend server and then to the ABS (automated banking system / settlement system) of the bank for settlements. One of the possible options for embedding an anti-fraud system into such an architecture of RBS systems is shown below.
In this case, the Backend server sends a transaction to the anti-fraud system and waits for permission to send this transaction to the ABS. After the anti-fraud system processes the transaction and makes a decision on its legitimacy, it transmits its decision to the RBS Backend server, and the latter sends it further to the ABS or refuses the user, depending on the decision made.
The anti-fraud system can be embedded in different ways, for example, it can be located in the gap between the RBS and ABS servers of the bank, or it can be a cloud system, the services of which the bank uses. The architecture is chosen depending on various criteria, but the general principle is as follows.
Relationship between the anti-fraud system and user authentication
In a general sense, any RBS anti-fraud system determines the possibility of executing a transaction initiated by the RBS user. At the same time, the system assesses the riskiness of this transaction and, in the case of an increased risk, in various ways tries to additionally check that the transaction is legitimate. Methods can be automated (from the bank's point of view) or manual. For example, you can send an SMS or push notification to the user to confirm the transaction, ask the user to answer security questions, and call the user back. All these actions are designed to once again authenticate the transaction using additional factors (in this article, transaction / action authentication is understood as confirmation that the action was performed by an authenticated user). Finally,
As a result, the anti-fraud system can be called a multifactor adaptive authentication system. Adaptability is understood as the ability of the system to calculate the riskiness of transactions (including entering the RB System), based on this information to perform additional authentication of the transaction and then make a decision on the possibility of executing the transaction.
This is how the process of successfully logging into the RBS system looks like with additional user authentication for control questions, the need for which was determined by the anti-fraud system.
In the following figure, after a successful login, the user tries to make a money transfer. After assessing the risk of an event, the adaptive authentication system offers to authenticate the payment using a one-time password sent to the user via SMS with the transfer details.
Accordingly, the adaptive authentication system can be used not only for payment systems, such as RBS, but also, for example, for single authentication systems, such as the Unified Identification and Authentication System.
Anti-fraud system architecture
The anti-fraud system we have chosen consists of several main services. The first is the actual core of the system and the Adaptive Authentication service. The service has its own database. Adaptive Authentication processes events transmitted to it from the Internet bank (for example, login events, payments), evaluates the risk of the event, calls other services if necessary (for example, additional authentication) and sends back the solution. In this case, multi-stage interaction with the Internet bank is possible to make a decision.
The second component, BackOffice, uses multiple web applications to manage Adaptive Authentication settings. BackOffice has its own database.
The third component, Case Management, is responsible for the work of the fraud analyst; it handles cases that fall under manual control. The decision made by the fraud analyst is passed back to Adaptive Authentication. If additional user authentication is required, built-in or external authentication tools are used.
Recently, a new service has appeared in the system - Trojan Protection. It receives information about the user's device directly from the user's browser, and not through the Internet bank. The service analyzes the information received and, upon detecting anomalies, fills in its blacklist of devices . This list then uses Adaptive Authentication to decide if the event is legitimate. Note that the data received by Trojan Protection from the user's browser is not synchronized with events in the Internet bank, but is transmitted much more often. In other parts, we will touch on how this service works in more detail.
WWW
An interesting analysis of the leak of CIA materials published by the Wikileaks project: the CIA is everywhere and everywhere
The figure below shows the interaction of system components at the web service level. All events from the Internet bank are sent to Adaptive Authentication endpoints (AA Endpoint and Async AA Endpoint), which process synchronous and asynchronous calls, respectively. The Endpoint of the Adaptive Authentication Admin component (AdminService Endpoint) is used by the Internet bank or other external service to manage users and sessions. Such controls are rarely designed in the system. The Case Management component contains the Case Management Endpoint for case management by the fraud analyst and other systems, such as the organization's CRM.
RSA Adaptive Authentication Web Services
How the anti-fraud system works
Now let's move on to the internal structure of the anti-fraud system and its individual processes. Let's start by handling the event.
[/URL]
Event handling in the anti-fraud system
Information about the event, as we saw above, comes from the Internet bank to the Adaptive Authentication component. Then this component handles the event. At the upper level, it consists of preprocessing (filling in internal structures, searching for a user and a device in the database, obtaining a user and device history, calculations based on the received data, for example, the user's movement speed), risk assessment (scoring, normalization based on the facts obtained at the first stage ) and determining, based on the rules set by the fraud analyst, the value of the risk and the response of the anti-fraud system.
In the anti-fraud system, there are four responses (recommended actions): ALLOW (allow action), DENY (forbid action), CHALLENGE (perform additional authentication) and REVIEW (allow action, but create a case in the Case Management component for subsequent marking).
According to ALLOW and DENY, no additional process is foreseen.
INFO
The safest way to use Internet Banking is through a mobile application based on the Apple iOS platform.
The CHALLENGE response triggers additional user authentication. The methods for this additional authentication are described below. After the user passes it, depending on the result, the anti-fraud system allows or denies this event.
An additional process is also envisaged in REVIEW's response. But it has to do with post-processing. With REVIEW, the event is resolved, but postponed (a case is created) in Case Management for further manual processing by a fraud analyst. A fraud analyst can mark an event as “definitely fraudulent”, “possibly fraud”, “definitely legal”, “possibly legal” and “difficult to classify”. This decision is then passed to Adaptive Authentication and taken into account by the system in the model to score the next events. Sometimes the REVIEW response process is configured in such a way that the event will not be resolved, and the Internet bank will wait until the fraud analyst makes his decision (in fact, this is some overlap of the functionality of the CHALLENGE response, where the method of additional authentication is the fraud analyst's solution ).
Let's try to clarify a little:
INFO
Correct authentication systems send SMS to users with a one-time password at the end of the message. This is done so that it is impossible to read the password in notifications on the smartphone, the first characters of which are usually displayed in the notification center without having to unlock the device.
Conclusion
Today we got acquainted with the architecture and principles of the anti-fraud system, and we will dwell on this for now. In the next part of the cycle, we will continue the architectural description of the system, as well as the processes for allowing and forbidding a transaction, considering and additional authentication, we will designate the methods of additional authentication of user actions offered by the anti-fraud system.
xakep.ru
- Anti-fraud system architecture
- Relationship between the anti-fraud system and user authentication
- Anti-fraud system architecture
- How the anti-fraud system works
- Conclusion
The anti-fraud systems used in the banking sector and guarding the interests of credit institutions and their clients' money attract a completely healthy interest from both information security specialists and blackheads. But here's the bad luck: all these systems operate on the black box principle, and the creators are in no hurry to reveal the principles of their work. As always in such cases, the magazine "Hacker" rushes to the rescue!
Fraud becomes possible due to insufficient security of technologies and end devices of users, phishing, social engineering and the like. Antifraud systems try to detect fraud (fraudulent transactions) based on the attributes and characteristics of transactions. There are a lot of such systems on the market, including the Russian market. These are, for example, NICE Actimize, Eye4Fraud, SecureBuy Phoenix FM, RSA Adaptive Authentication, IRIS Analytics (IBM), Fraudwall and many others. And good solutions are expensive solutions. Vendors get a lot of money for their products, and their unwillingness to disclose the algorithms of the systems is understandable. The most advanced solutions use machine learning algorithms.
In a series of articles, you and I will consider the principles of operation of one widely known in narrow circles of the anti-fraud system, which is used in many banks. Let's get acquainted with the architecture of the system in relation to Internet banking, transaction processing mechanisms, as well as algorithms for risk assessment and decision-making to identify fraud. At the end of the cycle, we will try to assess what problems arise when working with this system, and identify the common weaknesses of the anti-fraud systems as a whole.
Anti-fraud system architecture
In general, the architecture of the remote banking system (RBS) is as follows.
Usually, the bank provides the user with several channels for managing the bank account remotely. The most common access is via a browser or using mobile applications. The user performs an action in his browser or mobile application, the transaction is delivered to the Frontend server, which already sends it to the RB Backend server and then to the ABS (automated banking system / settlement system) of the bank for settlements. One of the possible options for embedding an anti-fraud system into such an architecture of RBS systems is shown below.
In this case, the Backend server sends a transaction to the anti-fraud system and waits for permission to send this transaction to the ABS. After the anti-fraud system processes the transaction and makes a decision on its legitimacy, it transmits its decision to the RBS Backend server, and the latter sends it further to the ABS or refuses the user, depending on the decision made.
The anti-fraud system can be embedded in different ways, for example, it can be located in the gap between the RBS and ABS servers of the bank, or it can be a cloud system, the services of which the bank uses. The architecture is chosen depending on various criteria, but the general principle is as follows.
Relationship between the anti-fraud system and user authentication
In a general sense, any RBS anti-fraud system determines the possibility of executing a transaction initiated by the RBS user. At the same time, the system assesses the riskiness of this transaction and, in the case of an increased risk, in various ways tries to additionally check that the transaction is legitimate. Methods can be automated (from the bank's point of view) or manual. For example, you can send an SMS or push notification to the user to confirm the transaction, ask the user to answer security questions, and call the user back. All these actions are designed to once again authenticate the transaction using additional factors (in this article, transaction / action authentication is understood as confirmation that the action was performed by an authenticated user). Finally,
As a result, the anti-fraud system can be called a multifactor adaptive authentication system. Adaptability is understood as the ability of the system to calculate the riskiness of transactions (including entering the RB System), based on this information to perform additional authentication of the transaction and then make a decision on the possibility of executing the transaction.
This is how the process of successfully logging into the RBS system looks like with additional user authentication for control questions, the need for which was determined by the anti-fraud system.
In the following figure, after a successful login, the user tries to make a money transfer. After assessing the risk of an event, the adaptive authentication system offers to authenticate the payment using a one-time password sent to the user via SMS with the transfer details.
Accordingly, the adaptive authentication system can be used not only for payment systems, such as RBS, but also, for example, for single authentication systems, such as the Unified Identification and Authentication System.
Anti-fraud system architecture
The anti-fraud system we have chosen consists of several main services. The first is the actual core of the system and the Adaptive Authentication service. The service has its own database. Adaptive Authentication processes events transmitted to it from the Internet bank (for example, login events, payments), evaluates the risk of the event, calls other services if necessary (for example, additional authentication) and sends back the solution. In this case, multi-stage interaction with the Internet bank is possible to make a decision.
The second component, BackOffice, uses multiple web applications to manage Adaptive Authentication settings. BackOffice has its own database.
The third component, Case Management, is responsible for the work of the fraud analyst; it handles cases that fall under manual control. The decision made by the fraud analyst is passed back to Adaptive Authentication. If additional user authentication is required, built-in or external authentication tools are used.
Recently, a new service has appeared in the system - Trojan Protection. It receives information about the user's device directly from the user's browser, and not through the Internet bank. The service analyzes the information received and, upon detecting anomalies, fills in its blacklist of devices . This list then uses Adaptive Authentication to decide if the event is legitimate. Note that the data received by Trojan Protection from the user's browser is not synchronized with events in the Internet bank, but is transmitted much more often. In other parts, we will touch on how this service works in more detail.
WWW
An interesting analysis of the leak of CIA materials published by the Wikileaks project: the CIA is everywhere and everywhere
The figure below shows the interaction of system components at the web service level. All events from the Internet bank are sent to Adaptive Authentication endpoints (AA Endpoint and Async AA Endpoint), which process synchronous and asynchronous calls, respectively. The Endpoint of the Adaptive Authentication Admin component (AdminService Endpoint) is used by the Internet bank or other external service to manage users and sessions. Such controls are rarely designed in the system. The Case Management component contains the Case Management Endpoint for case management by the fraud analyst and other systems, such as the organization's CRM.
RSA Adaptive Authentication Web Services
How the anti-fraud system works
Now let's move on to the internal structure of the anti-fraud system and its individual processes. Let's start by handling the event.
Event handling in the anti-fraud system
Information about the event, as we saw above, comes from the Internet bank to the Adaptive Authentication component. Then this component handles the event. At the upper level, it consists of preprocessing (filling in internal structures, searching for a user and a device in the database, obtaining a user and device history, calculations based on the received data, for example, the user's movement speed), risk assessment (scoring, normalization based on the facts obtained at the first stage ) and determining, based on the rules set by the fraud analyst, the value of the risk and the response of the anti-fraud system.
In the anti-fraud system, there are four responses (recommended actions): ALLOW (allow action), DENY (forbid action), CHALLENGE (perform additional authentication) and REVIEW (allow action, but create a case in the Case Management component for subsequent marking).
According to ALLOW and DENY, no additional process is foreseen.
INFO
The safest way to use Internet Banking is through a mobile application based on the Apple iOS platform.
The CHALLENGE response triggers additional user authentication. The methods for this additional authentication are described below. After the user passes it, depending on the result, the anti-fraud system allows or denies this event.
An additional process is also envisaged in REVIEW's response. But it has to do with post-processing. With REVIEW, the event is resolved, but postponed (a case is created) in Case Management for further manual processing by a fraud analyst. A fraud analyst can mark an event as “definitely fraudulent”, “possibly fraud”, “definitely legal”, “possibly legal” and “difficult to classify”. This decision is then passed to Adaptive Authentication and taken into account by the system in the model to score the next events. Sometimes the REVIEW response process is configured in such a way that the event will not be resolved, and the Internet bank will wait until the fraud analyst makes his decision (in fact, this is some overlap of the functionality of the CHALLENGE response, where the method of additional authentication is the fraud analyst's solution ).
Let's try to clarify a little:
- (1, 2) The user initiates an event in the Internet bank (for example, fills out and sends a payment order).
- (3) The client part (if it is a browser, then using JavaScript) collects some data about the user's device, his software, browser, scripts, etc. and (4) together with the data on the payment order sends it to the bank.
- (5) All these data are translated by the server side of the Internet Bank into a standard structure for Adaptive Authentication and sent to it.
- (6) Adaptive Authentication searches for an Internet bank user. If such a user is absent, then (6a) starts him at home.
- (7b, 7c) In this case, Adaptive Authentication can request additional data about the user (from the Internet banking system or from the user himself).
- (7d, 7e) The user fills out a form (for example, address, mobile phone) and transmits data about himself to Adaptive Authentication.
- (7f) Adaptive Authentication updates user information in its database.
INFO
Correct authentication systems send SMS to users with a one-time password at the end of the message. This is done so that it is impossible to read the password in notifications on the smartphone, the first characters of which are usually displayed in the notification center without having to unlock the device.
- (8) Next, Adaptive Authentication processes the event: calculates the risk and processes it according to the policy rules. As a result, it forms the recommended action (see above) - ALLOW, DENY, CHALLENGE or REVIEW.
- (9) The recommended action is sent to the Internet Bank. In the case of CHALLENGE, the available additional authentication methods are also passed.
- (10a) If the recommended CHALLENGE action was returned to the Internet banking system, then the Internet banking (if it agrees with the recommended action) requests Adaptive Authentication to authenticate and sends the additional authentication method it has selected.
- (10b) Adaptive Authentication itself asks the user to perform additional authentication or uses an external service for this purpose, including the Internet bank itself.
- (10c, 10d) The service authenticates and (10e) returns the result in Adaptive Authentication.
- (10f) Adaptive Authentication sends additional user authentication status to the Internet bank.
- (11) After receiving the recommended action and, if necessary, the status of additional authentication, the Internet Bank conducts the user's operation or prohibits it, depending on what the anti-fraud system has reported.
- (12a) In case of the recommended action REVIEW, the anti-fraud system also creates a case in the Case Management component.
- (12b) This case is manually processed by a fraud analyst who makes a decision and marks the event.
- (12c) The fraud analyst's solution is transferred from the Case Management component of the anti-fraud system to Adaptive Authentication for accounting in the model and processing of the following transactions.
Conclusion
Today we got acquainted with the architecture and principles of the anti-fraud system, and we will dwell on this for now. In the next part of the cycle, we will continue the architectural description of the system, as well as the processes for allowing and forbidding a transaction, considering and additional authentication, we will designate the methods of additional authentication of user actions offered by the anti-fraud system.
xakep.ru
