Patent Description:
In order to maintain a secure network, an organization may establish a Security Operations Center (SOC). An SOC employs people, processes, and technology to continuously monitor and improve the organization's security while preventing, detecting, analyzing, and responding to cybersecurity incidents.

A common technology an SOC will employ is a SIEM tool (Security Information and Event Management). Such tools will provide security alerts generated by applications and network hardware that are deployed within the organization. The SOC will investigate the alerts and take appropriate action to mitigate potential threats.

Rather, this background is only provided to illustrate one exemplary technology area where some embodiments describe herein may be practiced.

<CIT> relates to techniques for detecting security incidents based on low confidence security events. A security management server aggregates a collection of security events received from logs from one or more devices. The security management server evaluates the collection of security events based on a confidence score assigned to each distinct type of security event. Each confidence score indicates a likelihood that a security incident has occurred. The security management server determines, based on the confidence scores, at least one threshold for determining when to report an occurrence of a security incident from the collection of security events. Upon determining that at least one security event of the collection has crossed the at least one threshold, the security management server reports the occurrence of the security incident to an analyst.

It is the object of the present invention to provide an improved method for providing likelihood validity assessments for security incident alerts.

The principles described herein relate to the providing of a list of new security alerts that each include a likelihood of being a valid security incident. In accordance with the method, the system accesses a labelled set of previous security incident alerts generated within a network environment controlled by an organization. Each security incident alert of the labelled set are labelled by the organization with a validity assessment of the respective security incident alert. For example, the security incident alert may be labelled as a true positive, or a false positive. Then, the system trains an assessment model with the accessed labelled set to configure the assessment model to perform a likelihood validity assessment for future security incident alerts generated as a result of security incidents within the network environment. The likelihood validity assessment includes an estimate of a validity of the respective security incident and a likelihood level of the estimate.

During the inference phase, the system predicts a likelihood validity assessment for future security incident alerts that arise from within the network environment. For example, in response to detecting that a respective security incident alert was generated within the network environment, the system uses the trained assessment model to perform the likelihood validity assessment on the respective security incident alert. As an example, the system could indicate that there is a certain probability of the alert being of a true positive security incident alert that represents a true security issue. The system then causes the multiple likelihood validity assessments to be reported to the organization.

This allows the entities within the organization to be able to quickly narrow in on security incident alerts that are most likely to be reflective of actual security problems. Therefore, the organization can take proper steps to remedy the security problem. In one embodiment, the list is provided as a sorted list that is sorted by the likelihood of the security incident being a true positive. Alternatively, or in addition, the sorting could take into account a severity level. Thus, the most severe and the most likely true security alerts will be surfaced to the top of the organization's attention, allowing for rapid remediation of the most urgent security problems within the organization.

<FIG> illustrates a representation of an organization <NUM>, which represents an example of an organization in which various security incidents might occur, and which includes a variety of different asset types. Examples of organizations include any organization that has interconnected computing systems including, but not limited to, corporations, institutions, universities, businesses, departments, buildings, and so forth. However, the principles described herein are not limited to any particular type of organization.

When a security incident occurs, there may be one or more assets of potentially different types that are related to the security incident. As an example, a particular security incident might occur when a particular user operating on a particular machine attempts to access a particular file. Thus, that particular user, machine and file are related to the security incident.

The illustrated environment <NUM> includes four different types of assets including resources <NUM>, files <NUM>, users <NUM> and machines <NUM>. However, the types and variety of assets may vary from organization to organization, as represented by the ellipsis <NUM>. Even within a single organization, the types of resources may change over time, as also represented by the ellipsis <NUM>. Accordingly, the enumeration of machines, files, resources, and users should be viewed as a mere example of the assets within an organization.

The resources <NUM> includes a resource <NUM> amongst potentially others as represented by the ellipsis <NUM>. The files <NUM> includes a file <NUM> amongst potentially others as represented by the ellipsis <NUM>. The users <NUM> includes a user <NUM> amongst potentially others as represented by the ellipsis <NUM>. The machines <NUM> includes a machine <NUM> amongst potentially others as represented by the ellipsis <NUM>. The ellipses <NUM>, <NUM>, <NUM> and <NUM> represent that the principles described herein are applicable regardless of how many assets of each type are present within an organization The ellipses <NUM>, <NUM>, <NUM> and <NUM> also represent that the number of each type of asset may even dynamically change over time. As an example, the users within an organization may change over time as new people join the organization.

An organization can be attacked through various types of network security breaches. Thus, organizations typically put in place various protective measures in order to guard against such network security incidents. Those protective measures begin by accurately detecting security incidents in the first place. Accordingly, in addition to assets, organizational networks also include various sensors that aim to detect behaviors or actions that are potentially indicative of a security threat.

<FIG> illustrates a representation of the organization <NUM> of <FIG> with protective measures in place. While the assets <NUM>, <NUM><NUM>, <NUM> and <NUM> are still present within the organization <NUM>, these assets are not shown in <FIG> in order to allow the focus of <FIG> to be on the protective measures of the organization <NUM>.

In particular, in <FIG>, the organization <NUM> is illustrated as including sensors <NUM> that detect security incidents, a logger <NUM> that reports respective security incident alerts to a log <NUM>, and a security operations center <NUM>. The sensors <NUM> are illustrated as including three sensors <NUM>, <NUM> and <NUM>. However, the ellipsis <NUM> represents that the organization can include any number of sensors that can detect potential security incidents. The sensors <NUM> may be distributed throughout the organization in order to detect security incidents by locale. Alternatively, or in addition, the sensors <NUM> may specialize in detecting particular types of security incidents.

The potential security incidents detected by the sensors <NUM>, <NUM> and <NUM> are reported into the log <NUM> via, for example, a logger component <NUM>. The log <NUM> is illustrated as including four security incident alerts <NUM> through <NUM>. However, the ellipsis <NUM> represents that there may be any number of security incident alerts within the log <NUM>. Over time, new security incident alerts will be added to the log <NUM> and potentially stale security incident alerts may be deleted from the log <NUM>.

The security operations center <NUM> monitors the log <NUM> by reading security incident alerts and making those alerts visible to artificial or human intelligence. The artificial or human intelligence can then evaluate whether the security incident alert reflects a real security incident, whether that security incident is significant, and what remedy (if any) should be taken in order to neutralize or ameliorate the effect of this or similar security incidents. In an example, one or more Information Technology (IT) representatives of the organization could staff the security operations center <NUM>. Artificial or human intelligence can also label the security incident alert with additional data, such as whether the security incident alert was a false positive in that there is no underlying security incident, or a true positive in that there was an underlying security incident. Alternatively, the artificial or human intelligence could label the security incident alert as a benign positive in that the security incident alert was caused by controlled testing of the protective measures of the organization's network.

The logger <NUM>, the log <NUM>, and the security operations center <NUM> are illustrated as being within the organization <NUM>. However, the logger <NUM> and the log <NUM> may alternatively be implemented external to the organization via perhaps a cloud service. Furthermore, while the security operations center <NUM> may be implemented internal to the organization, all or some of the functionality of the security operations center <NUM> may be implemented within a cloud computing environment. <FIG> schematically illustrates a security incident alert data structure <NUM>. The security incident alert data structure <NUM> is an example of how each of the security incident alerts <NUM> through <NUM> of the log <NUM> in <FIG> may be structured. The security incident alert data structure <NUM> includes various fields that represent features of the security incident alert <NUM>. For instance, the security incident alert data structure <NUM> includes an incident type <NUM>, a product identifier <NUM>, a severity level <NUM>, related entities <NUM>, an alert validity <NUM>, a time <NUM>, amongst potentially other features as represented by the ellipsis <NUM>.

The alert type <NUM> represents an incident type. As an example only, the alert type <NUM> might be unusual behavior from privileged user accounts, unauthorized insiders trying to access servers and data, anomalous outbound network traffic, traffic sent to or from unknown locations, excessive consumption of resources, unapproved changes in configuration, hidden files, abnormal browsing activity, suspicious registry entries and so forth. The product identifier <NUM> identifies the product that generated the alert. The severity level <NUM> indicates an estimated severity of the security incident (e.g., severe, moderate, minor).

The related entities <NUM> includes any organizational assets that relate to the security incident. For example, the assets <NUM>, <NUM>, <NUM> and <NUM> of <FIG> could be related to the security incident. As an example, if the security incident occurred due to user <NUM> using machine <NUM> to access resource <NUM>, then that user, machine and resource may be identified as related entities of the security incident. In <FIG>, the entities field <NUM> includes entity field <NUM> and entity field <NUM>. However, the ellipsis <NUM> represents that there may be any number of entities identified as being related to the security incident.

The validity field <NUM> identifies an estimated validity of the security incident alert. As an example, the validity could be expressed as a "true positive" if the underlying security incident is estimated to be real, a "false positive" if the alert is estimated to not really reflect an actual security incident, or perhaps "benign positive" if the alert is based on a real security incident that occurred as a result of controlled testing of the protective measures within the organization. As an example, skilled agents of the organization could use the security operations center <NUM> to attach validity labels to the security incidents.

In accordance with the principles described herein, security incident alerts in which agents of the organization have labelled the validity of the alert will be used as training data to train models that aim to automatically estimate validity data for future security incident alerts. Thus, the validity field <NUM> could also represent a validity estimation made by such a trained model. The validity data could also include a likelihood indicator that can be expressed qualitatively (e.g., "highly likely", "moderately likely", and so forth) or quantitatively by percentage for example. As an example, a particular security incident alert might be given a <NUM> percent chance of being a true positive.

Finishing the example of <FIG>, the security incident alert data structure <NUM> also includes a time <NUM> at which the security incident took place, the time that the security incident alert was created and/or the time that the security incident alert was recorded in the log. The ellipsis <NUM> represents that the security incident alert data structure could include any number, type, and variety of fields representing features of the security incident alert.

<FIG> illustrates a flowchart of a method <NUM> for training a machine-learned model to provide likelihood validity assessments for new security incident alerts generated within an organization.

<FIG> each relate to this training phase. After the discussion of the training phase with respect to <FIG>, an inference phrase will be described with respect to <FIG> and <FIG> in which the trained assessment model is put to use on live data in the form of subsequently generated security incident alerts to generate likelihood validity assessments for those subsequent alerts.

Referring to <FIG>, the training phase involves first accessing a labelled set of previous security incident alerts generated within a network environment controlled by an organization (act <NUM>). For example, referring to <FIG> and <FIG>, the organization could be the organization <NUM>, and the network controlled by that organization <NUM> could be the network that includes the assets <NUM>, <NUM>, <NUM>, <NUM> and <NUM> of <FIG>, and that includes the protective measures of <FIG>. In this case, the labelled set of previous security incident alerts could be acquired from the log <NUM>. That is, each of the security incident alerts in the labelled set is labelled by the organization <NUM> (via the security operations center <NUM>) with a validity assessment. In the example of <FIG>, each of the security incident alert data structures <NUM> for each of the labelled set of security incident alerts includes a populated validity field <NUM>.

Referring to <FIG>, the assessment model is then trained with the labelled set of previous security incident alerts (act <NUM>). <FIG> illustrates an environment <NUM> in which the assessment model is trained. In <FIG>, the labelled set <NUM> of previous security incident alerts <NUM> is provided (as represented by arrow <NUM>) to a model constructor component <NUM>. The model constructor component <NUM> may be structured as described below for the executable component <NUM> of <FIG>. The model constructor component <NUM> builds (as represented by arrow <NUM>) the assessment model <NUM> such that the assessment model <NUM> is configured to perform a likelihood validity assessment for future security incident alerts generated as a result of security incidents within the network environment of the organization. This likelihood validity assessment means that the assessment model <NUM> will, in the inference phase, populate the validity field (e.g., validity field <NUM>) of the respective future security incident alert data structure <NUM>.

<FIG> illustrates a method <NUM> for training an assessment model, and represents an example of the act <NUM> of training the assessment model of <FIG>. In accordance with the principles described herein, the trained assessment model itself includes two stages of models - an entity model and an incident model. For example, <FIG> illustrates a two-stage assessment model <NUM> that includes an entity model <NUM> and an incident model <NUM>. The trained assessment model <NUM> is an example of the assessment model <NUM> of <FIG>. The method <NUM> for training the two-staged assessment model will now be described with respect to the two-staged assessment model <NUM> of <FIG>.

The method <NUM> for training the two-staged assessment model includes formulating an entity model (act <NUM>). An example of this entity model is the entity model <NUM> of the assessment model <NUM> of <FIG>. The model constructor identifies entities within the labelled set of security incident alerts (act <NUM>). For example, the model constructor could read the entities field <NUM> of each of the security incident alerts in order to gather a list of entities for each of multiple (and potentially all) of the labelled security incident alert in the labelled set of security incident alerts. As an example, for each of the labelled set of security incident alerts, the model constructor could determine which resources, files, users, accounts, and machines are related to the respective labelled security incident alert. As an example, in <FIG>, the security incident alert <NUM> includes entities <NUM> and <NUM>.

Then, for each of one or more of the entities, the model constructor identifies one or more features of the identified one or more entities (act <NUM>). A feature of an entity could be, for example, a proportion of security incident alerts that have the identified entity having a particular validity assessment. As an example, there could be a particular user related to a security incident alert that repeatedly performs activities that result in a false positive security incident alert. Thus, the percentage false positive for that user could be a feature of that user entity. As another example, there could be a particular machine related to a security incident alert that is particularly subject to cyberattacks (e.g., a firewall machine) and thus the percentage of true positives for alerts related to that machine is high. Thus, the percentage true positive for that machine could be a feature for that machine entity. Another example of a feature is the number of times an entity appears (in a particular time window) as a related entity within security incident alerts.

These identified features of the entities are used to train the entity model (act <NUM>). The entity model could be as complex as a deep neural network. However, because the number of features here may be relatively small, the entity model may instead be a gradient boosted tree that receives the entity features and outputs an initial assessment of validity.

The incident model may also be formed (act <NUM>) by the model constructor. As an example, the incident model could be the incident model <NUM> of <FIG>. The incident model may be a neural network. However, because the number of features of a security incident alert may be quite small, the incident model may instead be a gradient boosted tree.

For each of multiple of the labelled set of previous security incident alerts, the model constructor performs the content of box <NUM>. That is, the model constructor uses the initial validity assessment for one or more of the entities of security incident alert as an actual feature in the incident model (act 621A). As an example, the incident might have a feature that is the highest initial assessment of validity generated by the entity model for all of the related entities of the incident alert.

The constructor also identifies one or more other features of the security incident alert (act 621B). Examples of such other features include a severity of the security incident alert, a source type of the security incident alert, a source of the security incident alert, and so forth.

The constructor then trains the incident model using the identified one or more features of the respective security incident alert and including the initial assessment of validity as one or more additional features (act 621C). The trained incident model then is configured to output a final likelihood validity assessment associated with future security incident alerts.

By separating the model into two phases (an entity model phase and an incident model phase), accuracy of the likelihood validity assessment is improved. By training on a significant number of labelled security incident alerts, the assessment model becomes highly capable of predicting a likelihood that a future security incident alert is a true positive. Furthermore, the model is capable of generating the likelihood validity assessment substantially immediately when the security incident alert is generated in the first place. Thus, urgent and likely true positive security incident alerts can be quickly surfaced to the attention of the security operations center.

<FIG> illustrates a flowchart of a method <NUM> for inferring a likelihood validity assessment for subsequent (after training) security incident alerts using the trained assessment model. The method <NUM> begins upon detecting a security incident alert that was generated within the network of the organization (act <NUM>), whereupon the trained assessment model is used to perform the likelihood validity assessment on the security incident alert.

To do this, the related entity features of the security incident alert are extracted (act <NUM>). That is, the constituent related entities are read from the alert, and the features of those entities are identified. The features of the entities are then fed to the entity model (act <NUM>). As an example, the features of entity <NUM> of the alert <NUM> may be fed (as represented by arrow <NUM>) to the entity model <NUM> resulting in one initial validity assessment <NUM>. Likewise, the features of the entity <NUM> of the alert <NUM> may be fed (as represented by arrow <NUM>) to the entity model <NUM> resulting in another initial validity assessment <NUM>.

Referring to <FIG>, the initial likelihood validity assessments are then provided to the incident model (act <NUM>). As an example, perhaps only the highest likelihood validity assessment is provided to the incident model to be used as a feature of the security incident alert. In addition, one or more other features of the security incident alert itself are identified (act <NUM>). The features of the security incident alert are then fed (as represented by arrows <NUM> and <NUM> in <FIG>) to the incident model (act <NUM>). The incident model then generates a likelihood validity assessment (act <NUM>), which can then be populated into the security incident alert data structure in the validity field (act <NUM>).

This process may be repeated as each future security incident is received. The alert is reported to the organization (act <NUM>) perhaps as often as each time a security incident alert is assessed. In addition, the list of security incident alerts can be re-sorted each time a new security incident alert is assessed. As an example, the incident alert can be sorted by likelihood of being a true positive alone. Alternatively, or in addition, the list could be sorted by a weighted combination of the likelihood of the alert being a true positive along with the severity of the alert. And this sorting can be updated frequently with the assessment of each new security incident alerts. Thus, urgent security incident alerts may be quickly inserted into the top of the list for the organization to address, without having to wait for a skilled user to make a manual assessment of the urgency of each security incident alert. Thus, urgent security incidents are likely to be addressed much faster. Because the principles described herein are performed in the context of a computing system, some introductory discussion of a computing system will be described with respect to <FIG>.

As illustrated in <FIG>, in its most basic configuration, a computing system <NUM> includes at least one hardware processing unit <NUM> and memory <NUM>. The processing unit <NUM> includes a general-purpose processor. Although not required, the processing unit <NUM> may also include a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. In one embodiment, the memory <NUM> includes a physical system memory. That physical system memory may be volatile, non-volatile, or some combination of the two. In a second embodiment, the memory is non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

The computing system <NUM> also has thereon multiple structures often referred to as an "executable component". For instance, the memory <NUM> of the computing system <NUM> is illustrated as including executable component <NUM>. The term "executable component" is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods (and so forth) that may be executed on the computing system. Such an executable component exists in the heap of a computing system, in computer-readable storage media, or a combination.

One of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term "executable component".

While not all computing systems require a user interface, in some embodiments, the computing system <NUM> includes a user interface system <NUM> for use in interfacing with a user. The user interface system <NUM> may include output mechanisms 912A as well as input mechanisms 912B. The principles described herein are not limited to the precise output mechanisms 912A or input mechanisms 912B as such will depend on the nature of the device. However, output mechanisms 912A might include, for instance, speakers, displays, tactile output, virtual or augmented reality, holograms and so forth. Examples of input mechanisms 912B might include, for instance, microphones, touchscreens, virtual or augmented reality, holograms, cameras, keyboards, mouse or other pointer input, sensors of any type, and so forth.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, datacenters, wearables (such as glasses) and the like.

For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in differing order. Furthermore, the outlined operations are only provided as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without detracting from the essence of the disclosed embodiments.

Claim 1:
A method for providing likelihood validity assessments for security incident alerts, the method comprising:
accessing (<NUM>) a labelled set of previous security incident alerts generated within a network environment controlled by an organization, each security incident alert of the labelled set of previous security incident alerts being labelled by the organization with a validity assessment of the respective security incident alert;
training (<NUM>) an assessment model with the accessed labelled set to configure the assessment model to perform a likelihood validity assessment for future security incident alerts generated as a result of security incidents within the network environment;
for each of a plurality of security incident alerts arising from within the network environment after the training: detecting (<NUM>) a respective security incident alert that was generated within the network environment; and in response to the detection, using the trained assessment model to perform the likelihood validity assessment on the respective security incident alert, the likelihood validity assessment include an estimate of a validity of a respective security incident and a likelihood level of the estimate; and
causing (<NUM>) the plurality of likelihood validity assessments to be reported to the organization.