Multi-perspective user / entity behavior analysis for software-as-a-service applications

Abstract

The Multi-Perspective User / Entity Behavior Analysis (UEBA) system ("the System") builds and maintains interchangeable modules for predicting the likelihood of anomalous user behavior within a range of actors (i.e., users or entities) in an organization over a period of time. Each module includes probabilistic models and / or machine learning models as submodules that model actor behavior at various levels of granularity with respect to the use of Software-as-a-Service applications. The System generates an anomaly score by decorrelating the likelihoods output by each submodule, and uses the anomaly score to monitor and implement corrective actions based on anomalous actor behavior to maintain an organization-wide security posture.

Description

[Background technology]

[0001] This disclosure generally relates to data processing (e.g., CPC subclass G06F) and computational configurations based on specific computational models (e.g., CPC subclass G06N).

[0002] User Behavior Analysis (UBA) or User / Entity Behavior Analysis (UEBA) is a cybersecurity technique for tracking user / entity behavior on a network (e.g., on servers, network devices, endpoint devices, etc.) to detect anomalies potentially related to threats or exposures to cybersecurity systems. Data reflecting user / entity activity on the network is collected periodically from various sources, such as log data. Statistical analysis, machine learning, or other analytical techniques are applied to the collected data to determine normal behavioral patterns between users and entities (e.g., regarding user activity and device usage reflected in the data). The collection of such data is carried out continuously for periodic analysis based on established normal behavioral patterns to determine whether any user / entity behavior reflected in the collected data is deviant or abnormal. Users and / or entities determined to correspond to data representing deviations from normal behavioral patterns may be detected as potentially related to threats or otherwise potentially posing a risk to the network. [Brief explanation of the drawing]

[0003] Embodiments of this disclosure can be better understood by referring to the accompanying drawings. [Figure 1] This is a conceptual diagram of an exemplary multi-perspective UEBA system for generating anomaly scores for actor behavior in a tenant organization with multiple modules. [Figure 2]This is a schematic diagram illustrating an exemplary multi-perspective UEBA system for training / updating and deploying multiple modules to identify abnormal actor behavior within a tenant organization. [Figure 3] This is a schematic diagram of an exemplary architecture for a neural network with an activity location modeling module for a multi-perspective UEBA system. [Figure 4] This is a flowchart illustrating exemplary behavior for performing UEBA anomaly detection on an actor over a specified time period, across multiple behavioral perspectives. [Figure 5] This is a flowchart of exemplary actions for implementing corrective measures based on the likelihood of multi-perspective abnormal behavior for an actor. [Figure 6] This is an illustrative flowchart of the process for decorrelating the likelihood of an actor's abnormal behavior over a given time period in order to generate an abnormality score. [Figure 7] This is an exemplary flowchart of operation for training / updating a multi-perspective UEBA system to generate anomaly scores for actor behavior across a tenant organization. [Figure 8] This is an exemplary flowchart of operations for maintaining a multi-perspective UEBA system over multiple time periods. [Figure 9] This illustrates an exemplary computer system with a multi-perspective UEBA system. [Modes for carrying out the invention]

[0004] The following description includes exemplary systems, methods, techniques, and program flows to aid in understanding this disclosure and does not limit the scope of the claims. Well-known instruction instances, protocols, structures, and techniques are not shown in detail for the sake of brevity.

[0005] term

[0006] The use of the phrase "at least one of" preceding a list containing the conjunction "and" should not be treated as an exclusive list unless otherwise specified, nor should it be interpreted as a list of categories having one item from each category. A clause containing "at least one of A, B, and C" may be violated by one of the listed items alone, multiple of the listed items, or one or more of the listed items and another unlisted item.

[0007] As used herein, "Actor" refers to a user or entity under the umbrella of an organization, which subscribes to one or more Software-as-a-Service applications (SaaS applications) as a tenant. The actor has associated historical activity data for one or more SaaS applications.

[0008] overview

[0009] Implementing UEBA for applications delivered according to a SaaS model presents several challenges, particularly due to the inherent variability of actor behavior both within and across tenant organizations. Additionally, data within the scope of individual actors within a tenant organization is typically sparse, making it difficult to train effective models that capture actor-specific behavior. Improving the quality of UEBA implementations and modeling different aspects of actor behavior to account for variability is especially challenging when the model scope data is sparse.

[0010] This specification discloses a multi-perspective UEBA system that effectively models actor behavior by leveraging SaaS activity data from both actors and nearby actors, according to the tenant organization's directory service for SaaS applications used by actors. Each perspective from which data is analyzed corresponds to a different aspect of behavior, where an "aspect" of actor behavior refers to a behavioral descriptor that can be identified from data showing the actor's activity within the tenant organization's SaaS applications. Exemplary aspects of behavior include activity volume (e.g., the amount of data uploaded / downloaded), activity duration, activity type, and location associated with actor activity. Each aspect of behavior is modeled by a separate module that implements machine learning and / or statistical techniques for the actor, and, where data is insufficient, across multiple actors in the tenant organization. The module is continuously trained against previous time periods of actor behavior and is used to predict anomalies in actor behavior in the current time period. Based on behavioral data collected during the current time period, the multi-perspective UEBA system decorrelates and combines the likelihoods obtained as outputs from inputting subsets of behavioral data into each module to generate an actor anomaly score, where each likelihood indicates the probability that the actor's behavior during the current time period is anomaly.

[0011] Each module implemented by the multi-perspective UEBA system potentially uses data from additional actors within the tenant organization for training. For example, in the case of a module capturing aspects of actor behavior such as activity volume, activity duration, and activity type, the multi-perspective UEBA system can determine that there is insufficient (i.e., too sparse) data about the actor in previous time periods and can extract data about nearby actors within the hierarchical structure defined by the tenant organization's directory service as additional data for training each module. In the case of a module capturing the location associated with an actor's activity, the multi-perspective UEBA system can collect location-based data of actors across the entire tenant organization as training data. Scores are generated as a simple weighted average of the likelihoods output by each module. As a result, this framework is flexible by allowing the dynamic addition and removal of modules with minimal impact on scoring and by allowing the dynamic addition of training data for modules with sparse actor activity over previous time periods.

[0012] Example explanation

[0013] This is a conceptual diagram of an exemplary multi-perspective UEBA system for generating anomaly scores for actor behavior in a tenant organization having multiple modules. The multi-perspective UEBA system ("System") 101 manages UEBA for tenant organizations 106 that are subscribed to at least SaaS applications 102A-102C. System 101 includes modules 103A-103D that generate likelihoods 112A-112D, respectively, that the actor behavior of a target actor 130 among the actors 104 of tenant organization 106 is anomaly over a certain period of time. The likelihoods 112A-112D are then aggregated by an anomaly likelihood aggregator 109 to generate an anomaly score 120, indicating that the behavior of the target actor 130 is anomaly over that period of time. As part of implementing UEBA, the tenant organization 106 continuously communicates actor activity data 108 and directory service data 110 to system 101 for online anomaly detection and updating of modules 103A-103D over fluctuating time periods of data collection. Although shown as including modules 103A-103D representing various aspects of actor behavior, system 101 is flexible and can dynamically add or remove modules by reconfiguring the anomaly likelihood aggregator 109 to accept different inputs. For example, the data loss prevention (DLP) module 103E is shown with a dashed outline to indicate that this module can be dynamically added or removed by system 101. Each module models a distinct perspective of the activity by actor 130 within a bucketed time window of a time period, where each time period includes a period for analyzing anomalous behavior by actor 130. While the granularity of time periods and the bucketed time windows within each time period may vary, for simplicity, each time period and bucketed time window will be described as a day and each hour of a day, respectively.

[0014] Tenant organization 106 consists of organizations that subscribe to multiple SaaS applications 102A-102C. Tenant organization 106 can be distributed across multiple locations and numerous data stores or networks, which may be on-premises or cloud-based private networks. Therefore, firewall 121 collects actor data from various communication channels and databases across tenant organization 106 (e.g., in a data lake in the cloud) and periodically communicates actor activity data 108 and directory service data 110 to system 101 in batches. Firewall 121 can sort the communicated data 108 and 110 by application identifier, for example, from process identifiers shown in traffic logs. Communication of actor activity data 108 and directory service data 110 occurs asynchronously. For example, firewall 121 can communicate actor activity data 108 for all time periods during which actor activity is being monitored, while firewall 121 can communicate directory service data 110 when updates occur or according to a long-term schedule spanning multiple time periods. Although firewall 121 and system 101 are shown as separate software components in Figure 1, system 101 could be a sub-component of firewall 121 and share memory with various other components that collect data for UEBA purposes, thereby avoiding the step of communicating data 108, 110 to system 101.

[0015] The Activity Volume Modeling Module 103A models the actor activity of actor 130 over bucketed time windows (e.g., hourly) within a given time period (e.g., one day). Actor activity includes events of actor 130 related to SaaS applications 102A-102C. An "event" refers to an action taken by actor 130 interacting with one of the SaaS applications 102A-102C, such as by initializing or modifying a process, by prompting data communication over a public or private network, by clicking on an element of the user interface, or by initializing a download or upload through the application. The Activity Volume Modeling Module 103A includes a submodule that is a probability distribution (e.g., exemplary probability distribution 105) that models the frequency of events for actor 130 within each of the bucketed time windows, based on historical activity data for actor 130. Each probability distribution models a specific action taken by actor 130 when using one of the SaaS applications 102A-102C during a bucketed time window. For example, the probability distribution can model downloads by actor 103 to application 102A between 9:00 AM and 10:00 AM, and uploads by actor 130 to application 102B between 1:00 PM and 2:00 PM.

[0016] Each probability distribution is selected from a family of probability distributions such as the power-law distribution, and the parameters from the family of probability distributions are selected, for example, using maximum likelihood estimation, to minimize the difference between the probability distribution and the historical data (i.e., the probability distribution is "fit" to the historical activity data). Other families of probability distributions such as the Gaussian distribution and the log-normal distribution can be fit to the historical data. The family of probability distributions is selected based on the expected shape of the past actor activity data. For example, in the case of the family of power-law distributions, the activity volume modeling module 103A models the distribution of the frequency of events in a bucketed time window for actor 130. In this case, the sorted frequencies within the bucketed time window are expected to have the shape of a power-law distribution. For other aspects of actor behavior with different expected shapes, other families of probability distributions can be used.

[0017] Next, the activity volume modeling module 103A calculates the likelihood 112A by determining the feature values corresponding to each probability distribution (e.g., the number of downloads by actor 130 for application 112A from 9:00 am to 10:00 am) from the actor activity data 108 for the current time period for analysis, and extracts the anomaly likelihood value given by the probability distribution for that feature value (e.g., 1 to 2 downloads by actor 130 for application 112A from 9:00 am to 10:00 am has a likelihood of 0.5 corresponding to abnormal behavior).

[0018] The activity type modeling module 103B and the activity time modeling module 103C also use probability distributions to model actor behavior based on actor activity data 108. The activity type modeling module 103B includes probability distributions corresponding to each application / activity type pair and each bucketed time window (e.g., each hour of a day) for the type of activity by applications 102A - 102C and actor 130. The activity time modeling module 103C includes probability distributions for each bucketed time window that model how frequently actor 130 performs activities within each bucketed time window, derived from actor activity data 108.

[0019] The activity location modeling module 103D models the historical locations of actors across tenant organization 106 within each bucketed time window. For example, the activity location modeling module 103D can include a neural network such as exemplary neural network 107. The activity location modeling module 103D receives as inputs both the locations identified in actor activities by actor 130 during that time period and the metadata and proximity data of nearby actors according to the hierarchical structure defined in directory service data 110. Likelihood 112D is the output of the final layer of the activity location modeling module 103D. Modules 103A - 103C are trained per actor, while the activity location modeling module 103D is trained against actor data across tenant organization 106. Further details of the architecture of the activity location modeling module 103D are described in FIG. 3.

[0020] The DLP module 103E models how often actor 130 accesses potentially sensitive documents, such as documents classified as potentially sensitive according to a DLP system managed by a firewall 121 (not shown). The DLP module 103E includes a probability distribution for each bucketed time window that models the number of potentially sensitive documents accessed by actor 130 from actor activity data 108.

[0021] Each of modules 103A-103C may suffer from data sparseness within the time window for predicting the likelihood of abnormal behavior by actor 130. To account for this sparseness, system 101 can determine whether the data in actor activity data 108 is insufficient for each of modules 103A-103C, and based on the determination that one or more of modules 103A-103C have insufficient data, it can determine the N actors closest to actor 130 according to the hierarchical structure of tenant organization 106 defined in directory service data 110. N is a parameter that may be fixed or depend on the hierarchical structure (i.e., all actors within a distance of 3 from the node corresponding to actor 130) and the type of module with insufficient data. An exemplary hierarchical structure 114 includes user 1 as the CEO of tenant organization 106, and users 2 and 3, who are the CFO and HR lead of tenant organization 106, respectively, and are connected under user 1 in the hierarchy. In this example, the two users closest to user 1 are user 2 and user 3. The exemplary hierarchical structure 114 may further have user data embedded in each node, such as the user's nationality, job title, and associated team. Although described as users, the nodes in the hierarchical structure defined in the directory service data 110 may correspond to entities, more generally, actors in the tenant organization 106, including users. Furthermore, although described as a hierarchical structure, the directory service generating the directory service data 110 may maintain any graphic data structure that represents the proximity of actors within the tenant organization 106 according to some concept of organizational structure.

[0022] When system 101 identifies the N actors closest to actor 130, system 101 retrieves data from actor activity data 108 for that time period and inputs it into the data of modules 103A-103C that have insufficient data. For example, system 101 can use the activity data from actor activity data 108 for the N closest actors to update the frequency of activity amounts within a bucketed time window, the frequency of events of a particular type, and the frequency of activity times within a bucketed time window. In some embodiments, system 101 is configured to collect data for the N closest actors for one or more of modules 103A-103C, regardless of whether the data within the time window is sufficient or insufficient.

[0023] Modules 103A-103D are described as one or more probabilistic models and neural networks. More generally, the modules implemented by system 101 may include any machine learning or statistical model, depending on the available computing resources, the desired accuracy of the anomaly score, etc. The modules are interchangeable, and the anomaly likelihood aggregator 109 may be configured to accept dynamically sized inputs indicating the likelihood and the type of module that generated the likelihood, in order to appropriately generate the anomaly score 120. Module implementations can be varied per actor and per tenant organization based on desired or pre-configured preferences.

[0024] The anomaly likelihood aggregator ("aggregator") 109 receives likelihoods 112A-112D output by modules 103A-103D, respectively, and decorrelates / averages the logarithms of likelihoods 112A-112D to generate anomaly scores. The decorrelation step attempts to isolate the likelihood values ​​output by each module so that the joint probability of any likelihood occurring is their product, i.e., their sum as logarithms. Decorrelation of log-likelihoods is performed first within each module (i.e., modules 103A-103C) if the modules have multiple likelihoods as outputs, and then across modules 103A-103D. Decorrelation within each module is performed in three stages. First, aggregator 109 determines the correlation matrix of pairs of probability distributions modeled by the modules (later called "submodules"). Next, aggregator 109 identifies sets of probability distributions that are strongly correlated according to the correlation matrix and replaces each set with its mean probability distribution. Finally, aggregator 109 recalculates the correlation matrix for the potentially averaged probability distributions and weights each probability distribution according to the recalculated correlation matrix to determine the updated likelihood for each module. Aggregator 109 then averages the likelihoods across the modules to determine a single likelihood for each of modules 103A–103D. Finally, aggregator 109 determines the correlation matrix between modules 103A–103D and generates an anomaly score 120 as a weighted average of the single likelihoods weighted according to the correlation matrix. The operation for decorrelating the likelihoods is described in more detail with illustrative examples, with reference to Figure 6.

[0025] Figure 2 is a schematic diagram of an exemplary multi-perspective UEBA system for training / updating and deploying multiple modules to identify anomalous behavior of actors within a tenant organization. System 101 in Figure 2 continuously collects new activity data of actors across tenant organizations (not shown) and dumps old activity data asynchronously with training, updating, and deploying modules for anomaly detection according to multiple behavioral perspectives. New activity data is added to a repository, analyzed along various vectors for potential risk, and discarded when the data is no longer closely related to UEBA (e.g., after 3 months or 1 year). Training and updating various modules for UEBA of identified actors within a tenant organization is shown in Figure 2 by a series of letters A-F. Each stage represents one or more actions. While these stages are ordered for this example, they are presented as an example to help understand this disclosure and should not be used to limit the claims. Subject matter that falls within the claims may differ from that illustrated.

[0026] In Stage A, System 101 identifies Actor 202 for UEBA training / updating of corresponding modules deployed for detecting abnormal actor behavior. Training and / or updates may be performed per actor according to a fixed schedule (e.g., monthly) or based on external triggers, such as System 101 administrators identifying one or more actors, or Actor 202's tenant organization firewall identifying Actor 202 as associated with SaaS application activity. Although shown as a single actor for simplicity, the operation in Figure 2 may run concurrently / in parallel for multiple actors from tenant organizations, with each actor having at least a subset of modules specific to that actor, separate subsets of modules trained across all actors. System 101 further identifies two sets of modules maintained for Actor 202: namely, a set of actor-specific modules 205 and a set of tenant organization modules 207. The actor-specific module 205 is trained in the context of actor 202's historical data, while the tenant organization module 207 is trained on historical data across actors in the entire tenant organization. Each module is trained to predict the likelihood that actor 202's (and / or other actors in the tenant organization's) behavior is anomalous. Note that both the actor-specific module 205 and the tenant organization module 207 may be submodules of modules maintained by system 101, which models a particular perspective of actor behavior.

[0027] In Stage B, the UEBA model trainer ("Trainer") 203 retrieves activity data 210 of actor 202 over the past N time periods. The Trainer 203 communicates a query 208 to the actor activity data repository 204, which specifies the identifier of actor 202 and the parameters for the past N time periods, and the repository 204 returns the activity data 210. The activity data 210 includes event data about actor 202's activities related to one or more SaaS applications used by the tenant organization over the past N time periods T(1) to T(N). N are adjustable parameters selected to minimize variability caused by external factors such as changes in actor 202's place of residence, sleep schedule, location within the tenant organization, work productivity, etc. The repository 204 can receive and store the actor activity data once the data is detected by the firewall in relation to actor 202 and one or more SaaS applications and transferred to system 101. Repository 204 can dump data older than N time periods to improve memory efficiency when this data is no longer desired for further training / updating.

[0028] In Stage C, trainer 203 identifies a subset of actor-specific modules 205 that have insufficient training data. For example, trainer 203 may determine that the amount of historical activity data collected for one or more perspectives of actor 202's actor behavior over the past N time periods falls below a threshold amount of historical activity data for those perspectives. The threshold amount of historical activity data may vary depending on the perspective.

[0029] In Stage D, trainer 203 identifies actors close to actor 202 within the same tenant organization. Trainer 203 identifies actors close according to a hierarchical structure defined by the tenant organization's directory service, e.g., an exemplary graph data structure 216. Actual actors close may be identified based on a threshold number of actors close (e.g., by performing a breadth-first search of the hierarchical structure), a threshold distance from actor 202, etc. If the corresponding module has insufficient training data, a different set of actors close may be identified for different perspectives of actor behavior. For example, trainer 203 can identify actors further away for a module with more training data. For each actor close for a behavioral perspective / module, trainer 203 retrieves activity data for those actors over N past time periods and adds it to the training data.

[0030] In Stage E, the trainer 203 trains at least actor-specific modules 205 and, in some embodiments, tenant organization modules 207 on the extracted data and additional data from nearby actors. Since the tenant organization modules 207 are trained on data from the entire tenant organization, model training of these modules may occur asynchronously with the training of actor-specific modules 205, based on separate triggers. Each module is trained according to its corresponding architecture and / or training criteria. In some cases, if modules 205, 207 have been previously trained, the trainer 203 may update the modules instead. Some model architectures for the models implemented by the modules, such as fitted probability distributions, enable efficient updates due to the low computational cost of best-fit parameters using updated training data.

[0031] In Stage F, Trainer 203 deploys modules 205 and 207, which were trained in Stage E, as the trained UEBA module 201 for detecting abnormal behavior of Actor 202 in future time periods T(N+1), T(N+2), ... Training / updating modules for Actor 202 and other actors in the tenant organization can occur simultaneously and in parallel. For example, Trainer 203 can collect / retrieve historical activity data of actors across the entire tenant organization over past N time windows and sort the data for each behavioral perspective into the appropriate module for each actor for training, based on sparseness and module / submodule scope (e.g., actor-specific or entire tenant organization) constraints.

[0032] Figure 3 is a schematic diagram of an exemplary architecture for a neural network with an activity location modeling module for a multi-perspective UEBA system. The activity location modeling module 103D includes a graph embedding model 301, a natural language processing (NLP) embedding layer 303, and a location embedding layer 305, which receive directory service data 110, actor metadata 300, and actor location data 302 as inputs, respectively. The directory service data 110 contains a data structure for an organizational hierarchy graph, representing the relative hierarchy of actors according to their occupation within the organization. The graph embedding model 301 generates a local graph embedding 304, e.g., a node2vec algorithm, by applying a graph embedding algorithm that captures local topology information around a specified actor in the directory service data 110. The graph embedding model 301 is trained separately from the rest of module 103D using the directory service data 110 for the entire organization. The other layers of module 103D are trained as an ensemble.

[0033] Both the NLP embedding layer 303 and the location embedding layer 305 include NLP embeddings, such as GloVe (Global Vectors for Word Representation) embeddings, which can be initialized and refined during training. The actor location data 302 includes an indicator of each location visited by the actor within a given time period, and the actor metadata 300 includes actor metadata, such as that stored by a directory service, including the actor's occupation, place of residence, etc. The embedded actor metadata 306 and the embedded actor location data 308 include outputs from the NLP embedding steps by the NLP embedding layer 303 and the location embedding layer 305, respectively.

[0034] The concatenation layer 307 receives and concatenates outputs 304, 306, and 308, and supplies the concatenated output to the fully connected layer 309. The fully connected layer 309 has outputs of a length equal to the number of countries monitored by module 103D, with each entry indicating the likelihood that actor activity in the location (i.e., country) corresponding to that entry contains abnormal actor behavior. As an example of the predicted location likelihoods 312 output by the fully connected layer 309, the exemplary likelihood 310 shows that the likelihood of actor activity in India corresponding to abnormal behavior is 0.92, the likelihood of actor activity in the Netherlands corresponding to abnormal behavior is 0.10, and the likelihood of actor activity in Germany corresponding to abnormal behavior is 0.02. The rule layer 311 receives the predicted location likelihoods 312 and generates the likelihoods 314 of abnormal behavior. The rule layer 311 determines the likelihoods 314 by applying different rules depending on the location. For example, the rules could generate a higher likelihood of abnormal behavior in locations known to have a higher cybersecurity risk, such as China or Russia.

[0035] Figures 4–8 are flowcharts illustrating exemplary operation for training and implementing a multi-perspective UEBA system for detecting anomalous actor behavior in a tenant organization using an adaptive, module-based architecture that captures multiple perspectives of actor behavior. For consistency with and / or ease of understanding with the preceding figure (or more), the exemplary operation is illustrated by reference to the multi-perspective UEBA system ("System"), a firewall, and a UEBA module trainer ("Trainer"). Names chosen for program code are not intended to limit the scope of the claims. Program structure and organization may vary depending on the platform, programmer / designer preferences, programming language, etc. In addition, names for code units (programs, modules, methods, functions, etc.) may also vary and are arbitrary for similar reasons.

[0036] Figure 4 is a flowchart illustrating exemplary operation for performing UEBA anomaly detection for an actor over a specified time period across multiple behavioral perspectives. In block 401, the multi-perspective UEBA system ("the System") identifies collected SaaS application activity data of an actor over a specified time period. The specified time period may be a period specified according to a system schedule maintained by the tenant organization (e.g., weekly) or based on an external trigger such as an actor audit by an administrator.

[0037] In block 403, the system initiates an iteration through the actor behavior perspective. Each perspective corresponds to feature values ​​generated from the characteristics of SaaS application activity data collected over a specified time period.

[0038] In block 405, the system begins iterating through submodules for perspectives. For example, the Activity Quantity Modeling module may include submodules corresponding to each application / action pair (e.g., download for application A, download for application B, click for application A, etc.) for actions performed and applications used by an actor during that time period. A module can vary in terms of the number of submodules; some modules, for example, the Activity Location Modeling module, may include one submodule.

[0039] In block 407, the system determines whether there is sufficient SaaS application activity data collected for the perspective's submodules within a specified time window. For example, the system may determine whether the number of feature values ​​for features corresponding to a submodule exceeds a threshold number of feature values, or whether there is a sufficient number of events corresponding to actor activity within a specified time window. Alternatively, the system may assess the sparseness of the activity data, for example, whether activity data is missing in a particular peak time slot, and if the activity data is excessively sparse, it may determine that the activity data is insufficient. The criteria for whether there is sufficient activity data may differ depending on the perspective. If the SaaS application activity data is insufficient for the perspective within a specified time window, the operation flow proceeds to block 409. Otherwise, the operation flow skips to block 413.

[0040] In block 409, the system identifies an additional M actors to supplement the activity data for the perspective. For example, the system can identify the nearest M actors by following a breadth-first search of the hierarchical structure of actors within the same tenant organization as defined by the directory service until M actors are identified. Alternatively, the system can identify actors within a threshold distance from an actor, where M may vary based on the number of actors found. The algorithm and / or criteria for identifying the additional M actors may differ depending on the perspective and submodule.

[0041] In block 411, the system supplements the collected activity data with data from the SaaS application activity of M actors within a specified time window. When the system detects activity data in user traffic / processes running on an endpoint device, it can access / retrieve the collected activity data from a repository that receives activity data from the firewall.

[0042] In block 413, the system preprocesses activity data and inputs it into a submodule to obtain the likelihood of an actor's abnormal behavior over a specified time period as output, according to the perspective of actor behavior. The preprocessing differs depending on the submodule. For example, the system generates the frequency of a specific event or event type for a probabilistic model. For machine learning models, the system applies various embedding and normalization steps, etc.

[0043] In block 414, the system updates the perspective's submodules using activity data. Certain submodules are suitable for efficient updates using activity data, for example, probabilistic models that fit probability distributions to historical activity data. This is because these probabilistic models can maintain the frequencies associated with actor activities in the historical activity data and efficiently update those frequencies using additional activity data. Block 414 and its in / out arrows are shown with dashed lines to indicate that these actions are optional and may vary depending on the implementation. For example, for actor-specific modules, the system can perform the actions in block 414, while for tenant-organization-wide submodules, the system can omit the actions in block 414.

[0044] In block 415, the system continues its iteration through submodules of the module for the perspective. If there are additional submodules, the operation flow returns to block 403. Otherwise, the operation flow proceeds to block 416.

[0045] In block 416, the system continues the iteration through the actor behavior perspective. If there is an additional perspective, the action flow returns to block 405. Otherwise, the action flow returns to block 417.

[0046] In block 417, the system takes corrective action based on the multi-perspective likelihood of abnormal behavior for an actor over a specified time period. The corrective action is determined based on the actor's anomaly score, which is generated from the likelihood of abnormal behavior. The operation in block 417 is described in more detail with reference to Figure 5.

[0047] Figure 5 is a flowchart illustrating exemplary actions for implementing corrective measures based on multi-perspective likelihoods of abnormal behavior for an actor. In block 501, the multi-perspective UEBA system ("the System") generates an anomaly score by decorrelating the likelihoods of an actor's abnormal behavior over a given time period. The actions in block 501 are described in more detail with reference to Figure 6.

[0048] In block 503, the system determines whether the anomaly score meets the risk criteria. For example, the risk criteria may be that the anomaly score is within a threshold and / or range that indicates the level of risk and / or the severity of the risk. If the anomaly score meets the risk criteria, the operation flow proceeds to block 505. Otherwise, the operation flow in Figure 5 is completed, and the actor is not flagged for potentially anomalous behavior during that time period.

[0049] In block 505, the system identifies high-risk behavioral perspectives based on the likelihood of abnormal behavior. For example, a high-risk behavioral perspective may be identified as corresponding to the top k likelihoods for some parameter k. Alternatively, each perspective may have a corresponding likelihood threshold, and if it exceeds this threshold, the perspective is identified as high-risk.

[0050] In block 507, the system initiates iteration through the identified high-risk behavioral perspectives. Actions for corrective actions are shown for each behavioral perspective, but corrective actions may be taken based on the risk assessed across all perspectives, for example, based on a set of high-risk behavioral perspectives or based solely on anomaly scores.

[0051] In block 509, the system assesses the risk severity of security exposure associated with an actor's activity over a period of time, based on the likelihood of abnormal behavior in high-risk perspectives and the actor's context. For example, certain high-risk perspectives known to have a more direct impact on the overall risk may trigger a higher risk severity. The actor context may include metadata such as job title and occupation, and certain metadata values ​​(e.g., the actor is a CEO or other high-ranking executive) may additionally trigger a higher risk severity.

[0052] In block 511, the system takes corrective actions based on risk severity. Corrective actions may include terminating sessions / flows associated with the actor's SaaS application activity, generating alerts to the actor and / or tenant organization's security administrators, and scanning endpoint devices, databases, etc., that are exposed by the actor's activity. Corrective actions can be sorted by hierarchy, and certain corrective actions can only be taken for higher severity tiers.

[0053] In block 513, the system continues the iteration through high-risk perspectives of actor behavior. If there are additional high-risk perspectives, the operation flow returns to block 507. Otherwise, the operation in Figure 5 is completed.

[0054] Figure 6 is a flowchart illustrating exemplary operation for decorrelating the likelihood of an actor's anomalous behavior over a given time period in order to generate an anomaly score. The likelihood of anomalous behavior is decorrelated to remove redundant and correlated models within each module and submodule of the multi-perspective UEBA system ("the System"). Without decorrelation, the likelihoods of strongly correlated models would be counted multiple times, and therefore, the predictions of these models would have an excessive impact on the anomaly score. As an exemplary example, one model for a submodule of the System's Activity Volume module might predict the likelihood of downloads for actor and application A within one hour per day, and another submodule might predict the number of page requests for actor and application A within the same one hour per day. The outputs of these models are expected to be strongly correlated and therefore, at least partially, redundant when generating an anomaly score.

[0055] In block 601, the system begins iterating through the actor behavior perspective, where the system maintains one or more probabilistic models as submodules of the module corresponding to each perspective. Each module corresponding to a perspective can contain one or more probabilistic models. For a module containing one probabilistic model (e.g., an activity-time modeling module), the system can skip the decorrelation operation in each iteration.

[0056] In block 602, the system normalizes the probability distributions for each sub-module of the perspective. For example, assume that the perspective is the amount of activity, and there are probability distributions X, Y, Z, V representing the download amount for app1, the preview amount for app1, the upload amount for app1, and the preview amount for app2, respectively. First, the system calculates the logarithms of each probability distribution as X' = log(X + 1), Y' = log(Y + 1), Z' = log(Z + 1), V' = log(V + 1). This processing step is because the probability distributions of most perspectives usually resemble log-normal distributions or power-law distributions, and by taking the logarithm, these distributions become more similar to Gaussian distributions. Then, the system calculates x = X' / σ X’ , y = Y' / σ Y’ , z = Z' / σ Z’ , v = V' / σ V’ to normalize each probability distribution by its standard deviation, where σ is the standard deviation of the distribution in the subscript. This normalizes the probability variables to resemble a Gaussian distribution with a standard deviation of 1, which helps in correlation analysis.

[0057] In block 603, the system calculates the correlation matrix between the probability distributions of each sub-module of the perspective. For example, the entry in the correlation matrix corresponding to the pair of distributions X, Y is calculated as E[(X - μ X )(Y - μ Y )] / (σ X σ Y ), where E is the expected value and μ is the mean of the distribution in the subscript. Each entry in the correlation matrix is within the interval [0, 1] and measures how the corresponding pair of probability variables are correlated, that is, how similar their probability density functions are, and a value closer to 1 indicates a stronger correlation.

[0058] In block 604, the system determines whether there are strongly correlated sets of probability distributions for a submodule of the perspective. For example, the system can identify a set of probability distributions such that all pairs of probability distributions in the set have a correlation above a threshold correlation (e.g., 0.85). Note that the set is thus selected so that the correlation of all pairs is above the threshold. For example, if x and y have a correlation of 0.91, and y and z have a correlation of 0.95, but y and z have a correlation of 0.3, the system generates two sets, {x,y} and {y,z}, rather than grouping all of x, y, and z into the same strongly correlated set (assuming v has a low correlation with all the other random variables, as it is in its own set).

[0059] In block 605, the system replaces each set of strongly correlated distributions with its mean. Replacing each set with its mean involves removing each random variable in each set and adding a new random variable for each set, which is the mean of the random variables. In the previous example, the set of random variables {x, y, z, v} was replaced with the set {x', y', v}, where x' = (x + y) / 2 and y' = (y + z) / 2.

[0060] In block 607, the system recalculates the correlation matrix using the updated probability distributions. The system calculates the correlations for the new set of random variables according to the formula described above. Although shown as a single instance in each iteration, averaging strongly correlated probability distributions and recalculating the correlation matrix, it should be noted that this process may occur multiple times until there are no more strongly correlated probability distributions.

[0061] In block 609, the system calculates a rareness score for each probability distribution and applies weights to each rareness score based on its correlation with other probability distributions for the perspective. The system constructs a probability density function for each of the resulting random variables, which in the previous example are denoted as p(x'), p(y'), and p(v). The system then generates a rareness score for each probability density function by taking the negative logarithm of each probability density function (so that a larger score corresponds to a higher rareness) and applying weights. The weights downscale the probability density function corresponding to a random variable that has a strong correlation with many other variables. For example, the weights could be the reciprocal of the sum of the correlations between the random variable and each other random variable. To illustrate, using the previous example, the system first generates the rareness scores as S(x')=-log(p(x')), S(y')=-log(p(y')), and S(v)=-log(p(v)). x’y’ =0.4, c x’v =0.1, and c y’v Assume that = 0.2. Then, each of the rarity scores is downweighted as w(x')=S(x') / (0.4+0.1), w(y')=S(y') / (0.4+0.2), and w(v)=S(v) / (0.1+0.2).

[0062] In block 611, the system calculates the rarity score for abnormal behavior for a perspective as the average of the rarity scores given by a weighted probability distribution. The overall rarity score is given as the average of each rarity score, i.e., S=(w(x')+w(y')+w(v)) / 3 in the previous example. The system extracts events corresponding to each distribution for an actor over a time period (e.g., the amount of actor activity for application A from 2pm to 3pm) and determines the likelihood of each event given by the probability distribution. For the random variables X, Y, Z, and V over that time period, event e X , e Y , e Z , e VAssume that the following has been observed. The system then determines p(x'), p(y'), and p(v) based on these observed events according to their probability density functions, and calculates a score for abnormal behavior based on the equations mentioned above. The rarity score S is higher for higher rarity (i.e., a higher probability of abnormal behavior) and lower for lower rarity (i.e., a higher probability of normal behavior).

[0063] In block 613, the system continues its iterations through the system's perspective. If there are additional modules corresponding to the perspective that include multiple probabilistic models, the operation flow returns to block 601. Otherwise, the operation flow proceeds to block 615.

[0064] In block 615, the system determines the correlations across perspectives and weights the rarity score for each perspective based on these correlations. The system then calculates the anomaly score as the average of the weighted scores for each perspective. For example, the system can determine the correlations according to the formula above using the probability density function corresponding to each module, and, as previously stated, can weight the rarity score using the reciprocal of the sum of the correlations with other modules.

[0065] Figure 7 is an exemplary flowchart of operation for training / updating a multi-perspective UEBA system to generate anomaly scores for actor behavior across a tenant organization. For simplicity of presentation, Figure 7 is illustrated with reference to a single actor within the tenant organization. Modules maintained by the multi-perspective UEBA system ("the System") can have varying scopes across multiple actors and can be trained / updated simultaneously for all actors within their scope. Training and updating of modules with varying scopes can be performed asynchronously according to different schedules and / or triggers, and when updating actor-specific modules, modules with scopes beyond a particular actor do not need to be trained / updated simultaneously.

[0066] In block 701, the UEBA module trainer ("Trainer") identifies actors for training / updating modules within the system. For example, the Trainer may identify actors according to a schedule for updating modules associated with the actor (e.g., monthly), or based on external triggers such as an administrator prompting module updates and / or training for an actor, or a firewall detecting previously unseen SaaS application activity of an actor against a tenant organization. Figure 7 illustrates how training / updates are triggered by actor identification, but alternatively, training may be triggered by the identification of modules for training / updating, and the action to iterate through the actor's perspective / scope may be omitted.

[0067] In block 705, the trainer initiates iterations through the perspectives of the multi-perspective UEBA system. In some embodiments, the trainer may omit perspectives corresponding to modules that have a range beyond a particular actor, and these modules can be trained / updated in a separate pipeline.

[0068] In block 709, the trainer determines whether the scope of the current perspective is actor-specific. The scope of the current perspective includes the scope of actors in the tenant organization from which training data is collected to train the module corresponding to the actor's current perspective. If the scope is actor-specific, the operation flow skips to block 713. Otherwise, the operation flow proceeds to block 711.

[0069] In block 711, the trainer determines whether the corresponding module meets the training criteria. For modules with a range beyond a specific actor, training / updating of these modules may be postponed for the operation shown in Figure 7, as these modules may be trained / updated according to a different schedule than the individual actors within their range. The training criteria may include determining whether the corresponding module has a sufficient amount of additional historical activity data for the actors across its range, the time elapsed since the previous training / update, and whether the module is flagged for training / updating in parallel with the module's training / update for each of the actors within its range. If the training criteria are met, the operation flow proceeds to block 713. Otherwise, the operation flow skips to block 719.

[0070] In block 713, the trainer trains and / or updates the corresponding module using collected activity data corresponding to the range of the current perspective across N past time windows. Training and / or updating is performed according to the corresponding model, and the collected activity data is preprocessed accordingly. For probabilistic models, training / updating is performed in a single pass by updating the parameters of the fitted probability distribution. For neural networks, updates are performed in batches and epochs of training data until training criteria such as convergence of internal parameters and sufficiently low training / test / validation errors are met.

[0071] In block 719, the trainer continues the iteration through the perspectives of the multi-perspective UEBA system. If there are additional perspectives, the operation flow returns to block 705. Otherwise, the operation flow in Figure 7 is completed.

[0072] Figure 8 is a flowchart illustrating exemplary operation for maintaining a multi-perspective UEBA system over multiple time periods. In block 801, the multi-perspective UEBA system ("the System") collects actor SaaS application activity data across the tenant organization over a time period. For example, the System may receive activity data from a firewall when the firewall detects requests or communications to a SaaS application in the internal and external network traffic of an endpoint in the tenant organization. Block 801 is shown with dashed lines to indicate that the collection of SaaS application activity data is continuous, while the remaining operations are asynchronous according to various triggers and criteria.

[0073] In block 803, the system determines whether a first trigger for training / updating has been met. The first trigger may be per actor, per user behavior perspective, per module maintained for a perspective and one or more actors, or any combination of the above. The first trigger may follow a corresponding schedule or be based on an external intervention, such as the detection of new actors in a tenant organization. If the first trigger has been met, the operation flow proceeds to block 805. Otherwise, the operation flow skips to block 807.

[0074] In block 805, the UEBA model trainer ("Trainer") trains / updates the system to generate anomaly scores for actor behavior across the entire tenant organization, based on the actor's historical activity data from the previous N time periods T(1) to T(N). The operation in block 805 is described in more detail above with reference to Figure 7.

[0075] In block 807, the system determines whether a second trigger for anomaly detection has been met. The second trigger may be per actor, per sub-unit of the tenant organization, and / or across the entire tenant organization. For example, each actor may have a schedule (e.g., weekly) for anomaly detection of actor behavior. If the second trigger is met, the operation flow proceeds to block 809. Otherwise, the operation flow skips to block 811.

[0076] In block 809, the system performs UEBA anomaly detection for actors(s) over time periods T(N+1), T(N+2), ... via multiple behavioral perspectives. The behavior of each actor during each specified time period is described above with reference to Figure 4.

[0077] In block 811, the system determines whether the data decay criterion is met. For example, the data decay criterion may include the data stored in the repository for the actor's historical activity being older than a threshold amount (e.g., 6 months). If the data decay criterion is met, the operation flow proceeds to block 813. Otherwise, the operation flow returns to block 801.

[0078] In block 813, the system dumps outdated actor activity data from time periods T(-1), T(-2), etc. The operation flow returns to block 801.

[0079] Variation

[0080] This disclosure refers to various methods for analyzing activity data about actors to determine abnormal behavior while using a SaaS application. Other types of activity data, such as background process activity data and process activity data initiated by the SaaS application itself, can also be used to analyze abnormal behavior.

[0081] The flowchart is provided to aid in illustrative understanding and should not be used to limit the scope of the claims. The flowchart illustrates exemplary behavior that may vary within the scope of the claims. Additional actions may be performed, fewer actions may be performed, actions may be performed in parallel, and actions may be performed in different orders. For example, the actions shown in blocks 805 and 809 may be performed in parallel or simultaneously. With respect to Figure 4, it is not necessary to update the submodule using activity data in block 414. It will be understood that each block in the flowchart and / or block diagram, as well as combinations of blocks in the flowchart and / or block diagram, may be implemented by program code. The program code may be provided to a processor of a general-purpose computer, a dedicated computer, or other programmable machine or device.

[0082] To be understood, aspects of this disclosure may be embodied as systems, methods, or program code / instructions stored in one or more machine-readable media. Thus, aspects may take the form of hardware, software (including firmware, resident software, microcode, etc.), or combinations of software and hardware aspects, all of which may be commonly referred to herein as “circuits,” “modules,” or “systems.” The functions presented as individual modules / units in the illustrative figures may be organized differently according to any one of the following: platform (operating system and / or hardware), application ecosystem, interface, programmer’s preference, programming language, administrator’s preference, etc.

[0083] Any combination of one or more machine-readable media may be used. A machine-readable media may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium may be, but not limited to, a system, apparatus, or device employing one or a combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies to store program code. More specific examples (a non-exhaustive list) of machine-readable storage media include portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the context of this specification, a machine-readable storage medium may be any tangible medium that contains or can store programs for use by, or in connection with, an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0084] A machine-readable signaling medium may include, for example, a propagating data signal in which machine-readable program code is embodied, either within the baseband or as part of a carrier wave. Such a propagating signal may take any of various forms, but is not limited to electromagnetic, optical, or any suitable combination thereof. A machine-readable signaling medium may be any machine-readable medium, rather than a machine-readable storage medium, that can communicate, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device.

[0085] Program code embodied on a machine-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wireline, fiber optic cable, RF, or any preferred combination thereof.

[0086] Program code / instructions may be stored on a machine-readable medium that can instruct a machine to function in a particular way, such that the instructions stored on the machine-readable medium produce a product containing instructions that perform functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0087] Figure 9 shows an exemplary computer system having a multi-perspective UEBA system. The computer system includes a processor 901 (which may include multiple processors, multiple cores, multiple nodes, and / or implement multithreading). The computer system includes memory 907. Memory 907 may be system memory or one or more of the possible implementations of machine-readable media already described above. The computer system also includes a bus 903 and a network interface 905. The system also includes a multi-perspective UEBA system ("System") 911. System 911 detects anomalous behavior of actors within an organization using modules that model perspectives of actor behavior. Each module includes one or more probabilistic models and / or machine learning models as submodules at further granularity, such as within a bucketed time window of a time period, per SaaS application, and per aspect of actor activity. System 911 generates an anomaly score by decorrelating and averaging the likelihoods output by the submodules within each module and the likelihoods output across modules. System 911 can continuously train, update, redeploy, add, and remove modules to maintain the security posture of each actor throughout the organization. Any one of the aforementioned functions may be partially (or completely) implemented in hardware and / or on processor 901. For example, the function may be implemented using application-specific integrated circuits, within logic implemented within processor 901, within a coprocessor on a peripheral device or card, etc. Furthermore, the implementation may include fewer or additional components not shown in Figure 9 (e.g., video card, audio card, additional network interface, peripheral device, etc.). Processor 901 and network interface 905 are coupled to bus 903. Although shown as coupled to bus 903, memory 907 may be coupled to processor 901.

Claims

1. A step of collecting, according to a directory service, first data about the cloud-based activities of a first actor and second data about the cloud-based activities of one or more actors adjacent to the first actor, wherein the first data and the second data correspond to a first time window. A step of training multiple machine learning models to detect abnormal behavior of the first actor using at least the first data, wherein at least a subset of the multiple machine learning models are trained using the first data and the second data, A step of generating a plurality of likelihood values ​​for the normal behavior of the first actor in a second time window following the first time window, wherein the step of generating the plurality of likelihood values ​​includes obtaining the plurality of likelihood values ​​as output from inputting third data relating to the first actor from the second time window into the plurality of machine learning models, The steps include: aggregating the plurality of likelihood values ​​to generate a score indicating the likelihood of anomaly in the first actor's behavior in the second time window; A method that includes this.

2. The method according to claim 1, wherein the plurality of machine learning models include at least one of a probabilistic model of the amount of activity in the actor activity of the first actor, a probabilistic model of the type of activity in the actor activity of the first actor, a probabilistic model of the duration of activity in the actor activity of the first actor, and a neural network model of locations visited by the first actor.

3. The step of training the aforementioned multiple machine learning models is performed for each machine learning model of at least a subset of the aforementioned multiple machine learning models, Based on the determination that the first subset of data representing aspects of actor activity corresponding to the machine learning model is sufficient for training, the steps include fitting a probability distribution to the subset of data, Based on the determination that the subset of the first data is insufficient for training, the step of fitting the probability distribution to the subset of the first data and the subset of the second data representing the aspects of the actor activity corresponding to the machine learning model. Includes, In particular, the probability distribution includes at least one of a power law distribution, a log-normal distribution, and a Gaussian distribution. The method according to claim 1.

4. In particular, the plurality of machine learning models include a neural network for predicting likelihood values ​​for which locations shown in actor activity for at least the first actor correspond to normal behavior, the neural network includes an input layer for locations visited by the first actor, an input layer for the characteristics of the first actor, an input layer for the characteristics of one or more actors, and a concatenation layer that combines the outputs of blocks of the neural network including each of the input layers, and further, the step of training the neural network includes training the neural network on third data collected for cloud-based activity of actors including the first actor across the entire tenant organization of the first actor, In particular, the one or more actors adjacent to the first actor according to the directory service include actors adjacent to the first actor in a graph data structure that models the hierarchical roles of actors maintained by the directory service, and the hierarchical roles of the actors include the hierarchical roles of actors within the same tenant organization that are monitored by the directory service. In particular, the plurality of machine learning models include one or more models for detecting anomalous access to confidential documents by the first actor in order to prevent data loss. The method according to claim 1.

5. The step of aggregating the multiple likelihood values ​​to generate the score is: The steps include: decorrelating the aforementioned multiple likelihood values ​​to obtain multiple decorrelated likelihood values; The steps include generating the score as the sum of the plurality of decorrelated likelihood values, The steps include generating a determination that the behavior of the first actor in the second time window is abnormal, based on the score exceeding the threshold likelihood value, A step of generating a determination that the behavior of the first actor in the second time window is normal, based on the score not exceeding the threshold likelihood value. The method according to claim 1, including the method described in claim 1.

6. A non-temporary machine-readable medium storing program code, wherein the program code is An instruction for maintaining multiple profiles of normal actor behavior for each actor's cloud-based activity of a plurality of actors in order to monitor actor entity and behavioral analytics, wherein the instruction for maintaining the plurality of profiles includes each actor of the plurality of actors and the corresponding profile within the plurality of profiles, An instruction for collecting first data about the cloud-based activity of the actor and second data about the cloud-based activity of one or more actors adjacent to the actor in a data structure maintained by a directory service, wherein the first data and the second data occur within a first time window. Instructions for training multiple machine learning models to predict scores of abnormal actor behavior of the actor using the first data, wherein the training data of at least a subset of the multiple machine learning models is supplemented with the second data, and the profiles include the multiple trained machine learning models, Based on third data about at least the actor's cloud-based activity collected in one or more time windows following the first time window, an instruction to update the profile and Non-temporary machine-readable media, including [specific examples of such media].

7. The instructions further include a command for deploying the profile to generate a score indicating the likelihood of anomaly in the actor's behavior in one or more time windows following the first time window, wherein the command for deploying the profile includes, for a second time window among the one or more time windows: An instruction for collecting fourth data about the actor's cloud-based activity in the second time window, wherein the third data includes the fourth data, and the instruction The output from inputting the fourth data into the multiple trained machine learning models in the profile is an instruction to obtain multiple likelihood values ​​for whether the actor's behavior in the second time window is normal, Instructions for generating a score based on the aforementioned multiple likelihood values, Includes, In particular, the instruction for generating the score based on the plurality of likelihood values ​​is, Instructions for decorrelating the aforementioned multiple likelihood values ​​to generate multiple decorrelated likelihood values, Instructions for generating the score as the sum of the plurality of decorrelated likelihood values, A non-temporary machine-readable medium according to claim 6, including the following:

8. The plurality of machine learning models include at least one of the following: a probabilistic model of the amount of activity in the actor's actor activity, a probabilistic model of the type of activity in the actor's actor activity, and a probabilistic model of the duration of activity in the actor's actor activity. In particular, the plurality of machine learning models include at least one of the following: a probabilistic model of the amount of activity in the actor's actor activity, a probabilistic model of the type of activity in the actor's actor activity, and a probabilistic model of the duration of activity in the actor's actor activity. In particular, the plurality of profiles include a neural network model for predicting the likelihood of abnormal behavior at locations visited by the plurality of actors across the entire tenant organization of the plurality of actors, the neural network model including an input layer for the locations visited by the actors, an input layer for the characteristics of the actors, an input layer for the characteristics of one or more actors, and a concatenation layer that combines the outputs of blocks of the neural network model, each of the input layers. The non-temporary machine-readable medium according to claim 6.

9. The instructions for training the plurality of machine learning models include, for each machine learning model of at least a subset of the plurality of machine learning models, Based on the determination that the first subset of data representing aspects of actor activity corresponding to the machine learning model is sufficient for training, instructions are given to fit a probability distribution to the subset of data, Based on the determination that the subset of the first data is insufficient for training, instructions are given to fit the probability distribution to the subset of the first data and the subset of the second data representing the aspects of the actor activity corresponding to the machine learning model. Includes, In particular, the probability distribution includes at least one of a power law distribution, a log-normal distribution, and a Gaussian distribution. The non-temporary machine-readable medium according to claim 6.

10. In particular, the non-temporary machine-readable medium according to claim 6, wherein the one or more actors adjacent to the actor in accordance with the directory service include actors adjacent to the actor in a graph data structure that models the hierarchical roles of actors maintained by the directory service, and the hierarchical roles of the actors include the hierarchical roles of actors within the same tenant organization monitored by the directory service.

11. It is a device, Processor and A machine-readable medium that stores the instructions and Equipped with The aforementioned instruction is, Training multiple machine learning models to detect abnormal behavior of a first actor using first data of the first actor's cloud-based activity collected in a first time window, wherein each of the multiple machine learning models is trained to detect abnormal behavior in one distinct of a plurality of aspects of the first actor's actor activity. In order to detect abnormal behavior of the first actor in the first time window and in subsequent time windows, the multiple trained machine learning models are deployed. The processor is capable of causing the device to perform the following actions: The instructions executable by the processor to cause the device to deploy the plurality of trained machine learning models include instructions for aggregating the likelihood values ​​obtained as outputs of the plurality of trained machine learning models based on inputs collected from data of the first actor's cloud-based activity in the subsequent time window, in order to generate a score for the first actor's abnormal behavior in the subsequent time window. Device.

12. The machine-readable medium further stores instructions, which are based on the determination that each of the at least first subset of the plurality of machine learning models has insufficient data for training in the first data. Identifying one or more actors adjacent to the first actor according to the directory service, The training of the first subset of the multiple machine learning models is supplemented with second data collected for the cloud-based activities of one or more actors in the first time window. The apparatus according to claim 11, wherein the processor is capable of causing the apparatus to perform the above.

13. The apparatus according to claim 12, wherein one or more actors adjacent to the first actor according to a directory service include actors adjacent to the first actor in a graph data structure that models the hierarchical roles of actors maintained by the directory service, and the hierarchical roles of the actors include the hierarchical roles of actors within the same tenant organization that are monitored by the directory service.

14. The instructions for training the plurality of machine learning models include, for each machine learning model of at least a second subset of the plurality of machine learning models, Based on the determination that the first subset of data representing one of the multiple aspects of actor activity corresponding to the machine learning model is sufficient for training, the probability distribution is fitted to the subset of data, Based on the determination that the subset of the first data is insufficient for training, the probability distribution is fitted to the subset of the first data and the subset of the second data representing the aspects of the actor activity corresponding to the machine learning model. The instructions include instructions that can be executed by the processor in order to cause the device to perform the following: In particular, the probability distribution includes at least one of a power law distribution, a log-normal distribution, and a Gaussian distribution. The apparatus according to claim 12.

15. In particular, the plurality of machine learning models include at least one of the following: a probabilistic model of the amount of activity in the actor activity of the first actor; a probabilistic model of the type of activity in the actor activity of the first actor; a probabilistic model of the duration of activity in the actor activity of the first actor; and a neural network model of the locations visited by the first actor. In particular, the plurality of machine learning models include a neural network for predicting likelihood values ​​for which locations shown in actor activity for at least the first actor correspond to normal behavior, the neural network including an input layer for locations visited by the first actor, an input layer for characteristics of the first actor, an input layer for characteristics of one or more actors adjacent to the first actor according to a directory service, and a concatenation layer that combines the outputs of blocks of the neural network including each of the input layers, and further, the instructions for training the neural network include instructions executable by the processor to cause the device to train the neural network on third data collected for cloud-based activity of actors, including the first actor, across the entire tenant organization of the first actor. The apparatus according to claim 11.

Images