Multi-view user and entity behavior analysis for software as service applications

Abstract

A multi-view user and entity behavior analysis (UEBA) system ("system") constructs and maintains interchangeable modules for predicting the likelihood of anomalous user behavior at the range of organized participants (i.e., users or entities) over a time period. Each module includes a probabilistic model and / or a machine learning model as a sub-module that models participant behavior at various granularity levels with respect to the use of a software as a service application. The system generates anomaly scores by decorrelating the likelihoods output by each sub-module, and uses the anomaly scores to monitor and perform corrective actions based on anomalous participant behavior to maintain a security situation across organizations.

Description

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

[0002] User Behavior Analytics (UBA), or User and Entity Behavior Analytics (UEBA), is a cybersecurity technique used to track user / entity activity on a network (e.g., at servers, network devices, endpoint devices, etc.) to detect anomalies potentially associated with threats or exposures to a network security system. Data reflecting user / entity activity within the network is collected periodically, for example from a variety of log data sources. Statistical analysis, machine learning, or other analytical techniques are applied to the collected data to determine normal behavioral patterns among users and entities (e.g., in terms of user activity and device usage reflected in the data). This data collection is ongoing for periodic analysis based on the established normal behavioral patterns to determine whether the behavior of any user / entity reflected in the collected data is anomalous or abnormal. Users and / or entities identified as corresponding to data indicating deviations from normal behavioral patterns can be detected as potentially threat-related or otherwise risky to the network. Attached Figure Description

[0003] Embodiments of this disclosure can be better understood by referring to the accompanying drawings.

[0004] Figure 1 This is a conceptual diagram of an example multi-view UEBA system used to generate anomaly scores for participant behavior in a tenant organization with multiple modules.

[0005] Figure 2 This is a schematic diagram of an example multi-view UEBA system used for training / updating and deploying multiple modules to identify anomalous behavior of participants in a tenant organization.

[0006] Figure 3 This is a schematic diagram of an example architecture of a neural network that includes the active position modeling module of a multi-view UEBA system.

[0007] Figure 4 This is a flowchart of an example operation for detecting UEBA anomalies in participants over a specified time period through multiple behavioral perspectives.

[0008] Figure 5 This is a flowchart of an example operation for performing corrective actions based on the likelihood of abnormal behavior from multiple perspectives of a participant.

[0009] Figure 6 This is a flowchart of an example operation used to decorrelate the likelihood of a participant’s anomalous behavior over a time period to generate an anomalousness score.

[0010] Figure 7 This is a flowchart of an example operation for training / updating a multi-view UEBA system to generate anomaly scores for participant behavior across tenant organizations.

[0011] Figure 8 This is a flowchart of an example operation for maintaining a multi-view UEBA system across time periods.

[0012] Figure 9 An example computer system with a multi-view UEBA system is described. Detailed Implementation

[0013] The following description includes example systems, methods, techniques, and process flows to aid in understanding this disclosure and does not limit the scope of the claims. For the sake of brevity, well-known examples of instructions, protocols, structures, and techniques are not shown in detail.

[0014] the term Unless otherwise specifically stated, the use of the phrase "at least one of..." before a list containing the conjunction "and" should not be considered an exclusive list and should not be interpreted as a list of categories having one item from each category. A clause stating "at least one of A, B, and C" may be violated by only one of the listed items, multiple of the listed items, one or more of the listed items, and other unlisted items.

[0015] As used in this article, "participant" refers to a user or entity under an organization that subscribes to one or more Software-as-a-Service (SaaS) applications as a tenant. The participant has historical activity data associated with one or more SaaS applications.

[0016] Overview Implementing UEBA (especially for applications delivered based on SaaS models) presents several challenges due to the inherent variability of participant behavior both within and across tenant organizations. Additionally, data across individual participants within a tenant organization is typically sparse, making it difficult to train effective models that capture participant-specific behaviors. Modeling different aspects of participant behavior to improve the quality of UEBA implementations while taking into account the variability of participant behavior is particularly challenging when the model-wide data is sparse.

[0017] This paper discloses a multi-perspective UEBA system that effectively models participant behavior by leveraging SaaS activity data from both the participant and nearby participants, based on a directory service of a tenant organization using SaaS applications utilized by the participants. Each perspective from which data is analyzed corresponds to a different aspect of behavior, where an "aspect" of participant behavior refers to a behavioral descriptor that can be identified from data indicating the activity of participants within the tenant organization's SaaS applications. Exemplary aspects of behavior include the amount of activity associated with the participant's activity (e.g., the amount of data uploaded / downloaded), the activity time, the activity type, and the location. Each aspect of behavior is modeled by a different module that implements machine learning and / or statistical techniques not only for the participant but also for multiple participants across the tenant organization when sufficient data is unavailable. The modules are continuously trained on previous time periods of participant behavior and are simultaneously used to predict anomalous behavior in the participant at the current time period. Based on the behavioral data collected at the current time period, the multi-perspective UEBA system decorrelates and combines the likelihoods obtained from the outputs of each module, which are inputs of a subset of the behavioral data, to generate an anomalousness score for the participant, where each likelihood indicates the probability that the participant's behavior is anomalous at the current time period.

[0018] Each module implemented by the multi-view UEBA system potentially uses additional participant data from the tenant organization for training. For example, for a module capturing the amount, timing, and type of participant activity, the multi-view UEBA system can determine that data on participants in previous time periods is insufficient (i.e., too sparse) and can retrieve data on nearby participants from a hierarchical structure defined by the tenant organization's directory service as additional data for training each module. For a module capturing the location associated with participant activity, the multi-view UEBA system can collect location-based data on participants across the entire tenant organization as training data. Scores are generated as a simple weighted mean of the likelihoods derived from the outputs of each module. As a result, the framework is flexible due to the ability to dynamically add and remove modules with minimal impact on the scoring, and the ability to dynamically add training data for modules with sparse participant activity in previous time periods.

[0019] Example illustration Figure 1This is a conceptual diagram of an example multi-view UEBA system for generating anomaly scores for participant behavior in a tenant organization with multiple modules. The multi-view UEBA system (“System”) 101 manages UEBA for a tenant organization 106 that has subscribed to at least SaaS applications 102A-102C. System 101 includes modules 103A-103D, which accordingly generate likelihoods 112A-112D of the participant behavior of a target participant 130 among participants 104 of the tenant organization 106 being anomalous over a time period. Likelihoods 112A-112D are then aggregated by anomaly likelihood aggregator 109 to generate an anomaly score 120 of the target participant 130’s behavior being anomalous over that time period. As one aspect of implementing UEBA, the tenant organization 106 continuously feeds participant activity data 108 and directory service data 110 to System 101 for online anomaly detection over shifted time periods of data collection and updates to modules 103A-103D. Although depicted as modules 103A-103D representing various aspects of participant behavior, system 101 is flexible and modules can be dynamically added or removed by reconfiguring the anomaly likelihood aggregator 109 to accept different inputs. For example, the data loss prevention (DLP) module 103E is depicted using a dashed outline to indicate that this module can be dynamically added or removed by system 101. Each module models different perspectives of the activities performed by participant 130 within segmented time windows of a time period, where each time period includes a segment for analyzing anomalous behavior performed by participant 130. Although the time periods and the segmented time windows within each time period can vary in granularity, for simplicity, each time period and segmented time window is correspondingly described as a day and each hour of a day.

[0020] Tenant organization 106 includes organizations with subscriptions to multiple SaaS applications 102A-102C. Tenant organization 106 can be distributed across multiple locations and numerous data stores or networks, and can be an on-premises or cloud-based private network. Therefore, firewall 121 collects participant data from various communication channels and databases (e.g., a data lake in the cloud) across tenant organization 106 and periodically transmits participant activity data 108 and directory service data 110 in batches to system 101. Firewall 121 can classify the transmitted data 108, 110 by application identifiers, such as process identifiers indicated from business logs. Communication between participant activity data 108 and directory service data 110 occurs asynchronously. For example, firewall 121 may transmit participant activity data 108 for each time period it monitors participant activity, while firewall 121 may transmit directory service data 110 upon update or according to an extended schedule over multiple time periods. Although firewall 121 and system 101... Figure 1 While they are described as different software components, system 101 can be a subcomponent of firewall 121 and can share memory with various other components that collect data for UEBA purposes, thereby avoiding the step of transmitting data 108, 110 to system 101.

[0021] Activity modeling module 103A models participant activity of participant 130 within segmented time windows (e.g., hourly) over a period of time (e.g., a day). Participant activity includes events of participant 130 in relation to SaaS applications 102A-102C. An “event” refers to an action taken by participant 130 interacting with one of the SaaS applications 102A-102C, such as: by initializing or changing a process, by prompting for data communication across a public or private network, by clicking an element in the user interface, by downloading or uploading via application initialization, etc. Activity modeling module 103A includes a submodule as a probability distribution (e.g., example probability distribution 105) that models the frequency of events of participant 130 within each segmented time window based on participant 130’s historical activity data. Each probability distribution models a specific action of participant 130 when using one of the SaaS applications 102A-102C during the segmented time window. For example, the probability distribution can be modeled for participant 103 downloading application 102A between 9:00 AM and 10:00 AM, and participant 130 uploading application 102B between 1:00 PM and 2:00 PM.

[0022] Each probability distribution is chosen from a family of probability distributions such as the power-law distribution, and the parameters from the family of probability distributions are chosen to minimize the difference between the probability distribution and the historical data, for example, using maximum likelihood estimation (i.e., the probability distribution is “fitted” to historical activity data). Other families of probability distributions, such as the Gaussian and log-normal distributions, can be fitted to the historical data. The family of probability distributions is chosen based on the expected shape of historical participant activity data. For example, in the case of the power-law distribution family, the activity modeling module 103A models the event frequency distribution of participant 130 within a segmented time window. In this case, the classification frequencies within the segmented time window are expected to have a power-law distribution shape. Other families of probability distributions can be used for other aspects of participant behavior with different expected shapes.

[0023] The activity modeling module 103A then calculates the likelihood 112A for analysis by determining the feature values ​​corresponding to each probability distribution of participant activity data 108 from the current time period (e.g., the number of times participant 130 downloaded application 112A between 9:00 AM and 10:00 AM), and retrieves the anomalous likelihood values ​​given by the probability distributions for that feature value (e.g., a likelihood of 0.5 between 1 and 2 downloads of application 112A by participant 130 between 9:00 AM and 10:00 AM corresponds to anomalous behavior).

[0024] Activity type modeling module 103B and activity time modeling module 103C also use probability distributions to model participant behavior based on participant activity data 108. Activity type modeling module 103B includes probability distributions for each application / activity type pair corresponding to applications 102A-102C and for each segmented time window (e.g., each hour of the day) as well as the activity types performed by participant 130. Activity time modeling module 103C includes probability distributions for each segmented time window that model how frequently participant 130 performs activities within each segmented time window based on participant activity data 108.

[0025] The activity location modeling module 103D models the historical locations of participants across tenant organization 106 within each segmented time window. For example, the activity location modeling module 103D may include a neural network, such as example neural network 107. The activity location modeling module 103D takes as input both the location identified during participant activities performed by participant 130 within that time period and metadata and neighborhood data of nearby participants according to the hierarchical structure defined in directory service data 110. Likelihood 112D comprises the final layer output of the activity location modeling module 103D. Although modules 103A-103C are trained per participant, the activity location modeling module 103D is trained on participant data across tenant organization 106. Further details of the architecture of the activity location modeling module 103D are provided in [the relevant section]. Figure 3 As described in the text.

[0026] DLP module 103E models the frequency with which participant 130 accesses potentially sensitive documents, such as those classified as potentially sensitive according to a DLP system (not depicted) managed by firewall 121. DLP module 103E includes a probability distribution for each segmented time window, which models the number of potentially sensitive documents accessed by participant 130 from participant activity data 108.

[0027] Any of modules 103A-103C may suffer from data sparsity within the time window used to predict the likelihood of anomalous behavior performed by participant 130. To account for this sparsity, system 101 may determine whether there is insufficient data in participant activity data 108 for each of modules 103A-103C, and based on the determination that one or more of modules 103A-103C do not have sufficient data, it may determine the N participants closest to participant 130 according to the hierarchical structure of tenant organization 106 defined in directory service data 110. N is a parameter that can be fixed, or it may depend on the hierarchical structure (i.e., all participants whose distance to the node corresponding to participant 130 is 3) and the type of module that does not have sufficient data. Example hierarchical structure 114 includes user 1 as the CEO of tenant organization 106, and users 2 and 3 as the CFO and HR leaders of tenant organization 106, respectively, and connected to user 1 in the hierarchical structure. In this case, the two users closest to user 1 are user 2 and user 3. Example hierarchical structure 114 can further enable the embedding of user data, such as user nationality, job title, associated team, etc., at each node. Although described as users, nodes in the hierarchical structure defined in directory service data 110 can correspond to entities, and more generally, to participants in tenant organization 106 that includes users. Furthermore, although described as a hierarchical structure, the directory service that generates directory service data 110 can maintain any graphical data structure representing the proximity of participants within tenant organization 106 based on some concepts of organizational structure.

[0028] Once system 101 identifies the N participants closest to participant 130, system 101 retrieves data from participant activity data 108 for that time period to feed into modules 103A-103C where data is insufficient. For example, system 101 can use activity data from the participant activity data 108 of the N closest participants to update the frequency of activity volume, the frequency of specific types of events, and the frequency of activity time within the segmented time window. In some embodiments, system 101 is configured to collect data from the N closest participants in one or more of modules 103A-103C, regardless of whether there is sufficient or insufficient data within the time window.

[0029] Modules 103A-103D are described as one or more probabilistic models and neural networks. More generally, the modules implemented by system 101 can include any machine learning or statistical model, depending on available computational resources, the expected accuracy of the anomaly score, etc. Modules are interchangeable, and the anomaly likelihood aggregator 109 can be configured to accept inputs of a dynamic size indicating the type of module and the generated likelihood, in order to appropriately generate anomaly scores 120. Based on desired or pre-configured preferences, the implementation of modules can vary by participant and by tenant organization.

[0030] An anomaly likelihood aggregator (“aggregator”) 109 receives likelihoods 112A-112D output from modules 103A-103D respectively, and decorrelates / averages the logarithms of likelihoods 112A-112D to generate an anomaly score. The decorrelation step attempts to make the likelihood values ​​output by each module independent, such that the joint probability of each likelihood occurring is their product, i.e., their log sum. When a module has multiple likelihoods as outputs (i.e., modules 103A-103C), the decorrelation of log-likelihoods occurs first within each module, and then across modules 103A-103D. Decorrelation within each module occurs in three phases. First, aggregator 109 determines the correlation matrix of probability distribution pairs modeled by the module (hereinafter referred to as a “submodule”). Then, aggregator 109 identifies highly correlated sets of probability distributions based on the correlation matrix and replaces each set with its average probability distribution. Finally, aggregator 109 then recalculates the correlation matrix of the potential average probability distributions and weights each probability distribution according to the recalculated correlation matrix to determine the updated likelihood of the modules. Aggregator 109 then averages the likelihoods across modules to determine the individual likelihood of each of modules 103A-103D. Finally, aggregator 109 determines the correlation matrix among modules 103A-103D and generates an anomaly score 120 as a weighted mean of the individual likelihoods weighted according to the correlation matrix. (Reference) Figure 6 The process of decorrelation of likelihood is described in more detail and with illustrative examples.

[0031] Figure 2 This is a schematic diagram of an example multi-view UEBA system used for training / updating and deploying multiple modules to identify anomalous behavior of participants in a tenant organization. Figure 2 System 101 continuously collects new activity data from participants across a cross-tenant organization (not depicted) and asynchronously dumps old activity data to train, update, and deploy modules for anomaly detection based on multiple behavioral perspectives. New activity data is added to a repository, analyzed along various vectors of potential risks, and discarded once data is no longer closely relevant to UEBA (e.g., after 3 months or a year). Figure 2 The diagram uses the letter series AF to depict various modules for training and updating UEBA for identified participants in a tenant organization. Each phase represents one or more operations. While these phases are ordered for this example, the phases are illustrated to aid understanding of this disclosure and should not be used to limit the claims. Subject matter falling within the scope of the claims may vary from what is illustrated.

[0032] In Phase A, System 101 identifies Participant 202 for UEBA training / update of the corresponding module deployed to detect anomalous behavior by the participant. Training and / or updates can occur per participant based on a fixed schedule (e.g., monthly), or can occur based on external triggers, such as System 101's administrator identifying one or more participants, Participant 202's tenant organization's firewall identifying Participant 202 associated with SaaS application activity, etc. While for simplicity... Figure 2 The operations are depicted as a single participant, but can be executed simultaneously / in parallel by multiple participants from a tenant organization, where each participant has at least one participant-specific subset of modules in addition to different subsets trained across all participants. System 101 is further identified as maintaining two sets of modules for participant 202—a set of participant-specific modules 205 and a set of tenant organization modules 207. Participant-specific modules 205 are trained in the context of participant 202's historical data, while tenant organization modules 207 are trained across the tenant organization's historical data across participants. Each module is trained to predict the likelihood of behavioral anomalies for participant 202 (and / or other participants in the tenant organization). Note that both participant-specific modules 205 and tenant organization modules 207 can be submodules of modules maintained by System 101 that model participant behavior from a specific perspective.

[0033] In phase B, the UEBA model trainer (“trainer”) 203 retrieves activity data 210 of participant 202 over the past N time periods. Trainer 203 sends a query 208 to participant activity data repository 204, indicating the identifier of participant 202 and parameters for the past N time periods, and repository 204 returns the activity data 210. Activity data 210 includes event data related to the activities of participant 202 associated with one or more SaaS applications used by a tenant organization over the past N time periods T(1)-T(N). N is an adjustable parameter chosen to minimize variability due to external factors such as participant 202’s change of residence, sleep schedule, location at the tenant organization, work productivity, etc. Repository 204 may receive and store participant activity data when it is detected by a firewall in association with participant 202 and one or more SaaS applications and forwarded to system 101. For storage efficiency, repository 204 may dump data prior to the past N time periods when the data is no longer expected for additional training / updates.

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

[0035] In phase D, trainer 203 identifies nearby participants to participants 202 within the same tenant organization. Trainer 203 identifies nearby participants based on a hierarchical structure defined by the tenant organization's directory service, such as example graph data structure 216. Nearby participants can be identified based on a threshold number of nearby participants (e.g., through breadth-first search of the hierarchical structure), a threshold distance from participant 202, etc. Different sets of nearby participants can be identified for different perspectives of participant behavior for which the corresponding module has insufficient training data. For example, trainer 203 can identify more distant participants for modules with more training data. For each nearby participant in a behavior perspective / module, trainer 203 retrieves activity data of those participants over the past N time periods to add to the training data.

[0036] In phase E, trainer 203 trains at least participant-specific modules 205 and, in some embodiments, tenant organization modules 207 on the retrieved data and additional data from nearby participants. Because tenant organization modules 207 are trained on data from across tenant organizations, model training for these modules can occur asynchronously and based on separate triggers with the training of participant-specific modules 205. Each module is trained according to its corresponding architecture and / or training criteria. In some cases, trainer 203 can alternatively update modules when modules 205 and 207 have been previously trained. Some model architectures of the models implemented by the modules (such as the fitted probability distribution) allow for efficient updates due to the calculation of the loss cost of the best-fit parameters using the updated training data.

[0037] In phase F, trainer 203 will deploy those modules 205, 207 trained in phase E as trained UEBA modules 201 to detect anomalous behavior of participant 202 in future time periods T(N+1), T(N+2), ... . Training / updating of modules for participant 202 and other participants in the tenant organization can occur simultaneously and in parallel. For example, trainer 203 can collect / retrieve historical activity data of participants across the tenant organization over the past N time windows and can classify the data from each behavioral perspective into the appropriate module for each participant for training based on sparsity and module / submodule scope constraints (e.g., participant-specific or tenant organization-wide).

[0038] Figure 3 This is a schematic diagram of an example neural network architecture including an activity location modeling module of a multi-view UEBA system. The activity location modeling module 103D includes three input layers—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, participant metadata 300, and participant location data 302 as inputs, respectively. The directory service data 110 includes a data structure for a hierarchical graph of an organization, which represents the relative rank of participants based on their occupations within the organization. The graph embedding model 301 applies a graph embedding algorithm that captures local topological information about the participants' surroundings as specified in the directory service data 110 to generate local graph embeddings 304, such as the node2vec algorithm. The graph embedding model 301 is trained separately from the remainder of module 103D using directory service data 110 across organizations. The other layers of module 103D are trained as a whole.

[0039] Both NLP embedding layer 303 and location embedding layer 305 include NLP embeddings, such as Global Vector (GloVe) word representation embeddings that can be initialized and refined during training. Participant location data 302 includes indicators of each location visited by the participant within a time period, and participant metadata 300 includes participant metadata, such as metadata stored by a directory service including the participant's occupation, address, etc. Embedded participant metadata 306 and embedded participant location data 308 respectively include the outputs from the NLP embedding steps performed by NLP embedding layer 303 and location embedding layer 305.

[0040] The concatenation layer 307 receives and concatenates outputs 304, 306, and 308, and feeds the concatenated outputs into the fully connected layer 309. The fully connected layer 309 has an output of length equal to the number of countries monitored by module 103D, and each entry indicates the likelihood that a participant's activity at the location (i.e., country) corresponding to that entry includes anomalous participant behavior. As an example of the predicted location likelihood 312 output by the fully connected layer 309, example likelihood 310 indicates that participant activity in India has a likelihood of 0.92 corresponding to anomalous behavior, participant activity in the Netherlands has a likelihood of 0.10 corresponding to anomalous behavior, and participant activity in Germany has a likelihood of 0.02 corresponding to anomalous behavior. The rules layer 311 receives the predicted location likelihood 312 and generates anomalous behavior likelihood 314. The rules layer 311 applies rules that vary with location to determine the likelihood 314. For example, for locations known to have higher cybersecurity risks, the rules may generate a higher anomalous behavior likelihood.

[0041] Figures 4 to 8 This is a flowchart illustrating example operations for training and implementing a multi-view UEBA system used to detect anomalous participant behavior within a tenant organization using a scalable, modular architecture that captures participant behavior from multiple perspectives. This is in conjunction with previous (one or more) [systems / programs]. Figure 1 For ease of understanding, the example operations are described with reference to a multi-view UEBA system (“System”), a firewall, and a UEBA module trainer (“Trainer”). The names chosen for the program code are not a limitation of the claims. The structure and organization of the program can vary due to platform, programmer / architect preferences, programming language, etc. Furthermore, the names of code units (programs, modules, methods, functions, etc.) can vary for the same reasons and can be arbitrary.

[0042] Figure 4This is a flowchart illustrating example operations for detecting UEBA anomalies in participants over a specified time period via multiple behavioral perspectives. In box 401, the multi-perspective UEBA system (“System”) identifies the SaaS application activity data of participants collected over the specified time period. The specified time period can be based on a schedule (e.g., weekly) maintained by the tenant organization or on an external trigger such as an administrator’s audit of participants.

[0043] In box 403, the system begins iterating through the perspective of participant behavior. Each perspective corresponds to a feature value generated from features of SaaS application activity data collected over a specified time period.

[0044] In box 405, the system begins iterating through the sub-modules of the perspective. For example, the activity volume modeling module may include sub-modules corresponding to each application / action pair that corresponds to the actions taken and applications used by the participant during that time period (e.g., downloading application A, downloading application B, clicking on application A, etc.). Modules may vary in the number of sub-modules, and some modules, such as the activity location modeling module, may include only one sub-module.

[0045] In box 407, the system determines whether sufficient SaaS application activity data has been collected for the submodule of the specified time window. For example, the system can determine whether the number of feature values ​​corresponding to the submodule's characteristics exceeds a threshold number of feature values, whether there are a sufficient number of events corresponding to participant activity within the specified time window, and so on. Alternatively, the system can assess the sparsity of the activity data, such as whether activity data is lost in specific peak time slots, and can determine that there is insufficient activity data if the activity data is too sparse. The criteria for whether there is sufficient activity data can vary by perspective. If the SaaS application activity data is insufficient for the perspective within the specified time window, the workflow proceeds to box 409. Otherwise, the workflow jumps to box 413.

[0046] In box 409, the system identifies M additional participants to supplement the activity data for this viewpoint. For example, the system may identify the nearest M participants through a breadth-first search based on the hierarchical structure of participants within the same tenant organization defined by the directory service, until all M participants are identified. Alternatively, the system may identify participants within a threshold distance of the participants, and M may vary based on the number of participants found. The algorithm and / or criteria used to identify the additional M participants may vary by viewpoint and submodule.

[0047] In box 411, the system supplements the collected activity data with data from SaaS application activities of M participants within a specified time window. The system can access / retrieve the collected activity data from a repository that receives the activity data from a firewall when activity data is detected in a user service / process running on an endpoint device.

[0048] In box 413, the system preprocesses the activity data and inputs it into a submodule to obtain the likelihood of anomalous behavior of participants over a specified time period from the perspective of participant behavior. Preprocessing varies across submodules. For example, the system generates the frequencies of certain events or event types for probabilistic models. For machine learning models, the system applies various embedding and criterionization steps, etc.

[0049] In box 414, the system updates the perspective submodule with activity data. Some submodules are responsible for efficiently updating the activity data, such as fitting probability distributions to probabilistic models of historical activity data. These probabilistic models maintain the frequency of participant activity in historical activity data and can efficiently update the frequencies with additional activity data. Box 414 and its input / output arrows are depicted with dashed lines to indicate that these operations are optional and can vary depending on the implementation. For example, for participant-specific modules, the system may perform operations in box 414, while for tenant organization-wide submodules, the operations in box 414 may be omitted.

[0050] In box 415, the system continues iterating over the sub-modules of the perspective module. If there are additional sub-modules, the operation flow returns to box 403. Otherwise, the operation flow proceeds to box 416.

[0051] In box 416, the system continues iterating through the perspective of participant behavior. If an additional perspective exists, the workflow returns to box 405. Otherwise, the workflow returns to box 417.

[0052] In box 417, the system performs corrective actions based on the likelihood of participants' multi-perspective aberrant behaviors over a specified time period. The corrective actions are determined based on the participants' aberration scores generated from the aberration behavior likelihoods. (See reference) Figure 5 The operation at box 417 is described in more detail.

[0053] Figure 5 This is a flowchart illustrating an example operation for performing corrective actions based on the likelihood of a participant's anomalous behavior from multiple perspectives. In box 501, the multi-perspective UEBA system ("the System") decorrelates the likelihood of a participant's anomalous behavior over a time period to generate an anomalousness score. Reference Figure 6 The operation at box 501 is described in more detail.

[0054] In box 503, the system determines whether the anomaly score meets a risk criterion. For example, a risk criterion could be that the anomaly score falls within a threshold and / or range indicating a level of risk and / or risk severity. If the anomaly score meets the risk criterion, the operational flow proceeds to box 505. Otherwise, Figure 5 The operation flow was completed, and the participants were not flagged for potential anomalous behavior during that time period.

[0055] In box 505, the system identifies high-risk behavioral perspectives based on the likelihood of anomalous behavior. For example, a high-risk behavioral perspective can be identified by the top k likelihoods corresponding to some parameter k. Alternatively, each perspective can have a likelihood threshold higher than the one corresponding to which it is identified as high-risk.

[0056] In box 507, the system begins iterating through the identified high-risk behavioral perspectives. Although the actions for corrective actions are described per behavioral perspective, corrective actions can be performed based on the risk assessed across all perspectives, such as based on a set of high-risk behavioral perspectives or individual anomaly scores.

[0057] In box 509, the system assesses the risk severity of security exposures associated with participants' activities during a given time period based on the likelihood of anomalous behavior from high-risk perspectives and the participant's context. For example, specific high-risk perspectives known to have a more direct impact on overall risk may trigger higher risk severity. Participant context may include metadata such as job title and occupation, and specific metadata values ​​(e.g., a participant is a CEO or other senior executive) may additionally trigger higher risk severity.

[0058] In box 511, the system performs corrective actions based on the severity of the risk. Corrective actions may include terminating sessions / streams associated with the participant's SaaS application activity, generating alerts to the participant and / or tenant organization's security administrators, and scanning endpoint devices, databases, etc., exposed through the participant's activity. Corrective actions can be categorized by level, and specific corrective actions can only occur for higher severity levels.

[0059] In box 513, the system continues iterating through high-risk perspectives of participant behavior. If additional high-risk perspectives exist, the workflow returns to box 507. Otherwise, Figure 5 The operation is complete.

[0060] Figure 6This is a flowchart illustrating an example operation for decorrelating the likelihood of anomalous behavior of participants over a time period to generate an anomaly score. The likelihood of anomalous behavior is decorrelated to remove redundant correlated models within each module and submodule of the multi-view UEBA system (“System”). Without decorrelation, the likelihoods of highly correlated models are counted multiple times, and therefore the predictions of these models have an undue influence on the anomaly score. As an illustrative example, one model in a submodule of the Activity module of the System can predict the likelihood of a participant and application A’s download counts within one hour of a day, while another submodule can predict the likelihood of a participant and application A’s page requests within the same hour of a day. The outputs of these models are expected to be highly correlated and therefore at least partially redundant in generating the anomaly score.

[0061] In box 601, the system begins iterating through the perspective of participant behavior, maintaining one or more probabilistic models as sub-modules of the module corresponding to each perspective. Each module corresponding to a perspective may include one or more probabilistic models. For a module that includes a probabilistic model (e.g., the activity time modeling module), the system may skip the decorrelation operation at each iteration.

[0062] In box 602, the system normalizes the probability distribution for each sub-module of the viewpoint. For example, suppose the viewpoint is an activity quantity, and there exist probability distributions X, Y, Z, and V representing the download count, preview count, upload count, and preview count of app1, respectively. First, the system calculates the logarithm of each probability distribution as follows: This processing step is necessary because the probability distributions of most perspectives typically resemble log-normal or power-law distributions, and taking the logarithm makes these distributions more closely resemble Gaussian distributions. The system then normalizes each probability distribution using their standard deviations. ,in It is the standard deviation of the distribution in the subscript. This normalizes the random variable to a Gaussian distribution with a standard deviation of 1, which is helpful for correlation analysis.

[0063] In box 603, the system calculates the correlation matrix between the probability distributions of each submodule from the perspective of computation. For example, the entries in the correlation matrix corresponding to the distribution pairs X and Y are calculated as follows: Where E is the expectation, and It is the mean of the distribution in the subscript. Each entry in the correlation matrix is ​​in the interval [0, 1], and measures how correlated the corresponding pairs of random variables are, i.e. how similar their probability density functions are, where a value closer to 1 indicates a higher correlation.

[0064] In box 604, the system determines whether there exists a set of possible highly correlated distributions for the sub-modules of the viewpoint. For example, the system can identify a set of probability distributions such that each pair of probability distributions in the set has a correlation higher than a threshold (e.g., 0.85). Note that the set is selected in such a way that all pairwise correlations are higher than the threshold. For example, if the correlation between x and y is 0.91, the correlation between y and z is 0.95, but the correlation between y and z is 0.3, instead of grouping all x, y, z into the same highly correlated set, the system generates two sets—{x, y} and {y, z} (assuming v has a low correlation with all other random variables, so it resides in its own set).

[0065] In box 605, the system replaces each set of highly correlated distributions with their mean. Replacing each set with the mean of each set involves removing each random variable from one of the sets and adding a new random variable to each set as the mean of the random variables. In the previous example, the set of random variables {x, y, z, v} was replaced with the set... ,in and .

[0066] 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 aforementioned formula. Note that although described as a single instance of averaging the highly correlated probability distributions and recalculating the correlation matrix at each iteration, this process can occur multiple times until no highly correlated probability distributions exist.

[0067] In box 609, the system calculates a rarity score for each probability distribution and applies weights to each rarity score based on its relevance to other probability distributions within that viewpoint. The system constructs a probability density function for each of the resulting random variables, which is denoted for the previous example as follows: The system then generates a rarity score for each probability density function by taking the negative logarithm of each (so that a larger score corresponds to a higher rarity) and applying weights to it. The weights reduce the probability density function corresponding to a random variable that is highly correlated with many other variables. For example, the weights could be the inverse of the sum of the correlations between the random variable and each of the other random variables. For instance, using the previous example, the system first generates rarity scores as follows: Assuming and Then, the rarity score is downweighted to... and .

[0068] In box 611, the system calculates the rarity score of the anomalous behavior for that viewpoint as the mean of the rarity scores given by a weighted probability distribution. The total rarity score is given as the mean of each rarity score, i.e., as in the previous example. The system retrieves events corresponding to each distribution for the participant during that time period (e.g., the participant's activity level from 2 PM to 3 PM for application A) and determines the likelihood of each event given by the probability distribution. Assume events are observed for random variables X, Y, Z, and V during that time period. Then, the system determines, based on these observed events, the probability density functions. and The score for anomalous behavior is calculated based on the aforementioned formula. The rarity score S is higher for higher rarity (i.e., higher likelihood of anomalous behavior) and lower for lower rarity (i.e., higher likelihood of normal behavior).

[0069] In box 613, the system continues to iterate through the system's perspective. If an additional module corresponding to a perspective that includes multiple probability models exists, the operation flow returns to box 601. Otherwise, the operation flow proceeds to box 615.

[0070] In box 615, the system determines the cross-view correlation and weights the rarity score for each view based on this correlation. The system then calculates the anomaly score as the mean of the weighted scores for each view. For example, the system can determine the correlation using the probability density function corresponding to each module according to the aforementioned formula, and can weight the rarity score using the reciprocal of the sum of correlations with other modules as described above.

[0071] Figure 7 This is a flowchart of example operations used to train / update a multi-view UEBA system to generate anomaly scores for participant behavior across tenant organizations. For simplicity of presentation, Figure 7 This is described with reference to a single participant within a tenant organization. Modules maintained by the multi-perspective UEBA system (“System”) can have varying ranges across multiple participants and can be trained / updated simultaneously for all participants within that range. Training and updating of modules with varying ranges can occur asynchronously based on different schedules and / or triggers, and when a participant-specific module is updated, modules with ranges outside that participant do not need to be trained and updated simultaneously.

[0072] In box 701, the UEBA module trainer (“trainer”) identifies participants used to train / update modules in the system. For example, the trainer may identify participants based on a schedule (e.g., monthly) for updating modules associated with a participant or based on external triggers such as administrator prompts to update and / or train a participant's module, or a firewall detecting previously unseen SaaS application activity of a participant within a tenant organization. Although Figure 7 The text describes training / update being triggered by the participant's identifier, but alternatively, training can be triggered by the identifier of the module used for training / update, and the operation for iterating through the participant's perspective / scope can be omitted.

[0073] In box 705, the trainer begins iterating through the views of the multi-view UEBA system. In some embodiments, the trainer may omit views corresponding to modules that extend beyond a particular participant, and these modules may be trained / updated in separate pipelines.

[0074] In box 709, the trainer determines whether the current viewpoint range is participant-specific. The current viewpoint range includes the range of participants within the tenant organization, and training data is collected for the range of participants within the tenant organization to train a module corresponding to the participant's current viewpoint. If the range is participant-specific, the operation flow jumps to box 713. Otherwise, the operation flow proceeds to box 711.

[0075] In box 711, the trainer determines whether the corresponding module meets the training criteria. For modules that extend beyond a specific participant, these modules can be trained / updated according to a different schedule for each individual participant within the scope, and therefore for Figure 7 The operations described herein allow for the deferral of training / updates for these modules. Training criteria may include determining whether a corresponding module has sufficient additional historical activity data from participants across its range, the time period since the previous training / update, whether the module has been tagged for training / updates and for training / updates of modules for each participant in its range, and so on. If the training criteria are met, the operation flow proceeds to box 713. Otherwise, the operation flow jumps to box 719.

[0076] In box 713, the trainer uses collected activity data corresponding to the current viewpoint range over the past N time windows to train and / or update the corresponding modules. Training and / or updating are performed according to the corresponding model, and the collected activity data is preprocessed accordingly. For probabilistic models, training / updating occurs in a single epoch by updating the parameters of the fitted probability distribution. For neural networks, updates occur in batches and epochs of training data until training criteria, such as convergence of intrinsic parameters and sufficiently low training / test / validation errors, are met.

[0077] In box 719, the trainer continues iterating through the views of the multi-view UEBA system. If additional views exist, the operation flow returns to box 705. Otherwise, Figure 7 The operation flow is completed.

[0078] Figure 8 This is a flowchart illustrating example operations for maintaining a multi-perspective UEBA system across time periods. In Box 801, the multi-perspective UEBA system (“the System”) collects SaaS application activity data from participants across a tenant organization over a time period. For example, the System can receive activity data from the firewall when it detects requests or communications for a SaaS application in internal and external network traffic at endpoints within a tenant organization. Box 801 is depicted using dashed lines to indicate that the collection of SaaS application activity data occurs continuously, while the remaining operations occur asynchronously based on various triggers and criteria.

[0079] In box 803, the system determines whether the first trigger for training / update is satisfied. The first trigger can be a trigger per participant, a trigger per user behavior perspective, a trigger per module maintained for a perspective and one or more participants, or a combination of any of the foregoing. The first trigger can be based on a corresponding schedule or on external intervention, such as detecting a new participant in a tenant organization. If the first trigger is satisfied, the operational flow proceeds to box 805. Otherwise, the operational flow jumps to box 807.

[0080] In box 805, the UEBA model trainer (“trainer”) trains / updates the system to generate anomaly scores for the behavior of participants across the tenant organization based on historical activity data of participants at the first N time intervals T(1)–T(N). (Refer to the foregoing) Figure 7 The operation at box 805 is described in more detail.

[0081] In box 807, the system determines whether a second trigger for anomaly detection is satisfied. The second trigger can be per participant, per sub-part of a tenant organization, and / or across the entire tenant organization. For example, each participant can have a schedule for anomaly detection of participant behavior (e.g., weekly). If the second trigger is satisfied, the operational flow proceeds to box 809. Otherwise, the operational flow jumps to box 811.

[0082] In box 809, the system performs UEBA anomaly detection for (one or more) participants across time periods T(N+1), T(N+2), … via multiple behavioral perspectives. (Refer to the foregoing...) Figure 4 It describes the actions of each participant at each specified time period.

[0083] In box 811, the system determines whether a data decay criterion is met. For example, a data decay criterion could include data stored in a repository of a participant's historical activity that is older than a threshold amount (e.g., 6 months). If the data decay criterion is met, the operation flow proceeds to box 813. Otherwise, the operation flow returns to box 801.

[0084] In box 813, the system dumps outdated participant activity data from time periods T(-1), T(-2), etc. The workflow returns to box 801.

[0085] Variant This disclosure differs in that it involves analyzing participant activity data to identify anomalous behavior while using a SaaS application. Other types of activity data can be analyzed for anomalous behavior, such as activity data of background processes or processes started by the SaaS application itself.

[0086] The flowchart is provided to aid in understanding the illustrations, not to limit the scope of the claims. The flowchart depicts example operations that can vary within the scope of the claims. Additional operations may be performed; fewer operations may be performed; the operations may be performed in parallel; and the operations may be performed in a different order. For example, the operations described in blocks 805 and 809 can be performed in parallel or simultaneously. Regarding Figure 4 Updating the submodule using activity data at box 414 is not mandatory. It should be understood that each box in the flowchart and / or block diagram, as well as combinations of boxes in the flowchart and / or block diagram, can be implemented using program code. The program code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable machine or device.

[0087] As should be understood, aspects of this disclosure can be embodied as systems, methods, or program code / instructions stored in one or more machine-readable media. Therefore, aspects can take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, which are generally referred to herein as “circuit,” “module,” or “system.” The functionality presented as individual modules / units in the example illustrations can be organized differently based on any of the following: platform (operating system and / or hardware), application ecosystem, interface, programmer preferences, programming language, administrator preferences, etc.

[0088] Any combination of one or more machine-readable media may be used. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable storage medium can be, for example, but not limited to, a system, apparatus, or device that uses any 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 will include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium can be any tangible medium capable of containing or storing a program used by or in connection with an instruction execution system, apparatus, or device. A machine-readable storage medium is not a machine-readable signal medium.

[0089] Machine-readable signal media may include propagated data signals having machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such propagated signals may take any of a wide variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. Machine-readable signal media may be any machine-readable medium that is not a machine-readable storage medium and may transmit, propagate, or transfer programs used by or in connection with an instruction execution system, apparatus, or device.

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

[0091] Program code / instructions may also be stored in a machine-readable medium that can direct a machine to operate in a particular manner, such that the instructions stored in the machine-readable medium produce an article of manufacture which includes instructions that implement the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0092] Figure 9An example computer system with a multi-view UEBA system is depicted. The computer system includes a processor 901 (which may include multiple processors, multiple cores, multiple nodes, and / or implement multithreading, etc.). The computer system includes memory 907. Memory 907 may be system memory or any one or more possible implementations of the machine-readable media described above. The computer system also includes a bus 903 and a network interface 905. The system also includes a multi-view UEBA system (“System”) 911. System 911 uses modules that model the perspective of participant behavior to detect anomalous behavior of participants within an organization. Each module includes one or more probabilistic models and / or machine learning models as sub-modules at further granularities, such as within segmented time windows of time periods and by SaaS application and by participant activity. System 911 generates anomaly scores by decorrelation and averaging the likelihoods of the outputs of sub-modules within each module and across module outputs. System 911 can continuously train, update, redeploy, add, and remove modules to maintain the security posture of each participant across the organization. Any of the aforementioned functionalities can be implemented, in part or in all, in hardware and / or processor 901. For example, the functionality can be implemented using an application-specific integrated circuit (ASIC), logic implemented in processor 901, peripheral devices, or a coprocessor on a card. Furthermore, implementation may include... Figure 9 Fewer or additional components not shown in the diagram (e.g., video card, sound card, additional network interface, peripherals, 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 method comprising: According to the directory service, first data of the cloud-based activities of the first participant and second data of the cloud-based activities of one or more participants close to the first participant are collected respectively, wherein the first data and the second data correspond to a first time window; Multiple machine learning models are trained using at least the first data to detect anomalous behavior of a first participant, wherein at least a subset of the multiple machine learning models are trained using the first data and the second data. The generation of multiple likelihood values ​​for the behavior of the first participant in a second time window following the first time window includes obtaining the multiple likelihood values ​​as output by inputting third data from the first participant in the second time window into multiple machine learning models. and The multiple likelihood values ​​are aggregated to generate a likelihood score that indicates the anomalousness of the first participant's behavior in the second time window.

2. The method according to claim 1, wherein the plurality of machine learning models include at least one of a probability model of the amount of activity in the first participant's participant activities, a probability model of the type of activity in the first participant's participant activities, a probability model of the time of activity in the first participant's participant activities, and a neural network model of the location visited by the first participant.

3. The method according to any one of the preceding claims, wherein training the plurality of machine learning models comprises training each machine learning model for at least a subset of the plurality of machine learning models. Based on determining that a first subset of data representing aspects of participant activity corresponding to a machine learning model is sufficient for training, a probability distribution is fitted to that subset of data; and Based on the premise that the subset of the first data is insufficient for training, the probability distribution is fitted to a subset of the first data and a subset of the second data representing aspects of participant activity corresponding to the machine learning model. Specifically, the probability distribution includes at least one of a power-law distribution, a log-normal distribution, and a Gaussian distribution.

4. The method according to any one of the preceding claims, Specifically, the plurality of machine learning models include a neural network for predicting the likelihood values ​​of locations indicated in the participant activity of at least a first participant corresponding to normal behavior. The neural network includes an input layer for locations already visited by the first participant, an input layer for characteristics of the first participant, input layers for characteristics of one or more participants, and a concatenation layer that combines the outputs of blocks of the neural network from each of the input layers. Further, training the neural network includes training the neural network on third data collected for cloud-based activities of participants, including the first participant, across a tenant organization of the first participant. Specifically, one or more participants near the first participant according to the directory service include participants near the first participant in a graph data structure that models the hierarchical roles of participants maintained by the directory service, wherein the hierarchical roles of participants include the hierarchical roles of participants within the same tenant organization monitored by the directory service, and Specifically, the plurality of machine learning models include one or more models for detecting anomalous access to sensitive documents by a first participant for data loss prevention.

5. The method according to any one of the preceding claims, wherein aggregating the plurality of likelihood values ​​to generate a score comprises: The multiple likelihood values ​​are decorrelated to obtain multiple decorrelated likelihood values; Generate a score as the sum of multiple decorrelation likelihood values; Based on the score exceeding the threshold likelihood value, a ruling is generated indicating that the behavior of the first participant is normal and not within the second time window; and Based on the score not exceeding the threshold likelihood value, a ruling is generated indicating that the behavior of the first participant is normal in the second time window.

6. A non-transitory machine-readable medium having program code stored thereon, the program code including instructions for: Maintain multiple profiles of normal participant behavior for each of the multiple participants in a cloud-based activity to monitor participant entities and perform behavioral analysis. The instructions used to maintain these multiple profiles include instructions for performing the following for each participant and the corresponding profile in the multiple profiles. Collect first data of the cloud-based activities of the participant and second data of the cloud-based activities of one or more participants close to the participant in a data structure maintained by the directory service, wherein the first data and the second data appear in a first time window; Multiple machine learning models are trained using first data to predict scores for anomalous participant behavior, wherein second data is used to supplement at least a subset of the training data of the multiple machine learning models, wherein the profile includes multiple trained machine learning models. and The profile is updated based on third data on the cloud-based activities of at least the participants collected in one or more time windows following the first time window.

7. The non-transitory machine-readable medium of claim 6, further comprising instructions for deploying the profile to generate a score indicating the likelihood of behavioral anomalousness of the participants in one or more time windows following the first time window, wherein the instructions for deploying the profile include instructions for performing the following for a second time window within the one or more time windows: Fourth data on the cloud-based activities of the participants are collected in the second time window, wherein the third data includes the fourth data; The fourth data point is input into multiple trained machine learning models in the profile to obtain multiple likelihood values ​​as outputs indicating that the participants' behavior was normal in the second time window; and A score is generated based on the multiple likelihood values. Specifically, the instructions for generating scores based on multiple likelihood values ​​include instructions for performing the following: Decorrelate multiple likelihood values ​​to generate multiple decorrelated likelihood values; and Generate a score as the sum of multiple decorrelation likelihood values.

8. The non-transitory machine-readable medium according to claim 6 or 7, wherein the plurality of machine learning models include at least one of a probabilistic model of the amount of activity in the participant's participant activities, a probabilistic model of the type of activity in the participant's participant activities, and a probabilistic model of the duration of activity in the participant's participant activities. Specifically, the plurality of machine learning models includes at least one of the following: a probabilistic model of the amount of activity in the participant's participant activities; a probabilistic model of the type of activity in the participant's participant activities; and a probabilistic model of the duration of activity in the participant's participant activities. Specifically, the plurality of profiles includes a neural network model for predicting the likelihood of anomalous behavior in locations visited by participants of a tenant organization comprising multiple participants across multiple participants, wherein the neural network model includes an input layer of locations visited by the participants, an input layer of characteristics of the participants, an input layer of characteristics of one or more participants, and a splicing layer that combines the outputs of blocks of the neural network model comprising each of the input layers.

9. The non-transitory machine-readable medium according to any one of claims 6-8, wherein the instructions for training the plurality of machine learning models include instructions for performing the following, for each machine learning model of at least a subset of the plurality of machine learning models, Based on determining that a first subset of data representing aspects of participant activity corresponding to a machine learning model is sufficient for training, a probability distribution is fitted to that subset of data; and Based on the determination that the subset of the first data is insufficient for training, the probability distribution is fitted to both the subset of the first data and the subset of the second data, where the subset of the second data represents aspects of participant activity corresponding to the machine learning model. Specifically, the probability distribution includes at least one of the power-law distribution, the log-normal distribution, and the Gaussian distribution.

10. The non-transitory machine-readable medium according to any one of claims 6-9, wherein one or more participants near the participants according to the directory service include participants near the participants in a graph data structure, the graph data structure modeling hierarchical roles of participants maintained by the directory service, wherein the hierarchical roles of participants include hierarchical roles of participants within the same tenant organization monitored by the directory service.

11. An apparatus comprising: processor; and A machine-readable medium storing instructions that can be executed by a processor to cause the device to perform the following: Multiple machine learning models are trained using first data of cloud-based activities of a first participant collected in a first time window to detect anomalous behavior of the first participant, wherein each of the multiple machine learning models is trained to detect anomalous behavior in a different aspect of multiple aspects of the first participant’s participant activities. and Deploying the plurality of trained machine learning models for detecting anomalous behavior of the first participant in a time window following the first time window, wherein instructions executable by the processor to deploy the plurality of machine learning models include instructions to perform the following steps: aggregating the likelihood values ​​obtained as outputs of the plurality of trained machine learning models based on inputs from data collection of the first participant’s cloud-based activities in subsequent time windows to generate a score of anomalous behavior of the first participant in subsequent time windows.

12. The apparatus of claim 11, wherein the machine-readable medium further stores instructions executable by the processor to cause the apparatus to perform the following based on data determining that each of the plurality of machine learning models in at least a first subset is insufficient in the first data used for training: Based on the directory service identifier, one or more participants are located near the first participant; and The training of a first subset of the multiple machine learning models is supplemented with second data collected from cloud-based activities of one or more participants within the first time window.

13. The apparatus of claim 11 or 12, wherein one or more participants close to the first participant according to the directory service include participants close to the first participant in a graph data structure, the graph data structure modeling the hierarchical roles of participants maintained by the directory service, wherein the hierarchical roles of participants include the hierarchical roles of participants within the same tenant organization monitored by the directory service.

14. The apparatus of any one of claims 11-13, wherein the instructions for training the plurality of machine learning models include instructions executable by the processor to cause the apparatus to perform the following for each machine learning model of at least a second subset of the plurality of machine learning models: Based on determining that a subset of first data representing one of several aspects of participant activity corresponding to a machine learning model is sufficient for training, a probability distribution is fitted to the subset of data; and Based on the premise that the subset of the first data is insufficient for training, the probability distribution is fitted to a subset of the first data and a subset of the second data representing aspects of participant activity corresponding to the machine learning model. Specifically, the probability distribution includes at least one of the power-law distribution, the log-normal distribution, and the Gaussian distribution.

15. The apparatus according to any one of claims 12-14, Specifically, the plurality of machine learning models include at least one of the following: a probabilistic model of the amount of activity in the first participant's participant activities; a probabilistic model of the type of activity in the first participant's participant activities; a probabilistic model of the duration of activity in the first participant's participant activities; and a neural network model of the locations visited by the first participant. Specifically, the plurality of machine learning models include a neural network for predicting the likelihood values ​​of at least a first participant's location corresponding to normal behavior indicated in participant activity, wherein the neural network includes an input layer for locations already visited by the first participant, an input layer for characteristics of the first participant, an input layer for characteristics of one or more participants close to the first participant according to the directory service, and a splicing layer that combines the outputs of blocks of the neural network including each input layer, and further wherein the instructions for training the neural network include instructions executable by a processor to train the neural network on third data collected for cloud-based activities of participants including the first participant across a tenant organization of the first participant.

Images