INVOKING RESPONSE(S) BASED ON ANALYSIS OF A DATASET OBTAINED FROM SEARCHING A SECURITY ENDPOINT

A computer-implemented method according to one embodiment includes causing a search to be performed for data on at least one security endpoint and organizing information about the performed search into steps and variables. Security analytics are run on a dataset provided from the performed search, and based on results of the analytics, a response is invoked to protect a system that interacts with the analyzed dataset. A computer program product according to another embodiment includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a computer to cause the computer to perform the foregoing method. A system according to another embodiment includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor. The logic is configured to perform the foregoing method.

STATEMENT REGARDING PRIOR DISCLOSURES BY THE INVENTOR OR A JOINT INVENTOR, OR ANOTHER WHO OBTAINED THE SUBJECT MATTER FROM AN INVENTOR OR JOINT INVENTOR

The following disclosure(s) are submitted under 35 U.S.C. 102(b)(1)(A): IBM Cloud Pak for Security 1.7.2 platform adds IBM Security Risk Manager, enabling data security teams to take prioritized remedial actions for identified risk areas; features enhanced threat management capabilities for finding and documenting anomalous behaviors, IBM Japan, Jul. 27, 2021.

BACKGROUND

The present invention relates to threat hunting, and more particularly, this invention relates to structured threat hunting on data gathered through a federated search on one or more security endpoints.

Threat hunting includes proactive actions typically performed by a program that is configured to search for potentially harmful behavior and/or actors within a network. Such proactive actions are typically performed based on the notion that the harmful behavior and/or actors may exist within the network despite active security parameters existing within the network. Various examples of such harmful behavior and/or actors include malicious actors within a network, risky network traffic, large data accesses, etc.

One or more components of a network remain vulnerable to the harmful behavior and/or actors until the harmful behavior and/or actors are addressed. This is problematic because the harmful behavior and/or actors are likely not noticeable until a threat hunt is performed to determine an existence of the actors. This potentially allows the harmful actors to operate undetected for prolonged periods of time within the network.

BRIEF SUMMARY

A computer-implemented method according to one embodiment includes causing a search to be performed for data on at least one security endpoint and organizing information about the performed search into steps and variables. Security analytics are run on a dataset provided from the performed search, and based on results of the analytics, a response is invoked to protect a system that interacts with the analyzed dataset.

A computer program product according to another embodiment includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a computer to cause the computer to perform the foregoing method.

A system according to another embodiment includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor. The logic is configured to perform the foregoing method.

DETAILED DESCRIPTION

The following description discloses several embodiments for defining a sharable and reusable structured threat hunting template (“Hunt”) using data gathered through a federated search on at least one security endpoint.

In one general embodiment, a computer-implemented method includes causing a search to be performed for data on at least one security endpoint and organizing information about the performed search into steps and variables. Security analytics are run on a dataset provided from the performed search, and based on results of the analytics, a response is invoked to protect a system that interacts with the analyzed dataset.

In another general embodiment, a computer program product includes a computer readable storage medium having program instructions embodied therewith. The program instructions are readable and/or executable by a computer to cause the computer to perform the foregoing method.

In another general embodiment, a system includes a processor, and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor. The logic is configured to perform the foregoing method.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Workloads layer90provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analytics processing94; transaction processing95; and structured threat hunting96on data gathered through a federated search on at least one security endpoint.

FIG.3illustrates an architecture300, in accordance with one embodiment. As shown inFIG.3, a plurality of remote networks302are provided including a first remote network304and a second remote network306. A gateway301may be coupled between the remote networks302and a proximate network308. In the context of the present architecture300, the networks304,306may each take any form including, but not limited to a local area network (LAN), a wide area network (WAN) such as the Internet, public switched telephone network (PSTN), internal telephone network, etc.

In use, the gateway301serves as an entrance point from the remote networks302to the proximate network308. As such, the gateway301may function as a router, which is capable of directing a given packet of data that arrives at the gateway301, and a switch, which furnishes the actual path in and out of the gateway301for a given packet.

Further included is at least one data server314coupled to the proximate network308, and which is accessible from the remote networks302via the gateway301. It should be noted that the data server(s)314may include any type of computing device/groupware. Coupled to each data server314is a plurality of user devices316. User devices316may also be connected directly through one of the networks304,306,308. Such user devices316may include a desktop computer, lap-top computer, handheld computer, printer or any other type of logic. It should be noted that a user device311may also be directly coupled to any of the networks, in one embodiment.

A peripheral320or series of peripherals320, e.g., facsimile machines, printers, networked and/or local storage units or systems, etc., may be coupled to one or more of the networks304,306,308. It should be noted that databases and/or additional components may be utilized with, or integrated into, any type of network element coupled to the networks304,306,308. In the context of the present description, a network element may refer to any component of a network.

According to some approaches, methods and systems described herein may be implemented with and/or on virtual systems and/or systems which emulate one or more other systems, such as a UNIX® system which emulates an IBM® z/OS® environment (IBM and all IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation and/or its affiliates), a UNIX® system which virtually hosts a known operating system environment, an operating system which emulates an IBM® z/OS® environment, etc. This virtualization and/or emulation may be enhanced through the use of VMware® software, in some embodiments.

FIG.4shows a representative hardware environment associated with a user device316and/or server314ofFIG.3, in accordance with one embodiment. Such figure illustrates a typical hardware configuration of a workstation having a central processing unit410, such as a microprocessor, and a number of other units interconnected via a system bus412.

The workstation shown inFIG.4includes a Random Access Memory (RAM)414, Read Only Memory (ROM)416, an input/output (I/O) adapter418for connecting peripheral devices such as disk storage units420to the bus412, a user interface adapter422for connecting a keyboard424, a mouse426, a speaker428, a microphone432, and/or other user interface devices such as a touch screen and a digital camera (not shown) to the bus412, communication adapter434for connecting the workstation to a communication network435(e.g., a data processing network) and a display adapter436for connecting the bus412to a display device438.

As mentioned above, threat hunting includes proactive actions typically performed by a program that is configured to search for potentially harmful behavior and/or actors within a network. Such proactive actions are typically performed based on the notion that the harmful behavior and/or actors may exist within the network despite active security parameters existing within the network. Various examples of such harmful behavior and/or actors include malicious actors within a network, risky network traffic, large data accesses, etc.

One or more components of a network remain vulnerable to the harmful behavior and/or actors until the harmful behavior and/or actors are addressed. This is problematic because the harmful behavior and/or actors are likely not noticeable until a threat hunt is performed to determine an existence of the actors. This potentially allows the harmful actors to operate undetected for prolonged periods of time within the network.

During a manual threat hunting process, instant responder services may be hired and utilized, which collect data, sort the data, and search for harmful behavior and/or actors within the data. For example, consider a business email compromise occurring in an application; threat hunting may be utilized to collect the endpoint data. Power shells may be searched for, which start from an endpoint connecting to an external source that is known for computer numerical control (CNC). This all takes time to perform, and among different applications, different threat hunting tools are employed. This adds to the complexity of performing threat hunting. Furthermore, conventional threat hunting does not employ reusability when switching between applications, and therefore nothing is shared between instances of performing the threat hunting. This is despite threat hunting across these applications often including repetitive tasks. Moreover, conventional techniques for performing threat hunting do not employ a standard.

In sharp contrast to the deficiencies of the conventional techniques described above, various embodiments and approaches described herein include techniques for standardizing threat hunting by establishing constructs for a sharable and reusable threat hunting template, e.g., a “Hunt.” The “Hunt” in some approaches serves as a template and constructs for an apparatus to enable structured threat hunting on the data gathered through a federated search built for a hybrid cloud. Moreover, the “Hunt” is useful for security analyst devices to perform cyber reasoning and threat discovery relatively faster and easier than conventional threat hunting techniques by providing a simple, composable, and interactive way to encode, share and reuse hunting knowledge into hunt-flows. Specifically, the constructs enable a search to be performed for threat hunt data on at least one security endpoint, information about the performed search to be organized and/or managed into steps and variables, analytics to be run on a dataset provided from the performed search and a response to be invoked that protects a system that interacts with the analyzed dataset.

A threat hunt that searches for anomalous and/or suspicious behavior in a federated search environment benefits from these special constructs built for threat hunting. As will be described in greater detail elsewhere below, the constructs may be built on top of Structured Threat Information eXpression (STIX). Data analysis forms a core part of the threat hunting process. Analysts spend a majority of time arranging and transforming the data collected from EDRs, security data lakes, and STEMS. STIX is a standard to capture CTI from the data that spans multiple domains, including security and event management (SIEM), endpoint, network, and file levels. The federated search data is captured/stored and operated upon using the STIX standard. For context, STIX is a standard to capture cyber threat intelligence (CTI) from the data that spans multiple domains, including security and event management (SIEM), endpoint, network, and file levels. The federated search data is captured/stored and operated upon using the STIX standard.

Now referring toFIG.5, a flowchart of a method500is shown according to one embodiment. The method500may be performed in accordance with the present invention in any of the environments depicted inFIGS.1-9, among others, in various embodiments. Of course, more or fewer operations than those specifically described inFIG.5may be included in method500, as would be understood by one of skill in the art upon reading the present descriptions.

Operation502of method500includes causing a search to be performed for data on at least one security endpoint of any type. In one approach, the security endpoint may be a portion of a network, e.g., such as a server, a computer, a processor, etc. In another approach, the security endpoint may additionally and/or alternatively be a collection of software code, or any portion thereof. In another approach, the security endpoint may additionally and/or alternatively be a hybrid cloud platform, or any portion thereof.

The search may in some approaches be a federated search that is performed for threat hunt data on the at least one security endpoint. The federated search may in some approaches be performed for data from multiple security endpoint points such as IBM's SIEM, Endpoint Detection And Response (EDR) and/or Guardium. For context, threat hunt data may be defined as data that is not, at least initially, ruled out for analysis to determine whether the hunt data of the security endpoint is anomalous and/or suspicious behavior in a federated search environment.

Causing the search to be performed may in some preferred approaches include instructing a threat hunting core engine (THCE) to perform the search. The THCE may be driven by threat hunting commands in a predefined threat hunting language. For example, the threat hunting language may include commands for patterning and normalizing the data uncovered during the performed search. In one approach, the commands of the language may define instructions to obtain data from one or more predetermined data sources, e.g., such as a security endpoint of the federated search environment. In another approach, the commands of the language may additionally and/or alternatively define instructions to obtain data from one or more data sources that are encountered during a known type of crawl search across the federated search environment. The commands of the language may additionally and/or alternatively define how to sort data on at least one security endpoint. The commands of the language may additionally and/or alternatively define how to apply analytics on the data on at least one security endpoint and furthermore how to invoke a response based on the analytics. One or more known commands that would become apparent to one of ordinary skill in the art upon reading the descriptions herein may additionally and/or alternatively be utilized for patterning and/or normalizing data uncovered during the search. The patterned and/or normalized data obtained as a result of performing such commands may be useful for defining a dataset associated with suspicious processes, e.g., where the dataset is a portion of the data uncovered during the search. For context, as will be described elsewhere below, further analysis may be applied to such a dataset to determine whether anomalous and/or suspicious behavior is in fact present in the at least one security endpoint of the federated search environment, e.g., see operation506.

In some approaches, the dataset mentioned above may be additionally and/or alternatively determined as a result of analyzing records of the data uncovered in the performed search. For example, individual records of activity of the data uncovered in the performed search are in some approaches analyzed to extract unique cyber-observable entities for inclusion in the dataset. This way, system resources may be preserved in optionally performing analysis on an entity by entity basis rather than aimlessly performing analysis on all data of a federated search environment and/or security endpoint thereof. Extracting unique cyber observable entities furthermore reduces an amount of time and processing that would otherwise be consumed were analysis to be performed on all data of the federated search environment and/or security endpoint thereof. The predefined threat hunting language may use STIX patterning for data acquisition and normalization during the search of the at least one security endpoint. Data uncovered in the performed search and or a dataset thereof may be stored in a database, e.g., to retain the data and/or dataset for further analysis to performed thereon. According to some approaches, the database may include one or more storage locations of a hybrid cloud platform which may include one or more types of storage, e.g., magnetic recording tape, hard disk, etc. Accordingly, in some approaches the data uncovered in the performed search and or a dataset thereof may be stored distributed across a plurality of storage locations in the hybrid cloud platform in some approaches.

The predefined threat hunting language may be utilized to analyze individual records of activity of the data uncovered in the performed search to extract unique cyber observable entities for inclusion in the dataset. For example, in some approaches, the predefined threat hunting language may define operations to perform on the entities for modifying details of the dataset. For context, in some approaches, the term “modifying” may refer to an operation that is performed to increase an extent of contents of the dataset. For example, in one of such approaches, the predefined threat hunting language may define an operation for finding related entities of instances of data uncovered in the performed search. The related entities may be included in the dataset. In contrast, in some approaches, the term “modifying” may refer to an operation that is performed to increase an extent of contents of the dataset. For example, in one of such approaches, the predefined threat hunting language may additionally and/or alternatively define an operation for filtering instances of data uncovered in the performed search. The filtered instances of data may in some approaches be excluded from the dataset. In another approach, the predefined threat hunting language may additionally and/or alternatively define an operation for enabling visualization of instances of data uncovered in the performed search. The predefined threat hunting language may additionally and/or alternatively define an operation for aggregation of instances of data uncovered in the performed search. Aggregation operations may be useful for reducing an amount of data that is analyzed without sacrificing a scope of broadness of the search that is performed as different instances of data across a plurality of security endpoints in the federated search environment may be aggregated into a dataset for analysis. Depending on the approach, one or more known operations that would become apparent to one of ordinary skill in the art upon reading the descriptions herein may be utilized for the operations defined within the predefined threat hunting language. In some approaches the predefined threat hunting language may additionally and/or alternatively include a “user defined function” capability to run analytics on the entities and records of the federated search environment. This may provide a customizable aspect to a sharable and/or reusable template of the threat hunting, e.g., see “Hunt” described in greater detail below.

Various illustrative embodiments of threat hunting in which commands of the THCE may be applied to perform the search in order to determine a dataset that is potentially associated with anomalous and/or suspicious behavior are described below. A first embodiment of threat hunting includes matching a Tactics, Techniques, and Procedures (TTP) such as process exploit, and then finding the payload process (malicious). The threat hunting includes then finding activities of the payload process to uncover a malicious attack plot. Another embodiment of threat hunting includes searching for suspicious behaviors as a step in a hunt such as: an office application launching power shell which in turn downloads and starts a process with obfuscated command line. Yet another embodiment of threat hunting includes checking network traffic against pre-defined or pre-trained models to identify domain name generation (DGA) or data exfiltration. Linking back to the host and process associated with the network traffic is then performed to uncover command and control (C&C) communication and data exfiltration attacks. Another embodiment of threat hunting includes screening all system startup services, selecting suspicious services to drill down, revealing a process that setup the startup service and the process that is spawned by the service to understand its activity, and finally uncovering a persistent threat. Yet another embodiment of threat hunting includes grouping network traffic by an associated occurring time of the day, filtering spikes and diving into the network traffic that causes the spikes, and associated hosts and processes and data flow sources, to detect potential data exfiltration attack campaigns.

Operation504of method500includes organizing and/or managing information about the performed search into steps and variables. Such an operation may also be referred to as “hunt organization,” as one goal of performing one or more operations of method500may include providing a template, e.g., “Hunt,” including threat hunt information and analysis that may be shared and/or reused for performing federated searches thereafter, e.g., on one or more security endpoints of the federated search environment and/or on one or more security endpoints another federated search environment. Organizing and/or managing information about the performed search in some approaches may begin with data uncovered by the search being organized into a logical entity, e.g., the “Hunt.” The logical entity, e.g., “Hunt,” itself contains “steps” which are iterative and executable. Steps involve collection of data, application of analytics, transformations and/or enrichment of data uncovered in the performed search. The result of performing each step may be a variable which provides a perspective and/or view into an output of each step. Accordingly, the steps and variables define the operative steps and results of a performed threat hunt in order to serve as a template, e.g., “Hunt,” that is a sharable and reusable threat hunting process template of the threat hunting and response achieved by performing one or more operations of method500. In some approaches, the result of a step is also a visual graphic representation, e.g., as described in greater detail elsewhere herein (seeFIG.7). In some approaches the steps may include a predetermined command, e.g., LOAD, FIND, GET, etc.

Security analytics are run on a dataset, or a plurality of datasets, provided from the performed search, e.g., see operation506. In one approach, an analytics orchestration may be invoked to run extended security analytics on the dataset, or a plurality of datasets, provided from the performed search, e.g., the dataset associated with suspicious processes. Running the analytics on the dataset may include one or more operations which will now be described according to various approaches. In one approach, running the analytics on the dataset may include performing data enrichment by gathering and annotating threats within the dataset. One or more techniques that would become apparent to one of ordinary skill in the art upon reading the descriptions herein may additionally and/or alternatively be utilized for gathering and annotating threats within a dataset. For example, in some approaches, known techniques for gathering and annotating threats within the dataset may be utilized. Running the analytics on the dataset may additionally and/or alternatively include performing clustering of data of the dataset. For example, in some approaches, K-Means and/or a known type of graph-based clustering algorithm may be used to performing clustering of data of the dataset where the dataset and/or information about the search is included in a visual graphic representation. In some other approaches, known technique(s) for performing clustering of data of a dataset may additionally and/or alternatively be used. Running the analytics on the dataset may additionally and/or alternatively include performing outlier detection on data of the dataset, e.g., a threat with anomalous and/or suspicious behavior. Based on the run analytics, one or more instances of data may be determined to be associated with anomalous and/or suspicious behavior. For example, instances of data that are identified as a result of performing outlier detection on data of the dataset may be determined to be associated with anomalous and/or suspicious behavior. In another approach, instances of data of the dataset that are clustered with an instance of data of the dataset that is determined to be associated with anomalous and/or suspicious behavior, may also be determined to be associated with anomalous and/or suspicious behavior. Instances of data identified from the results of gathering and annotating threats within the dataset may additionally and/or alternatively be determined to be associated with anomalous and/or suspicious behavior.

Note that in some approaches, the analytics are performed on a serverless platform such as a hybrid cloud platform. More specifically, in some approaches because analytics that are run may be relatively compute intensive and in order to realize memory and/or CPU limitations, the analytics may be run on an elastic serverless platform such as a hybrid cloud platform. The hybrid cloud platform may in some approaches be similar to and/or include any one or more components illustrated in the embodiments of other FIGS included herein. The hybrid cloud platform may in some other approaches be similar to and/or include any one or more components of known types of hybrid cloud platforms.

Federated data enrichment and/or additional insights are in some preferred approaches added to the data collected during threat hunting of method500. In some approaches the data enrichment and/or additional insights are added to the dataset as a result of the extended security analytics, e.g., a security analytics step, being run on the dataset, e.g., see operation506. Such data enrichment and/or additional insights may additionally and/or alternatively be added to information organized and/or managed in the logical entity, e.g., the “Hunt.” The process of adding federated data enrichment and/or additional insights to the dataset is in some approaches invoked as a result of executing an “APPLY” command in the THL which results in invocation of a containerized software that implements purpose built analytics code. The analytic insights that result from the performed analysis preferably become part of the resulting variable, e.g., collection of data, in the THL. Moreover, performance of analytics as a pipeline may be composed in some approaches using known techniques, as this allows a sequence of transformations and steps to be performed as part of a single analytics invocation.

As described above, results of the analytics may include instances of data that are determined to be associated with anomalous and/or suspicious behavior, federated data enrichment, additional insights, etc. These results may optionally be added to the template including threat hunt information, e.g., “Hunt” in some approaches.

In some approaches, a response to protect a system that interacts with the analyzed dataset may be invoked based on results of the analytics, e.g., see operation508. More specifically, the system that interacts with the analyzed dataset may be a system that uses at least some instances of the dataset determined to be associated with anomalous and/or suspicious behavior. During threat hunting, e.g., which may include any of the steps of method500in the process of establishing the “Hunt,” at any point a response command may be initiated to trigger a predefined automated playbook run. In some preferred approaches, playbooks are predefined ansible scripts that perform certain action in a coordinated environment, e.g., such as coordinated environment that includes one or more components of the system that interacts with the analyzed dataset. Invoking the response in some approaches includes causing robotic response automation launching BOTs to execute commands of a playbook. Note that a BOT may be defined as a piece of software that automates a request with a predetermined various goal. Moreover, the playbook may store and/or define predefined ansible scripts that perform certain actions in coordinated environment. Accordingly, ansible script processing BOTs capable of processing the commands in the playbook may be directed to pick up and execute the response actions.

In one approach, the response may include requesting and/or re-requesting access credentials from a device, e.g., such as a device that is determined to have interacted with at least some instances of the dataset determined to be associated with anomalous and/or suspicious behavior. In another approach, the response may additionally and/or alternatively include inserting a firewall, e.g., inserting a firewall in one or more components that are determined to potentially interact with at least some instances of the dataset determined to be associated with anomalous and/or suspicious behavior. According to yet another approach, the response may additionally and/or alternatively include terminating a session, e.g., a session having network traffic originates from a device that is determined to be associated with anomalous and/or suspicious behavior. The response may additionally and/or alternatively include powering down a server. Such a server may be included in a hybrid cloud platform, and have at least a portion of the dataset and/or executable software associated with the dataset stored thereon. The response may additionally and/or alternatively include quarantining one or more components of the system, where the quarantined components of the system are determined using known techniques to be potentially subject to corruption and/or damage as a result of the anomalous and/or suspicious behavior. The response is useful from a performance standpoint in that security threats that exist in the search environment are addressed, e.g., mitigated. Accordingly, the response also enables a preservation of processing/computing resources of the search environment that would otherwise be expended in recovering from damage that the security threats would cause in the search environment if not mitigated. The “Hunt” is also standardized and therefore repeatable across a plurality of different search environments.

Information about the analytics and/or response, e.g., see hunt steps and response steps ofFIG.9, may be added to the organized information, e.g., of the “Hunt,” to provide additional detail and/or context for future hunts that are performed using the “Hunt.” Operation510includes storing the steps and variables of the “Hunt” in accordance with one approach. This storage operation may be a part of a larger storage operation, e.g., such as an operation that includes storing the “Hunt.” Operation512, if performed, includes sharing the steps and variables and/or the “Hunt” itself. This information may be shared with any one or more destinations that can reuse the information to perform a federated search on other endpoints of the same and/or another federated search environment. Such destinations may include, e.g., other systems, a device managing one or more other security endpoints, a server, a troubleshooting application, a known type of security application, a known type of device that is used to manage and/or perform threat hunts, etc. The “Hunt” and/or the steps and variables thereof may be reused to perform a federated search, e.g., see operation514. For example, a device having a controller and/or processor may use the “Hunt” and/or the steps and variables thereof may be reused to perform a federated search in response to a determination that similar system parameters/metrics, e.g., anomalous/suspicious behavior, that existed while the steps and variables were developed to organize the “Hunt,” are detected and/or known to be present, e.g., on the device, on data used by the device, on a security endpoint associated with the device, on a hybrid cloud platform that includes the device, etc. In response to detecting these similar system parameters/metrics, a playbook that includes the “Hunt” may be accessed and applied to protect one or more components and/or systems that are determined to be at risk to the similar system parameters/metrics.

The techniques in various embodiments and approaches described herein provide numerous benefits that are not otherwise enabled by conventional threat hunting. In some embodiments described herein, these techniques include unique constructs built for federated search data to define, organize and analyze data during threat hunting on a hybrid cloud platform. Moreover, these techniques include organization of hunts as steps and variables (hunt data of a hunt-flow) that is sharable and re-playable as a “Hunt.” Extended analysis functions for federated search datasets run on a serverless compute, and inline invocation of robotic process automation that acts on incident response during a threat hunt may also be incorporated into such techniques. These techniques have heretofore not been considered in conventional threat hunting, and in sharp contrast, conventional threat hunting does not employ reusability when switching between applications. Thus, within conventional threat hunting, nothing is shared between instances of threat hunting performance. Accordingly, the inventive discoveries disclosed herein, e.g., with regards to use of organization of threat hunts as steps and variables that is sharable and re-playable, proceed contrary to conventional wisdom.

FIG.6depicts an architecture600, in accordance with one embodiment. As an option, the present architecture600may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such architecture600and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the architecture600presented herein may be used in any desired environment.

InFIG.6, the architecture600illustrates a threat hunting core engine (THCE), which may be used in a threat hunting process such as the threat hunting process described in method500. The THCE is driven by threat hunting commands from a threat hunting language, e.g., see a logical path flow from the “Threat hunting language” to the THCE. Federated searches are performed by the THCE, e.g., see “Federated search data,” and data from multiple security endpoint points, e.g., see “SIEM”, “EDR” and “Guardium”, is normalized. Threat hunt data from the search is organized and managed, e.g., see “Data” and “Steps” of the “Hunt” and a Threat hunting data organization logical path of the THCE flow to the Hunt. Analytics orchestration is invoked for running extended security analytics on the federated search data. For example, the analytics orchestration may be invoked using predefined commands of an analytics library. In some approaches the extended security analytics may be run on a serverless platform, e.g., see “Serverless analytics execution.” The THCE may additionally and/or alternatively invoke robotic response automation launching BOTs to execute playbooks, e.g., see “Respond BOTs” having access to “Playbooks.”

FIG.7depicts a flowchart of a process architecture700, in accordance with one embodiment. As an option, the present process architecture700may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such process architecture700and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the process architecture700presented herein may be used in any desired environment.

As described in greater detail elsewhere herein, a predefined threat hunting language of an THCE may define an operation for finding related entities of instances of data uncovered in a performed search. For example, a known type of “FIND” command and/or construct may be executed during a federated search of at least one security endpoint to find security specific relationships within data uncovered during the search. The related entities may be included in a dataset that is analyzed. A known type of sorting command may in one approach additionally and/or alternatively be used during the search to sort the data uncovered during the search. A known type of display command may in another approach additionally and/or alternatively be used during the search. In another approach, pattern matching may be performed during the search. For example, a predetermined STIX command for pattern matching may be included in a template for performing a federated search, e.g., a “Hunt” that includes steps and variables, and upon being executed, the command may return matching patterns within the searched data. By using the STIX language, diverse language specific commands are not required for the search performed.

According to various approaches, in a first step, the commands may be configured to return one or more predetermined pattern matches, e.g., a process having a predetermined command line, network traffic with a predetermined IP address, network traffic with a predetermined destination port, etc. In a second step, the commands may be configured to return one or more related entities, e.g., child processes, of discovered, e.g., returned, predetermined pattern matches. For example, in the process architecture700, an initial search via STIX pattern is performed on at least one endpoint. This search may return data on at least one security endpoint, e.g., suspicious processes, that meet one or more predetermined pattern matches of a command executed to perform the search. One or more related entities of the suspicious processes may be determined. For example, in one approach, a known type of command to determine child processes of the suspicious processes is performed, e.g., see “get their children,” which may use a known type of “GET” command to return child processes. These child processes may route to a destination such as a malicious website, at least one known malicious address, etc. In one approach, files for the child processes may be determined in the process of finding related entities of the suspicious processes. A known type of command for determining and/or obtaining modified files of child processes may be executed, which may return files. In response to a determination that a data access of a process to the files is greater than a predetermined size threshold, e.g., see “huge data access,” it may be determined that the process is a ransomware attack, e.g., see “ransomware confirmed.” In contrast, it may be determined that none of the files are compromised, e.g., see “no sys file compromised,” in response to a determination that the data access is not greater than the predetermined size threshold, e.g., see “in sys file.” Network traffic of the child processes may additionally and/or alternatively be obtained using one or more known techniques, e.g., see “get network traffic” return “network traffic.” Analytics defined in a predefined “FIND” construct may be performed on the network traffic to determine whether a system that interacts with the results are a dangerous threat. For example, a known type of beaconing analytics and/or data exfiltration analytics may be performed on the network traffic. In one approach, from the analytics it may be determined that no beaconing exists in the network traffic. In contrast, it may be determined that a data exfiltration is confirmed, e.g., such as in response to a determination that the network traffic flows from a process to a file to another process. Based on finding threats702such as the data exfiltration and the ransomware, a predetermined response may be invoked to protect a system that interacts with data to determine the threats.

It may also be noted that merging may occur between two or more processes in a “Hunt.” For example, an additional known type of related information about the suspicious processes may be determined, e.g., see step708return variable704. The variable704merges with the “files” variable to the “no sys file compromised” variable as a result of step706being performed.

Note that the circles, e.g., such as “child processes,” inFIG.7illustrate variable information about the performed search, while the arrows, e.g., such as “get their children,” inFIG.7illustrate step information about the performed search. These steps and variables may be organized into a sharable and reusable “Hunt.”

FIG.8depicts an architecture800, in accordance with one embodiment. As an option, the present architecture800may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such architecture800and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the architecture800presented herein may be used in any desired environment.

The architecture800includes information about a search performed in accordance with operations described elsewhere herein, e.g., see method500. For example, the information includes “Steps” and “Variables.” The information about the performed search may be organized and managed into a “HUNT,” using techniques similar to those described in operation504of method500. Such an operation may also be referred to as “hunt organization,” as one goal of performing such organizing and managing includes providing a template, e.g., see “HUNT,” that includes threat hunt information and analysis that may be shared and/or reused for performing federated searches thereafter. For example, the federated searches may be performed using the “HUNT” on one or more security endpoints of a federated search environment.

FIG.9depicts a hunt-flow architecture900, in accordance with one embodiment. As an option, the present architecture900may be implemented in conjunction with features from any other embodiment listed herein, such as those described with reference to the other FIGS. Of course, however, such architecture900and others presented herein may be used in various applications and/or in permutations which may or may not be specifically described in the illustrative embodiments listed herein. Further, the architecture900presented herein may be used in any desired environment.

The architecture900includes a plurality of hunt steps, e.g., see “HS1-9,” variables, e.g., see “V,” and response steps, e.g., see “RS1-3,” that are chained together with merging into hunt-flows, e.g., see the connection between threat hypothesis B and threat hypothesis A and the connection between threat hypothesis A and threat hypothesis A.2.FIG.9also includes a collection of pseudocode902that further defines the specifics of operations that are performed in each of the hunt steps and each of the response steps. Note that the variables are generated as output, e.g., a result, of the hunt steps. In the collection of pseudocode902, hunt steps include “GET” operations which are used for pattern matching, “FIND” operations which are used for finding related entities, “ALERT” operations and “TERMINATE” operations which are responses that may be applied during threat hunting. According to one specific example, a variable V7may include finding processes created by V4, e.g., the parent processes. In response to a determination that the processes are malicious, the process may be terminated, e.g., see “TERMINATE” of the pseudocode902as well as RS1. In another example, a variable V8may find files read by another variable, e.g., see FIND file READ BY V7. It may be determined that the files are suspicious, and V8may be alerted, e.g., see “ALERT V8.”

It should be noted that the hunt-flow ofFIG.9also includes merging of different variables to the same hunt step. For example, V6is equal to V4and V5based on the merge of V4and V5. Accordingly, V6is a collection of data that includes a multitude of processes that are captured by V4and V5. Similarly, V4is equal to V2and V3based on the merge of V2and V3. Accordingly, V4is a collection of data that includes a multitude of processes that are captured by V2and V3.