Real-time mitigation of unfamiliar threat scenarios

Abstract

A computing system performs real-time mitigation against unfamiliar threat scenarios by identifying specific threat scenarios for client systems that have not previously experienced a threat scenario and for which the remediation process is unknown. The computing system responds to unknown threat scenarios by generating and providing to the client system a mitigation file that includes a set of predictive mitigation processes for responding to the threat scenario. The mitigation file is generated by first generating a threat vector that identifies a plurality of different threat scenario characteristics for the specific threat scenario. Then, a classification model is applied to the threat vector to identify the set of predictive mitigation processes that are determined to be most suitable for the threat vector and that are included in the mitigation file.

Description

BACKGROUND OF THE INVENTION

[0001] Computers and computing systems impact almost every aspect of modern life. Computers are commonly involved in work, entertainment, healthcare, transportation, recreation, home management, and the like.

[0002] Certain computer functions can be enhanced by the ability of a computing system to interconnect with other computing systems via a network connection. Network connections can include, but are not limited to, connections via wired or wireless Ethernet, cellular connections, or even computer-to-computer connections via serial, parallel, USB, or other connections. These connections allow computing systems to access services at other computing systems and to receive application data from other computing systems quickly and efficiently.

[0003] The interconnection of computing systems has facilitated distributed computing systems, such as so-called "cloud" computing systems. In this description, "cloud computing" can be a system or resource for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services, etc.) that can be provisioned and released with reduced management effort or service provider interaction. Cloud models can include various characteristics (e.g., on-demand self-service, broad network access, resource pooling, rapid elasticity, measurable service, etc.), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), infrastructure as a service ("IaaS")), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.).

[0004] Cloud-based and remote service applications are prevalent. Such applications are hosted on public and private remote systems, such as clouds, and typically provide a set of network-based services to communicate back and forth with clients.

[0005] Unfortunately, the cloud and interconnection of computing systems expose computing systems to vulnerabilities and threats from malicious parties. For example, a malicious party can transmit malware code to an unsuspecting computing system, or create applications known to be executed by a computer system, but which contain hidden malware that performs adverse operations on the computing system. A malicious party also has the potential to initiate brute force attacks or DDoS (distributed denial of service) attacks on the computing system.

[0006] To address and prevent the threat scenarios described above, many organizations hire information technology (IT) experts to monitor the health of their computer systems, identify alerts associated with threat scenarios, and manage and update antivirus and anti-malware to mitigate newly developed and discovered threats. However, this type of monitoring and updating is very expensive and time-consuming. Additionally, many organizations do not have the same monitoring software and / or cannot hire full-time experts who understand all possible remediation actions available for newly developed and discovered threats. Different remediation solutions are also not always applicable to all organizations, which makes things even more complex. As a result, IT experts often rely on their own devices to search the Internet for solutions that may be applicable to address threat scenarios. However, this is a very inefficient process. In many cases, due to the existence of various computing systems and various types of possible solutions available to implement to address different threat scenarios, it is completely impractical or impossible for IT experts to even determine the best remediation process to perform on their (multiple) computing systems.

[0007] When a new and unknown threat scenario emerges, the above problems are even more evident, and no one has yet established a remediation protocol for it. In particular, IT professionals can search for a remediation protocol but cannot find any. In such a situation, it would be helpful to provide a way for IT professionals and threatened systems to understand how to respond to unknown threat scenarios.

[0008] Accordingly, there is a continuing need and expectation for identifying and providing remediation techniques for identifying and applying a remediation process to address threat scenarios, particularly new and unknown threat scenarios.

[0009] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technical field in which some embodiments described herein may be practiced. SUMMARY OF THE INVENTION

[0010] The disclosed embodiments relate to systems, methods, and storage devices configured to facilitate real-time mitigation of unknown threat scenarios.

[0011] In some embodiments, a computing system performs real-time mitigation of unfamiliar threat scenarios by identifying a specific threat scenario for a client system that has not previously experienced a threat scenario and for which the remediation process is unknown. The computing system responds to the unknown threat scenario by generating and providing to the client system a mitigation file that includes a set of predictive mitigation processes for use in response to the threat scenario.

[0012] A mitigation file is generated by first generating a threat vector that identifies multiple different threat scenario characteristics for a specific threat scenario. Then, a classification model is applied to the threat vector to identify a set of predictive mitigation processes that are determined to be most suitable for the threat vector and are dynamically added to the mitigation file.

[0013] In some cases, the classification model includes multiple different sets of client remediation processes corresponding to different types of alerts associated with different threat scenarios, at least some of the threat scenarios in the different threat scenarios are related to a specific unknown threat scenario, and the mitigation file includes remediation processes identified as corresponding to the alert types determined to be related to the specific threat scenario.

[0014] In some cases, for each identified alert, multiple different sets of client remediation processes are generated for each type of alert among different types of alerts by: identifying multiple processes executed by corresponding multiple different client systems, the multiple processes being executed at a predetermined time and / or within a process close to the identified alert; determining which of the multiple processes are related to the identified alert based on a correlation vector of the multiple processes with the identified alert; and for each client of the multiple different client systems, creating a set of client remediation processes that includes processes determined to be related to the identified alert and executed by the client at a predetermined time period and / or within a process close to the identified alert.

[0015] In some embodiments, the mitigation file includes a non-executable list of remediation actions for addressing the threat scenario.

[0016] In alternative or additional embodiments, the mitigation file includes an executable file having executable instructions corresponding to the set of remediation processes, the executable instructions for automatically performing the remediation actions in response to running the mitigation file at a client system.

[0017] This "Summary of the Invention" is provided to introduce some concepts in a simplified form that will be further described below in the "Detailed Description". This "Summary of the Invention" is neither intended to identify key features or essential features of the claimed subject matter nor intended to be used to assist in determining the scope of the claimed subject matter.

[0018] Additional features and advantages will be set forth in the description below, and in part will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims. The features of the invention will become more fully apparent from the following description and the appended claims, or may be learned by the practice of the invention as set forth below. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] To describe the manner in which the above and other advantages and features are obtained, the subject matter briefly described above will be described in more detail by reference to specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments and are not to be considered limiting of the scope, and the embodiments will be described and explained with additional features and details by using the drawings, in which:

[0020] Figure 1 A flowchart of actions associated with the disclosed method for performing automatic generation of threat remediation through a crowdsourcing security solution is shown;

[0021] Figure 2 An exemplary computing environment including a computing system configured to implement and / or include the disclosed embodiments is shown;

[0022] Figure 3 A representation of the correlation vectors for multiple processes and their correlation with alerts is shown;

[0023] Figure 4 Shows from Figure 3 A representation of a set of remediation processes derived from the correlation vectors shown;

[0024] Figure 5 A representation of a cluster of sets of remediation processes for different clients associated with a particular alert is shown;

[0025] Figure 6 Various representations of a composite remediation file, such as a representation that can be derived from a cluster of sets of remediation processes, are shown;

[0026] Figure 7 A flowchart of actions associated with the disclosed method for facilitating real-time mitigation against unknown threat scenarios is shown;

[0027] Figure 8 A representation of threat vectors that can be used to identify different types of threats / alerts is shown; and

[0028] Figure 9 A representation of different threat classification files or groupings, which include different threats / alerts grouped based on the type of threat / alert, is shown. Detailed Description

[0029] The disclosed embodiments generally relate to systems, methods, and storage devices configured to facilitate automatic mitigation and remediation of threat scenarios based on a crowdsourcing security solution.

[0030] In some embodiments, a computing system performs real-time mitigation against unfamiliar threat scenarios by identifying a specific threat scenario for a client system that has not previously experienced the threat scenario and for which the remediation process is unknown. The computing system responds to the unknown threat scenario by generating and providing to the client system a mitigation file that includes a set of predictive remediation processes for responding to the threat scenario. The mitigation file is generated by first generating a threat vector that characterizes a plurality of different threat scenario characteristics that identify the specific threat scenario. A classification model is then applied to the threat vector to identify the set of predictive remediation processes that are determined to be most suitable for the threat vector and that are included in the mitigation file.

[0031] As used herein, the terms "mitigation" and "remediation" are used interchangeably and refer to response protocols for responding to a specific threat or alert condition. In this regard, it should be understood that a threat or alert condition may also be used interchangeably with other terms such as "threat scenario", "threat", "alert", etc.

[0032] From the disclosure provided herein, it will be appreciated that the disclosed embodiments are capable of solving the technical and practical problems associated with the mitigation of threat scenarios, including unknown threat scenarios for which a remediation protocol has not been established, by improving the way in which a computing system can apply machine learning and artificial intelligence in a manner that is impossible or at least infeasible for a human to automatically and dynamically generate a mitigation file having remediation processes that are predicted / estimated to be capable of mitigating the unknown threat scenario.

[0033] Automated Generation of Threat Remediation via Crowdsourced Security Solutions

[0034] Figure 1 Illustrated are various actions of a flowchart 100 performed by a computing system (e.g., Figure 2 the computing system 200 shown) for performing the automated generation of remediation steps via a crowdsourced security solution.

[0035] As shown, the computing system identifies a plurality of different types of alerts, where each identified alert of the plurality of different types of alerts is associated with a corresponding plurality of different client systems that each triggered or detected the identified alert (action 110). This identification of alerts can be based on various information. For example, the computing system can identify an alert by receiving / identifying the definition of the alert from an application or remote system (e.g., clients 270, 272, 274). The computing system can also automatically define an alert based on detecting an anomaly associated with a configuration file, a log file, or a measured computer health metric associated with a computer component, such as when performing automated health monitoring of various client systems.

[0036] In some cases, the identified alerts are for detected threat scenarios such as viruses, malware, DDoS, brute force attacks, unexpected changes in performance, capacity, or bandwidth, unexpected or unauthorized requests, unexpected execution, or a process being executed, etc. In some cases, the identified alerts are for processes whose association with malicious activity is uncertain, but which may be processes such as installation, update, modification, deletion, upload, download, or other processing of files, etc.

[0037] Figure 3 An example of a correlation vector 300 is shown, which in some cases is generated and used to identify processes associated with an alert, and can also be used to identify an alert from the processes being executed. The correlation vector 300 will be described in more detail below.

[0038] After identifying the alert(s), the computing system generates multiple different sets of client remediation processes (action 120) for each alert or each type of alert. This process includes various sub-steps or sub-actions, including: (1) for each identified alert or alert type, identifying the processes executed by the corresponding multiple different client systems within a predetermined time and / or process after and close to the identified alert (action 121), determining which of the multiple processes are related to the identified alert based on the correlation vector of the multiple processes with the identified alert (action 122), and for each client of the multiple different client systems, creating a set of client remediation processes that includes the processes determined to be related to the identified alert and executed by the client within a predetermined time period and / or process close to the identified alert (action 123).

[0039] The identification of the processes executed by the computing system (action 121) can include logging processes and / or accessing log files. In some cases, this can also include filtering the identified processes to identify a subset of all the processes being executed and excluding processes that are too far in time or too close in relation to the alert condition. For example, if an alert condition is detected to occur at a specific time, the identified processes can be restricted / filtered to include only a subset of the processes that occur within a predetermined time after the alert condition. The predetermined time can be a threshold time period defined by minutes, hours, days, or another duration from the occurrence of the alert condition.

[0040] Similarly, the identification process can be restricted / filtered to include only a subset of the processes executed by specific components of the computing system, and this subset of processes is determined to be close to or otherwise closely related to the alert condition (e.g., processors in the same host system, sessions run or opened by a specific application associated with the alert condition, virtual machines associated with a specific client, specific load balancers, routers, servers, services, or websites, etc.).

[0041] The action (action 122) of determining which of the multiple processes are related to the identified alert based on the correlation vectors of the multiple processes with the identified alert can involve establishing / processing correlation vectors, such as Figure 3 shown by the correlation vector 300 as shown.

[0042] Although the current embodiment only includes seven processes (i.e., processes A - G), it should be understood that in other embodiments, the correlation vector will include more processes, and based on time, components, or any other qualifier, it can include any number in the complete set of identified processes or only include a limited / filtered subset of processes (e.g., dozens, hundreds, thousands, or even more processes).

[0043] In some cases, an initial set of processes is used to help find and identify the alert condition (action 110). In other cases, the set of processes is selectively filtered based on the defined alert condition and based on only selecting processes that are determined to have occurred within a threshold time period and / or process close to the defined alert condition (substantially as described above).

[0044] In the current embodiment, the correlation vector 300 associates each identified process A - G with a corresponding distance attribute (i.e., distance attributes 1 - 4). Although only four distance attributes are shown, any number of distance attributes can be utilized to accommodate different requirements and preferences.

[0045] In some cases, the distance attribute is represented as a value (e.g., values A1 - G4), and these values include absolute values, or alternatively, these values include normalized / relative values that can be used to identify the correlation distance between the process and a specific alert or alert type. In other embodiments, the distance attribute is a value that is actually a string or other type of identifier (except numerical values), and the value is used to filter processes during the construction of the remediation process set.

[0046] In some cases, the distance attribute includes, for example, temporal proximity to an alert condition or alert trigger event, components of an execution process, networking proximity to the component(s) identified as involved in the alert condition, uniqueness, execution frequency, execution counter, known correlation between the process and the alert condition, and / or any other metric that can be used to evaluate the relative correlation between the process and a known alert condition.

[0047] Then, in some cases, the distance attribute can be normalized to identify the relative weight or distance of the corresponding process with respect to a particular alert, and thereby determine which processes may be associated with the alert condition. Alternatively or additionally, the process can be filtered by a specific identifier or threshold (e.g., values A1 - G4).

[0048] In some cases, the process of determining which processes are relevant to the identified alert (action 122) is performed to identify specific processes that the client executes when remediating the detected alert condition. These processes can be antivirus / anti - malware - based automated processes and / or processes that are manually triggered or implemented based on administrator / user actions or input commands. For example, these processes can include actions such as opening a firewall, closing a port, changing a password, shutting down a service, reinstalling or reformatting a file, quarantining a file, disabling a specific component or application, blocking traffic from a specific address, generating a notification for an administrator or third party, rebalancing network traffic, instantiating a new session or function, dispersing or recruiting new resources into a distributed network, creating a copy or backup of data, shutting down or rebooting a system / component, and / or any other process.

[0049] The sub - action of creating a set of remediation processes (action 123) and / or the action of generating multiple sets of remediation processes (action 120) can also include storing a data structure representing the set of remediation processes. An illustrative example of a set of remediation processes for the correlation vector 300 for Figure 3 is the set of remediation processes 400. As shown, the set of remediation processes 400 includes processes executed by the client 1 for alert type 1. At this point, it should be understood that alert type 1 can be any type of alert condition (e.g., detected DDoS, detected login request with unauthorized credentials, detected execution of an unknown and unexpected executable file, or any other alert condition). In some cases, multiple different sets of remediation processes associated with different alert conditions are created and stored for each of multiple different clients.

[0050] Figure 1The next action shown in the flowchart 100 is an action (action 130) in which the computing system generates a composite remediation file for each type of alert based on a correlation existing between multiple different client remediation process sets. For example, this can be done by saving a single file or a distributed file that identifies a list of one or more common remediation processes from multiple different client remediation process sets from a common alert condition and meets a generality or correlation threshold between the multiple different client remediation process sets, while deleting from the composite remediation file one or more uncommon remediation processes that do not meet the generality or correlation threshold between the different client remediation process sets.

[0051] In some cases, the process of generating the composite remediation file (action 130) includes identifying / generating a cluster of remediation process sets associated with different clients and a common alert condition. A representation of the cluster 500 of remediation process sets is as Figure 5 shown. As shown, a number of client remediation process sets (corresponding to clients 1 - 6 and n respectively) are compiled into a single table that reflects the processes determined to meet the corresponding thresholds for being selected and included in the corresponding remediation process sets of different clients. For example, Figure 4 the remediation process set 400 is shown in the top row of the cluster 500 of remediation process sets, where processes A, C, D, F, and G are marked as processes executed by client 1 in response to alert type 1. The cluster 500 of remediation process sets also includes the remediation process set of client 2 associated with the same alert type 1, where client 2 is determined to have executed processes A, C, D, F, and G, i.e., the same set of processes executed by client 1. However, clients 3, 4, 5, 6, and n have executed different sets of processes in response to the same alert, as indicated by their corresponding remediation process set indicators in the cluster.

[0052] Although only a few client remediation process sets are shown in the cluster, it should be understood that any number of client remediation process sets can be included. In fact, the more process sets used, the more accurate the final composite remediation file output may be.

[0053] In some cases, the generation (130) of the composite remediation file is based on a cluster of remediation process sets for a particular alert type that omits some of the overall identified or stored remediation process sets associated with the alert type, such as by omitting remediation process sets corresponding to clients of a non-specific type. Even more specifically, the cluster of remediation process sets can filter or include only a subset of the available remediation process sets to include only remediation process sets that are determined to be a particular type of computing system (e.g., systems with a common processing configuration, a common operating system, a common network configuration, etc.). In some cases, this can enable a target system in an alert condition to obtain a corresponding composite remediation file that is specifically tailored for and based on remediation process sets for similarly configured client systems.

[0054] Once the cluster 500 of remediation process sets is assembled / identified, the computing system may perform analysis on the various processes to determine which processes should be included in one or more composite remediation files (act 130), such as Figure 6 The composite remediation files 610, 620, 630, 640, 650 and 660. The determination is primarily based on a determination that the process meets a particular relevance threshold.

[0055] For example, in some cases, the selection of processes for a composite remediation file, such as composite remediation file 610, is based on determining that the processes to be included are performed by all clients in a cluster that have a client remediation process set. In this case, the relevance threshold is the inclusion in a cluster associated with a particular type of alert.

[0056] In other cases, the selection of processes for a composite remediation file, such as composite remediation file 620, is based on determining that the processes to be included are executed by a majority of clients in the cluster that have a client remediation process set. In this case, the relevance threshold is that the processes are associated with the majority of clients that remedy a particular alarm condition.

[0057] In other cases, the selection of processes for a composite remediation file (such as composite remediation files 630, 640, and 650) is based on a determination that the processes to be included are performed by all or most clients of the same or similar type (e.g., system type affinity). Figure 5The labels of clients 1-5 and n shown are client type identifiers, rather than just sequential quantity identifiers. Then, the processes executed by clients of types 1-2 (e.g., client 1 and client 2) will be included in the composite remediation file 630 based on client type 1-2. Similarly, the processes executed by clients of types 3-4 will be included in the composite remediation file 640, and the processes executed by clients of types 5-6 will be included in the composite remediation file 650. Although not shown, other composite remediation files for client type n will include processes A, C, D, E, G, I, and n. Similarly, although not currently shown, composite remediation files for multiple different types (more than 2 types) can be included in a single composite remediation file.

[0058] It will also be appreciated that in some cases, the composite remediation file contains a list of non-executable processes and does not include any triggers for triggering the execution of the listed processes. However, in some embodiments, alternatively or additionally, the composite remediation file contains the actual executable files for the processes to be executed by the target system and / or includes triggers for triggering the executable files available to the target system, such as when the target system loads or runs the composite remediation file. In these cases, the generation of the composite remediation file also includes the following actions: for each relevant / corresponding process in the composite file, downloading and loading the executable file and / or the trigger into the composite remediation file.

[0059] Although the currently shown composite remediation files 610, 620, 630, 640, 650, and 660 only contain several processes (i.e., 3 ≤ processes ≤ 8), it should be understood that the composite remediation file can include any number of relevant processes that are determined to be sufficiently relevant to a specific alert type and also based on client type in some embodiments. For example, the composite remediation file may only contain 1 or 2 processes, and in some cases may contain 9 or more processes.

[0060] In some embodiments, the generation of the (multiple) composite remediation file also includes receiving user input for including or excluding a specific remediation action from a composite remediation action file (or set of remediation processes or relevance vector) based on a prompt, which is triggered in response to determining that there is not enough information to determine whether a specific remediation action meets the relevance threshold between multiple different client remediation process sets or the proximity threshold of generality or relevance to a specific alert condition or system type.

[0061] As Figure 6As shown, the various composite remediation files need not be categorized or separated based on client type. Alternatively, they may be based on a threat / alert classification type(s) such as reflected by composite remediation file 670, which may include any number of related processes (as reflected by ellipsis 627). Composite remediation files may also be based on any type of classification based on client type, alert type, or other factors, as shown by ellipsis 680.

[0062] Now turn your attention to Figure 2 , Figure 2 shows how the aforementioned computing system 200 includes sufficient Figure 1 The components of the actions shown in the flowchart 100 of and other functions described herein. For example, the computing system 200 includes a threat mitigation-related data collector 210, which is specifically configured with executable code for causing the computing system 200 to collect metadata about different threat / alert types and detect threat-specific information including or used to identify different alert types. The threat mitigation-related data collector also identifies and marks processes that are determined to be executed within a specific time / proximity of a threat / alert condition.

[0063] The computing system 200 also includes a mitigation embedder 220 that is specifically configured with code for constructing a correlation vector by identifying distance attribute values of different identified processes and for embedding / inserting that information into the correlation vector to identify the relative correlation distance of the processes to a particular threat / alarm condition and to identify processes that are sufficiently close / correlated to the alarm condition to be included in the corresponding remediation process set(s).

[0064] The computing system 200 also includes a mitigation generator 230 specifically configured with code for generating clusters of remediation process sets and for filtering / selecting appropriate remediation process sets for generating composite remediation file(s), and for generating composite remediation file(s).

[0065] Computing system 200 also includes one or more processors 240, which are hardware processors for instantiating various system components (eg, 210, 220, 230) and / or for executing the above-described executable code for implementing the disclosed and claimed functionality.

[0066] The computing system 200 also includes a storage device 250, which includes a hardware storage device for storing executable code and related system components (e.g., 210, 220, 230) and for storing various correlation vectors (252), sets of remediation processes (254), and composite remediation files (256) described herein. The storage device 250 can be a local and / or remote storage device (including a distributed storage device). The storage device can also be any combination of volatile and non-volatile storage devices.

[0067] The computing system 200 is connected to various client systems (e.g., 270, 272, 274 and / or any number of other client systems) via one or more network connections, and these client systems can provide process information to the computing system 200 to generate the correlation vectors 252, sets of remediation processes 254, and composite remediation files 256, and / or can receive the composite remediation files 256 from the computing system.

[0068] The client that communicates with the computing system via the network connection 260 can also include one or more target systems that generate and send a request for a composite remediation file to the computing system, and the composite remediation file corresponds to an alert condition experienced by the target system. For example, client n (274) can be a target system that experiences an alert condition and generates a corresponding request for a composite remediation file in response to the alert condition. Such a request for a composite remediation file can specify a particular type of alert condition and (in some cases, a particular type of computing system that encounters the alert condition, such as the target system type).

[0069] In response to a request for a composite remediation file, the computing system 200 determines whether the corresponding composite remediation file exists and is accessible. Then, when it is determined that the corresponding composite remediation file exists, the computing system automatically performs one or more actions illustrated and described in the flowchart 100 of Reference Figure 1 to generate the composite remediation file. Alternatively, when it is determined that the composite remediation file has been generated and is accessible, the computing system 200 will simply identify the appropriate composite remediation file 256 from the storage device 250 and provide it to the target system (action 140). Then, the administrator can view the listed processes and determine whether to execute these processes without having to search for and determine the relevance of remediation processes that are relevant or irrelevant to the conditions and system types that the administrator is concerned about.

[0070] The newly generated composite remediation files will also be stored so that they can be accessed and be ready to be provided upon the next request. Alternatively, based on the recency of creation (e.g., within the last day, last week, last month, etc.), and / or which are predicted to be requested again within a certain immediate threshold (e.g., within the next day, next week, next month, etc.), no composite remediation files are stored, or only a subset of the generated composite remediation files are stored. One reason for not storing all composite remediation files is that they become obsolete and / or can be adjusted more precisely using more information received since the last creation so as to initiate a newly adjusted composite remediation file when a new request is received. In such a case, the various sets and clusters of remediation processes will also be refreshed and replaced on demand. Alternatively, when a request for a new composite remediation file is subsequently received, the sets and clusters of remediation processes will remain in the storage device and be simply updated (when new information is available and appropriate).

[0071] In some embodiments, the computing system 200 monitors the health of a target system (e.g., client n274), and automatically detects the alert conditions experienced by the target system and the target system type. Then, in cases where the computing system 200 does not receive a request for a composite remediation file from the target system, it automatically generates and / or provides to the target system the (multiple) composite remediation files associated with the alert condition (and system type) for manual application (e.g., when the composite remediation file contains non-executable files) and automatic application (e.g., when the composite remediation file contains executable files) in response to detecting the alert condition.

[0072] The computing system 200 can also monitor various clients to detect alert conditions so as to trigger various correlation vectors and / or the (multiple) sets and / or the (multiple) clusters of the (multiple) remediation processes, even if the composite remediation files are not fully generated. Then, the composite remediation files are generated only in response to a specific request for the composite remediation file from the target system and / or in response to detecting an alert condition at the target system. This can help reduce the overhead and cost required to frequently generate and store composite remediation files for each detected alert condition.

[0073] Real-time Mitigation of Unknown Threat Scenarios

[0074] Attention is now turned to Figure 7 , Figure 7 which shows a flowchart 700 that includes actions performed by a computing system (such as Figure 2 the computing system 200) and associated with the disclosed method for facilitating real-time mitigation of unknown threat scenarios.

[0075] As shown, the computing system first identifies a specific threat scenario for a client system that has not previously experienced a threat situation (action 710). This can include, for example, the computing system 200 monitoring one of the client systems and detecting an alarm triggered at the client system or an irregular situation experienced by the client system. This can include real-time inspection of log files and / or tracking processes performed at the client system. The identification of the threat situation can also include the computing system 200 receiving a request for a composite remediation file (as described above) or any type of mitigation file for addressing the threat scenario. In some cases, the request is automatically generated by the client system that detects the abnormal situation. In other cases, the request is generated at the interface in response to user input (e.g., an administrator submits a request).

[0076] Identification of threat scenarios may also include any of the aforementioned techniques for identifying alerts (as described with reference to action 110). For example, a computing system may identify threat scenarios based on detecting anomalies associated with configuration files, log files, or measured computer health metrics associated with computer components, such as when performing automatic health monitoring of various client systems. In some cases, the identified threat scenarios are based on detecting files or behaviors similar to profiles associated with viruses, malware, DDoS, brute force attacks, unexpected changes in performance, capacity, or bandwidth, unexpected or unauthorized requests, unexpected executions, or processes being executed, etc. In some cases, the identified threat scenarios may also include scenarios that do not necessarily match malicious behavior or patterns, but may be such as the installation, update, modification, deletion, upload, download, or other processing of a file.

[0077] Next, the computing system generates a threat vector that identifies a plurality of different threat scenario characteristics for the detected particular threat scenario (act 720). The threat vector is generated by the threat embedder / classifier 280 (e.g., Figure 2 ) is generated based on information provided to the computing system (automatically or in response to a request for such information) by (multiple) client systems experiencing the threat scenario and / or obtained by the computing system from a third-party system.

[0078] In some cases, a threat vector identifies a plurality of different characteristics that are used to detect a relative relevance or similarity distance measure between a particular threat and one or more similar threat scenarios (some of which may be known and associated with known remediation protocols and some of which may be unknown or have no known remediation protocols). In this regard, different characteristics of the distance attribute may be considered to help the computing system determine the distance or similarity between various threats.

[0079] Figure 8An example of a threat vector 800 is shown, which includes one or more threats or threat types (including one or more processes or conditions) and various distance attributes / characteristics associated with the corresponding threat or threat type. In some cases, the threat vector will consist of only a single threat. In other instances, as shown, the threat vector 800 will include multiple different threats that can be of the same type or different types. In the current representation, the various threat / alert types (e.g., AG, n) are threat scenarios corresponding to one or more different defined sets of processes or conditions associated with the alerts / threats identified during actions 110 and / or 710.

[0080] The various distance attributes are defined characteristics associated with the identified threat scenarios. Non-limiting examples of distance attribute types include such things as the resources / components involved, the detection component, severity, threat-specific information, the mitigation steps taken, the timestamp, and other attributes (such as those referred to Figure 3 to). Some specific examples of distance attributes include the number of user connection attempts, the number of information requests, requests to install or run an executable file, requests to download or upload a file, the number of requests from a single user, or accounts from multiple different locations or from new or unknown devices.

[0081] In some cases, a single threat vector is generated for all known threat scenarios. In other cases, different threat vectors are generated for different threat scenarios, each threat vector based on any combination of location, system type, system configuration, or other differentiating system characteristics.

[0082] Once the threat vector is generated, the computing system applies a classification model (e.g., Figures 3 to 6 the data structure described in) to the threat vector to identify the set of predictive mitigation processes (action 730) determined to be the most appropriate threat vector. This action (action 730) involves multiple processes, such as the classification of the threat scenario and the identification of mitigation files, which can include the above-mentioned set of remediation processes and / or composite remediation files and can be used to mitigate the identified threat scenario(s).

[0083] For example, the computing system applies machine learning / artificial intelligence with a threat embedder / classifier 280 to the threat vector in order to identify the category of the threat scenario and can be used to match an unknown threat scenario (or a threat scenario with no known remediation) with a known threat scenario (or a threat scenario with a known set of remediation processes or composite remediation file). Then, when an unknown threat scenario similar to a known threat scenario with a known mitigation file (e.g., a set of remediation processes and / or composite remediation file) is detected, the mitigation file can be provided to the target client system (action 740).

[0084] The machine learning applied by threat embedder / classifier 280 determines the relative similarity of different threat scenarios based on the distance / similarity of distance attributes. The similarity threshold used to determine whether threat scenarios are similar can be adjusted via user input and will control the final grouping / classification of different threats. In some embodiments, threat embedder / classifier 280 groups various threat scenarios into multiple different groups / files / data structures, which include at least one group that has both known and unknown threat scenarios (where a known threat scenario is a threat or alert with a known set of remediation processes and / or a composite remediation file, and where an unknown threat scenario is a threat or alert without a known set of remediation processes and / or a composite remediation file).

[0085] Figure 9 Several examples of grouping different types of threat scenarios are shown, where groupings 910, 920, and 930 all have mutually exclusive sets of threats / alerts associated with the different groupings. In other cases, as shown by groupings 940 and 910, two different groupings can share at least one common threat / alert (e.g., B).

[0086] In other embodiments, a single classified grouping 920 can contain multiple sub-groupings of different similar / undistinguishable alert types.

[0087] Once the different groupings / classifications of threat scenarios occur, these groupings can be saved, such as in a threat classification file (257) stored in storage device 250 of computing system 200, as Figure 2 shown.

[0088] Threat embedder / classifier 280 can also store a mitigation file 258 in storage device 250, and this mitigation file 258 is provided to different client systems.

[0089] As described above, mitigation file 258 is a list of mitigation processes for mitigating / responding to a specific threat scenario associated with (multiple) mitigation file 258.

[0090] Computing system 200 identifies / constructs mitigation file (258) from Figure 4 and Figure 5 the set of remediation processes and / or composite remediation file described. In some cases, the mitigation file includes a set of remediation processes associated with known alerts according to the classification grouping described in Figure 9 and also matching unknown threats.

[0091] In other cases, the mitigation file includes a composite remediation file associated with known alerts according to the classification grouping described in Figure 9 and also matching unknown threats.

[0092] In some embodiments, the mitigation file includes a non-executable list of remediation actions for addressing threat scenarios. In alternative or additional embodiments, the mitigation file includes an executable file having executable instructions corresponding to a set of remediation processes for automatically performing remediation actions in response to running the mitigation file at a client system.

[0093] It should be understood that the scope of the present disclosure includes any combination of the foregoing embodiments. In view of the foregoing, it should be understood that the current embodiments enable a computing system to more effectively generate and provide, compared to the prior art, a composite remediation file related to a target system experiencing threat conditions (including unknown threat conditions) and that can be used to remediate these threat conditions.

[0094] As an example, and using the current embodiments, the system can distinguish a brute force attack (threat scenario A) from a DDoS attack (threat scenario B) and another threat scenario C (e.g., the running of malicious executable code on an application at a client system). In this embodiment, the computing system will determine that threat scenario A (which may be unknown and have no known mitigation file) is more similar to threat scenario B (which may also be known and have a known composite remediation file) than to threat scenario C (which may be known and have a known composite remediation file). In such a case, the computing system will determine the similarity and provide a mitigation file to the client system affected by threat scenario A, the mitigation file including the composite remediation file associated with threat scenario B.

[0095] The disclosed methods may be practiced using a variety of types of special-purpose or general-purpose computing systems including computer hardware. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. A computer-readable medium storing computer-executable instructions is a physical storage medium. A computer-readable medium carrying computer-executable instructions is a transmission medium. Thus, by way of example and not limitation, embodiments of the present invention can include at least two distinctly different kinds of computer-readable media: physical computer-readable storage media and transmission computer-readable media.

[0096] Physical computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM, or other optical disk storage (such as CDs, DVDs, etc.), magnetic disk storage, or any other medium that can be used to store the desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer.

[0097] "Network" is defined as one or more data links that enable the transfer of electronic data between computer systems, and / or modules, and / or other electronic devices. When information is transmitted or provided to a computer via a network or another communication connection (wired, wireless, or a combination of wired or wireless), the computer correctly views the connection as a transmission medium. The transmission medium can include a network that can be used to carry the desired program code means in the form of computer-executable instructions or data structures and can be accessed by a general-purpose or special-purpose computer. The above combinations are also included within the scope of computer-readable media.

[0098] In addition, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be automatically transferred from a transmission computer-readable medium to a physical computer-readable storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module (e.g., "NIC") and then ultimately transferred to the computer system RAM and / or to a less volatile computer-readable physical storage medium at the computer system. Thus, computer-readable physical storage media can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0099] Computer-executable instructions include, for example, instructions and data that cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a particular function or group of functions. Computer-executable instructions can be, for example, binary, intermediate format instructions (such as assembly language), or even source code. Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0100] Those skilled in the art should understand that the present invention can be practiced in a network computing environment having many types of computer system configurations, including personal computers, desktop computers, laptop computers, messaging processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. The present invention can also be practiced in a distributed system environment where local and remote computer systems (connected via wired data links, wireless data links, or a combination of wired and wireless data links) each perform tasks via a network link. In a distributed system environment, program modules can be located in local and remote storage devices.

[0101] Alternatively or additionally, the functionality described herein may be performed, at least in part, by one or more hardware logic components. By way of example, and not limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system on a chip systems (SOCs), complex programmable logic devices (CPLDs), and the like.

[0102] Without departing from the spirit or characteristics of the present invention, the present invention may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Thus, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A computing system, comprising one or more processors and one or more hardware storage devices storing computer-executable instructions, the computer-executable instructions being executable by the one or more processors to cause the computing system to perform real-time mitigation for unfamiliar threat scenarios by at least causing the computing system to perform the following: Identifying a specific threat scenario for a client system that has not previously experienced the threat scenario and for which the remediation process is unknown; Generating a threat vector identifying a plurality of different threat scenario characteristics for the specific threat scenario; Applying a classification model to the threat vector to identify a set of predictive mitigation processes determined to be most suitable for the threat vector, wherein the classification model includes a plurality of different sets of client remediation processes corresponding to different types of alerts associated with different threat scenarios, at least some of the different threat scenarios being related to the specific threat scenario; And Providing a mitigation file including the set of predictive mitigation processes to the client system for responding to the specific threat scenario.

2. The computing system according to claim 1, wherein the different types of alerts associated with the different threat scenarios correspond to different client systems.

3. The computing system according to claim 1, wherein the system is further caused to perform: generating the plurality of different sets of client remediation processes for each type of the different types of alerts by performing the following for each identified alert: Identifying a plurality of processes performed by a corresponding plurality of different client systems, the plurality of processes being performed at a predetermined time and / or within a process related to the identified alert; Determining which of the plurality of processes are related to the identified alert based on a correlation vector of the plurality of processes with the identified alert; And For each client of the plurality of different client systems, creating a set of client remediation processes, the set of client remediation processes including processes determined to be related to the identified alert and performed by the client at the predetermined time and / or within the process related to the identified alert.

4. The computing system according to claim 3, wherein the mitigation file includes remediation processes included in the plurality of different sets of client remediation processes and identified as corresponding to an alert type determined to be related to the specific threat scenario.

5. The computing system according to claim 1, wherein the mitigation file includes an executable file having executable instructions for automatically performing a remediation action in response to running the mitigation file at the client system.

6. The computing system according to claim 1, wherein the mitigation file includes a non-executable file including a list of recommended remediation actions for resolving the threat scenario.

7. A method for performing real-time mitigation for unfamiliar threat scenarios, the method comprising: Identifying a specific threat scenario for a client system that has not previously experienced the threat scenario and for which the remediation process is unknown; Generate a threat vector that identifies multiple different threat scenario characteristics for the specific threat scenario; Apply a classification model to the threat vector to identify a set of predictive mitigation processes determined to be most suitable for the threat vector, where the classification model includes multiple different sets of client remediation processes corresponding to different types of alerts associated with different threat scenarios, and at least some of the different threat scenarios are related to the specific threat scenario; And Provide a mitigation file including the set of predictive mitigation processes to the client system for responding to the specific threat scenario.

8. The method according to claim 7, wherein the different types of alerts associated with the different threat scenarios correspond to different client systems.

9. The method according to claim 8, wherein the method further includes generating the multiple different sets of client remediation processes for each type of the different types of alerts by performing the following for each identified alert: Identify multiple processes performed by a corresponding multiple different client systems, the multiple processes being performed within a predetermined time and / or process related to the identified alert; Determine which of the multiple processes are related to the identified alert based on a correlation vector of the multiple processes with the identified alert; And For each client of the multiple different client systems, create a set of client remediation processes, the set of client remediation processes including the processes determined to be related to the identified alert and performed by the client within the predetermined time and / or process related to the identified alert.

10. The method according to claim 9, wherein the mitigation file includes remediation processes included in the multiple different sets of client remediation processes and identified as corresponding to the alert type determined to be related to the specific threat scenario.

11. The method according to claim 7, wherein the mitigation file includes an executable file having executable instructions for automatically performing a remediation action in response to running the mitigation file at the client system.

12. The method according to claim 7, wherein the mitigation file includes a non-executable file including a list of recommended remediation actions for resolving the threat scenario.

13. A hardware storage device storing computer-executable instructions executable by one or more processors of a computing system to cause the computing system to perform real-time mitigation against an unfamiliar threat scenario by at least causing the computing system to perform the following: Identify a specific threat scenario for a client system that has not previously experienced the threat scenario and for which the remediation process is unknown; Generate a threat vector that identifies multiple different threat scenario characteristics for the specific threat scenario; Apply a classification model to the threat vector to identify a set of predictive mitigation processes determined to be most suitable for the threat vector, where the classification model includes multiple different client remediation process sets corresponding to different types of alerts associated with different threat scenarios, and at least some of the different threat scenarios are related to the specific threat scenario; and Provide a mitigation file including the set of predictive mitigation processes to the client system for responding to the specific threat scenario.

14. The hardware storage device according to claim 13, wherein the different types of alerts associated with the different threat scenarios correspond to different client systems.

15. The hardware storage device according to claim 14, wherein the stored computer-executable instructions are further executable to cause the computing system to generate the multiple different client remediation process sets for each type of the different types of alerts by performing the following for each identified alert: Identify a plurality of processes executed by a corresponding plurality of different client systems, the plurality of processes being executed at a predetermined time and / or within a process related to the identified alert; Determine which of the plurality of processes are related to the identified alert based on a correlation vector of the plurality of processes with the identified alert; and For each client of the plurality of different client systems, create a client remediation process set that includes processes determined to be related to the identified alert and executed by the client at the predetermined time and / or within the process related to the identified alert.

16. The hardware storage device according to claim 15, wherein the mitigation file includes remediation processes included in the multiple different client remediation process sets and identified as corresponding to the alert type determined to be related to the specific threat scenario.

17. The hardware storage device according to claim 13, wherein the mitigation file includes an executable file having executable instructions for automatically performing a remediation action in response to running the mitigation file at the client system.

18. The hardware storage device according to claim 13, wherein the mitigation file includes a non-executable file that includes a list of recommended remediation actions for resolving the threat scenario.

Images