Patent Description:
To combat security issues, cloud security providers offer services with threat detection capabilities to alert customers to malicious activity targeting their environments. As in conventional computer systems, cloud computing systems may generate several alerts related to a single attack campaign. Many attacks follow a common sequence of steps to achieve some nefarious objective. Such attacks are often referred to as a "kill-chain.

To render a collection of alerts meaningful to a system administrator, a cloud security provider may aggregate alerts that align with a kill-chain pattern, or other known pattern, into an "incident" to provide a consolidated view of the attack campaign. Typically, an incident includes a sequence of alerts, where each alert corresponds to a particular step in the attack pattern. These alerts contain valuable information helpful in determining what triggered the alert, the resources targeted, and the source of the attack. <CIT> describes implementations directed to methods for detecting and identifying advanced persistent threats (APTs) in networks, including receiving first domain activity data from a first network domain and second domain activity data from a second network domain, including multiple alerts from the respective first and second network domains and where each alert of the multiple alerts results from one or more detected events in the respective first or second network domains. A classification is determined for each alert of the multiple alerts with respect to a cyber kill chain. A dependency is then determined for each of one or more pairs of alerts and a graphical visualization of the multiple alerts is generated, where the graphical visualization includes multiple nodes and edges between the nodes, each node corresponding to the cyber kill chain and representing at least one alert, and each edge representing a dependency between alerts. <CIT> describes methods, systems, and apparatuses which are provided for evaluating a chain of alerts. Historical alerts may be grouped together to form sets of alerts based on a predetermined relationship between the alerts. A score is determined for each set of alerts representing a statistical likelihood that one alert in the set is correlated to another alert in the set, generating a plurality of scores for the sets of alerts. The scores may be placed into a model containing a score for each set of alerts. After the model is formed, a received chain of alerts may be evaluated by examining whether the chain of alerts, or a sub-chain of alerts, corresponds to a score in the model through an iterative process. If the chain of alerts corresponds to a score in the model and meets a predetermined criteria, a system administrator can be alerted of the chain of alerts. "Using Data Science Techniques for the Automatic Clustering of IT Alerts" (https://tanzu. com/content/blog/using-data-science-techniques-for-the-automatic-clustering-of-it-alerts) relates to categorizing alert messages generated in large enterprise IT infrastructure - such as by network, storage or database components - to obtain insights which may be useful for root-cause analysis and failure prediction. <CIT> describes how a computer-implemented method for using event-correlation graphs to detect attacks on computing systems may include (<NUM>) detecting a suspicious event involving a first actor within a computing system, (<NUM>) constructing an event-correlation graph that includes a first node that represents the first actor, a second node that represents a second actor, and an edge that interconnects the first node and the second node and represents a suspicious event involving the first actor and the second actor, (<NUM>) calculating, based at least in part on the additional suspicious event, an attack score for the event-correlation graph, (<NUM>) determining that the attack score is greater than a predetermined threshold, and (<NUM>) determining, based at least in part on the attack score being greater than the predetermined threshold, that the suspicious event may be part of an attack on the computing system.

Implementations disclosed herein are directed to inferring security incidents from a group of received alerts. For example, alerts generated with respect to a set of entities by a first alert generator are received, association scores are calculated for pairs of alerts, the alerts are formed into clusters based on the association scores, and a security incident model is formed based on the clusters. The security incident model may define sequences of alerts corresponding to security incidents. Furthermore, the security incident model can be used to determine a match between additional alerts and a sequence of alerts in the security incident model and identify the additional alerts as a security incident corresponding to the sequence of alerts in the security incident model.

Further features and advantages of the invention, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the embodiments are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

Cloud computing is a form of network-accessible computing that provides shared computer processing resources and data to computers and other devices on demand over the Internet. Cloud computing enables the on-demand access to a shared pool of configurable, network-accessible computing resources, such as computer networks, servers, storage, applications, and services (collectively, in any combination, "the cloud"). Given the vast resources available on "the cloud", cloud workload security has become increasingly important.

To render a collection of alerts meaningful to a system administrator, a cloud security provider aggregates any alerts that align with a kill-chain pattern into an "incident" to provide a consolidated view of the attack campaign. Typically, an incident includes a sequence of alerts, where each alert corresponds to a particular step in the attack pattern. These alerts contain valuable information helpful in determining what triggered the alert, the resources targeted, and the source of the attack.

However, in some instances, a malicious event in an attack series may not be detected and thereby an alert corresponding to the malicious event may not be triggered. If an alert is not reported for a sequence of issued alerts, then the appropriate incident associated with the attack series may not be designated and provided to a system administrator. For example, an attacker may move laterally from a compromised resource to another resource within a same network to harvest valuable data. If the lateral move to the other resource is not detected, then an alert indicating that the other resource is comprised will not be included in the reported incident and a system administrator will be unaware of the comprised resource and unable to remediate the attack. Current threat detection techniques are not necessarily foolproof and can at times miss malicious activity targeting resources.

Moreover, because of the dynamic nature of attackers and of systems targeted by attackers, it is not necessarily obvious how an attack campaign is represented as a security incident to a system administrator. Conventionally, associations between alerts may be discovered using data mining association rules (e.g., Apriori algorithm). However, this methodology may identify spurious associations between pairs of alerts. For example, two alerts might be indicated as associated with each other because the events that triggered the alerts occurred on the same type of resource (e.g., web servers). The events may not be associated with the same attack campaign and the fact that the events occurred on the same type of resource may be merely coincidental. Thus, current threat detection techniques may group alerts into security incidents that may not accurately represent an attack campaign.

Embodiments disclosed herein address these issues described above. Embodiments disclosed herein are directed to inferring security incidents from observational data. For example, in embodiments, alerts generated with respect to a set of entities by a first alert generator are received, association scores are calculated for pairs of alerts, the alerts are formed into clusters based on the association scores, and a security incident model is formed based on the clusters. The security incident model may define sequences of alerts corresponding to security incidents. Furthermore, in embodiments, the security incident model can be used to determine a match between additional alerts and a sequence of alerts in the security incident model and identify the additional alerts as a security incident corresponding to the sequence of alerts in the security incident model.

Such embodiments, and further embodiments, may be implemented in various ways. For instance, <FIG> shows a block diagram of an example security incident determination system <NUM>, according to an embodiment. As shown in <FIG>, system <NUM> is implemented with respect to an environment <NUM> that includes any number of resources (e.g., resources 106A, 106B, 106C, 106D) that a user <NUM> is authorized to access and an attacker <NUM> is not authorized to access, a security management system <NUM>, and a security incident inference system <NUM>. System <NUM> is described in further detail as follows.

As shown in <FIG>, resources 106A-106D, security management system <NUM>, and security incident inference system <NUM> are communicatively coupled via a network <NUM>. Resources 106A-106D are also communicatively coupled with each other via network <NUM>. Network <NUM> may comprise one or more networks such as local area networks (LANs), wide area networks (WANs), enterprise networks, the Internet, etc., and may include one or more of wired and/or wireless portions.

For illustration purposes, environment <NUM> is shown to include resources 106A, 106B, 106C, and 106D, but may include any number of resources, including tens, hundreds, thousands, millions, and even greater numbers of resources. Environment <NUM> may be comprised of resources (e.g., servers) running on different clouds and/or in on-premises data centers of an enterprise or organization associated with a user <NUM>. Resources 106A, 106B, 106C, and 106D may include any cloud computing resources, including computer networks, servers, storage, applications, and/or services, and/or may include further types of resources. For example, in an embodiment, resources 106A, 106B, 106C, and 106D may each be a server and form a network-accessible server set that are each accessible by a network such as the Internet (e.g., in a "cloud-based" embodiment) to store, manage, and process data. Additionally, in an embodiment, environment <NUM> may include any type and number of other resources including resources that facilitate communications with and between the servers (e.g., network switches, networks, etc.), storage by the servers (e.g., storage devices, etc.), resources that manage other resources (e.g., hypervisors that manage virtual machines to present a virtual operating platform for tenants of a multi-tenant cloud, etc.), and/or further types of resources.

In an embodiment, resources 106A, 106B, 106C, and 106D may be configured to execute one or more services (including microservices), applications, and/or supporting services. A "supporting service" is a cloud computing service/application configured to manage a set of servers to operate as network-accessible (e.g., cloud-based) computing resources for users. Examples of supporting services include Microsoft® Azure®, Amazon Web Services™, Google Cloud Platform™, IBM® Smart Cloud, etc. A supporting service may be configured to build, deploy, and manage applications and services on the corresponding set of servers. Each instance of the supporting service may implement and/or manage a set of focused and distinct features or functions on the corresponding server set, including virtual machines, operating systems, application services, storage services, database services, messaging services, etc. Supporting services may be coded in any programming language. Resources 106A, 106B, 106C, and 106D may be configured to execute any number of supporting services, including multiple instances of the same and/or different supporting services.

User <NUM> and any number of further users (e.g., individual users, family users, enterprise users, governmental users, etc.) may access resources 106A, 106B, 106C, and 106D and any other resources of environment <NUM> through network <NUM> via computing devices, including a computing device <NUM> accessed by user <NUM>. These computing devices used to access resources of environment <NUM> may be any type of a stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a Microsoft ® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple iPad™, a netbook, etc.), a mobile phone, a wearable computing device, or other type of mobile device, or a stationary computing device such as a desktop computer or PC (personal computer), or a server. Computing device <NUM> of user <NUM> may interface with resources 106A, 106B, 106C, and 106D through application programming interfaces (API)s and/or by other mechanisms. Note that any number of program interfaces may be present.

Though security management system <NUM> and security incident inference system <NUM> are shown separate from resources 106A, 106B, 106C, and 106D, in an embodiment, security management system <NUM> and security incident inference system <NUM> may be incorporated in one or more resources of environment <NUM>. Security management system <NUM> and security incident inference system <NUM> may also be incorporated in any type of stationary or mobile computing device(s) described elsewhere herein or otherwise known. For instance, security management system <NUM> and security incident inference system <NUM> may be incorporated in a network/cloud supporting service mentioned elsewhere herein or otherwise known.

Security management system <NUM> may be configured to manage and/or monitor the security of resources 106A-106D and any other resources in environment <NUM>. For example, attacker <NUM> may attempt to access resources 106A, 106B, 106C, and 106D via network <NUM> for an unauthorized purpose using any type of stationary or mobile computing device, which may be similar to computing devices used by user <NUM>, such as a computing device <NUM>. In some instances, attacker <NUM> may try to install and execute malicious software (e.g., malware) on a resource, attempt a brute-force attack (e.g., password guessing) on a resource, persist in a compromised network to access valuable data and/or use a compromised resource to mount attacks against other resources in an environment.

If such attacks by attacker <NUM> occur, a resource of resources 106A, 106B, 106C, and 106D that is a target of an attack may generate an alert indicating that a perceived threat has been detected. For instance, as shown in <FIG>, resources 106A and 106C generate alerts 104a, 104b, and 104c. These alerts may be generated following unauthorized or illegitimate attempts perpetrated by attacker <NUM> to access resources 106A and 106C. After being generated, in an embodiment, alert 104a may be stored in a log file maintained by resource 106C and alerts 104b and 104c may be stored in a log file maintained by resource 106A. A monitoring agent associated with security management system <NUM> may be installed on each of resources 106A, 106B, 106C, and 106D and configured to collect events (such as alerts 104a, 104b, and 104c) from log files, performance data, and other telemetry from the resources and send the collected information to security management system <NUM> via network <NUM>.

Alerts 104a, 104b, and 104c may comprise any type of security alert, including but not limited to a potential virus alert, web application firewall alert, endpoint data protection alert, memory or other device access violations, etc. Similarly, alerts 104a, 104b, and 104c are not limited to security alerts generated in cloud computing systems described herein as exemplary embodiments. Alert evaluating system <NUM> may also operate on one or more standalone devices connected to a network in which security alerts are generated.

Alerts 104a, 104b, and 104c may have any suitable format, including an electronic file, one or more data packets, etc., and may include contextual information, such as a username, process name, IP address, etc., associated with a resource and/or application that the alert was generated based upon. Alerts 104a, 104b, and 104c may also include contextual information regarding any relationship the alert may have to another one or more alerts, such as temporal connections. Alerts 104a, 104b, and 104c may be individual alerts, groups of alerts, logs of alerts, or chains of alerts that may together resemble a potential threat.

Security management system <NUM> is further configured to correlate and analyze the collected information described above to enable real-time reporting and alerting on incidents that may require intervention. For example, security management system <NUM> may receive, via network <NUM>, alert 104a from resource 106C and alerts 104b and 104c from resource 106A that warn of threats posed to the resources. Security management system <NUM> may further analyze alerts 104a, 104b, and 104c and generate a security incident based on the analysis of the alerts. More specifically, security management system <NUM> may correlate information associated with alerts 104a, 104b, and 104c and deduce that the alerts are part of the same security incident, which comprises a sequence of alerts of [104a, 104b, 104c], based on temporal relationships and/or contextual information (e.g., a username, process name, IP address, etc.) associated with each alert.

Additionally, security management system <NUM> may analyze a history of alerts existing on a cloud service, such as alert logs generated by individual computing devices and/or servers connected to a cloud or environment <NUM> or through logs aggregating a history of alerts across multiple computing devices and/or servers connected to the cloud or environment <NUM>. The historical alerts may then be grouped together to form incidents based on a preexisting relationship, such as a timing relationship and/or whether the alert occurred on the same or similar resources. As described previously, these relationships between alerts may be discovered using data mining association rules, which may identify spurious associations between alerts and cause a security incident to be indicated that does not accurately represent an attack campaign. Moreover, in some instances, a malicious event in an attack series may not be detected and thereby an alert corresponding to the malicious event may not be triggered. If an alert is missing from a sequence of issued alerts, then the appropriate incident associated with the attack series may not be designated and provided to a system administrator.

Security incident inference system <NUM> is configured to form a security incident model that defines sequences of alerts corresponding to security incidents. The security incident model is formed based on valid associations between alerts that are generated with respect to a set of entities and prevents missing alerts not generated because a malicious event was not detected from causing an incomplete or invalid security incident being identified. When used herein, "entity" refers to a characteristic shared between a group of alerts. For example, alerts may be aggregated by entity based on alerts' association with a subscription, a resource, a user, an attacker, an organization or enterprise, and/or IP address.

In an embodiment, security incident inference system <NUM> may receive alerts identified by security management system <NUM> as a security incident via network <NUM>. In one embodiment, for example, security incident inference system <NUM> may receive a set of alerts, including an alert sequence, generated with respect to a set of entities (e.g., any alerts generated in environment <NUM>) from security management system <NUM> and form a security incident model based on the received alerts. Alternatively, or in addition to, security incident inference system <NUM> may receive one or more alerts directly from resources 106A, 106B, 106C, and 106D via network <NUM>.

Once the security incident model is generated, security incident inference system <NUM> is further configured to determine a match between the alerts in the security incident model and identify the alerts as a security incident that corresponds to the sequence of alerts defined in the security incident model. To help illustrate, security incident inference system <NUM> may determine alert sequence [104a, 104b, 104c] corresponds to a security incident including alert sequence of [104a, 104b, <NUM>, 104c]. The indicated security incident includes alert <NUM> which is not included in the received alert sequence. As previously described, a security incident may include a sequence of alerts, where each alert corresponds to a step in an attack campaign. Say for illustration purposes, a malicious event committed by attacker <NUM> corresponding to alert <NUM> was not detected, resulting in alert <NUM> not to be generated. The notification indicating that the alert sequence corresponds to the security incident including the alert sequence of [104a, 104b, <NUM>, 104c] could be provided to user <NUM>-informing the user of the previously unnoticed malicious event corresponding to alert <NUM> and allowing user <NUM> to investigate the attack and remediate any harm caused by the malicious event.

To provide real-world context, say attacker <NUM> first tries to unsuccessfully access resource 106C by submitting several possible passwords for an account associated with user <NUM>, and resource 106C then generates alert 104a indicating that a brute force attempt was found. Next, attacker <NUM> successfully accesses resource 106A by submitting a correct password for an account associated with user <NUM>, and resource 106A generates alert 104b indicating that a successful brute force attack was found. Attacker <NUM> then executes malicious code on resource 106A without detection by masquerading the malicious code as a benign process. If the event had been detected, alert <NUM> would have been generated by resource 106A indicating that a malicious process was created. Finally, attacker <NUM> uses resource 106A to try again to access resource 106C by submitting several possible passwords for an account associated with user <NUM> and resource 106A then generates alert 104c indicating an outgoing brute force attempt was found. Because alert <NUM> was not generated, user <NUM> is unaware that the malicious code is executing on resource 106A. This scenario, however, is preventable.

Embodiments described herein can provide users and/or system administrators with information associated with missing alerts that may be critical to an investigation of an attack campaign and that can help identify vulnerabilities in a threat detection solution offered by a cloud provider. Embodiments described herein also act as a second line of defense for resources of the environment, as threat detection systems are not necessarily foolproof and can at times miss malicious activity targeting resources. In addition, embodiments described herein avoid using spurious associations between alerts when inferring security incidents so that a security incident unrelated to an attack will not be indicated to a user and/or system administrator.

The process described with reference to <FIG> is described as follows in more detail with reference to <FIG>. Note that security incident inference system <NUM> of <FIG> may be implemented in various ways to perform its functions. For instance, <FIG> is a block diagram for a system <NUM> that forms a security incident model based on received alerts generated with respect to a set of entities and identifies additional alerts as a security incident using the security incident model, according to an example embodiment.

System <NUM> includes an example embodiment of security incident inference system <NUM>. As shown in <FIG>, security incident inference system <NUM> includes an alert association determiner <NUM>, a community identifier <NUM>, a security incident model generator <NUM>, and an alert incident identifier <NUM>. System <NUM> is described in further detail as follows.

Alert association determiner <NUM> is configured to determine how strongly associated pairs of alerts are that were generated with respect to a set of entities. For example, as depicted in <FIG>, alert association determiner <NUM> receives alerts <NUM> (e.g., the alert sequence of [104a, 104b, 104c] from security management system <NUM> or alerts 104b and 104c from resource 106A and alert 104a from resource 106A in <FIG>) and calculates association scores for pairs of alerts of alerts <NUM>, where the association scores indicate a strength of association between pairs of alerts. In an embodiment, alerts <NUM> may be generated with respect to a set of entities. To help illustrate, with reference to <FIG>, alerts 104a, 104b, and 104c are generated with respect to some of the following entities: being generated in relation to events detected on resources in environment <NUM>, being generated in relation to events detected on resources accessible to user <NUM>, and being generated in relation to events related to an attack campaign perpetrated by attacker <NUM>.

In an embodiment, alert association determiner <NUM> may be configured to generate an alert association graph <NUM> based on the calculated association scores. Alert association determiner <NUM> may store security alert association graph <NUM> in a storage (not pictured in <FIG>) that may include one or more of any type of suitable storage medium, such as a hard disk, solid-state drive, magnetic disk, optical disk, read-only memory (ROM), or random-access memory (RAM). Alternatively, alert association graph <NUM> may be stored remotely from alert association determiner <NUM>. Alert association graph <NUM> may be stored in storage in any form, such as in the form of a table, array, or otherwise. Additional detail for generating alert association graph <NUM> is described with reference to <FIG> further below.

Community identifier <NUM> is configured to cluster alerts that were generated with respect to a set of entities. For example, as shown in <FIG>, community identifier <NUM> receives alert association graph <NUM> from alert association determiner <NUM>. Community identifier <NUM> may cluster alerts <NUM> based on alert association graph <NUM>. Any suitable algorithm (e.g., the Louvain method, Bron-Kerbosch algorithm, the Jaccard index, etc.,) may be used to find one or more communities (interconnected sets of alerts in graph <NUM>) within alerts <NUM>. In another embodiment, community identifier <NUM> may receive association scores for pairs of alerts of alerts <NUM> from alert association determiner <NUM> and cluster alerts <NUM> based on the association scores.

Security incident model generator <NUM> is configured to form a security incident model that defines sequences of alerts corresponding to security incidents. For example, as shown in <FIG>, security incident model generator <NUM> may receive a list of clusters <NUM> indicating the determined clusters of alerts <NUM> from community identifier <NUM> and generate a security incident model <NUM> based on list of clusters <NUM>. Security incident model <NUM> may define sequences of alerts of alerts <NUM> that correspond to security incidents. In an embodiment, security incident model generator <NUM> may store security incident model <NUM> in storage (not pictured in <FIG>) that may include one or more of any type of suitable storage medium, such as a hard disk, solid-state drive, magnetic disk, optical disk, read-only memory (ROM), or random-access memory (RAM). Alternatively, security incident model <NUM> may be stored remotely from security incident model generator <NUM>. Security incident model <NUM> may have any suitable format, including being a file containing model definition information in any form, such as human-readable text, XML (extensible markup language), C# or other programming language, binary code, or any other form. Additional detail for generating security incident model <NUM> is described with reference to <FIG>, further below.

Alert incident identifier <NUM> is configured to use security incident model <NUM> to identify if alerts received by alert incident identifier <NUM> as a security incident. For example, as shown in <FIG>, alert incident identifier <NUM> receives alerts <NUM> (e.g., from security management system <NUM> and/or resources 106A, 106B, 106C, 106D in <FIG>) and accesses security incident model <NUM> to identify if alerts <NUM> matches a sequence of alerts in security incident model <NUM>. If a match is detected, alert incident identifier <NUM> may identify alerts <NUM> as a security incident and provide a notification <NUM> of the security incident to an alert generator (e.g., security management system <NUM> and/or resources 106A, 106B, 106C, 106D in <FIG>) or system administrator. In one embodiment, the identified security incident may include alerts <NUM> and additional alerts not included in alerts <NUM> that are related to the identified security incident and all these alerts may be indicated in notification <NUM>. In another embodiment, the identified security incident may include a portion of alerts <NUM> that are related to the identified security incident and only the portion of alerts <NUM> that are related to the identified security incident may be indicated in notification <NUM>.

As described above, security incident inference system <NUM> of <FIG> and <FIG> may operate in various ways. For instance, <FIG> shows a flowchart <NUM> for forming a security incident model that defines sequences of alerts corresponding to security incidents, according to an example embodiment. In an embodiment, steps of flowchart <NUM> may be implemented by alert association determiner <NUM>, community identifier <NUM>, and security incident model generator <NUM> of <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, alerts generated with respect to a set of entities by a first alert generator are received. For example, with reference to <FIG>, alert association determiner <NUM> receives alerts <NUM>. In an embodiment, as described herein with reference to <FIG> and continued reference to <FIG>, alert association determiner <NUM> may receive a security incident (e.g., an alert sequence of [104a, 104b, 104c] in <FIG>) from security management system <NUM> and/or may receive alerts (e.g., 104a, 104b, 104c in <FIG>) directly from resources of environment <NUM>. The received alerts may be generated with respect to a set of entities (e.g., generated with respect to: environment <NUM>, user <NUM>, attack <NUM>, resources 106A, 106B, 106C, 106D etc.).

In step <NUM>, association scores are calculated for pairs of the alerts. For example, with reference to <FIG>, alert association determiner <NUM> calculates association scores for all pair combinations of alerts of alerts <NUM>. In an embodiment, as described herein with reference to <FIG> and continued reference to <FIG>, if alerts <NUM> included alerts 104a, 104b, and 104c, alert association determiner <NUM> may calculate association scores between pairs of alerts: 104a and 104b, 104a and 104c, 104b and 104c. The calculated associations scores would indicate strength of association between pairs of alerts: 104a and 104b, 104a and 104c, 104b and 104c.

In step <NUM>, the alerts are clustered into clusters based on the association scores. For example, with reference to <FIG>, community identifier <NUM> may receive association scores for pairs of alerts of alerts <NUM> from alert association determiner <NUM> and cluster alerts <NUM> based on the association scores. As described above different algorithms may be used to find communities of related alerts within alerts <NUM>.

In step <NUM>, a security incident model is formed based on the clusters, where the security incident model defines sequences of alerts corresponding to security incidents. For example, with reference to <FIG>, alert incident identifier <NUM> may form security incident model <NUM>, based on the clusters of alerts <NUM>. In this example, security incident model <NUM> defines sequences of alerts <NUM> that correspond to security incidents. To help further illustrate, as shown in <FIG>, security incident model generator <NUM> may receive a list of clusters <NUM>, indicating the determined clusters of alerts <NUM>, from community identifier <NUM> and generate security incident model <NUM> based on list of clusters <NUM>.

As described previously, community identifier <NUM> may also cluster alerts <NUM> based on alert association graph <NUM>. <FIG> is described as follows with regard to an association graph example. <FIG> shows a flowchart <NUM> for generating an alert association graph and clustering alerts based on the alert association graph, according to an example embodiment. In an embodiment, steps of flowchart <NUM> may be implemented by alert association determiner <NUM> and community identifier <NUM> of <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, an alert association graph is generated, where the alert association graph indicates the alerts as nodes and the association scores as edges between corresponding pairs of alerts. For example, with reference to <FIG>, alert association determiner <NUM> may generate alert association graph <NUM> indicating alerts <NUM> as nodes and the association scores as edges between corresponding pairs of alerts of alerts <NUM>. In an embodiment, association scores can be determined by assigning pairs of alerts of alerts <NUM> a lift score, where the lift score indicates a ratio of the probability that pairs of alerts will happen together on an entity to the probability that pairs of alerts will happen separately on an entity, for example: <MAT> where A and B represent different alerts generated with respect to an entity. The probabilities may be determined by analyzing alerts <NUM> that are generated with respect to a set of entities.

In step <NUM>, the alert association graph is filtered by removing edges between corresponding pairs of alerts from the alert association graph that have co-occurrence scores below a first threshold. For example, with reference to <FIG>, alert association determiner <NUM> may filter alert association graph <NUM> by removing edges from alert association graph <NUM> that have co-occurrence scores with a predetermined relationship with a threshold value, such as the score being below the threshold value. In an embodiment, alert association determiner <NUM> may calculate the number of instances that a pair of alerts connected by an edge in alert association graph <NUM> are seen co-occurring (i.e., occurring in a same entity within a same timeframe) in alerts <NUM>. If below a threshold (e.g., <NUM> alert co-occurrences), for example, then the edge between the pair of alerts is removed. A pair of alerts with a co-occurrence score below the threshold occurring close in time in an entity may be merely coincidentally. Removal of an edge from alert association graph <NUM> prevents an association between a pair of alerts, whose connection is merely coincidental, from being used in forming security incident model <NUM>.

In an embodiment, alert association determiner <NUM> may further filter alert association graph <NUM> by uniting nodes in alert association graph <NUM> with edges between them that have co-occurrence scores above a threshold. For example, if an edge between two nodes representing a pair of alerts has an edge with a co-occurrence score above a threshold (e.g., <NUM> observed co-occurrences of the alerts), the nodes may be combined in the graph to form a single node. It may be well established that pairs of alerts with a co-occurrence score above the threshold are associated and no further analysis is needed to determine if the pair of alerts belong to a security incident. These thresholds may be set by analyzing a history of alerts existing on a cloud service, such as alert logs generated by individual computing devices and/or servers connected to a cloud or environment <NUM> or through logs aggregating a history of alerts across multiple computing devices and/or servers connected to the cloud or environment <NUM>.

In step <NUM>, the alerts are clustered into the clusters based on the filtered alert association graph. For example, with reference to <FIG>, community identifier <NUM> clusters alerts <NUM> into the clusters based on filtered alert association graph <NUM>. To help further illustrate, community identifier <NUM> may extract a list of communities from alert association graph <NUM>. In an embodiment, community identifier <NUM> may extract a list of sets of nodes, each node set intersecting within itself (its own nodes connected by edges) but not intersecting with others of the sets of nodes (unconnected with others of the node sets), such that each set is considered a community. To perform this clustering, community identifier <NUM> may use a community detection algorithm that is sensitive to edge weights (such as the Louvain method, etc.) or other clustering algorithm or technique.

<FIG> will now be described to provide additional detail for generating security incident model <NUM>. <FIG> shows a flowchart <NUM> for forming a security incident model that defines sequences of alerts corresponding to security incidents, according to an example embodiment. In an embodiment, steps of flowchart <NUM> may be implemented by security incident model generator <NUM> of <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, for each cluster of the clusters, dependencies are determined between alerts of the cluster. For example, with reference to <FIG>, security incident model generator <NUM> determines dependencies between alerts of a cluster for each cluster indicated in list of clusters <NUM> received from community identifier <NUM>. In an embodiment, security incident model generator <NUM> may determine dependencies between alerts of a cluster using conditional probabilities and generate a skeleton of a graph (e.g., a directed acyclic graph (DAG)) based on the conditional probabilities, where nodes indicate the alerts of the cluster, edges between nodes indicate conditional dependencies (i.e., a pair of alerts that are directly connected and their connection cannot be explained through any other alerts in the graph), and nodes that are not connected represent alerts that are conditionally independent (i.e., pair of alerts are not directly connected) from each other. The graph may fulfill the conditional independence property. This may be accomplished using a casual discovery algorithm (e.g., PC algorithm).

In step <NUM>, for each cluster of the clusters, the alerts of the cluster are oriented based on the dependencies to generate a model portion corresponding to the cluster. For example, with reference to <FIG>, security incident model generator <NUM> orients alerts of a cluster based on the dependencies to generate a model portion corresponding to the cluster for each cluster indicated in list of clusters <NUM>.

Continuing with the example discussed in step <NUM> of <FIG>, security incident model generator <NUM> may orient the edges of the graph generated in step <NUM> based on kill-chain position information. For example, if kill-chain position information is available, then edges in the graph are oriented according to kill-chain precedence. Additionally, the edges of the graph generated in step <NUM> may be oriented based on temporal relation information between alerts. For example, if there is a strict temporal relation between alerts (i.e., alert A is always seen coming before alert B and the time difference between the alerts is shorter than random), then the edges of the graph are oriented accordingly (i.e., alert A → alert B). Further, the edges of the graph generated in step <NUM> may be oriented based on a collider. For example, considering a group of alerts connected as such: A-C-B, if alert A and alert B are independent, but conditionally dependent given alert C, then alert C is a collider and both alert A and alert B are related to alert C. In this case, the graph may be oriented in the following manner (with no path between alert A and alert B): A→C←B or A←C→B.

In step <NUM>, the model portions are aggregated to form the security incident model. For example, with reference to <FIG>, security incident model generator <NUM> may aggregate all the model portions generated for the clusters indicated on list of clusters <NUM> to form security incident model <NUM>. After aggregation, any alerts connected in a path in security incident model <NUM> indicates a single security incident.

For instance, <FIG> shows a flowchart <NUM> for identifying alerts as a security incident using a security incident model, according to an example embodiment. In an embodiment, steps of flowchart <NUM> may be implemented by alert incident identifier <NUM> of <FIG>. Other structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following discussion regarding flowchart <NUM>.

Flowchart <NUM> begins with step <NUM>. In step <NUM>, a set of additional alerts are received from a second alert generator. For example, with reference to <FIG>, alert incident identifier <NUM> receives alerts <NUM> from a second alert generator (e.g., security management system <NUM> and/or resources 106A, 106B, 106C, 106D in <FIG>).

In step <NUM>, a match between the additional alerts and a sequence of alerts in the security incident model is determined. For example, with reference to <FIG>, alert incident identifier <NUM> may determine a match between alerts <NUM> and a sequence of alerts of alerts <NUM> defined in security incident model <NUM>. In an embodiment, alert incident identifier <NUM> applies alerts <NUM> to security incident model <NUM> and receives an indication <NUM> from security incident model <NUM> that alerts <NUM> or a portion of alerts <NUM> matches one or more sequence of alerts of alerts <NUM> defined in security incident model <NUM>. For illustration purposes, security incident model <NUM> is shown to be deployed in security incident model generator <NUM> but may be deployed separately from security incident model generator <NUM>, including being deployed in alert incident identifier <NUM>.

In step <NUM>, the additional alerts are identified as a security incident corresponding to the sequence of alerts in the security incident model. For example, with reference to <FIG>, alert incident identifier <NUM> may identify alerts <NUM> as a security incident corresponding to the sequence of alerts of alerts <NUM> in security incident model <NUM>. In an embodiment, based on the matching of alerts <NUM> or a portion of alerts <NUM> to one or more sequence of alerts of alerts <NUM>, alert incident identifier <NUM> may identify alerts <NUM> or a portion of alerts <NUM> as being related to security incidents corresponding to one or more sequence of alerts of alerts <NUM> defined in security incident model <NUM>.

In step <NUM>, a notification of the security incident is provided to the second alert generator. For example, with reference to <FIG>, alert incident identifier <NUM> may provide notification <NUM> of the security incident to the second alert generator (e.g., security management system <NUM> and/or resources 106A, 106B, 106C, 106D in <FIG>) and/or a system administrator.

Step <NUM> is described in further detail with reference to <FIG>. For instance, <FIG> shows computing device <NUM>, which may be used by a system administrator in charge of managing and/or monitoring the security of any of resources in 106A, 106B, 106C, and 106D in environment <NUM> in <FIG>. In this example, computing device <NUM> may contain a display <NUM>, which may be any suitable display, such as a liquid crystal display, cathode ray tube display, light-emitting diode display, or any other type of display connectable to computing device <NUM>. Display <NUM> may be external to or incorporated in computing device <NUM>. Display <NUM> may contain a user interface <NUM> (e.g., a graphical user interface) that displays, among other things, information to a system administrator regarding the security of any of resources in 106A, 106B, 106C, and 106D in environment <NUM>. In an embodiment, notification <NUM> may be displayed on user interface <NUM> of computing device <NUM>. Computing device <NUM> may also include other peripheral output devices (not shown) such as speakers and printers. In another embodiment, incident indication may be transmitted to any such peripheral device attached to computing device <NUM>.

Notification <NUM> alerts of security incident identified using security incident model <NUM> of <FIG> may be displayed to a user of computing device <NUM>. Notification <NUM> may also include information helpful to the user of computing device <NUM> in investigating an attack. For example, notification <NUM> indicating such information, such as identifying a resource that was attacked, a description of attack, a level of seriousness of attack, a time of detection, any action taken to address an attack, remediation steps, etc., may be displayed to the user of computing device <NUM>.

Security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> may be implemented in hardware, or hardware combined with one or both of software and/or firmware. For example, security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium. In another embodiment, security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> may also be implemented in hardware that operates software as a service (SaaS) or platform as a service (PaaS). Alternatively, security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> may be implemented as hardware logic/electrical circuitry.

For instance, in an embodiment, one or more, in any combination, of security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> may be implemented together in a system on a chip (SoC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

<FIG> depicts an exemplary implementation of a computing device <NUM> in which embodiments may be implemented. For example, components of system <NUM> and system <NUM> may each be implemented in one or more computing devices similar to computing device <NUM> in stationary or mobile computer embodiments, including one or more features of computing device <NUM> and/or alternative features. The description of computing device <NUM> provided herein is provided for purposes of illustration, and is not intended to be limiting. Embodiments may be implemented in further types of computer systems, as would be known to persons skilled in the relevant art(s).

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include operating system <NUM>, one or more application programs <NUM>, other programs <NUM>, and program data <NUM>. Application programs <NUM> or other programs <NUM> may include, for example, computer program logic (e.g., computer program code or instructions) for implementing security incident inference system <NUM>, security management system <NUM>, alert association determiner <NUM>, community identifier <NUM>, security incident model generator <NUM>, alert incident identifier <NUM>, flowchart <NUM>, flowchart <NUM>, flowchart <NUM>, and/or flowchart <NUM> (including any suitable step of flowcharts <NUM>, <NUM>, <NUM>, and <NUM>), and/or further embodiments described herein.

Display screen <NUM>, and/or any other peripheral output devices (not shown) may be used for implementing user interface <NUM>, and/or any further embodiments described herein.

Claim 1:
A computing device (<NUM>), comprising:
one or more processors (<NUM>); and
one or more memory devices (<NUM>) that store executable computer program logic (<NUM>) for execution by the one or more processors (<NUM>), the executable computer program logic (<NUM>) comprising:
an alert association determiner (<NUM>) configured to
receive alerts generated with respect to a set of entities by a first alert generator, and
calculate association scores for pairs of the alerts, each association score indicating a strength of association between a pair of alerts;
a community identifier (<NUM>) configured to cluster the alerts into clusters based on the association scores; and
a security incident model generator (<NUM>) configured to form a security incident model, based on the clusters, that defines sequences of alerts corresponding to security incidents.