Patent Description:
Stored data and applications are often prone to malicious cyber-attacks depending on their storage location and associated network connections. To monitor for intrusions and malware, organizations utilize monitoring systems that detect behavioral anomalies. Conventional monitoring systems require, however, manual definition of alert thresholds for key application metrics. Setting alert thresholds is firstly labor intensive. Alert thresholds also prevent detection of abnormal behavior when key metrics are not within intervals defined by an administrator. For example, an alert threshold set by the administrator may identify a CPU usage percentage greater than <NUM>% on a given server during the time between <NUM>:<NUM> am and <NUM>:<NUM> am as anomalous. However, a malicious entity utilizing only <NUM>% of the CPU processing would not be detected.

Other the other hand, alert thresholds may also lead to several false positives. For example, an authorized user may in fact utilize the server during the time window described above such that <NUM>% of the CPU processing is used at one point. Despite the usage occurring by an authorized user, a conventional monitoring system would trigger a false positive when declaring an anomaly. Depending on how the system is designed to react to a trigger, access by the authorized user can be made difficult or impossible. Accordingly, there is a need for an improved approach to anomaly detection. Document <CIT> is a relevant document in the field of monitoring the behavior of an application.

Aspects of the disclosure relate to the field of detecting a behavioral anomaly in an application. In one exemplary aspect, a method may comprise retrieving historical usage information for an application on a computing device. The method may comprise identifying at least one key metric from the historical usage information. The method may comprise generating a regression model configured to predict usage behavior associated with the application based on data associated with the at least one key metric. The method may comprise generating a statistical model configured to identify outliers in the data associated with the at least one key metric. Subsequent to generating the regression model and the statistical model, the method may comprise receiving usage information in real-time for the application. The method may comprise predicting, using the regression model, a usage pattern for the application indicating expected values of the at least one key metric. In response to determining that the usage information received in real-time does not correspond to the predicted usage pattern, the method may comprise determining via the statistical model whether the usage information comprises a known outlier. In response to determining that the usage information does not comprise the known outlier, the method may comprise detecting the behavioral anomaly. The method may comprise generating an alert indicative of the behavioral anomaly.

In one example, the historical usage information occurred within a time interval that is periodic, and predicting the usage pattern further comprises using a version of the regression model associated with the time interval.

In one example, the statistical model is a probability distribution that highlights data points associated with the at least one metric that are not anomalous.

In one example, the at least one key metric comprises at least one of (<NUM>) client connections, (<NUM>) latency, (<NUM>) number of account lookups, (<NUM>) bytes read, and (<NUM>) number of file lookups.

In one example, in response to determining that the usage information received in real-time corresponds to the predicted usage pattern or that the usage information comprises the known outlier, the method may comprise determining that the behavioral anomaly has not occurred and not generating the alert.

In one example, determining that the usage information received in real-time does not correspond to the predicted usage pattern further comprises determining that an average difference, between values of the at least one key metric from the usage information received in real-time and the expected values of the at least key metric according to the predicted usage pattern, exceeds a threshold difference.

In one example, the method may comprise receiving a response to the alert indicating that the behavioral anomaly is a false positive, and automatically increasing the threshold difference.

In one example, the method may comprise receiving a response to the alert indicating that the behavioral anomaly is a false positive and adjusting both the regression model and the statistical model based on the usage information received in real-time, wherein the regression model is retrained on an updated dataset and the statistical model indicates an updated outlier.

It should be noted that the methods described above may be implemented in a system comprising a hardware processor. Alternatively, the methods may be implemented using computer executable instructions of a non-transitory computer readable medium.

The above simplified summary of example aspects serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects of the present disclosure. Its sole purpose is to present one or more aspects in a simplified form as a prelude to the more detailed description of the disclosure that follows. To the accomplishment of the foregoing, the one or more aspects of the present disclosure include the features described and exemplarily pointed out in the claims.

The invention is defined in the independent claims <NUM> and <NUM>. Exemplary aspects are described herein in the context of a system, method, and computer program product for detecting behavioral anomalies in applications. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other aspects will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of the example aspects as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.

In order to address the shortcomings of conventional monitoring systems, an anomaly detection system should require no manual work to train models, work for any type of device, automatically detect anomalies, tune the definition of anomalies based on user needs, adapt thresholds such that anomalies can be detected independent of system load, be highly accurate, and decrease alert-spam (e.g., false positives).

<FIG> is a block diagram illustrating an exemplary system <NUM> for detecting behavioral anomalies in applications. Anomaly detection system (ADS) <NUM> may be a module of a security software such as an anti-virus software. ADS <NUM> may be stored in storage device <NUM> to monitor for anomalies on storage device <NUM>, or may be stored on a different device and communicate with storage device <NUM> over a network such as the Internet. ADS <NUM> may be comprised of multiple components such as data retriever <NUM>, machine learning module <NUM>, statistical module <NUM>, and security module <NUM>.

In one example, data retriever <NUM> of ADS <NUM> may be configured to retrieve historical usage information for an application on a computing device (e.g., computer system described in <FIG>). The historical usage information may include details such as when the application was accessed, by whom, device state information (e.g., RAM consumption, CPU usage percentage, storage space, etc.), requests made to the application, requests made by the application, network connections utilized by the application (e.g., IP addresses), etc. In some examples, the historic usage information may account for all information since the application was installed on the computing device. In some examples, the historic usage information may be for a given time interval (e.g., June <NUM>, <NUM> at <NUM>:<NUM> am to June <NUM>, <NUM> at <NUM>:<NUM> am). In some examples, the historic usage information may be for a periodic time interval. For example, data retriever <NUM> may retrieve information for every Monday since the application was installed. Based on the data specifically for Monday, ADS <NUM> can predict behavior for a subsequent Monday.

From the historic usage information, data retriever <NUM> may identify at least one key metric. A key metric may be, in association with the application, a number of client connections, command and execution latency, a number of account lookups, an amount of bytes read, and a number of file lookups. It should be noted that many other key metrics may exist as well, such as an amount of bytes written, a usage time length, features accessed in the application, etc. Data retriever <NUM> may parse the historic usage information to identify at least one key metric and generate a data structure with data associated with the at least one key metrics. For example, if the key metric identified is the amount of bytes read in association with the application, the data structure may include time stamps and the respective numbers of bytes read. This data structure is training data <NUM> and is utilized by ADS <NUM> to generate machine learning module <NUM>, which is configured to predict usage behavior associated with the application based on data associated with the at least one key metric.

In some examples, machine learning module <NUM> may be a one-class support vector machine (SVM) used for novelty detection. The one-class SVM may be trained used key metrics acquired from historic usage information. Because anomalies may be quite rare, a majority of the data <NUM> may only indicate correct usage of an application. The one-class SVM enables usage data that looks different from training data <NUM> (i.e., the correct usage key metrics) to be classified as an anomaly.

In some examples, machine learning module <NUM> may be a machine learning algorithm that targets a prediction value based on independent variable(s). In some examples, if only one key metric is utilized, machine learning module <NUM> may be using a linear regression model. In other examples, if multiple key metrics are considered when generating the module <NUM>, a polynomial regression or a multi-variable linear regression model is used. The goal of the machine learning module <NUM> is to learn how the application has historically behaved, and then predict how the application will behave in the future. For example, if the application had a certain latency and a certain number of lookups for the past ten Mondays between <NUM>:00am and <NUM>:01am, then the application can expect to have the same latency and lookups in an upcoming Monday. Machine learning module <NUM> may be trained and tested on training data <NUM> using a teaching method such as stochastic gradient descent.

ADS <NUM> may also generate statistical module <NUM> configured to identify outliers in the data associated with the at least one key metric. The statistical module uses a probability distribution that highlights data points associated with the at least one key metric that are not anomalous. Suppose that the key metric is the number of bytes read. For the time interval in consideration such as Monday between <NUM>:<NUM> am and <NUM>:<NUM> am, ADS <NUM> may create a probability distribution indicative of the bytes read. In this probability distribution, the number of bytes read that have the lowest probability of occurring (and yet having occurred) are considered outliers. For example, <NUM>% of the time, the application may have had between <NUM> million bytes and <NUM> million bytes read in the given interval. However, <NUM>% of the time, the application had over <NUM> million bytes read in the given interval. In some examples, ADS <NUM> may set probability thresholds to identify outliers. In this case, any number of bytes having a probability of <NUM>% of less are considered outliers.

Machine learning module <NUM> and statistical module <NUM> together provide a way to predict how an application will likely behave and how the application may behave in rare instances. There may be instances when conventional monitoring systems declare than an activity is an anomaly and malicious. However, the activity may be associated with an outlier that is caused by an authorized user of the computing device.

Subsequent to generating the machine learning model (e.g., a regression model) and the statistical model, data retriever <NUM> of ADS <NUM> may receive usage information in real-time for the application. ADS <NUM> may predict, using machine learning module <NUM>, a usage pattern for the application relative to the at least one key metric. The usage pattern indicates a predicted set of values of the key metric at a future time. For example, machine learning module <NUM> may be provided with a time interval as an input and will output an expected number of bytes read during the interval. In this case, the output may be a data structure comprising a number of bytes read per second.

Security module <NUM> may be a module configured to compare the predicted usage pattern with a real-time pattern. For example, the output of machine learning module <NUM> may be <NUM> data points for a time interval associated with Monday between <NUM>:00am and <NUM>:01am (one for each second). The data points may be an expected number of bytes read. Data retriever <NUM> may also provide <NUM> data points for the same time interval. These data points may be the actual number of bytes read.

In some examples, determining that the usage information received in real-time does not correspond to the predicted usage pattern comprises determining that an average difference, between values of the at least one key metric from the usage information received in real-time and the expected values of the at least key metric according to the predicted usage pattern, exceeds a threshold difference. For example, the average number of bytes read may be <NUM> million during the time interval and the average number of predicted bytes read may be <NUM> million. The threshold difference may be an initial value equal to <NUM> million. The difference between the average values is <NUM> million, which exceeds the threshold difference. Accordingly, security module <NUM> may determine that the usage information is a potential anomaly. It should be noted that the average number can be a mean value, a standard deviation value, a median value, etc..

In some examples, security module <NUM> may compare each respective data point and determine a percent error in the prediction. For example, security module <NUM> may determine a percent error between the first data point in the predicted usage pattern and the first data point of the actual usage. For each percent error, if the percent error is greater than a threshold percent error (e.g., <NUM>%), security module <NUM> may determine that the received data (i.e., usage information) does not correspond to the usage pattern. To determine whether the usage information is a potential anomaly, security module <NUM> may determine the number of data points with percent errors greater than the threshold percent error. If a majority of the data points have percent errors exceeding the threshold percent error, the usage information may be identified as a potential anomaly. The change from "potential anomaly" to "anomaly" is then based on a statistical model.

More specifically, security module <NUM> determines whether the received usage information comprises a known outlier rather than an anomaly via statistical module <NUM>. For example, a known outlier may show that the application once had slightly less than <NUM> million bytes read on average during the given time interval (while the regression model predicted at most <NUM> million). If the received usage information also shows <NUM> million bytes read for a brief period of time within the time interval, the received usage information can be considered an outlier. However, if the usage information shows over a much higher number of bytes read (e.g., <NUM> million bytes read), security module <NUM> may determine that this amount of bytes were never read in the past and thus this may be anomalous. Thus, in response to determining that the usage information does not comprise an outlier, security module <NUM> may detect the behavioral anomaly, and generate an alert indicative of the behavioral anomaly. On the other hand, in response to determining that the usage information received in real-time corresponds to the predicted usage pattern or that the usage information comprises the known outlier, determining that the behavioral anomaly has not occurred and not generating the alert.

In some examples, an anomaly may be detected when a window comprising several outliers is detected. For example, in response to receiving the usage information, ADS <NUM> may generate another statistical model of the received usage information (specifically if the predicted behavior does not match, to conserve processing power). The new received usage information may indicate that during the time interval, the number of bytes read was approximately <NUM> million <NUM>% of the time and only <NUM> million <NUM>% of the time. This prolonged percentage for reading more than <NUM> million bytes may be compared to an anomalous probability threshold (e.g., <NUM>%). When the percentage is greater than the anomalous probability threshold, the determination can be made that the number of bytes is an outlier, but the probability of the outlier occurring is high enough to be considered an anomaly.

In some examples, in order to detect a behavioral anomaly when an outlier is detected, security module <NUM> determines if more than a threshold number of outlying key metrics are detected at once. For example, an outlying key metric may be the number of bytes read. Another outlying key metric may be the amount of latency. Suppose that of <NUM> tracked key metrics, <NUM> have outliers. In response to determining that a threshold amount of key metrics have outliers, security module <NUM> may detect a behavioral anomaly. In some examples, security module <NUM> may detect a behavioral anomaly specifically if the amount of key metrics that have outliers are independent key metrics. An independent key metric may be a key metric that does not get affected by another key metric. For example, the number of bytes read may be correlated to the number of file lookups. Accordingly, if outliers are detected in both key metrics, only one outlier is counted for the purposes of comparing with the threshold amount. In contrast the number of bytes read may be unrelated to the number of accounts on an application. Accordingly, if outliers are detected in both key metrics, two outliers may be counted. ADS <NUM> may keep track of all key metrics and each of their independent key metric counterparts in a database.

It should be noted that the use of the statistical model eases the reliance on thresholds by machine learning module <NUM>. This is because even if the application is not used as historically expected (e.g., percent errors or average difference is too different from a threshold percent error or threshold difference, respectively), the check for outliers minimizes the chance of false positives/negatives. This is because usage that may be normally misclassified as an anomaly may be correctly classified as normal usage if the usage turns out to be an outlier according to the statistical model.

Furthermore, the thresholds used by modules <NUM> and <NUM> may be adjusted based on whether usage classified as an anomaly is in fact an anomaly. For example, security module <NUM> may generate an alert indicating that usage of the application during a given time interval is an anomaly. This alert may be generated on a computing device of a user (e.g., an administrator of device <NUM>) in the form of an email, text, audio output, application notification, etc. In response to generating the alert, ADS <NUM> may receiving a response to the alert indicating that the behavioral anomaly is a false positive. For example, the alert may request confirmation whether the usage was by the user or an unauthorized entity. The user may indicate that the usage was authorized. Accordingly, security module <NUM> may adjust the thresholds used by modules <NUM> and <NUM> (e.g., by easing them). In the example of the threshold difference associated with average values of key metrics (both predicted and actual), security module <NUM> may automatically increase the threshold difference.

In some examples, in response to receiving a response to the alert indicating that the behavioral anomaly is a false positive, security module <NUM> may also adjust both the regression model and the statistical model based on the usage information received in real-time. More specifically, ADS <NUM> may retrain the regression model using an updated dataset where the collected usage information received in real-time is classified as non-anomalous and may regenerate the statistical model, which may identify the usage information as an outlier.

<FIG> is a flow diagram illustrating method <NUM> for detecting behavioral anomalies in applications. At <NUM>, data retriever <NUM> retrieves historical usage information for an application on a computing device. At <NUM>, data retriever <NUM> identifies at least one key metric from the historical usage information. At <NUM>, anomaly detection system <NUM> generates a machine learning module <NUM> configured to predict usage behavior associated with the application based on data associated with the at least one key metric. At <NUM>, anomaly detection system <NUM> generates a statistical module <NUM> configured to identify outliers in the data associated with the at least one key metric.

At <NUM>, data retriever <NUM> receives usage information in real-time for the application. At <NUM>, anomaly detection system <NUM> predicts, using the machine learning module <NUM>, a usage pattern for the application relative to the at least one key metric. At <NUM>, anomaly detection system <NUM> determines whether the usage information corresponds to the usage pattern. In response to determining that the usage information does not correspond to the usage pattern, at <NUM>, anomaly detection system <NUM> determines whether the usage information comprises a known outlier. In response to determining that the usage information does not comprise a known outlier, at <NUM>, security module <NUM> detects a behavioral anomaly and at <NUM>, security module <NUM> generates an alert. It at <NUM> or <NUM>, anomaly detection system <NUM> determines either that the usage information corresponds to the usage pattern or that the usage information comprises a known outlier, method <NUM> returns to <NUM> as anomaly detection system <NUM> continues to monitor for behavioral anomalies.

<FIG> is a block diagram illustrating a computer system <NUM> on which embodiments of systems and methods for detecting behavioral anomalies in applications may be implemented. The computer system <NUM> can be in the form of multiple computing devices, or in the form of a single computing device, for example, a desktop computer, a notebook computer, a laptop computer, a mobile computing device, a smart phone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

As shown, the computer system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, and a system bus <NUM> connecting the various system components, including the memory associated with the central processing unit <NUM>. The system bus <NUM> may comprise a bus memory or bus memory controller, a peripheral bus, and a local bus that is able to interact with any other bus architecture. Examples of the buses may include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<NUM>C, and other suitable interconnects. The central processing unit <NUM> (also referred to as a processor) can include a single or multiple sets of processors having single or multiple cores. The processor <NUM> may execute one or more computer-executable code implementing the techniques of the present disclosure. For example, any of commands/steps discussed in <FIG> may be performed by processor <NUM>. The system memory <NUM> may be any memory for storing data used herein and/or computer programs that are executable by the processor <NUM>. The system memory <NUM> may include volatile memory such as a random access memory (RAM) <NUM> and non-volatile memory such as a read only memory (ROM) <NUM>, flash memory, etc., or any combination thereof. The basic input/output system (BIOS) <NUM> may store the basic procedures for transfer of information between elements of the computer system <NUM>, such as those at the time of loading the operating system with the use of the ROM <NUM>.

Computer readable program instructions for carrying out operations of the present disclosure may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, through the Internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform embodiments of the present disclosure.

In various examples, the systems and methods described in the present disclosure can be addressed in terms of modules. The term "module" as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or FPGA, for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a computer system. Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

In the interest of clarity, not all of the routine features of the embodiments are disclosed herein.

Furthermore, it is to be understood that the phraseology or terminology used herein is for the purpose of description and not of restriction, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combination with the knowledge of those skilled in the relevant art(s). Moreover, it is not intended for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.

Claim 1:
A computer implemented method for detecting a behavioral anomaly in an application, the method comprising:
retrieving historical usage information for an application on a computing device;
identifying data associated with at least one key metric from the historical usage information;
generating a regression model configured to predict usage behavior associated with the application based on the data associated with the at least one key metric;
generating a statistical model configured to identify known outliers in the data associated with the at least one key metric;
subsequent to generating the regression model and the statistical model, receiving usage information in real-time for the application;
predicting, using the regression model, a usage pattern for the application indicating expected values of the at least one key metric;
in response to determining that the usage information received in real-time does not correspond to the predicted usage pattern, determining via the statistical model whether the usage information comprises a known outlier, wherein the known outlier is a historical value of the at least one key metric that is not anomalous;
in response to determining that the usage information does not comprise the known outlier, detecting the behavioral anomaly; and
generating an alert indicative of the behavioral anomaly.