Several weeks ago I introduced the Shape AI Fraud Engine (SAFE), a product to identify and mitigate manual fraud for F5 customers (Shape AI Fraud Engine (SAFE): Mitigating Manual Fraud Using Machine Learning). In this article, I will describe the actions that may be taken by SAFE to alert the customer to potential fraud or to block it outright. Much of the information in this post comes directly from SAFE documentation which can be found in this guide on Sharepoint (guide largely created by Payal Shah, Pragyan Sharma, and Yesenia Barajas).
SAFE may be deployed for existing Shape Enterprise Defense (SED) customers which utilizes existing SED JavaScript (JS), for existing F5 BIG-IP customers by injecting SAFE’s JavaScript (1JS) into their iApp configuration, or for completely new enterprises by inserting 1JS using any method of the customer’s choice.
How SAFE Works in Real Time - SED Customers
For SED enterprises, Shape inserts 1JS through a bootloader on all flows. Any additional flows (relevant for SAFE use-case) are also routed through SED for more coverage. Important flows which may be of interest for financial customers include money transfer and billpay pages and the account profile page, where a customer can change their personal and contact information. Having visibility into these flows allows SAFE to detect anomalous behavior through actions which may lead to loss for the enterprise. For retail customers, we would like 1JS loaded on checkout and payment pages so that anomalies in these flows can be observed. The enterprises who do not have SED JS tag on all the webpages, it’s recommended to have customers insert 1JS tag directly into all the web pages and not update SED JS to invoke 1JS.
The figure below shows how SAFE operates for an existing SED customer.
First, 1JS is added to every page on the customer’s website. Next, all relevant URLs for which a customer will want SAFE to take an action are then routed through SED. For financial customers, this may include URLs such as the login page, the money transfer page, the billpay page, and the profile update page. It should be ensured that SAFE collects an identifier that can be shared between the customer and Shape to identify the transaction. This may include a username, account number, order number, session ID, etc. This will ensure that Shape and the customer can exchange information regarding specific transactions without confusion. Once SAFE’s 1JS is injected, SAFE will begin collecting data. This data includes default features such as keyboard and mouse events performed on each page as well as browser and IP characteristics. With permission from the customer, SAFE will often collect additional fields which may be helpful to identifying fraud. These may include credit card names and billing and delivery zip codes, which can be helpful in determining retail fraud.
Once SAFE is deployed, each time a device accesses the customer’s site, the SED calls 1JS and collects the necessary data to predict manual fraud. The prediction response is then returned to the enterprise and the device, which may be consumed in real time. These possible predictions include: (1) no fraud, (2) mitigate, (3) challenge, and (4) review. SAFE recommendations are sent in the SAFE cookie within the fr “fraud recommendation” dictionary, which is URL encoded and AES-GCM encrypted. For transactions to be mitigated (i.e., blocked), SAFE can mitigate those transactions using the same mechanism used to block automation using SED. For other actions such as challenge (i.e., MFA) or review, the customer can use their own solution to take actions on those transactions. Shape can also provide a file feed of transactions in these categories for the customer to review and action on offline. Shape recommends that customers take action on SAFE recommendations asynchronously as to avoid giving fraudsters real-time feedback. This way, fraudsters will not know which action(s) contributed most to the positive fraud recommendation. This can be done by only blocking on a small number of URLs or not alerting the user immediately when a transaction has been blocked. The customer may also serve a generic message to avoid giving the user specifics on why the transaction was mitigated.
How SAFE Works in Real Time - BIG-IP Enterprises
For Big-IP customers not utilizing SED, SAFE operates through BIG-IP instead of SED. 1JS is hosted on the enterprise's domain -- allowing Shape to run invisibly.
The figure below shows how SAFE operates for an existing BIG-IP enterprise.
Quoted from the SAFE documentation, the series of requests that take place are:
- The enterprise’s user requests the entry page.
- BIG-IP Local Traffic Manager (LTM) injects 1JS tag. The URL path can be a relative JavaScript (JS) tag.
- The browser requests 1JS, which is forwarded to the SAFE backend via the BIG-IP LTM.
- Once downloaded, 1JS executes and collects browser, network, and behavior signals called telemetry. In addition, the 1JS makes one or many API requests to the SAFE backend -- sending the telemetry.
- The SAFE backend analyzes the telemetry and responds with an encrypted fraud recommendation in the API response.
- When 1JS receives the API response, it writes the fraud recommendation (if the app is configured to do so) into an encrypted cookie. Then, when the enterprise’s user invokes a certain action on the website (for example: submits an order or makes a money transfer), this encrypted cookie is transmitted as part of the HTTP request.
- The BIG-IP LTM intercepts this request, decrypts the SAFE cookie, and extracts the SAFE recommendation (for example: fr: 2). Then, BIG-IP LTM passes it in the form of a request header to the backend servers.
How SAFE Works in Real Time - New Enterprise of Non-SED/Non-BIG-IP
If an enterprise is not a current Shape enterprise and not a BIG-IP enterprise, then Shape recommends the enterprise insert 1JS via any method of their choice (i.e. tag manager, code update, app server). Shape recommends enterprises use first party 1JS insertion. If the customer is not willing to make the necessary routing changes for 1JS and API requests, third party 1JS insertion can be considered.
The figure below shows how SAFE operates for new enterprises not currently using SED or BIG-IP solutions.
Per the SAFE Deployment guide, the following describes how SAFE operates for non-SED and non-BIG-IP customers:
The series of requests that take place are:
- The enterprise adds 1JS to all of their web pages.
- The enterprise provides Shape with a fraud file (file of confirmed fraud) to establish a source of truth.
- 1JS makes real-time API calls to the SAFE AI Engine.
- The SAFE AI Engine returns recommendations to the origin via an encrypted cookie or header in real-time.