Traditional FDS solutions usually consist of various modules (anti-money laundering, case management, fraud network analysis and others). While their functionality in terms of data mining, case management and tuning outmatches ThreatMark’s, the implementation is much more complex and time-consuming. Traditional solutions are also more difficult to use and require ample internal resources to keep the system optimized. Most importantly, the majority of these solutions rely on signatures and take only transactions into account. For modern threats such as zero-day attacks, social engineering, account and session takeover or man-in-the-browser attacks, this approach is not sufficient. Also it is unable to detect financial malware on users’ devices.
Traditional solutions do not collect behavioral biometrics, either, so there is a limit to their detection rate and number of false positives. Some can analyze certain changes in user behavior, but they do so in a simplified way so it can be easily bypassed by fraudsters in the following ways:
ThreatMark AFS has been designed to replace traditional analytical platforms that are not flexible and fast enough to react to emerging threats.
ThreatMark AFS is provided as a service, which requires a broad software stack and various Linux OS resources for correct functionality. Each AFS version is determined by its code and specific versions of used libraries, open source applications, and configuration state of the operating system. Thus, the AFS system is not an application that can be hosted on an unknown server.
The “blackbox approach” enables us to maintain a consistent state across AFS installations at our customers. Any patch depends on a previous known system state, and makes our updates quick and deterministic. It saves us time and effort that can be then invested in developing high-tech features instead of preparing specific updates for each customer. Another advantage is a greatly reduced maintenance price.
With consistent environment, patching is not difficult, and we can provide smaller, more frequent incremental updates. Each new version is distributed to all our customers. To illustrate, a traditional non-agile FDS is released once a year, and the update typically includes changing components on multiple servers. In a non-managed mode, this mostly requires effort on the customer’s side (for example, a bank).
ThreatMark AFS comprises of the following components:
The JS probe code is rebuilt every 30 minutes using dynamic, non-deterministic obfuscation, which protects it from reverse engineering. In addition, we perform cross-checking of session activity reported by JavaScript, and information sent through an API call by the backend (an authentication server or the banking core). If the JavaScript probe is removed but the API reports activity, we raise the risk score.
Our system publishes a REST API that processes information about transactions and outputs a real-time score with a detailed explanation. The score is calculated at the customer’s side. Our case management can then be used to solve any identified suspicious transactions and threats. The case management system can instruct other systems to block or allow the transactions.
The AFS is not an inline element, so it does not stop threats proactively, by itself. The desired results depend on the integration:
The problem of “stopping a fraudulent transaction” is a more complex task than mere transaction scoring. It can be done at any time during the session, depending on integration and sufficient evidence to minimize the risk of a false positive. For example, when a user connects from a safe environment and the second factor of authentication would normally not be required, then requiring it can be also considered as a transaction blocking.
At any action, we score the connected entities (user, session, device, action) based on the data available at the time, and we provide the score as a response to an API call, in real time. It is up to the customer how they want to react. For example, we score atomic actions (creating a payment, signing a payment). A bank has three score ranges: pass, verify, and block. Pass and block are obvious, verify means that a case is created in the case management and the bank waits for a decision by fraud analysts. However, this is not required and sometimes not even desirable, for example in case of instant payments. It is up to the bank, considering the following:
When a malicious or suspicious event occurs, the system silently alerts internal analytic servers. These notify the banking servers and fraud analysts. Our policy is that users are never actively notified of a threat as this would raise an alert for the attacker as well. However, the bank can choose to react in a number of ways:
Our solution does not rely on behavioral biometrics only. A legitimate user may behave in a sligthly unusual way due to temporary reasons (alcohol, inability to use all fingers, injury, etc.) but other fraud indicators may still show standard values on a few hundred parameters from devices, sessions, users and actions. In such a case, we will likely ignore the anomalous behavioral biometrics.
ThreatMark’s Security Operations Center is the main infrastructure used by all our customers. It allows them to benefit from the shared threat intelligence. Anonymized data such as unknown malicious code samples, phishing attempts, suspicious operations, etc. are collected from all software deployments. The data is then used by TM SOC to improve the machine-learning models, detection capabilities, and overall efficiency.
If a new malware sample, phishing campaign, fraudulent identity or behavior is identified, ThreatMark can share the information immediately and automatically with all customers, meaning that threats found in one location can be identified instantly if they appear elsewhere. System monitoring and continuous updates are also managed through the SOC connection.
For malware and phishing detections, the system is fully operational immediately after implementation. For other threats, the modules need to go through a learning phase. Its length depends on the application type and operation size, typically ranging from two weeks to two months.
The way ThreatMark AFS is implemented makes it fail-safe. For example, if the JavaScript probe does not load in the browser, it will not affect the performance and user experience of the protected application.