Systems and methods for anomaly detection on core banking systems

US 10 701 096B1

drawing #0

Show all 5 drawings

In certain embodiments, three or more sensors may be installed on a core banking system to detect anomalous behavior. Each of the sensors may be configured to detect removal or corruption of any of the other sensors at a periodic interval and to repair or reinstall any of the other sensors that has been corrupted or removed so that the combination of the sensors makes the group of sensors unremovable. A sensor may be configured to detect anomalous behavior by applying an anomaly detection model developed using live data collected by the sensor. In certain embodiments, a new anomaly detection model may be developed and trained to recognize potentially anomalous events; tested; and used to generate a live score to indicate the likelihood that a detected event is an anomaly. A model may be used for scoring in as little as 6 hours after initial receipt of live data.

PatentSwarm provides a collaborative workspace to search, highlight, annotate, and monitor patent data.

Start free trial Sign in

Tip: Select text to highlight, annotate, search, or share the selection.

Claims

wherein the first sensor is configured to detect anomalous behavior by:
collecting identifying information and first live data;
generating a first live data template from the first live data;
transmitting the first live data template to a data engineering engine configured to apply an anomaly detection model developed using live data to first live data collected by the first sensor;
wherein the anomaly detection model is configured to:
compare the first live data template to a plurality of existing anomaly detection models; and
if an existing anomaly detection model is applicable to the first live data template,
update the existing model to incorporate the first live data template; or
if an existing anomaly detection model is not applicable to the first live data template,
generate a new anomaly detection model of a first event in the first live data template;
train the new anomaly detection model to recognize the first event in the first live data template;
test the new anomaly detection model against second live data; and
generate a live score of the first live data template to indicate the likelihood that the first event is an anomaly;
storing the new model with the plurality of existing models;
receiving the first live score at the first sensor.

Show 12 dependent claims

14. An anomaly detection system for core banking systems, comprising:
a data engineering engine configured for
receiving live data from an endpoint anomaly detection system comprising;
a first sensor program for detecting anomalous behavior on a core banking system;
a second sensor program for verifying that the first sensor remains active;
a third sensor program for detecting removal or corruption of the first sensor or the second sensor; and
wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed;
applying an anomaly detection model developed using live data to first live data collected by the first sensor;
wherein the anomaly detection model is configured to:
comparing the first live data to a plurality of existing anomaly detection models; and
if an existing anomaly detection model is applicable to the first live data,
updating the existing model to incorporate the first live data; or
if an existing anomaly detection model is not applicable to the first live data,
generating a new anomaly detection model of a first event in the first live data;
training the new anomaly detection model to recognize the first event in the first data;
testing the new anomaly detection model against second live data; and
generating a live score of the first live data to indicate the likelihood that the first event is an anomaly;
storing the new model with the plurality of existing models.

Show 7 dependent claims

22. An anomaly detection method for core banking systems, comprising:
receiving live data from an endpoint anomaly detection system comprising;
a first sensor program for detecting anomalous behavior on a core banking system;
a second sensor program for verifying that the first sensor remains active;
a third sensor program for detecting removal or corruption of the first sensor or the second sensor; and
wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed;
applying an anomaly detection model developed using first live data collected by the first sensor;
comparing the first live data to a plurality of existing anomaly detection models; and
if an existing anomaly detection model is applicable to the first live data,
updating the existing model to incorporate the first live data; or
if an existing anomaly detection model is not applicable to the first live data,
generating a new anomaly detection model of a first event in the first live data;
training the new anomaly detection model to recognize the first event in the first data;
testing the new anomaly detection model against second live data; and
generating a live score of the first live data to indicate the likelihood that the first event is an anomaly;
storing the new model with the plurality of existing models.

Show 7 dependent claims

Description

This application claims priority of U.S. Patent Application No. 62/903,947, entitled Systems and methods for anomaly detection on core banking systems, and filed Sep. 23, 2019. The entirety of the foregoing patent application is incorporated by reference herein to the extent consistent with the present disclosure.

II. TECHNICAL FIELD

The present disclosure relates to systems and methods for anomaly detection and more particularly to systems and methods for anomaly detection on core banking systems.

III. BACKGROUND OF THE INVENTION

Core banking systems protect high-value data that is at constant risk of cyber attack. There is a need for early detection of anomalies on core banking system to prevent compromise of valuable data and systems. Current anomaly detection systems and methods are at risk of removal from the systems they are designed to protect by cyber attackers. Conventional anomaly detection models typically require considerable configuration and large quantities of historical data to develop and test the anomaly detection models.

There is a need to address the foregoing deficiencies in the art.

IV. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a core banking system including three sensors for anomaly detection in accordance with certain embodiments.

FIG. 2 depicts data collection methods and systems in accordance with certain embodiments.

FIG. 3 depicts a data ingest system and method in accordance with certain embodiments.

FIG. 4 depicts anomaly model development and data scoring modes in accordance with certain embodiments.

V. DETAILED DESCRIPTION

In certain embodiments, an anomaly detection device for core banking systems is disclosed, comprising: a first sensor for detecting anomalous behavior on a core banking system; a second sensor for verifying that the first sensor remains active; a third sensor for detecting removal or corruption of the first sensor or the second sensor; and wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed. The first sensor may be configured to detect anomalous behavior by applying an anomaly detection model developed using first live data collected by the first sensor; wherein the anomaly detection model is configured to compare the first live data to a plurality of existing anomaly detection models; and if an existing anomaly detection model is applicable to the first live data, update the existing model to incorporate the first live data; or if an existing anomaly detection model is not applicable to the first live data, generate a new anomaly detection model of a first event in the first live data; train the new anomaly detection model to recognize the first event in the first data; test the new anomaly detection model against second live data; and generate a live score of the first live data to indicate the likelihood that the first event is an anomaly; storing the new model with the plurality of existing models. The anomaly detection model may apply time differential analysis to determine which of the first live data to compare to the existing anomaly detection models. The time differential analysis may be performed by monitoring one or more event logs, process logs and file watcher logs for change over a monitored interval to identify one or more changed logs and comparing the changed logs to the existing anomaly detection models. The one or more changed logs may have changed in at least one of a size of a file, a number of lines of a file or a byte count of a file snapshot over the monitored interval. The live score may comprise: a first live score based on the frequency that the first event occurred during testing of the new anomaly detection model; and a second live score based on an assessment of token similarity between the first live event and the existing anomaly detection model or the new anomaly detection model; wherein the live score comprises a probability that the first event is anomalous based on the first live score and the second live score. The first live data may comprise a first moving live data and a first static live data; and wherein the live score is generated by comparing the first static live data to an event template in the existing anomaly detection model or the new anomaly detection model. The first live data may be collected via a decision guide that comprises one or more data collection methods starting with a least resource intensive collection method and if the first live data needed by the anomaly detection model is not obtained by the least resource intensive collection method, may direct the performance of progressively more resource intensive collection methods until the first live data needed by the anomaly detection model is collected. The first live data may comprise stitched together data from a plurality of data sources to allow the anomaly detection model to detect inconsistencies in the first live data collected from different data sources. The stitched together data may comprise event data wherein the user data may be labeled as third party data. The stitched together data may be produced by revalidating a UserID and an IP address outside of a system capture log.

In certain embodiments, an anomaly detection device for core banking systems is disclosed, comprising: a first sensor for detecting anomalous behavior on a core banking system; a second sensor for verifying that the first sensor remains active; a third sensor for detecting removal or corruption of the first sensor or the second sensor; and wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed. The first sensor may be configured to detect anomalous behavior by: collecting identifying information and first live data; generating a first live data template from the first live data; transmitting the first live data template to a data engineering engine configured to apply an anomaly detection model developed using live data to first live data collected by the first sensor; wherein the anomaly detection model is configured to: compare the first live data template to a plurality of existing anomaly detection models; and if an existing anomaly detection model is applicable to the first live data template, update the existing model to incorporate the first live data template; or if an existing anomaly detection model is not applicable to the first live data template, generate a new anomaly detection model of a first event in the first live data template; train the new anomaly detection model to recognize the first event in the first live data template; test the new anomaly detection model against second live data; and generate a live score of the first live data template to indicate the likelihood that the first event is an anomaly; storing the new model with the plurality of existing models; receiving the first live score at the first sensor. If the first live data template does not match any of the existing anomaly detection models, the anomaly detection module may be further configured to: remove at least one rapidly changing field from the first live data template to generate a set of tokens; and compare the set of tokens to the existing anomaly detection models; and if the set of tokens matches an existing anomaly detection model, generate a live score of the first live data to indicate the likelihood that the first event is an anomaly. The anomaly detection model may apply time differential analysis to determine which of the first live data to compare to the existing anomaly detection models. The time differential analysis may be performed by monitoring one or more event logs, process logs and file watcher logs for change over a monitored interval to identify one or more changed logs and comparing the changed logs to the existing anomaly detection models. The one or more changed logs may have changed in at least one of a size of a file, a number of lines of a file or a byte count of a file snapshot over the monitored interval. The live score may comprise: a first live score based on the frequency that the first event occurred during testing of the new anomaly detection model; and a second live score based on an assessment of token similarity between the first live event and the existing anomaly detection model or the new anomaly detection model; wherein the live score comprises a probability that the first event is anomalous based on the first live score and the second live score. The first live data may comprise a first moving live data and a first static live data; and wherein the live score is generated by comparing the first static live data to an event template in the existing anomaly detection model or the new anomaly detection model. The first live data may be collected via a decision guide that comprises one or more data collection methods starting with a least resource intensive collection method and if the first live data needed by the anomaly detection model is not obtained by the least resource intensive collection method, directs the performance of progressively more resource intensive collection methods until the first live data needed by the anomaly detection model is collected. The first live data may be collected via one or more kernel command to minimize use of the first sensor on the core banking system. The first live data may be collected via a decision guide using one or more of the following three steps: executing one or more kernel command to minimize use of the first sensor on the core banking system; and if the one or more kernel command does not return a desired data set: collected the first live data by querying a factory default path for the desired data set or by traversing a system configuration file used by. the core banking system on startup of one or more apps at each run level of the kernel. The first live data may comprise stitched together data from a plurality of log categories comprising event logs, process logs and watcher logs based on a timestamp. The stitched together data may comprise event data wherein the user data may be labeled as third party data. The stitched together data may be produced by revalidating a UserID and an IP address outside of a system capture log.

In certain embodiments, an anomaly detection system for core banking systems is disclosed, comprising: a data engineering engine configured for receiving live data from an endpoint anomaly detection system comprising; a first sensor for detecting anomalous behavior on a core banking system; a second sensor for verifying that the first sensor remains active; a third sensor for detecting removal or corruption of the first sensor or the second sensor; and wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed; applying an anomaly detection model developed using live data to first live data collected by the first sensor; wherein the anomaly detection model is configured to: comparing the first live data to a plurality of existing anomaly detection models; and if an existing anomaly detection model is applicable to the first live data, updating the existing model to incorporate the first live data; or if an existing anomaly detection model is not applicable to the first live data, generating a new anomaly detection model of a first event in the first live data; training the new anomaly detection model to recognize the first event in the first data; testing the new anomaly detection model against second live data; and generating a live score of the first live data to indicate the likelihood that the first event is an anomaly; storing the new model with the plurality of existing models. The live score may comprise: a first live score based on the frequency that the first event occurred during testing of the new anomaly detection model; and a second live score based on an assessment of token similarity between the first live event and the existing anomaly detection model or the new anomaly detection model; wherein the live score comprises a probability that the first event is anomalous based on the first live score and the second live score. The first live data may comprise a first moving live data and a first static live data; and wherein the live score is generated by comparing the first static live data to an event template in the existing anomaly detection model or the new anomaly detection model. The first live data may be collected via one or more kernel command to minimize use of a system memory on the core banking system. The first live data is collected via a decision guide using one or more of the following three steps: executing one or more kernel command to minimize use of the first sensor on the core banking system; and if the one or more kernel command does not return a desired data set: collected the first live data by querying a factory default path for the desired data set or by traversing a configuration file for the desired data set. The first live data may comprise stitched together data from a kernel journal and one or more additional markers from an app auditor. The stitched together data may comprise event data wherein the user data is labeled as third party data. The stitched together data may be produced by revalidating a UserID and an IP address outside of a system capture log.

In certain embodiments, an anomaly detection method for core banking systems is disclosed, comprising: receiving live data from an endpoint anomaly detection system comprising; a first sensor for detecting anomalous behavior on a core banking system; a second sensor for verifying that the first sensor remains active; a third sensor for detecting removal or corruption of the first sensor or the second sensor; and wherein each of the first sensor, the second sensor and the third sensor are configured to detect removal or corruption of either of the other two sensors at a periodic interval and to repair any of the other two sensors that has been corrupted or to reinstall any of the other sensors that have been removed; applying an anomaly detection model developed using first live data collected by the first sensor; comparing the first live data to a plurality of existing anomaly detection models; and if an existing anomaly detection model is applicable to the first live data, updating the existing model to incorporate the first live data; or if an existing anomaly detection model is not applicable to the first live data, generating a new anomaly detection model of a first event in the first live data; training the new anomaly detection model to recognize the first event in the first data; testing the new anomaly detection model against second live data; and generating a live score of the first live data to indicate the likelihood that the first event is an anomaly; storing the new model with the plurality of existing models. The live score may comprises: a first live score based on the frequency that the first event occurred during testing of the new anomaly detection model; and a second live score based on an assessment of token similarity between the first live event and the existing anomaly detection model or the new anomaly detection model; wherein the live score comprises a probability that the first event is anomalous based on the first live score and the second live score. The first live data may comprise a first moving live data and a first static live data; and wherein the live score is generated by comparing the first static live data to an event template in the existing anomaly detection model or the new anomaly detection model. The first live data may be collected via one or more kernel command to minimize use of a system memory on the core banking system. The first live data may be collected via a decision guide using one or more of the following three steps: executing one or more kernel command to minimize use of the first sensor on the core banking system; and if the one or more kernel command does not return a desired data set: may be collected the first live data by querying a factory default path for the desired data set or by traversing a configuration file for the desired data set. The first live data may comprise stitched together data from a kernel journal and one or more additional markers from an app auditor. The stitched together data may comprise event data wherein the user data is labeled as third party data. The stitched together data may be produced by revalidating a UserID and an IP address outside of a system capture log.

Sensor Application

Introduction

In certain embodiments, a sensor application may be a daemon type service, that audits all activities on the devices it's installed on. It may be a Linux or Unix sensor. These collected activities logs may be stitched(associated) with user login session and a parent process that triggered all the other child or grandchild processes. These collected activities logs may be encrypted and uploaded to an analytics station, for further monitoring and analysis.

In certain embodiments, the sensor implementation may be broken down into two major components:

    • 1) Application Installation on the device using OS kernel hooks or sensors
    • 2) Application (itself) that collects all activities and stitches them with Users Session (contain remote IP address or physically logged in) and creates a custom audit log or activities logs of the device.

In certain embodiments, the sensor agent that resides in a client device, Server or any Linux/Unix Machine may use Three (3) Kernel Hooks or sensors to ensure the Application is always Present respawn and run even under the described given circumstance.

    • 1 If any logged in user, (with the highest privilege) tries to stop the daemon service.
    • 2. If any logged in user, (with the highest privilege) tries to kill the sensor application using the Task-Manager (using the Application processes ID)
    • 3. If the Sensor Application file is corrupted (by some other cleanup or malware application)
    • 4. If the Sensor Application older is deleted from the system.

In certain embodiments, Present may mean registered using Daemon, SystemD or Initd Service to the OS Kernel; Running may mean all task running on a operating system must have an Operating system assigned Process ID or else they are halted; and Kernel Hooks may mean sensors that are securely cinched with the kernel of the operating System. In certain embodiments, even if the User has deleted one or more of the kernel hooks or sensors, the other sensors will detect that condition of the sensor application and restore it to its normal state and re-run the sensor application.

In certain embodiments as shown in FIG. 1, HookOne 150, HookTwo 160, and HookThree 170 may be three different sensor applications, installed on a client device. The client device may be a core banking system or connected to one or more core banking systems. HookOne 150 may be a first sensor. The client device may include User Space 100, Operating Space 110, Kernel 180 and Device Drivers 190.

In certain embodiments, HookONE 150, HookTWO 160 and HookTHREE 170 may be registered with the Operating System 110 using one of the preferred configurations with the OS specification, which may include but not be limited to Daemon or service or Cron or SystemD is accordance with configuration guideline provided by the OS Manufacture and/or distributed company. The combination of the three sensors HookONE 150, HookTWO 160 and HookTHREE 170 may cooperate to ensure that the sensor application, HookOne 150 is always auditing and has not lost track of audit, for example, if it was temporarily disabled for audit by some Admin user.

HookOne 150 may be a first sensor that may be written in C++, Java or Golang or other suitable language that reads OS Data and may include Main Sensor Package 130.

HookTwo 160, may be a second sensor that may check on sensor one/HookOne 150 (Application) using Crontab 140 and restart it if, it was stopped as a service register to the OS or the Processes were killed and are no longer running. The checks may be performed on a periodic interval, which may be for example a 2 min interval.

HookThree 170, may be a third sensor that may repair and replace damaged files of sensor one/HookONE 160 using repair package 120. HookThree 170 may store a backup of HookOne 150 in a different folder as a zip file and if necessary, may unzip and replace the existing HookONE 150.

Citations

US 7,159,237 B2 - Method and system for dynamic network intrusion monitoring, detection and response
A probe attached to a customer's network collects status data and other audit information from monitored components of the network, looking for footprints or evidence...

US 7,650,638 B1 - Network security monitoring system employing bi-directional communication
The present invention provides for the receipt of a heartbeat message transmitted from a software agent within a host machine to a server-based agent manager....

US 8,104,087 B2 - Systems and methods for automated data anomaly correction in a computer network
Systems and methods for correcting an anomaly in a target computer that is part of a network of computers. An anomaly is detected in data...

US 2018 52,907 A1 - Method And System For Real-Time, False Positive Resistant, Load Independent And Self-Learning Anomaly Detection Of Measured Transaction Execution Parameters Like Response Times
A combined transaction execution monitoring, transaction classification and transaction execution performance anomaly detection system is disclosed. The system receives and analyzes transaction tracing data which...

US 8,069,230 B2 - System and method of configuring a network
Methods and systems for configuring a network are provided. A method may include monitoring properties of a connection between a computing device and a network....

US 2007 192,400 A1 - Anomaly management scheme for a multi-agent system
An anomaly management method is provided for a multi-agent system (MAS) in which a plurality of application agents are arranged to be capable of interacting...

US 2015 341,376 A1 - DETECTION OF ANOMALY IN NETWORK FLOW DATA
Disclosed is a method 101 to be used on collected network data flow 116 associated with a network 100; the method 101 includes: an anomaly-detection...

US 9,813,432 B2 - Tracking anomaly propagation at the network level
In one embodiment, a device in a network monitors one or more metrics regarding network traffic associated with a particular application. The device detects an...

US 8,291,258 B2 - High availability for network security devices
In one example, a backup intrusion detection and prevention (IDP) device includes one or more network interfaces to receive a state update message from a...

US 9,021,583 B2 - System and method for network security including detection of man-in-the-browser attacks
A method is performed in a network security system implemented in a computer or electronic device that is coupled to secured online resources for detecting...

US 9,729,416 B1 - Anomaly detection using device relationship graphs
Embodiments are directed to monitoring network traffic in a network. A device relation model that may be comprised of two or more nodes and one...

PatentSwarm provides a collaborative workspace to search, highlight, annotate, and monitor patent data.

Start free trial Sign in