Patent Description:
Traditional techniques for authenticating a user to access a computing device and/or software application require login credentials typically including a username, password, and in some cases, a multi-factor authentication technique such as a code or biometric data. While such authentication techniques are helpful in initially confirming the identity and access level of the user, they offer little, if any protection, when login credentials are stolen or otherwise obtained by malicious actors. <NPL>, discloses applying a Gaussian Mixture Model for speaker recognition where for a reference group of speaker models, the objective is to find a speaker identity whose model has a maximum posterior probability for an input feature-vector sequence.

In one aspect, there is provided a method for Bayesian continuous user authentication according to claim <NUM>. The method comprises iteratively receiving a sequence of observed behavior data that collectively characterizes interaction of an active user with at least one computing device or software application, wherein the active user is presumed to be the account owner, that is, the user associated with login credentials. A sequence of events within the observed behavior data can be identified. Each of the events are scored using a universal background model that generates first scores that characterize an extent to which each event or history of events is anomalous for a particular population of users. Further, each of the events are scored using a user model that generates second scores that characterizes an extent to which each event or history of events is anomalous for the particular user who owns the account. The first scores and the second scores are smoothed using a smoothing function which upweights the first scores and/or the second scores based on recency. A probability that the active user is the account owner associated with the user model is determined based on the smoothed first scores and the smoothed second scores. Data can then be provided which characterizes the determined probability.

In some variations, after login credentials are received for the account owner, a user model is selected among a plurality of available user models which is associated with the login credential.

The observed behavior data can include one or more of: keystroke data, logon activity, mouse movements, initiated processes, network activity, registry activity, file activity. The observed behavior data can include one or more of: a timestamp, an active process identifier, a device identifier, keystroke information, mouse information, process start information, network activity information, registry activity information, file activity information, logon activity information, account name, computer name, event code, logon process, logon type, record number, subject, or a source network IP address. The observed behavior data can include one or more of: a timestamp, an active process identifier, a device identifier, keystroke information (including typed character with upstroke vs. downstroke), mouse information (including spatial coordinates), process start information (including identifiers for the process start and process start parent, the command line expression used to execute a process that is started and its parent, and the file location of the process that is started and its parent), network activity information (including the instigating process identifier, the source IP address, destination IP address, source port, destination port, packet size, and incoming vs. outgoing direction), registry activity information (including the instigating process identifier, type of registry change, and whether the event occurs in a registry location that determines persistence), file activity information (including the instigating process identifier, activity type (create, delete, etc.), whether it is alternating data stream (true or false); whether it is delete pending (true or false); whether it is a directory (true or false); whether it is hidden (true or false); whether it is on removable drive (true or false; whether it is read only (true or false); its suspected file type (for example pdf, PE, etc.); its write position (where in file to write), and logon activity information (including account name (for example administrator, guest, etc.), computer name, event code (for example <NUM>, <NUM>, etc.), logon process (for example Advapi, Kerberos, etc.), logon type (for example, interactive, unlock, etc.), record number (an enumeration of logon event), subject (that accompanies each event code, for example "An account was successfully logged on"), and/or a workstation name (name of computer user is sitting at).

The smoothing function can include an exponential moving average smoothing function with, can optionally, include bias correction.

The universal background model can be a mixture model trained using historical observed behavior data from a population of users that interacted with the at least one computing device or software application. The mixture model can be a mixture of distributions from an exponential family. The mixture of distributions from the exponential family can be a Gaussian mixture model.

The provided data can include a posterior user probability where smoothing is used to construct the likelihood. The smoothing can be exponential smoothing.

The joint likelihoods for both the user model and universal background models can be defined by the equation below <MAT> where E<NUM>:T are behavioral events <NUM>,. ,T that have been observed so far, where Ui=Us refers to an event where the active user is the account owner, where Ui=Uo refers to the event where the active user is a person other than the account owner, where P(Et | Ui) is the likelihood of behavioral event Et assuming that the active user is Ui, where P(Et | Us) is a probability score given by the user model, where P(Et | Uo) is a probability score given by the universal background model, and where α refers to a smoothing parameter for an exponential moving average with bias correction.

The posterior user probability with exponentially smoothed log likelihoods can be defined by: <MAT> where P(Us) refers to a prior probability that the active user is the presumed user, and where P(Uo) = <NUM>-P(Us) refers to a prior probability that the active user is not the presumed user.

Access to the at least one computing device or software application can be prevented or otherwise limited or restricted when the probability is above a threshold. Limiting access can include one or more of: reducing permissions granted to the active user to the at least one computing device or software application, preventing access to the at least one computing device or software application, triggering an endpoint detection and response routine to log actions of active the user, or logging the observed behavior data.

In some variations, the first scores generated by the universal background model and the second scores generated the user model are both probability scores that are represented as likelihoods.

Non-transitory computer program products (i.e., physically embodied computer program products, non-transitory computer readable media, etc.) are also described that store instructions, which when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform operations herein. Such computing systems can be connected and can exchange data and/or commands or other instructions or the like via one or more connections, including but not limited to a connection over a network (e.g., the Internet, a wireless wide area network, a local area network, a wide area network, a wired network, or the like), via a direct connection between one or more of the multiple computing systems, etc..

The current subject matter is directed to advanced techniques for continuously authenticating a user of a computing device and/or software application. In particular, as will be described in further detail below, a universal background model (sometimes referred to herein as UBM) based on user interaction for a population of users is used in connection with a user-specific model to determine, based on the observed behavior of the user, a probability that the user at any given time is the account owner, i.e., the user associated with the login credentials. In some variations, a Bayesian approach is used which generates posterior user probabilities using a proxy likelihood constructed by exponential smoothing in the per-observation log likelihood terms.

Initially, with reference to diagram <NUM> of <FIG>, at <NUM>, login credentials associated with the account owner are entered (for example, via a graphical user interface and/or by using one or more biometric sensors, etc.). After successfully entering the login credentials, at <NUM>, an iterative process commences in which observed user behavior is monitored. This observed user behavior relates to aspects of the computing device, software application(s), operating system, and/or network activity generated in connection with the user's interaction with at least one computing device and/or one software application.

The observed behavior data can include one or more of: a timestamp, an active process identifier, a device identifier, keystroke information (including typed character with upstroke vs. downstroke), mouse information (including spatial coordinates), process start information (including identifiers for the process start and process start parent), the command line expression used to execute a process that is started and its parent, and the file location of the process that is started and its parent), network activity information (including the instigating process identifier), the source IP address, destination IP address, source port, destination port, packet size, and incoming vs. outgoing direction), registry activity information (including the instigating process identifier), type of registry change, and whether the event occurs in a registry location that determines persistence), file activity information (including the instigating process identifier, activity type (create, delete, etc.), whether it is alternating data stream (true or false); whether it is delete pending (true or false); whether it is a directory (true or false); whether it is hidden (true or false); whether it is on removable drive (true or false; whether it is read only (true or false); its suspected file type (for example pdf, PE, etc.); its write position (where in file to write), and logon activity information (including account name (for example administrator, guest, etc.), computer name, event code (for example <NUM>, <NUM>, etc.), logon process (for example Advapi, Kerberos, etc.), logon type (for example, interactive, unlock, etc.), record number (an enumeration of logon event), subject (that accompanies each event code, for example "An account was successfully logged on"), a source network IP address, and a workstation name (name of computer user is sitting at).

Further, the observed user behavior can characterize actions of the active user (which might not be the account owner) including how many times that a particular file was accessed, how the particular file was used, when the particular file was first detected, location of a registry persistence point, use of a registry by a software routine to allow itself to persist after a reboot, registry keys being used for malware persistence to survive reboots, files being created or modified with content that can be directly executed or interpreted for execution, files being downloaded that contain executable or interpretable code, processes being created with excessive or unexpected permissions, users with excessive permissions or users obtaining permissions through non-standard mechanisms, network connections that are used in non-standard ways, network connections that are used in ways that exhibit malicious command and control activities, network connections that are used to exfiltrate files that contain sensitive information, network connections that connect to IP addresses that are considered suspect due to geo-location or reputation, processes that exhibit control over or inject code into other processes, processes that change user ownership during execution, and the like.

Using data characterizing the observed user behavior, at <NUM>, one or more sequence of events can be identified. Such identification can be performed using various techniques including which can involve parsing, vectorization, and the like to represent raw data at a higher level of abstraction which is more useful for modeling. For instance, a sequence of raw keystroke events of the form (timestamp, character, upstroke or downstroke) may be represented downstream as a sequence of n-gram duration vectors, where an n-gram duration vector contains the durations of the button presses and transitions for each of n sequentially typed characters. Events can then be identified from these n-gram duration vectors (e.g., the event that the Mahalanobis distance is less than some quantity), and such events can be assigned probability scores.

The sequence of events can be input, at <NUM>, into a universal background model which generates first scores indicating whether the events, a grouping of events, and/or the entire sequence of events is anomalous, unexpected, or otherwise atypical in relation to a population of users. In some cases, the universal background model is trained using observed behavior data / events from the population of the users when accessing the same computing device(s) and/or software application(s) while, in other cases, the universal background model is trained using observed behavior data / events from the population of the users when accessing different computing device(s) and/or different software application(s). Further, in some cases, the universal background model is trained with a representative population of benign users, whereas in other cases, the universal background model is trained with a representative population of malicious users, and in still other cases, the universal background model trained with a representative population of both malicious and benign users.

In addition, the sequence of events can be input, at <NUM>, into a user model (i.e., a model specific to the user associated with the login credentials) to generate second scores indicating whether the events, a grouping of events, and/or the entire sequence of events is anomalous, unexpected, or otherwise atypical in relation to past observed behavior of the user. In some cases, the user model is trained using observed behavior data / events from the user when accessing the same computing device(s) and/or software application(s) while, in other cases, the universal background model is trained using observed behavior data / events from the user when accessing different computing device(s) and/or different software application(s).

Subsequently, at <NUM>, a smoothing function can be used to weight the first scores and the second scores (e.g., upweight recent scores, etc.). A probability can then be determined, at <NUM>, based on the smoothed first scores and the smoothed second scores, that the active user is the user associated with the user model / login credentials. Thereafter, at <NUM>, data can be provided (e.g., loaded into memory, stored in physical persistence, displayed in a graphical user interface, transmitted to a remote computing devices, etc.) indicating the probability. The operations of <NUM>-<NUM> can be implemented as an iterative process so that as additional user behavior data is received, the probability can be update / modified (thus providing continuous user authentication). For example, a new probability can be provided, at <NUM>, every time or potentially every time there is a new datum, at <NUM>, where a datum could be something as fine-grained as a half keystroke, a change in mouse coordinates at some sampling rate, a new process start, and the like.

Let <IMG> denote a finite population of users, Us ∈ <IMG> denote a particular user (which is sometimes referred to herein as the presumed user, account owner, or self), <MAT> denote a sequence of observed raw behavioral data, and <MAT> denote a sequence of parsed events determined by the raw behavioral data. In the presentation herein, we assume that Et = f(Xt) for each t. This assumption is often just a convenient fiction, and only approximately true, since, in practice, each Et can depend on observations over a small lookback window, Xt,. For instance, for keystrokes behavioral data, each Xt may contain the tuple (timestamp, character identity, upstroke or downstroke), and Et may be the event that the Mahalanobis distance of the (2n-<NUM>)-dimensional duration vector of a typed n-gram with respect to the user's learned distribution of duration vectors for that n-gram is smaller than or equal to the observed Mahalanobis distance. In this example, a single raw input, Xt. describes only a half of a keystroke, so when working with, say, bigrams (n=<NUM>), at least four raw observations, Xt,. , Xt-<NUM>, would be needed to construct Et.

The user model for a given account owner, Us, maps a stream of observed raw behavioral data (i.e., the observed behavior data) to a stream of event scores (i.e., the second scores) where each event score takes the form P(Et | Us). By Bayes law, the posterior probability that the self has generated the event history can be determined by <MAT>.

For any given user Us, the goal is to determine if that user or some other user is generating the data, so U = {Us, Uo} (where the subscripts are meant to suggest self and other) can be decomposed such that the denominator of (<NUM>) decomposes as <MAT> and P(E<NUM>:T| Uo) is taken to be a joint likelihood of the parsed events as given by a universal background model. The universal background model is a model which averages across many user models, e.g. a mixture model where the mixture is taken over a representative set of users which may or may not include malicious users. Note that P(Us) and P(Uo) are prior probabilities, and P(Us) + P(Uo) = <NUM>.

The joint conditionals, P(E<NUM>:T | Ui) for i in {o, s}, can then be factorized. The typical independent and identical distributed (i. d) assumption would lead the following to be used: <MAT>.

However, instead, the following generalization can be used: <MAT> where it is noted that.

The generalization in (<NUM>) supports the construction of a likelihood which upweights the contribution of observations in accordance with their recency. For instance, the logarithm of the event scores can be smoothed by means of an exponential moving average with parameter α, where α is the weight on an incoming value, and with bias correction, thereby determining a value , wtα, T, for (<NUM>). Equivalently, wtα, T is the weight given to terms by an exponential moving average with parameter α, without bias correction, and with initial value of <NUM>. Therefore, event score weights can be as follows: <MAT> with effective sample size <MAT> which incidentally equals the bias correction term.

By substituting (<NUM>) and (<NUM>) into (<NUM>), the following can be obtained: <MAT> More specifically, this is a joint likelihood of behavioral events where an exponential moving average has been applied to the logarithms of the likelihoods of the individual behavioral events.

By substituting (<NUM>) into (<NUM>) and (<NUM>), a posterior user probability can be defined as follows: <MAT>.

The posterior user probability, P(Us | E<NUM>:T), is the estimated probability that the account owner (i.e., the presumed user) is the one (i.e., the active user) using the device, given the behavior events observed so far. This value is the actionable value for continuous user authentication; if it dips below a threshold, remediation may be taken (such as preventing or limiting access to some computing device or software application). For an example, with reference to diagram <NUM> of <FIG>, probability scores for an account owner having a user-specific model is compared to those of six other users.

The reporting of posterior user probabilities for the purpose of informing decisions about preventing or limiting user access to a device or software application confers at least the following technical advantages.

Interpretability and actionability. Model-based approaches to continuous authentication would more commonly make decisions using an event score, P(Et|U), or a smoothed history of event scores. However, the interpretation of such quantities is typically not straightforward. For example, what value should be considered "low" by a user authentication platform can vary as a wildly as a function of the properties of the behavioral data (e.g., the data rate) or the model applied to that data (e.g., its goodness of fit). This makes it difficult to move directly from an event score or a history of event scores into a decision. In contrast, P(U|Et) has a clear interpretation, and is more directly relevant to a decision about access: it is the estimated probability that the user is who they say they are, given the data (and, implicitly, the trained model).

Filtering out of anomalies that are not informative to the goal of continuous user authentication. A fundamental issue for anomaly detection models is that they can easily report uninteresting, "non-informative" anomalies, that is, anomalies that are not relevant to some eventual decision. (In this case, the decision to be made concerns limiting or preventing access, and this decision is made in part or in whole based on the model's belief about who is currently using the device - the owner of a user account, or some other user. ) For an example of a non-informative anomaly in the context of continuous authentication, consider a situation where somebody accidentally drags their elbow across the keyboard. This behavior would yield low event scores - and hence a typical anomaly detector would raise an alert. However, this situation does not suggest that a different person is sitting at your computer, typing; indeed, it is unlikely that any human would type that quickly under natural circumstances. The posterior user probability returned by Equation (<NUM>) corrects for such "non-informative anomalies". While the numerator in Equation (<NUM>) would presumably be lowered, reflecting that the behavior is anomalous for the owner of the particular user account of interest, the denominator in Equation (<NUM>), i.e. the evidence, would presumably be lowered as well, since the behavior would presumably be anomalous for most or all users in the universal background model.

Tracking of non-stationarities induced by changes in user identity. One might imagine using the scores from a user model and universal background model to report a Bayesian posterior user probability, as in (<NUM>), but with a more traditional likelihood imposing an i. d assumption, as in (<NUM>). Such a scheme would provide the advantages, mentioned so far, of interpretability/actionability and filtering out of non-interesting anomalies. However, this scheme would lead scores to become rigid over time. As the number of observations, T, grows, the joint likelihood ratio, P(E<NUM>:T | Us) / P(E<NUM>:T | Uo), will typically become astronomically large (i.e. move towards infinity) or astronomically small (i.e. move towards zero), depending on whether the observations typically favor the user model over the universal background model, or vice versa, respectively. Thus, the posterior user probability would typically become very close to <NUM> or very close to <NUM> as T grows. As a result, if the user were to switch from the account owner to some other user after a long period of scoring, it could easily take an exceedingly long time for the posterior user probability to override the contribution from earlier observations. In contrast, the joint likelihood of (<NUM>) uses smoothing to upweight the contributions of more recent observations, which makes it easier for the posterior user probability scores to track non-stationarities in the data (and, specifically, non-stationarities induced by a change in user identity).

In Bayesian models, the relative contributions of the likelihood and the prior on the posterior depend on the number of observations. An oft-observed property of traditional Bayesian models is that, as more observations are collected, the likelihood overwhelms the prior in determining the posterior. For instance, when the joint likelihood in (<NUM>) contains a conditional i. d assumption (<NUM>), the posterior distribution is proportional to <MAT>, that is, to the product of two terms: (<NUM>) a likelihood viewed as a typical likelihood <MAT> with exponent T and (<NUM>) a prior P(Ui). Note that T = <NUM> at the start of data collection and goes to infinity as more data is collected. So as more data is collected, the prior has diminishing influence on the posterior. More generally, when (<NUM>) is substituted into (<NUM>), the influence of the data, relative to the prior, on the posterior probability is quantified by the effective sample size <MAT>. That is, the posterior distribution is proportional to <MAT>, which is a product of two terms: (<NUM>) a likelihood viewed as typical likelihood <MAT> with exponent S, and (<NUM>) a prior P(Ui). For the highlighted use case in which Pgeneral = Pema, the effective sample size S = <NUM> - (<NUM> - α)T. So S equals some (typically small) α on the unit interval at the start of data collection and goes to <NUM> as more data is collected. That is, the user probability scores given by (<NUM>) have the property that initial values in the sequence are highly constrained by the prior, but after some transient period, the prior and data have approximately constant levels of influence on the posterior. Thus, by using Pema instead of Piid to construct user probability scores, desirable properties are obtained. First, the use of Pema limits the ability of the data to overwhelm the prior in determining the posterior, thereby supporting the tracking of non-stationarities described above. Second, and as is emphasized here, the use of Pema helps to control the fact that the exponential moving average is high variance when it has been applied to a small number of samples from a non-degenerate probability distribution.

<FIG> is a diagram <NUM> illustrating a sample computing device architecture for implementing various aspects described herein. A bus <NUM> can serve as the information highway interconnecting the other illustrated components of the hardware. A processing system <NUM> labeled CPU (central processing unit) (e.g., one or more computer processors / data processors at a given computer or at multiple computers) and/or a processing system <NUM> labeled GPU (graphical processing unit) can perform calculations and logic operations required to execute a program. A non-transitory processor-readable storage medium, such as read only memory (ROM) <NUM> and random access memory (RAM) <NUM>, can be in communication with the processing system <NUM> and can include one or more programming instructions for the operations specified here. Optionally, program instructions can be stored on a non-transitory computer-readable storage medium such as a magnetic disk, optical disk, recordable memory device, flash memory, or other physical storage medium.

In one example, a disk controller <NUM> can interface with one or more optional disk drives to the system bus <NUM>. These disk drives can be external or internal solid state drives such as <NUM>, external or internal CD-ROM, CD-R, CD-RW or DVD drives such as <NUM>, or external or internal hard drives <NUM>. As indicated previously, these various disk drives <NUM>, <NUM>, <NUM> and disk controllers are optional devices. The system bus <NUM> can also include at least one communication port <NUM> to allow for communication with external devices either physically connected to the computing system or available externally through a wired or wireless network. In some cases, the at least one communication port <NUM> includes or otherwise comprises a network interface.

To provide for interaction with a user, the subject matter described herein can be implemented on a computing device having a display device <NUM> (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information obtained from the bus <NUM> via a display interface <NUM> to the user and an input device <NUM> such as keyboard and/or a pointing device (e.g., a mouse or a trackball) and/or a touchscreen by which the user can provide input to the computer. Other kinds of input devices <NUM> can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback by way of a microphone <NUM>, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input. The input device <NUM> and the microphone <NUM> can be coupled to and convey information via the bus <NUM> by way of an input device interface <NUM>. Other computing devices, such as dedicated servers, can omit one or more of the display <NUM> and display interface <NUM>, the input device <NUM>, the microphone <NUM>, and input device interface <NUM>.

In the descriptions above and in the claims, phrases such as "at least one of" or "one or more of' may occur followed by a conjunctive list of elements or features.

Claim 1:
A computer-implemented method for Bayesian continuous user authentication comprising:
iteratively:
receiving (<NUM>) a sequence of observed behavior data that collectively characterizes interaction of an active user with at least one computing device or software application, wherein the active user is presumed to be an account owner, that is, a user associated with login credentials;
identifying (<NUM>) a sequence of events within the observed behavior data;
scoring (<NUM>) each of the events using a universal background model that generates first scores that characterize an extent to which each event or history of events is anomalous for a particular population of users;
scoring (<NUM>) each of the events using a user model that generates second scores that characterize an extent to which each event or history of events is anomalous for the active user presumed to own the account;
smoothing (<NUM>) the first scores and the second scores using a smoothing function which upweights the first scores and/or the second scores based on recency;
determining, (<NUM>) based on the smoothed first scores and the smoothed second scores, a probability that the active user is the account owner associated with the user model; and
providing (<NUM>) data indicating the probability.