Terminology

References to “an embodiment” or “some embodiments” mean that the feature, function, structure, or characteristic being described is included in at least one embodiment. Occurrences of such phrases do not necessarily refer to the same embodiment, nor are they necessarily referring to alternative embodiments that are mutually exclusive of one another.

The term “based on” is to be construed in an inclusive sense rather than an exclusive sense—that is, in the sense of “including, but not limited to.” Accordingly, unless otherwise noted, the term “based on” is intended to mean “based at least in part on.”

The terms “connected,” “coupled,” and variants thereof are intended to include any connection or coupling between two or more elements, either direct or indirect. The connection or coupling can be physical, logical, or a combination thereof. For example, elements may be electrically or communicatively coupled to one another despite not sharing a physical connection.

The term “module” may refer broadly to software, firmware, hardware, or combinations thereof. Modules are typically functional components that generate one or more outputs based on one or more inputs. A computer program may include or utilize one or more modules. For example, a computer program may include multiple modules that are responsible for completing different tasks, or a computer program may include a single module that is responsible for completing all tasks.

When used in reference to a list of multiple items, the word “or” is intended to cover all of the following interpretations: any of the items in the list, all of the items in the list, and any combination of items in the list.

The term “enterprise” may be used to refer to an entity of any size, complexity, or organizational structure. The term “enterprise” may be used interchangeably with the terms “business,” “company,” and “organization.”

The term “account” may be used to refer to a digital profile with which an employee is able to perform digital activities on a corresponding service (e.g., a SaaS service). These digital profiles are commonly used to access software via which digital activities, such as exchanging emails or accessing information, can be performed. The digital activities that are performed with these digital profiles may be called “events,” each of which can be attributed to a corresponding digital profile and therefore a corresponding employee.

Overview of Threat Detection Platform

FIG. 1 depicts an example of a threat detection platform 100 that is designed to examine the digital activities performed with accounts associated with employees to detect threats to the security of an enterprise. As shown in FIG. 1, the threat detection platform 100 may include a profile generating module 102, a training module 104, a monitoring module 106, a scoring module 108, an analysis module 110, a remediation module 112, and a reporting module 114. Some embodiments of the threat detection platform 100 include a subset of these components, while other embodiments of the threat detection platform 100 include additional components that are not shown in FIG. 1.

At a high level, the threat detection platform 100 can acquire data related to digital activities that are performed with accounts associated with employees and then determine, based on an analysis of the data, how to handle threats in a targeted manner. Some data may be acquired from an enterprise network 116, while other data may be acquired from a developer 118 of a service, for example, via an application programming interface (“API”). Consider a scenario in which the threat detection platform 100 is tasked with monitoring digital activities performed with a first plurality of accounts on a first SaaS service (e.g., Microsoft Office 365) and a second plurality of accounts on a second SaaS service (e.g., Slack), where the first and second pluralities of accounts are associated with an enterprise, employees of which are associated with one of the first plurality of accounts and one of the second plurality of accounts. In such a scenario, the threat detection platform 100 can acquire, from the first SaaS service via a first API, a first dataset that is representative of digital activities performed with the first plurality of accounts and acquire, from the second SaaS service via a second API, a second dataset that is representative of digital activities performed with the second plurality of accounts. Further, the threat detection platform 100 could acquire, from the enterprise network 116, a third dataset that is representative of digital activities (e.g., sign-in actions) performed with the first plurality of accounts, the second plurality of accounts, or a separate third plurality of accounts.

As shown in FIG. 1, the data acquired from the enterprise network 116 and/or developers 118 of services may include information related to emails, messages, mail filters, sign-in actions, access activities, and the like. For each service for which data is acquired by the threat detection platform 100, the nature of the underlying digital activities—and therefore, the content of the data—may vary. For example, data acquired from a communication service (e.g., Microsoft Office 365) may be examined to glean insights into communications (e.g., emails and/or messages) transmitted and received by a plurality of accounts, while data acquired from a non-communication service (e.g., Salesforce or Workday) may be examined to glean insights into sign-in actions of another plurality of accounts. As another example, data acquired from a first communication service (e.g., Microsoft Office 365) may be examined to glean insights into emails transmitted and received by a plurality of accounts, while data acquired from a second communication service (e.g., Slack) may be examined to glean insights into messages transmitted and received by another plurality of accounts. As further discussed below, the threat detection platform 100 can, and generally does, acquire data from different sources in order to better understand the behavior of employees across different services.

In some embodiments, the threat detection platform 100 is implemented, at least partially, within the enterprise network 116. In other embodiments, the threat detection platform 100 is implemented entirely within a remote computing environment (e.g., an instance on Amazon Web Services) to which data regarding digital activities of employees is routed for analysis. The remote computing environment can belong to, or be managed by, the enterprise or another entity. The threat detection platform 100 could also be implemented within a gateway or another suitable location. For example, the threat detection platform 100 could be integrated into the enterprise's email system (e.g., at the gateway) as part of an inline deployment, though such an approach to implementation may be computationally burdensome if data from another service (i.e., one not supported by the email system) is to be examined by the threat detection platform 100. In other embodiments, the threat detection platform 100 is integrated into the enterprise's email system via an API such as the Microsoft Outlook® API. In such embodiments, the threat detection platform 100 may obtain data related to emails transmitted and received by accounts associated with the enterprise via the API. Thus, the threat detection platform 100 can supplement and/or supplant other security products that are employed by the enterprise.

In a first variation, the threat detection platform 100 is maintained by a threat service (also referred to as a “security service”) that has access to multiple enterprises' data. In this variation, the threat detection platform 100 can route data related to digital activities performed with accounts associated with the multiple enterprises to a computing environment managed by the security service. The computing environment may be an instance on Amazon Web Services, for example. The threat detection platform 100 may maintain one or more databases for each enterprise that include organizational charts, attribute baselines, models trained to understand employee behavior, and the like. For example, the threat detection platform 100 may maintain, for a first enterprise, a first database that includes information related to the first enterprise and its employees and maintain, for a second enterprise, a second database that includes information related to the second enterprise and its employees. The threat detection platform 100 may also maintain federated databases that are shared among at least some of the multiple enterprises. Examples of federated databases include databases specifying vendors and/or individuals who have been deemed fraudulent, domains from which incoming emails determined to be malicious originated, and the like. The security service may maintain different instances of the threat detection platform 100 for different enterprises, or the security service may maintain a single instance of the threat detection platform 100 for multiple enterprises-though data related to each of the multiple enterprises may be handled separately and analyzed independently by the threat detection platform 100. The data hosted in these instances can be obfuscated, encrypted, hashed, depersonalized (e.g., by removing personal identifying information), or otherwise secured or secreted. Accordingly, each instance of the threat detection platform 100 may only be able to access and then process data related to accounts that are associated with the corresponding enterprise(s).

In a second variation, the threat detection platform 100 is maintained by the enterprise whose accounts are being monitored-either remotely or on premises. In this variation, all relevant data may be hosted by the enterprise itself, and any information to be shared across multiple enterprises can be transmitted to a computing system that is maintained by the security service or a third party.

As shown in FIG. 1, the profile generating module 102, training module 104, monitoring module 106, scoring module 108, analysis module 110, remediation module 112, and reporting module 114 can be integral parts of the threat detection platform 100. Alternatively, these components could be implemented individually while operating “alongside” the threat detection platform 100. For example, the reporting module 114 may be implemented in a remote computing environment to which the threat detection platform 100 is communicatively connected across a network. As mentioned above, the threat detection platform 100 may be implemented by a security service on behalf of an enterprise or by the enterprise itself. In some embodiments, aspects of the threat detection platform 100 are interactable via a network-accessible computer program operating on a computer server or a distributed computing system. For example, an individual may be able to interface with the threat detection platform 100 through a web browser that is executing on an electronic computing device (also called an “electronic device” or “computing device”).

The enterprise network 116 may be a mobile network, wired network, wireless network, or some other communication network maintained by the enterprise or an operator on behalf of the enterprise. As noted above, the enterprise may utilize a security service to examine digital activities to discover potential threats. For example, the enterprise may grant permission to the security service to monitor the enterprise network 116 by examining emails (e.g., incoming emails or outgoing emails) and then addressing those emails that are determined to represent threats. The threat detection platform 100 may be permitted to remediate the threats posed by those emails, or the threat detection platform 100 may be permitted to surface notifications regarding the threats posed by those emails. In some embodiments, the enterprise further grants permission to the security service to obtain data regarding other digital activities involving the enterprise (and, more specifically, employees of the enterprise) in order to build a profile that specifies communication patterns, behavioral traits, normal context of emails, normal content of emails, etc. For example, the threat detection platform 100 may identify the filters that have been created and/or destroyed by each employee to infer whether any significant variations in behavior have occurred. As another example, the threat detection platform 100 may examine the emails or messages received by a given employee to establish the characteristics of normal communications (and thus, be able to identify abnormal communications). As another example, the threat detection platform 100 may examine sign-in actions to establish characteristics (e.g., in terms of location, time, frequency) that can then be used to establish whether a single sign-in action is unusual or a combination of sign-in actions are unusual.

The threat detection platform 100 may manage one or more databases in which data can be stored. Examples of such data include enterprise data (e.g., email data, message data, sign-in data, access data, and mail filter data), remediation policies, and models that are trained to learn what constitutes normal behavior for employees, for example, in terms of communication patterns, behavioral traits, and the like. The data stored in the database(s) may be determined by the threat detection platform 100 (e.g., learned from data available on the enterprise network 116 or available from a developer 118), provided by the enterprise, or retrieved from the Internet or an external database (e.g., associated with LinkedIn®, Microsoft Office 365, or Google Workspace). The threat detection platform 100 may also store outputs produced by the various modules, including machine- and human-readable information regarding insights into threats and any remediation actions that were taken.

As shown in FIG. 1, the threat detection platform 100 may include a profile generating module 102 that is responsible for generating one or more profiles for the enterprise. For example, the profile generating module 102 may generate a separate profile for each employee of the enterprise based on an analysis of digital activities performed across one or more services. Alternatively, the profile generating module 102 may generate a separate profile for each account that is associated with the enterprise, in which case each employee may be associated with one or more profiles. Profiles could also be generated for business groups, organizational groups, or the enterprise as a whole. Examining the data may enable the profile generating module 102 to discover organizational information (e.g., employees, titles, and hierarchy), behavioral traits of employees (e.g., based on historical emails, messages, and historical mail filters), normal content of incoming or outgoing emails, behavioral patterns of employees (e.g., when each employee normally logs in), communication patterns of employees (e.g., who each employee communicates with internally and externally, when each employee normally communicates), etc. This information can be populated into a profile so that the profile can serve as a baseline for what constitutes normal digital activity by the corresponding account or employee.

A profile could include a number of behavioral traits associated with the corresponding account. The profile generating module 102 may determine the behavioral traits based on the data that is acquired from the enterprise network 116 and developers 118. Referring to FIG. 1, for example, the profile generating module 102 may determine the behavioral traits based on an analysis of access data, sign-in data, message data, email data, and mail filter data. For example, the email data may include information on the senders of past emails received by a given account, the content of those past emails, the frequency of those past emails, the temporal patterns of those past emails, the topics of those past emails, the geographical locations from which those past emails originated, the formatting characteristics of those past emails (e.g., usage of HTML, fonts, styles, etc.), and more. For the given account via which emails can be received or transmitted, the profile generating module 102 may attempt to build a profile that includes information regarding the other accounts that emails are commonly transmitted to or received from, the normal content of incoming and outgoing emails, the normal transmission times, the normal transmission locations, and the like. As a more specific example, consider a scenario in which an employee of an enterprise is associated with a first account via which she is able to perform digital activities on a first SaaS service (e.g., Microsoft Office 365) and a second account via which she is able to perform digital activities on a second SaaS service (e.g., Slack). To build a profile for the employee, the profile generating module 102 may examine digital activities performed in the past with the first and second accounts. Through this analysis, the profile generating module 102 can glean insights into behavior on the first SaaS service and behavior on the second SaaS service, but also behavior on the first SaaS service in relation to behavior on the second SaaS service. For instance, the profile generating module 102 may discover that when emails are transmitted by the first account to other employees of the enterprise (and more specifically, other accounts for the first SaaS service), the second account generally transmits messages to those same employees (and more specifically, other accounts for the second SaaS service) around the same time. This type of insight-which can only be gleaned through analysis of digital activities performed across different services—can be helpful in identifying threats when digital activity only slightly or mildly deviates from the norm.

Accordingly, the profile generating module 102 may attempt to build a profile for each employee, such that each profile is representative of an archetype of behavior of the corresponding employee across one or more services with her accounts. Additionally or alternatively, the profile generating module 102 may attempt to build a profile for each account, such that each profile is representative of an archetype of behavior of a corresponding account. As further discussed below, the profiles may be helpful in identifying digital activities that are unusual, and therefore may be indicative of a threat to the security of an enterprise.

The monitoring module 106 may be responsible for monitoring digital activities performed with accounts associated with employees of a given enterprise. For example, the monitoring module 106 may monitor communications handled by the enterprise network 116. These communications may include incoming emails (e.g., external and internal emails) received by a first plurality of accounts associated with employees of the enterprise, outgoing emails (e.g., external and internal emails) transmitted by the first plurality of accounts, and messages exchanged between the first plurality of accounts or a second plurality of accounts associated with the employees of the enterprise. In some embodiments, the monitoring module 106 is able to monitor communications in near real time so that appropriate action can be taken if, for example, a malicious email is discovered. If an incoming email is determined to be representative of a phishing attack (e.g., based on an output produced by the scoring module 108), then the incoming email may be prevented from reaching its intended destination by the monitoring module 106 at least temporarily. In some embodiments, the monitoring module 106 is able to monitor digital activities only upon the threat detection platform 100 being granted permission by the enterprise (and thus, given access to the enterprise network 116 or an API associated with a service).

The scoring module 108 may be responsible for examining digital activities to determine the likelihood that a threat exists. As further discussed below, the scoring module 108 may not only examine each digital activity on its own—comparing that digital activity to the baseline established for the corresponding account—but also examine combinations of digital activities performed on a single service or across multiple services.

For example, the scoring module 108 may examine each incoming email to determine how its characteristics compare to past emails sent by the sender or received by the recipient. In such a scenario, the scoring module 108 may determine whether characteristics such as timing, formatting, and location of origination (e.g., in terms of sender email address or geographical location) match the baseline established for the sender or recipient based on an analysis of past emails that have been determined to be non-malicious. For example, the scoring module 108 may determine that an email is likely malicious if the sender email address (support-xyz@gmail.com or JohnDoe1@gmail.com) differs from an email address (John.Doe@CompanyABC.com) that is known to be associated with the alleged sender (John Doe). As another example, the scoring module 108 may determine that an account may be compromised if the account performs a sign-in action that is impossible or improbable given its most recent sign-in action. Similarly, the scoring module 108 may determine that an account may be compromised if the account performs an access action (e.g., of an enterprise network, enterprise-supported database, or enterprise-supported service) that is impossible or improbable given its most recent access action.

In addition to this “single-service analysis,” the scoring module 108 may examine digital activities performed across different services. With this “multi-service analysis,” the scoring module 108 may be able to identify sets of digital activities that are not noteworthy on their own but are indicative of risk when viewed together. Assume, for example, that the scoring module 108 monitors digital activities performed with a first account on a first service and a second account on a second service, where the first and second accounts are associated with the same employee. The scoring module 108 may discover that the first account performs a first digital activity (e.g., transmitting an email originating from a first geographical location) around the same time that the second account performs a second digital activity (e.g., accesses an enterprise network from a second geographical location). When viewed separately, neither the first digital activity nor the second digital activity may significantly deviate from normal behavior of the employee. However, when viewed together, the scoring module 108 may be able to establish that either the first account or the second account is likely compromised.

The scoring module 108 can make use of heuristics, rules, or models that are representative of neural networks or rely on decision trees (e.g., gradient-boosted decision trees), logistic regression, or linear regression. Accordingly, the scoring module 108 may produce discrete outputs or continuous outputs as further discussed below.

As mentioned above, the scoring module 108 may consider combinations of digital activities-across the same service or different services-to determine whether a threat exists. This may be done in a “rolling” manner, where each digital activity is compared against prior digital activities performed on the same service with the same account that have been identified as unusual to some degree. Each digital activity could also be compared against prior digital activities performed with related accounts (e.g., corresponding to the same employee but other services) that have been identified as unusual to some degree.

The analysis module 110 may be responsible for considering whether different combinations of digital activities are indicative of a threat. For example, the analysis module 110 may determine, based on the scores produced by the scoring module 108, whether a digital activity is individually indicative of a threat or collectively—with at least one other digital activity—indicative of a threat. Assume, for example, that the scores produced by the scoring module 108 are representative of deviation values, indicating the degree to which each corresponding digital activity deviates from past digital activities performed on the same service with that account. These deviation values can be supplied to the analysis module 110, and the analysis module 110 may input these deviation values into a rules-based engine, heuristics-based engine, or model that predicts the likelihood of a threat.

The remediation module 112 may perform one or more remediation actions in response to the analysis module 110 determining that an account may be compromised. The remediation action(s) may be based on the nature of the threat, the policies implemented by the enterprise, etc. These policies may be predefined or dynamically generated based on inference, analysis, or the data obtained by the threat detection platform 100 (e.g., from the enterprise network 116 or developers 118 of services). Examples of remediation actions include moving communications generated by a compromised account into a hidden folder (also referred to as a “quarantine folder”) for further analysis, prohibiting a compromised account from accessing sensitive information, sending notifications (e.g., to the actual employee, enterprise, or member of the security service), resetting the password of the compromised account, ending all active sessions of the compromised account, and resetting connections with services or databases accessible to the compromised account.

The reporting module 114 may be responsible for reporting insights derived from the outputs that are produced by the scoring module 108. For example, the reporting module 114 may provide a summary of the threats discovered through analysis of the outputs produced by the scoring module 108 to an electronic device 120. The electronic device 120 may be managed by the employee associated with the account under examination, an individual associated with the enterprise (e.g., a member of the IT department), or an individual associated with a security service. The reporting module 114 can surface insights into threats in a human-readable format for display on an interface accessible via the electronic device 120. For example, the reporting module 114 may be responsible for generating a visual indicium of digital activities, performed with accounts associated with a given employee, that have been determined to deviate from the usual behavior of the given employee. The visual indicium could take the form of a timeline, as further discussed below.

As shown in FIG. 1, the threat detection platform 100 may also include a training module 104 that operates to train the models employed by the other modules. For example, the training module 104 may train the models that are applied by the scoring module 108 to the data acquired from the enterprise network 116 and/or developers 118 of services by feeding training data into those models. Additional information regarding the processes for training and implementing the models is provided below with respect to FIG. 3.

Moreover, the training module 104 may implement a retraining pipeline (or simply “pipeline”) in order to protect against novel threats as further discussed below. At a high level, the pipeline may be representative of a series of steps that, when executed by the training module 104, cause the models employed by the scoring module 108 to be retrained. By consistently training the models using up-to-date information, the threat detection platform 100 can protect against novel threats that would otherwise escape detection.

FIG. 2 illustrates how a threat detection platform 200 may employ a multi-tiered approach to aggregate information (also referred to as “signals”) related to the employees of an enterprise (step 201), examine the signals to discover ones that may be indicative of account compromise (step 202), and then enact remediation actions (step 203) to address the threat to an enterprise. The appropriate remediation action, if any, can be determined by the threat detection platform 200 based on those “compromise signals” that are detected through an analysis of the aggregated signals.

Unlike conventional security products, the threat detection platform 200 can be completely integrated within the enterprise environment. For example, the threat detection platform 200 may receive input that is indicative of an approval by an individual (e.g., an administrator associated with the enterprise) to access data related to the digital activities performed with accounts associated with employees of the enterprise. The data may include, for example, information on communications (e.g., incoming and outgoing emails, incoming and outgoing messages), mail filters, mail groups, sign-in events, access events, identity risk events, active directory, etc. The approval may be given through an interface that is generated by the threat detection platform 200. For example, the individual may access an interface generated by the threat detection platform 200 and then approve access to the data as part of a registration process.

Then, the threat detection platform 200 can establish a connection with one or more sources from which the data can be acquired. For example, the threat detection platform 200 may establish, via an API, a connection with a computer server that is managed by the enterprise or some other entity (e.g., a developer of a service). Consider, for example, a scenario in which the threat detection platform 200 is instructed to acquire data from a first SaaS service via which employees transmit and receive emails—potentially among other things—using a first plurality of accounts and data from a second SaaS service via which the employees transmit and receive messages—again, potentially among other things—using a second plurality of accounts. In such a scenario, the threat detection platform 200 may acquire the data from the first SaaS service via a first API and acquire the data from the second SaaS service via a second API.

The threat detection platform 200 can download the data from the source(s) into a programming environment that is managed by the threat detection platform 200. For instance, the threat detection platform 200 may obtain information regarding outbound communications, inbound communications, mail filters, access events, and sign-in events involving accounts associated with the enterprise. As further discussed below, the threat detection platform 200 may process the information in order to define the digital activities that are performed with each account over time. The information that defines each digital activity may be referred to as a “signal.” As mentioned above, all of these digital activities need not necessarily be performed with the same accounts. Employees may use a first plurality of accounts for digital activities related to email (e.g., creating mail filters, receiving emails, transmitting emails) and a second plurality of accounts for digital activities related to accessing an enterprise network, an enterprise-supported database, or an enterprise-supported service.

FIG. 3 illustrates exemplary training and inferencing processes 300, 302 that use data regarding digital activities performed with one or more accounts associated with an employee of an enterprise. For the purpose of illustration, the training and inferencing processes 300, 302 are discussed in the context of two services, namely, a first SaaS service for which the employee has a first account and a second SaaS service for which the employee has a second account. However, those skilled in the art will recognize that the training and inferencing processes 300, 302 can be carried out similarly regardless of how many accounts and services are monitored.

Referring to the training process 300, the training module 304 may initially obtain (i) a first dataset that includes information regarding digital activities performed with the first account in the past and (ii) a second dataset that includes information regarding digital activities performed with the second account in the past. In some embodiments, the first and second datasets correspond to the same interval of time, generally having a predetermined length. For example, the first dataset may include information regarding digital activities performed with the first account over the preceding month, three months, or six months, while the second dataset may include information regarding digital activities performed with the second account over the preceding month, three months, or six months. As another example, the first dataset may include information regarding digital activities performed with the first account over a predefined period of time (e.g., July 2023 through December 2023), and the second dataset may include information regarding digital activities performed with the second account over the same predefined period of time.

Then, the training module 304 can canonicalize the first and second datasets into a canonicalized dataset. Note that, in some embodiments, another module (e.g., profile generating module 102 of FIG. 1) is responsible for canonicalizing the first and second datasets into the canonicalized dataset. The training module 304 may ingest data from different sources—here, for example, from the first and second SaaS services—and therefore may canonicalize the respective datasets into one or more data structures having a given form. In some embodiments, a single data structure is created and then maintained for the employee, such that information regarding digital activities performed with the first and second accounts is stored in the same data structure. In other embodiments, more than one data structure is created and then maintained for the employee. For example, a separate data structure could be created and then maintained for each service for which the employee has an account. Therefore, in this example, the training module 304 could maintain a first data structure for the first SaaS service and a second data structure for the second SaaS service, though the first and second data structures may still have the same form. Further information regarding canonicalization can be found below.

In some embodiments, the training module 304 creates labels for the various digital activities that are represented in the canonicalized dataset. Because the training module 304 is interested in establishing a baseline for normal behavior of the employee across the first and second SaaS services, labels may not be necessary. Instead, the training module 304 may simply presume that all digital activities reflected in the first and second datasets (and therefore, in the canonicalized dataset) are representative of normal behavior. However, the training module 304 may append labels to the digital activities indicating as much. Moreover, the training module 304 could append labels to the digital activities that indicate the degree to which each digital activity is representative of normal behavior, and therefore how strongly each digital activity should be considered when defining the baseline. For example, if the employee moves between different business groups, organizational groups, or physical locations, then her behavior may change, and labels can be used to flag those changes. As another example, the canonicalized dataset could include digital activities that are known to be malicious, and labels can be used to flag those digital activities. These malicious digital activities may be present because the employee has been targeted by attackers in the past, or these malicious digital activities may be present because the training module 304 has “injected” them into the canonicalized dataset. To improve robustness of the model (and specifically, its ability to identify threats), the training module 304 may “inject” malicious digital activities that involve other employees of the same enterprise or employees of other enterprises—in which case, the information may be manipulated so as to appear to affect the employee for whom the model is being trained.

This canonicalized dataset can be segmented by the training module 304 into two datasets, namely, a training dataset and a validating dataset. Generally, the training dataset is larger than the validating dataset, with the training dataset being about 60-90 percent of the size of the canonicalized dataset.

At a high level, the process of training a model involves providing a machine learning algorithm (or simply “learning algorithm”) with the training dataset from which to learn relationships and the validating dataset from which to validate the learned relationships. The learning algorithm tries to discover patterns in the training dataset and then outputs the model 306 that captures these patterns. In order for the learning algorithm to create an accurate model, the training dataset must contain evidence of the answer to be predicted-commonly called the “target.” In this scenario, the digital activities represented in the training dataset—and more specifically, characteristics of the digital activities—can serve as examples of normal behavior of the employee with respect to the first and second SaaS services. As mentioned above, the training dataset could also include malicious digital activities—that are labeled as such—so that the model 306 learns how to detect at least that type of threat.

Evaluating whether the model performs as expected is an important part of the training process 300. The data to which the model is applied during the inferencing process 302 has an unknown target, and therefore it is important to check the accuracy of the model 306 on data for which the target is known. That's where the validating dataset can be used, namely, as a means of assessing accuracy as a proxy for predictive accuracy on future data.

To properly evaluate the model 306, the training module 304 can hold onto a portion of the canonicalized dataset, namely, the validating dataset, that is used only for validation. Evaluating the predictive accuracy of the model 306 with the same training dataset supplied to the learning algorithm is not useful, as the model 306 would be rewarded for remembering the training dataset rather than learning to generalize from it. Specifically, portions of data in the validating dataset corresponding to different digital activities can be supplied to the model 306 that produces, as output, predictions regarding degree of abnormality from the baseline. These predictions can then be compared to outcomes that are known for those digital activities in order to establish a metric that indicates how well the model 306 performs. If, for example, a malicious digital activity is “injected” into the validating dataset, then the training module 304 may seek to ensure that the model 306 actually predicts that digital activity as malicious when the corresponding portion of the validating dataset is supplied as input. The metric may be representative of an indication of how well the predictions output by the model 306 match the known outcomes, which may be represented as labels. In response to a determination that the metric exceeds a threshold—indicating that performance of the model 306 is sufficient—the training module 304 can store the now-validated model 308. For example, the validated model 308 may be stored in a digital profile that is maintained for the employee or a digital profile that is maintained for the employer (and that includes various models validated for its employees). In response to a determination that the metric does not exceed the threshold—indicating that performance of the model 306 is not sufficient—the training module 304 may perform some other action. For example, the training module 304 may initiate a retraining operation in which aspects (e.g., weights) of the model 306 are adjusted to see whether performance can be improved. As another example, the training module 304 may restart the training process 300 with different data or more data.

Thereafter, the threat detection platform may be tasked with implementing the validated model 308. Assume, for example, that the threat detection platform obtains streams of data, in real time, from the first and second SaaS services as digital activities are performed with the first and second accounts. In such a scenario, the scoring module 310 can apply the validated model 308 to the first and second streams of data in an ongoing manner, such that for each digital activity performed with the first account or second account, a prediction is made as to whether that digital activity is representative of unusual behavior. As further discussed below, the validated model 308—or the scoring module 310—may consider digital activities individually and collectively when determining whether behavior is unusual.

The analysis module 312 can store indications of digital activities for which the prediction output by the validated model 308 indicated at least some degree of deviation from normal behavior. While indications of all digital activities performed with the first and second accounts could be stored by the analysis module 312, this approach is generally not preferred due to computational resource considerations. Instead, the analysis module 312 may only store indications of digital activities that might lead, directly or indirectly, to a conclusion that the first account or second account is compromised.

Moreover, the analysis module 312 may determine which remediation action, if any, is appropriate based on the predictions output by the validated model 308. Upon identifying an appropriate remediation action, the analysis module 312 may transmit an instruction to implement the appropriate remediation action to a remediation module (e.g., remediation module 112 of FIG. 1). Alternatively, the predictions output by the validated model 308—or analysis thereof output by the analysis module 312—could be transmitted to the remediation module, in which case the remediation module may be responsible for determining the appropriate remediation action as well as implementing it.

Several examples of models are provided below:

- Binary Classification Models: The output of a binary classification model specifies one of two classes. An example of such a model is one that when applied to data related to a digital activity, determines whether the corresponding account is or is not compromised.
- Non-Binary Classification Models: The output of a non-binary classification model specifies one of at least three classes. An example of such a model is one that when applied to data related to a digital activity, specifies whether the corresponding account is not compromised, is subject to a first type of attack, is subject to a second type of attack, or is subject to a third type of attack. The number of classes can vary, though it generally depends on whether sufficient training data is available for the model to learn patterns that are representative of each class.
- Regression Models: The output of a regression model is generally a single number (e.g., 50 percent) or an interval of numbers (e.g., 40-60 percent). An example of such a model is one that when applied to data related to a digital activity, estimates the probability that the corresponding account is compromised. One of the benefits of a regression model is that it can provide context that is helpful in better understanding the threat posed. For example, different action may be taken if a regression model indicates that the likelihood of an account being compromised is 80-90 percent versus 50-60 percent or 20-30 percent.

The nature of the validated model 308 may affect not only how its outputs are used by the threat detection platform, but also how training, validating, and inferencing are performed. To train a binary classification model, the training module 304 may use the learning algorithm known as logistic regression. To train a multiclass classification model, the training module 304 may use the learning algorithm known as multinomial logistic regression. Other learning algorithms that could be used for classification include (i) the Decision Tree Classifier, which uses a decision tree, as a predictive model, to go from observations to conclusions about the target, (ii) the Random Forest Classifier, which implements ensemble learning by constructing various decision trees during the training stage and then making a prediction based on the outputs of those decision trees during the inferencing stage, (iii) the XGBoost Classifier, (iv) the Naïve Bayes algorithm, which is based on Bayes theorem, (v) support-vector machines (“SVMs”), which, during the training stage, map examples to points in space to maximize the width of the gap between different classifications and then, during the inferencing stage, maps new examples into that same space to formulate a prediction, and (vi) neural networks, which learn by adjusting weights assigned to nodes across different layers. To train a regression model, the training module 304 may use the learning algorithm known as linear regression.

The nature of the validated model 308—and the nature of the learning algorithm and underlying model architecture—may depend on the expectations of the threat detection platform and computational resources available to the threat detection platform. Neural networks, especially deep ones with more than three layers of nodes, tend to require a significant amount of computational resources during the training stage (and a decent amount of computational resources during the inferencing stage). Performance is generally quite good, however. Accordingly, the training module 304 may opt to train and implement a neural network so long as sufficient computational resources are available.

Ingesting Data Regarding Digital Activities Across Different Sources

To detect threats to an enterprise, a threat detection platform may monitor the digital activities that are performed with accounts associated with its employees across different services as discussed above. The threat detection platform can be programmed to ingest data from these different services, as well as canonicalize the data into data structures having a given form. Canonicalizing the data has several benefits. First, several of the aforementioned learning algorithms—and the corresponding models produced as output—perform more efficiently when handling data with a known structure. Simply put, the consistent structure can make it less “costly” to train and implement the model, especially if the model is to be implemented continually and in real time. Second, a consistent approach to canonicalization allows the threat detection platform to better monitor digital activities performed across different services, as data regarding different types of digital activities can be more easily logged and compared.

To ensure that data ingested from various sources can be analyzed by the threat detection platform (and more specifically, its scoring module), the threat detection platform may employ a standardization mechanism that canonicalizes the “language” of any network-accessible source from which data could be obtained. Simply put, the standardization mechanism can be designed so that data ingested from a given source can be readily used by the various modules of the threat detection platform. For example, the standardization mechanism may be designed to canonicalize data into (i) employees, (ii) digital activities, (iii) contextual information regarding those digital activities, and (iv) a take-action administrator stream. Note that the standardization mechanism may need to be designed for each source from which data is to be ingested by the threat detection platform.

Taking an informed approach to designing how data can be ingested by the threat detection platform may provide greater flexibility for future extensions. For example, the threat detection platform may be readily extendable to on-premises applications and standard interfaces, dataflows, and architectures—simply through the development of new standardization mechanisms. For example, if data regarding physical access actions (e.g., of physical buildings using a physical badge) were made available to the threat detection platform, this data could be similarly considered in determining whether an enterprise is at risk.

FIG. 4 includes a high-level illustration of a data ingestion mechanism (“DIM”) 400 that can be implemented by a threat detection platform (e.g., threat detection platform 100 of FIG. 1). As shown in FIG. 4, the DIM 400 may support one or more APIs via which data can be ingested from various sources. Here, for example, the DIM 400 supports APIs via which data can be acquired from SaaS services (e.g., those offered by Microsoft, Google, Salesforce, Workday, ServiceNow, Oracle, etc.) and cloud infrastructures (e.g., Google Cloud Platform, Amazon Web Services, and Microsoft Azure). In some embodiments, the DIM 400 supports an API that serves as a generic data interface via which data can be provided to the threat detection platform in nearly any form, whether structured or unstructured. Via this API, data can be acquired from an open-source Hypertext Transfer Protocol (“HTTP”) server, on-premises computer programs (also called “long-tail computer programs” or “long-tail applications”), and the like. Because this “generic API” can serve as a connection mechanism between the threat detection platform and sources of data, it may also be called a “generic connection mechanism” or “generic connector.”

As further discussed below, each API supported or accessed by the DIM 400 may include—or interface with—a standardization mechanism that allows the data ingested from a corresponding service to be more readily handled by the various modules of the threat detection platform. FIG. 5A includes an example of an interface that shows how deployment can be summarized visually, so as to indicate the services for which data is presently being received and analyzed by the threat detection platform. FIG. 5B, meanwhile, includes an example of an interface that shows how further information regarding protected employees can be made readily accessible. FIGS. 6A-C include examples of interfaces that show how new sources may be made programmatically accessible to the threat detection platform, such that the threat detection platform is able to ingest data related to digital activities performed on those sources. Specifically, the interface in FIG. 6A shows the sources with which the threat detection platform is currently integrated, the interface in FIG. 6B shows how a new source can be identified, and the interface in FIG. 6C shows how the new source can be integrated into the threat detection platform.

Accordingly, the threat detection platform—via the DIM 400—may obtain or monitor data that is available from one or more sources, aggregate the data, and then canonicalize the digital activities represented in the data into a single event stream—on either a per-employee or per-account basis—to perform behavioral analysis. Such an approach ensures that the data available from these sources can be holistically examined to gain a better understanding of behavioral patterns on a per-account, per-employee, or per-enterprise basis.

FIG. 7 includes a flow diagram of a process 700 for standardizing data relating to digital activities across multiple services. These services may be SaaS services, for example.

For each of the multiple services, the threat detection platform can initially acquire data related to digital activities that are performed with a set of accounts associated with an enterprise (step 701). As mentioned above, the threat detection platform may acquire the data from each of the multiple services via a corresponding one of multiple APIs, each of which is offered and supported by one of the multiple services. Alternatively, the threat detection platform may offer and support its own API at which the data can be received from the multiple services. Generally, the set of accounts is one of multiple sets of accounts, each of which is associated with a corresponding one of the multiple services.

Then, the threat detection platform can canonicalize the data such that multiple data structures are produced (step 702). These data structures can be produced on a per-account, per-employee, or per-service basis. For example, in the event that the multiple data structures are produced on a per-service basis, each data structure may specify (i) the set of accounts associated with the corresponding service, (ii) digital activities that were performed with the set of accounts, and (iii) information regarding the set of accounts and/or the digital activities that were performed with the set of accounts. In some embodiments, each data structure further specifies (iv) an indication as to whether action should be taken by the threat detection platform on behalf of the enterprise, though the indication may not be populated into the data structure until the likelihood of compromise is established as discussed below with reference to step 703.

Canonicalization can take several forms.

In some embodiments, the threat detection platform implements a separate set of rules for each of the multiple services. When implemented, a set of rules may convert data acquired from a corresponding service into a given form, such that the data acquired from the multiple services has the same form and/or can be populated into data structures having the same form.

In other embodiments, the threat detection platform implements a separate model for each of the multiple services that acts as a standardization mechanism for that service. Accordingly, the threat detection platform may have access to multiple models, each of which is designed and trained to standardize data acquired from a different one of multiple sources. These models may produce, as output, data in a given form or data structure—in which the data is populated—having the same form.

Thereafter, the threat detection platform can establish a likelihood of compromise based on an analysis of the multiple data structures (step 703). Assume, for example, that the enterprise has multiple employees, each of whom is associated with an account in each of the multiple sets of accounts, such that each employee is associated with multiple accounts. To establish the likelihood of compromise, the threat detection platform can—for each of the multiple employees—identify the multiple accounts that are associated with that employee; establish entries across the multiple data structures that are associated with the multiple accounts; apply, to the entries, a model that is trained to understand what constitutes normal behavior of that employee with respect to the multiple services; and determine the likelihood of compromise based on an output produced by the model.

In response to a determination that the likelihood of compromise for a given account among the multiple sets of accounts does not exceed a threshold, the threat detection platform may not take any further action (step 704). However, in response to a determination that the likelihood of compromise of the given account does exceed the threshold, the threat detection platform may perform a remediation action on behalf of the enterprise (step 705). For example, the threat detection platform may transmit, to a given employee associated with the given account or someone else (e.g., a member of the IT department), a notification that specifies the threat. As another example, the threat detection platform may transmit an instruction to a given one of the multiple services that is associated with the given account. The instruction may be representative of a request to (i) reset a password of the given account, (ii) terminate active sessions, if any, of the given account, or (iii) reset connections, if any, of the given account with a network associated with the enterprise.

FIG. 8 includes a flow diagram of a process 800 for canonicalizing data acquired from multiple SaaS services that are accessible to employees of an enterprise. Those skilled in the art will recognize that the process 800 is discussed in the context of SaaS services for the purpose of illustration. The process 800 may be similarly applicable if data is acquired from sources other than, or in addition to, SaaS services.

For each of the multiple SaaS services, the threat detection platform can initially acquire data that is related to digital activities that are performed with one of multiple sets of accounts associated with the enterprise (step 801). Each of the multiple sets of accounts may be associated with a different one of the multiple SaaS services. Assume, for example, that the employees are able to access three SaaS services, namely, SaaS Service A, SaaS Service B, and SaaS Service C. In such a scenario, the threat detection platform may acquire, from SaaS Service A, a first dataset regarding digital activities that are performed with a first set of accounts, each of which may be associated with a different one of the employees. Similarly, the threat detection platform may acquire, from SaaS Service B, a second dataset regarding digital activities that are performed with a second set of accounts, and the threat detection platform may acquire, from SaaS Service C, a third dataset regarding digital activities that are performed with a third set of accounts. To acquire the first, second, and third datasets, the threat detection platform may establish a connection with SaaS Services A, B, and C via respective APIs. Thus, the threat detection platform may establish, via a first API, a connection with SaaS Service A via which the first dataset can be downloaded into a local processing environment; establish, via a second API, a connection with SaaS Service B via which the second dataset can be downloaded into the local processing environment; and establish, via a third API, a connection with SaaS Service C via which the third dataset can be downloaded into the local processing environment.

For each of the multiple SaaS services, the threat detection platform can then provide the data, as input, to a standardization mechanism that canonicalizes the data into a data structure having predetermined fields (step 802), so as to produce multiple data structures for the multiple SaaS services. As mentioned above, data structures could be produced on a per-account or per-employee basis rather than a per-service basis in some embodiments. The nature and number of predetermined fields can vary depending on the level of detail provided by each of the multiple SaaS services, but also the level of detail needed by the threat detection platform to ascertain whether a threat exists. For example, if the threat detection platform produces data structures on a per-service basis, then the predetermined fields may include (i) a first field or a first set of fields in which a corresponding set of accounts is specified, (ii) a second field or a second set of fields in which digital activities that were performed with the corresponding set of accounts are specified, (iii) a third field or a third set of fields in which information regarding the context of the digital activities or the corresponding set of accounts is specified, and (iv) a fourth field or a fourth set of fields in which indications of whether remediation action should be taken are specified. At a high level, the third field or the third set of fields may be representative of a space for contextual information related to the digital activities or the corresponding set of accounts. Consider, for example, the aforementioned scenario in which data structures are produced on a per-service basis. In such a scenario, a separate data structure may be maintained for each of the multiple SaaS services, such that a first one of the multiple SaaS services is associated with a first data structure, a second one of the multiple SaaS services is associated with a second data structure, etc. In the first data structure, there may be entries that correspond to different digital activities performed with accounts for the first SaaS service. Each of these entries may include a third field—or a third set of fields—that specifies accounts across the other ones of the multiple SaaS services that are associated with the same employee. This contextual information can allow the threat detection platform to better understand connectedness of various accounts across the multiple SaaS services. As another example, the third field—or the third set of fields—may include information regarding a context of the digital activity that is determined, inferred, or otherwise gleaned by the threat detection platform, whereas the second field—or the second set of fields—may simply identify the digital activity itself. Again, the fourth field or the fourth set of fields may remain empty until a determination of risk is made, for example, based on an output produced by a scoring module (e.g., scoring module 108 of FIG. 1).

In some embodiments, the standardization mechanism is an API that is developed and maintained by the threat detection platform. This API may be representative of a software intermediary that allows for many-to-one communication between different SaaS services and the threat detection platform. Alternatively, the threat detection platform may implement multiple APIs, each of which is representative of a software intermediary that allows for one-to-one communication between one of the multiple SaaS services and the threat detection platform. In other embodiments, the standardization mechanism is a model that is trained by the threat detection platform. Like the API, the model may be programmed and trained to allow for many-to-one communication or one-to-one communication. That is, the model may be programmed and trained to standardize data received from a single SaaS service, or the model may be programmed and trained to standardize data received from any of multiple SaaS services.

Thereafter, the threat detection platform can determine, for each account, a likelihood of compromise based on an analysis of the multiple data structures (and more specifically, the digital activities that are performed with each account) (step 803).

FIG. 9 includes a flow diagram of a process 900 in which data acquired from multiple SaaS services is canonicalized and then examined in real time to identify threats to an enterprise. Again, those skilled in the art will recognize that the process 900 is discussed in the context of SaaS services for the purpose of illustration. The process 900 may be similarly applicable if data is acquired from sources other than, or in addition to, SaaS services.

Initially, the threat detection platform can establish a separate connection with each of multiple SaaS services that are accessible to employees of an enterprise (step 901). For example, for each of the multiple SaaS services, the threat detection platform may initiate a connection with a corresponding one of multiple APIs. Each API may be supported by a corresponding one of the multiple SaaS services and allow for communication therewith. For each of the multiple SaaS services, the enterprise may have a separate set of accounts. For example, the enterprise may have a first set of accounts for a first SaaS service and a second set of accounts for a second SaaS service. Accordingly, each of the employees may be associated with multiple accounts (e.g., one account in the first set and one account in the second set). Note that some accounts could be used across different SaaS services. For example, an employee could be associated with a single account that provides access to a first SaaS service and a second SaaS service. In such a scenario, the threat detection platform may still acquire data from the first and second SaaS services as discussed above, though the digital activities performed on the first and second SaaS services may be attributed to a single account rather than multiple accounts associated with the same employee.

The threat detection platform can then canonicalize data received from the multiple SaaS services by populating the data, or analyses of the data (e.g., outputs produced by models), into at least one data structure having predetermined fields (step 902). This can be performed in real time as data is received from the multiple SaaS services, such that a data structure—maintained for an account, an employee, or the enterprise itself—is updated as digital activities are performed. Assume, for example, that the threat detection platform is tasked with creating data structures on a per-employee basis. In such a scenario, each data structure can be updated whenever a digital activity is performed with any of the accounts associated with the corresponding employee. Such an approach allows the threat detection platform to document and then analyze conduct across different SaaS services, in a way that allows for threats—especially cross-services ones—to be detected more reliably and quickly.

Further, the threat detection platform can determine, in real time, whether action is needed to address a threat to the enterprise by continually analyzing the at least one data structure (step 903). For example, for each of the employees, the threat detection platform may apply a model to entries in the at least one data structure that correspond to digital activities performed with accounts associated with that employee. The model may be trained to understand what constitutes normal behavior of that employee with respect to the multiple SaaS services, and therefore can predict whether any of the digital activities represent a deviation from normal behavior.

FIGS. 10A-D include examples of interfaces that show how digital activities can be tracked on a per-employee basis, but in a consistent form, in order to gain a better understanding of which digital activities are normal for each employee of an enterprise. In embodiments where the data can be accessed via APIs, direct enterprise integration (e.g., into the computing environment of an enterprise) and direct service integration (e.g., into the computing environment of a service provider) normally are not necessary.

Learning Behavioral Norms Across Different Services

Another important aspect of the threat detection platform is its ability to learn behavioral norms, on a per-employee basis, across different services. Assume, for example, that the threat detection platform is tasked with learning the behavioral norms of an employee who is able to access two services, namely, a first SaaS service for which she has a first account and a second SaaS service for which she has a second account. In such a scenario, the threat detection platform can acquire a first dataset that is representative of digital activities performed with the first account and a second dataset that is representative of digital activities performed with the second account. As further discussed below, the threat detection platform may attempt to learn not only what constitutes normal behavior with the first account and what constitutes normal behavior with the second account, but also what constitutes normal behavior across the first and second accounts.

Sometimes, a singular digital activity is sufficiently unusual to be flagged as evidence of a threat. Consider, for example, a scenario in which the first account completes a sign-in action in a country where the employee is known or presumed to not be located. However, it may also be the case that multiple digital activities—each of which is slightly or mildly unusual—are not sufficiently unusual when viewed separately but are sufficiently unusual when viewed together. Surfacing these “multi-event behavioral indicators” is not a trivial task, as the threat detection platform not only has to separately gauge the risk of each digital activity but also has to collectively gauge the risk of the multiple digital activities-even if those digital activities are performed across different services.

FIG. 11 includes a flow diagram of a process 1100 for learning what constitutes normal behavior of an employee across multiple services. Initially, the threat detection platform can acquire, via a first API, a first dataset related to past digital activities that are performed with a first account associated with the employee on a first SaaS service and acquire, via a second API, a second dataset related to past digital activities that are performed with a second account associated with the employee on a second SaaS service (step 1101). In some embodiments, the threat detection platform canonicalizes the first and second datasets as discussed above with respect to FIGS. 7-9.

The threat detection platform can then segment the first dataset into a first pair of segments, namely, a first segment that includes a portion of the past digital activities performed with the first account on the first SaaS service and a second segment that includes another portion of the past digital activities performed with the first account on the first SaaS service (step 1102). Similarly, the threat detection platform can segment the second dataset into a second pair of segments, namely, a third segment that includes a portion of the past digital activities performed with the second account on the second SaaS service and a fourth segment that includes another portion of the past digital activities performed with the second account on the second SaaS service (step 1103).

The threat detection platform can then provide the first and third segments—for example, as a concatenated training dataset—to a learning algorithm that produces, as output, a model that is able to predict the likelihood of the first and second accounts being compromised based on an analysis of digital activities performed with the first and second accounts on the first and second SaaS services (step 1104). The model could be, for example, a neural network with weights that are tuned as the learning algorithm learns from an analysis of the first segment, the third segment, and the first and third segments together. This “individual-and-collective learning” allows the model to understand what constitutes normal behavior of the employee in a more holistic manner. By learning from the first and third segments together, the learning algorithm may discover patterns—for example, that the second account generally performs a digital activity, like sending a message to another employee, proximate to the first account performing a digital activity, like receiving an email from that other employee—that would not be discovered if patterns were separately learned for the first and second SaaS services. The threat detection platform may use the second and fourth segments—for example, as a concatenated validating dataset—to validate the model (step 1105). How the model can be trained and validated is further discussed above with respect to FIG. 3. In response to a determination that performance of the model matches a criterion (e.g., exceeds a threshold), the threat detection platform can store the model in a data structure that is associated with the employee or the enterprise (step 1106).

Thereafter, the threat detection platform can use the model to predict the likelihood of either the first account or the second account being compromised. Assume, for example, that the threat detection platform acquires, via the first API, data that relates to one or more digital activities performed with the first account on the first SaaS service. In such a scenario, the threat detection platform can apply the model to the data, so as to generate an output that is representative of a prediction as to whether the first account is compromised. Similarly, if the threat detection platform acquires, via the second API, data that related to one or more digital activities performed with the second account on the second SaaS service, then the model can be applied to the data to generate an output that is representative of a prediction as to whether the second account is compromised. In the event that the output indicates that either the first account or the second account is compromised, the threat detection platform can determine an appropriate remediation action, if any.

Because the model is also trained to understand patterns across the first and second SaaS services, data acquired from the first and second SaaS services could be supplied to the model, together, as input. Thus, the threat detection platform may provide data acquired from the first SaaS service and data acquired from the second SaaS service to the model as input, so as to generate a prediction as to whether the first account or the second account is compromised. Accordingly, the model could be separately applied to each data stream from a source or collectively applied to multiple data streams from multiple sources to glean insights into whether behavior of accounts associated with a single employee across those different sources is normal.

FIG. 12 includes a flow diagram of a process 1200 for training a model—here, a neural network—to learn what constitutes normal behavior for an employee across multiple sources. For the purpose of illustration, the process 1200 is described in the context of SaaS services. However, the process 1200 may be similarly applicable to other types of sources. For example, the process 1200 may be similarly applicable if the neural network is tasked with learning what constitutes normal behavior across a SaaS service and an enterprise network, or a SaaS service and a cloud infrastructure, or a SaaS service, an enterprise network, and a cloud infrastructure.

For each of multiple SaaS services that are accessible to the employee, the threat detection platform can initially acquire data that is related to past activities performed thereon with one of multiple accounts that are associated with the employee (step 1201). Each of the multiple accounts may be associated with a different one of the multiple SaaS services and be permitted to perform digital activities thereon. As discussed above, the data could be provided, as input, to a standardization mechanism that canonicalizes the data into at least one data structure having predetermined fields (step 1202). For example, the data may be canonicalized into a single data structure that serves as a record of digital activities performed by the multiple accounts across the multiple SaaS services. As another example, the data may be canonicalized into multiple data structures, each of which serves as a record of digital activities performed by one of the multiple accounts on one of the multiple SaaS services.

Thereafter, the threat detection platform can train the neural network using the at least one data structure, such that the neural network learns what constitutes normal activity for the employee on each of the multiple SaaS services separately and across the multiple SaaS services collectively (step 1203). Specifically, the neural network may learn behavioral traits of the employee with respect to the multiple SaaS services. These behavioral traits may relate to the time at which a service is accessed, a frequency at which a service is accessed, a location from which a service is accessed, content of communications, recipients of outbound communications, originators of inbound communications, frequency of communications, formatting characteristics of communications, and the like. Generally, the employee is one of multiple employees that are employed by an enterprise, and this process 1200 can be carried out for some or all of the multiple employees. Accordingly, a separate neural network could be trained for each employee of the enterprise—or at least each employee who has at least one account for a service.

This allows the threat detection platform to monitor digital activities performed with accounts associated with the enterprise in real time. Assume, for example, that the threat detection platform acquires, in real time, data that relates to one or more digital activities performed on one of the multiple SaaS services. For each digital activity represented in the data, the threat detection platform can provide a corresponding portion of the data to an appropriate neural network that predicts whether a corresponding account is compromised. The appropriate neural network can be determined by identifying the corresponding account that performed that digital activity, identifying the employee that is associated with the corresponding account, and then identifying the neural network that is trained for the employee.

While the process 1200 is described in the context of training a neural network, those skilled in the art will recognize that the process 1200 may be carried out similarly with a different type of learning algorithm and model.

In sum, the threat detection platform can be programmed to build a separate model for each account based on retrospective information regarding digital activities performed with that account—or each employee based on retrospective information regarding digital activities performed with one or more accounts associated with that employee—in order to better identify instances of compromise in near real time. For example, the threat detection platform may ingest digital activities performed with an account over the last three months, six months, or twelve months and then the threat detection platform may build a model that understands how the account normally completes digital activities such as accessing the enterprise network, communicating internally (e.g., via internal email with other employees), communicating externally (e.g., via external email with vendors), accessing documents, etc. The model may help identify when the behavior of the account has changed.

Such an approach allows the threat detection platform to employ an effective model nearly immediately upon receiving approval from the enterprise to deploy it. Unlike conventional security products that only have access moving forward in time (i.e., after receiving the approval), the threat detection platform may employ a backward-looking approach to develop models that are effective upon deployment. Such an approach also enables the threat detection platform to go through a repository of past digital activities to identify whether any accounts should presently be suspected of compromise.

The aforementioned API-based approach to acquiring data from services for which employees of an enterprise have accounts provides a consistent way of looking at information related to digital activities performed with the accounts. Because the threat detection platform can directly access data related to the digital activities performed with those accounts, the threat detection platform can examine digital activities that are invisible to—or overlooked by—standard integration solutions. For example, a SEG integration that occurs through the mail exchanger (“MX”) record will only be able to see external emails arriving from, or destined for, external sources. The only way to make internal email visible to the SEG integration would be to externally reroute the email through the gateway, which generally is not practical. These types of digital activities are visible to the threat detection platform, however, due to how data regarding digital activities is acquired.

Approaches to Documenting and Visualizing Indications of Risk

An important aspect of the threat detection platform is its ability to document and visualize threats discovered through analysis of digital activities. Again, threats may be represented by a single digital activity, called “single-activity behavioral indicators” or “single-event behavioral indicators,” or threats may be represented by multiple digital activities, called “multi-activity behavioral indicators” or “multi-event behavioral indicators,” performed on a single service or across multiple services.

Consider, for example, a scenario in which the threat detection platform acquires data, in real time, from two services, namely, a first SaaS service and a second SaaS service, and applies models thereto to identify digital activities that are indicative of account compromise. Rather than store information regarding each digital activity represented in the data, the threat detection platform may only store information regarding digital activities for which the output produced by one of the models indicates some variation from normal behavior of the corresponding employee. Accordingly, the outputs produced by the model may be used to filter the digital activities, ensuring that information is stored only for those digital activities that are unusual.

Moreover, the threat detection platform can cause display of a visual indicium of the digital activities for which the output produced by the model indicates some variation from normal behavior of the employee. Referring again to the aforementioned example, the threat detection platform may document unusual digital activities performed across the first and second SaaS services by generating a timeline. With this timeline, threats—especially those evidenced by digital activities across different services—can be more easily detected and impacts thereof understood.

At a high level, the timeline is representative of a conglomeration of digital activities that might influence a determination as to whether there is a threat. Examples of digital activities include sign-in actions (e.g., with information regarding account, Internet Protocol address, country, etc.), communications (e.g., with information regarding sender, recipient, time of transmission, content, etc.), posture changes (e.g., with information regarding new roles or responsibilities or modifications to access rights), access actions (e.g., of physical locations), and the like. An example of a timeline-which can be dynamically updated as new digital activities are performed with accounts associated with the employee (here, Audrey Johnson), new determinations regarding risk are made, and new remediation actions are performed—is shown in FIG. 13. FIG. 14, meanwhile, includes additional notes explaining context that may be added by the threat detection platform to make the timeline more readily comprehensible and more readily actionable.

For each source from which data is ingested, the threat detection platform can implement a filtration mechanism (also called a “translation mechanism”) that outputs, into a data structure, the digital activities that “power” the timeline. Assume, for example, that the threat detection platform acquires data from several SaaS services for which employees of an enterprise have accounts. As discussed above, the threat detection platform can canonicalize the data acquired from each SaaS service and then determine, using models trained for the employees, the degree to which each digital activity deviates from normal behavior. For each SaaS service, the threat detection platform may implement a filtration mechanism that determines which digital activities performed on that SaaS service should be retained and which digital activities performed on that SaaS service should be discarded. Accordingly, the threat detection platform may implement different filtration mechanisms for different types of digital activities, from completing sign-in actions to receiving and transmitting communications and making posture changes.

As an example, properly identifying and documenting changes in posture may be important in establishing a log for auditing purposes. FIGS. 15-17 include examples of interfaces that show how posture can be determined and documented by the threat detection platform. Specifically, FIG. 15 illustrates how posture categories established for employees can be monitored to detect changes, FIG. 16 illustrates how policy changes embodied as changes in tenant posture category can be monitored to detect changes, and FIG. 17 illustrates how changes in service availability (here, of an enterprise-wide application) embodied as changes in application posture category can be monitored to detect changes. Simply put, the log may allow for further analysis of when the rights of a given account were changed, as well as how the rights of the given account were changed.

FIG. 18 includes a diagrammatic illustration that shows how the threat detection platform can consume or define digital activities from data 1802 acquired from one or more sources 1800, convert the digital activities into per-activity judgments regarding how interesting, critical, or unusual each digital activity is, and then concatenate the per-activity judgments into a standard scheme for identifying notable digital activities. Specifically, the threat detection platform can apply filtration mechanisms 1804 to identify those digital activities that are representative of unusual behavior, to at least some degree, and should be populated onto the timeline 1806.

The timeline enables security professionals, such as Chief Information Security Officers (“CISOs”), to utilize the threat detection platform consistently by:

- Aggregating digital activities across different sources;
- Providing contextual judgment on the entirety of the multi-activity timeline, rather than sporadic or isolated judgment of individual digital activities; and
- Allowing for artificial intelligence (“AI”) augmentation with tools that boost productivity, for example, by assisting with dynamic consideration of new digital activities.

Consider, for example, a scenario in which the threat detection platform discovers a combination of events—say, a change in administrative privileges and a sign-in action from an unusual location (e.g., another country)—that are collectively indicative of a threat. Rather than have a security professional develop a theory and prepare a summary of events, the threat detection platform could instead automatically generate documentation (e.g., in the form of a slide or memorandum) that summarizes its findings. The documentation could be based on preexisting templates, or the documentation could be generated through the use of generative AI. The ability to assist security professionals in documenting and explaining threats may be called the “threat hunter tool.” At a high level, the threat hunter tool is representative of a user experience (“UX”) layer that resides on top of the timeline. The threat hunter tool may be accessible to, or part of, a reporting module (e.g., reporting module 114 of FIG. 1). Users may be able to access an interface that is generated by the threat detection platform, review notable digital activities, and generate cases (e.g., summarizing the nature of the threat, confidence in the determination, severity of the threat, etc.) without much—or any—input from those users. The threat hunter tool serves several purposes. First, it allows threats to be more quickly documented, leading to quicker resolution or remediation. Second, it allows threats to be documented in a more consistent manner. Simply put, the reports produced by the threat detection platform may have consistent format or content, allowing the reports to be more efficiently reviewed. Third, it allows for improved stratification of threats, as only those threats for which risk exceeds a threshold (e.g., severe threats and moderate threats) may be elevated for consideration by a security professional. That is, the threat detection platform may autonomously triage threats so that those threats most likely to cause meaningful harm are reviewed by a security professional more quickly, though the threat detection platform may still allow the security professional to review digital activities at a deeper level if desired. FIG. 19 shows how the threat detection platform can approach detecting and flagging anomalous digital activities by implementing a layered approach, where digital activities are initially examined to ascertain whether each digital activity is representative of a meaningful change in state or unusual behavior and then those notable digital activities are loaded into a queue. Digital activities loaded into the queue may not only be visualized in a timeline, as shown in FIGS. 10B-D, but may also be documented in a data structure. The threat detection platform may maintain data structures with information regarding notable digital activities—or analyses thereof—on a per-account, per-employee, or per-enterprise basis.

FIG. 20 includes a flow diagram of a process 2000 for surfacing indications of risk discovered through analysis of digital activities performed with multiple accounts associated with an employee across multiple services. For each of the multiple SaaS services, the threat detection platform can initially acquire data relating to digital activities performed with a corresponding one of the multiple accounts (step 2001) and canonicalize the data into a standardized format (step 2002), as discussed above. Moreover, the threat detection platform can apply a model trained for the employee to the resulting data structure(s) (step 2003), so as to produce outputs that indicate whether each digital activity deviates from a behavioral pattern learned to be normal for the employee. In embodiments where a separate data structure is maintained for each of the multiple SaaS services, the model can be applied to each data structure separately and/or the model can be applied to the multiple data structures collectively. Said another way, the model can be designed and trained to be separately applied to data that is streamed from each SaaS service or collectively applied to multiple streams of data to glean insights into whether behavior on a single SaaS service is normal and whether behavior across multiple SaaS services is normal.

The threat detection platform can then identify digital activities, if any, for which the output produced by the model indicates a variation from the normal behavior of the employee (step 2004). This can be accomplished by determining whether the output matches a criterion-which will depend on the nature of the model (e.g., whether the model is a binary classification model, non-binary classification model, or regression model). For each of the identified digital activities, the threat detection platform can store information related to that identified digital activity in a data structure associated with the enterprise, employee, or account with which that identified digital activity was performed (step 2005). Moreover, the threat detection platform can cause display of a visual indicium of that identified digital activity on an interface (step 2006). For example, information regarding that identified digital activity may be posted to a timeline, on which digital activities are arranged in temporal order to visually indicate activity level and threat over time. Specifically, the threat detection platform may create, for each identified digital activity, the visual indicium that includes at least some of the information and then arrange the visual indicia in temporal order so as to generate the timeline as shown in FIGS. 10B-D.

In some embodiments, insights can be gleaned by the threat detection platform through analysis of the timeline or the data structure.

For example, the threat detection platform may determine that one of the multiple accounts is at higher risk of being compromised due to an increasing frequency of unusual digital activities. In such a scenario, the threat detection platform may generate a summary of the threat posed by compromise of a given one of the multiple accounts. That summary could specify the primary entity and one or more digital activities that resulted in the determination being made. Generally, the primary entity is one of the multiple accounts that is suspected of being compromised. However, the primary entity could also be another account associated with another employee that is being targeted via one of the multiple accounts. The primary entity could also be a communication or a document that is involved in the one or more digital activities.

As another example, the threat detection platform may determine that the model requires retraining if a given number or percentage of digital activities deemed to be unusual are marked as normal through the interface. Such action may be representative of an acknowledgment that changes in behavior of the employee are normal, and therefore should be taken into account by the model through retraining.

Accordingly, the threat detection platform may generate visualizations—like timelines as shown in FIGS. 10B-D—to better help users understand the threat posed by singular digital activities and the threat posed by more coordinated attacks across multiple accounts.

Together, multiple digital activities in the timeline may define a “case” that exhibits characteristics of an attack. Generally, the core components include (i) a primary entity, (ii) a series of notable digital activities, and (iii) a judgment (and in some embodiments, a prediction of attack type and/or a prediction of attack severity). Generally, the primary entity is an employee, an account, or a document, depending on the type of digital activity (and therefore, the nature of the source from which the data representing the digital activity is acquired). However, the primary entity could be another type of object or even a piece of information. For example, if a digital activity is representative of a transmission or receipt of a communication, then the primary entity may be the person that is associated with the account that transmitted or received the communication. As another example, if a digital activity is representative of a sign-in action for a service through which information is accessed, then the primary entity may be the information. Meanwhile, the series of notable digital activities may include any digital activities involving the primary entity that have been determined to be unusual. Digital activities that have been deemed normal may be discarded by the threat detection platform to conserve computational resources, and therefore may not be recorded in the timeline.

The timeline allows the threat detection platform to use its core infrastructure, as discussed above with reference to FIGS. 1-3, across different use cases (e.g., from business email compromise to internal phishing to account takeover), across different services (e.g., from communication services to non-communication services), etc. By aggregating digital activities for a primary entity, the threat detection platform allows for higher-order determinations such as:

- External Attacker Risk: Establish whether account(s) associated with a given employee are at risk from an external attacker;
- Insider Attacker Risk: Establish whether account(s) associated with a given employee are being leveraged to do internal harm; and
- Document Risk: Establish whether there is a trend line (e.g., in terms of which employees have accessed the document, the frequency of access events, etc.) for a given document that makes the given document a high-priority issue.

Performing these higher-order determinations allows the threat detection platform to emulate security analysts in two key respects. First, the threat detection platform can ascertain whether multiple digital activities—when considered in combination with one another—are indicative of a threat. Second, the threat detection platform can monitor digital activities occurring across different services, which can be—and often are—entirely unrelated to each other. However, the threat detection platform can monitor digital activities across different platforms in real time—something security analysts simply cannot do—and, therefore, is also able to identify and address threats in real time. Moreover, the threat detection platform can more consistently and accurately identify the digital activities that are unusual. Security analysts tend to have “false positives,” where a digital activity is determined to be unusual despite being normal, and “false negatives,” where a digital activity is determined to be normal despite being unusual, due to the subjective nature of identifying threats.

Ascertaining Behavioral Deviations Through Multi-Activity Scoring

A significant benefit of the approach to detecting threats introduced here is that the threat detection platform can discover deviations in behavior within a single service, as well as deviations in behavior across multiple services. To accomplish this, the threat detection platform can employ a multi-activity scoring methodology, where digital activities are scored individually and collectively, to ascertain risk in near real time. Consider, for example, a scenario in which the threat detection platform applies a model to data streamed from a first SaaS service for which an employee has a first account and data streamed from a second SaaS service for which the employee has a second account. Over time, the model will output a series of predictions, in temporal order, as digital activities are performed with the first and second accounts. In determining whether the first account is compromised, the threat detection platform may consider not only its most recent digital activity but also other, less recent digital activities (and potentially digital activities performed with the second account, as discussed above). This methodology for “multi-activity scoring” may be adaptive, such that the scores are sensitive to timeliness. For example, in determining whether the first account is compromised, the threat detection platform may consider all digital activities performed with the first account within a predetermined interval of time (e.g., one day, three days, seven days), placing more weight on more recent digital activities. As another example, the determination may be sensitive to increasing “unusualness.” For example, the threat detection platform may determine that first and second digital activities are mildly unusual separately but, in combination, are highly unusual. In such a scenario, the combination of the first and second digital activities can be viewed as a stronger indicator that a threat exists.

Multi-event scoring may depend on accurately identifying digital activities by parsing data acquired from different sources and then sorting those digital activities-generally by account or employee-so that digital activity of a given person across multiple services can be better understood by the threat detection platform. Accordingly, the threat detection platform may establish relationships between accounts and then programmatically associate accounts corresponding to the same person. For example, the threat detection platform may specify, in a data structure (e.g., a table), that a first account for a first source (e.g., a first SaaS service) is associated with the same person as a second account for a second source (e.g., a second SaaS service). This data structure—which maps employees to accounts—can serve as a reference for identifying the appropriate model upon receiving data regarding a digital activity performed with a given account from a source. Establishing—or at least knowing—the relationships between accounts across different services is an important aspect of monitoring digital activities of employees across those different services. Digital activities of each employee can then be scored by the threat detection platform in real time as discussed above.