Automated detection of observations and automated triage of alerts in an endpoint detection and response (EDR) system using machine learning

Abstract

A threat response method associated with an endpoint detection and response (EDR) system. The system uses a combination of automated observation detection, threat data enrichment, graph analysis, and supervised machine learning to machine-predict analyst behavior in classifying EDR alerts (as "true" or "false" positives) and to (i) support automated suppression of those alerts that can be classified as true or false with sufficient confidence, or (ii) for those alerts for which such classification is not possible, support the provision of recommendations to analysts to enable their activities.Automated detection of observations for graph-based feature detection, along with automated alert triage where possible, significantly reduces the overall analyst workload for the EDR system. Even if a machine-based prediction lacks sufficient confidence to allow the analyst to bypass it, the system further provides the analyst with additional context and enrichment to facilitate faster (or at least more efficient) alert processing.

Description

BACKGROUND OF THE INVENTIONTechnical field

[0001] This disclosure generally relates to processing alerts in an endpoint detection and response (EDR) system. Background of related technology

[0002] Endpoint detection and response (EDR) systems are rule-based systems well-suited to correlating endpoint activity on host systems and generating alerts for suspicious or malicious behavior. However, one of the major drawbacks of these EDR systems is that they can generate large volumes of detections, ranging from many duplicates to false positives, leading to analyst fatigue. Approximately 60% to 70% of the alerts generated by these systems concern suspicious behavior triggered by system administrators, custom applications, or scripts, as well as reputation-based detections from next-generation antivirus (NGA) sensors, which can result in a large number of false positives until these are optimized.An analyst spends approximately 10 to 15 minutes evaluating and investigating these "false positive" alerts, increasing the time required to triage and process true positive detections. As a result, analyst fatigue occurs and investigations of more relevant alerts are delayed, which can lead to greater losses for a customer in the event of an actual cyberattack on their host systems. Another disadvantage of EDR systems is that while they correlate suspicious events and malicious behavior, they do not provide adequate explanations for anomalies, for example, through contextualization and data enrichment. They rarely create a list of suspicious observations in command lines where, for example, suspicious behavior has already occurred in the past.The task of enriching these suspicious observations with correct threat data and asset context is left to the analyst conducting the investigation, further delaying response actions. SUMMARY

[0003] This disclosure provides a method, apparatus, and computer program product for suppressing the number of alerts and reducing the time spent on alert processing in conjunction with an endpoint detection and response (EDR) system. The approach described herein implements a machine-based prediction service (e.g., a microservice) operating in conjunction with or as part of the EDR system. In response to receiving an alert from the EDR system, the content of the alert is analyzed to detect one or more "observations" in the alert that indicate potentially suspicious activity. Representative observations include, for example, high-risk hash functions, encoded commands, a number of command scripts, the presence of IP addresses in command lines, the presence of a shell script, and the like.The set of one or more observations identified in the alert content (e.g., the value of a hash function, a specific IP address identified in a command line, etc.) is then evaluated using a threat intelligence service, which returns the set of observations (or at least some of them) enriched with additional information (obtained from the threat intelligence service) useful for assessing the risk level posed by each such threat. The set of threats and their enrichment provided by a threat intelligence service exhibit a pattern. An additional enrichment level is then performed on one or more (or all) of the enriched observations in the pattern using graph-based analytics.

[0004] For this purpose, the enriched observations (as a sample) are then provided to a graph database, for which graph analysis is performed to identify a set of graph features that constitute a complete set of enriched features for the EDR alert. Representative graph features typically include alert-related data (e.g., the number of alerts, the number of alerts within a given time period, the number of entities associated with the alerts, the percentage of escalated alerts, and the like) as well as one or more graph-related metrics such as PageRank, community, centrality, proximity, and degree for each node in the sample.The output of this processing pipeline (containing the threat data and graph analysis enrichments) is a normalized EDR alert, which is then applied to a machine learning model previously trained on previous EDR alerts collected and processed in a similar manner. As a result, a prediction is generated for the EDR alert. The prediction preferentially classifies the alert as either a "true" positive or a "false" positive, along with a confidence level representing the degree of confidence in the machine-generated prediction.

[0005] Depending on the machine confidence, the system processes the alert without providing it to an analyst. This is automated triage. If the machine confidence level is sufficiently high, e.g., at or above a configurable threshold such as 90%, the system performs an automated action. For example, if the alert is a "true" positive, the system automatically triages the alert by escalating the alert, e.g., by providing tools with a command or control to initiate automated remediation, or the like; if, on the other hand, the machine confidence is sufficiently high for a "false" positive, the system automatically closes the alert. In both cases, the number of alerts is reduced because the alert does not need to be processed directly by an analyst (alert suppression).However, if the machine confidence is not sufficiently high for the alert, instead of performing automated triage, the system outputs an alert prediction (the "true" or "false" positive prediction along with the machine's confidence in that prediction) for the EDR alert to an analyst dashboard. To facilitate the processing of the alert for which the machine confidence is not sufficiently high to trigger automated triage, the alert prediction preferably includes various types of additional information to assist the analyst in expeditiously processing the alert. For this purpose, the additional information includes, for example, the observations detected in the alert content, a historical analysis explaining the machine decision, and an identification of past behaviors or events.

[0006] Automated detection of observations for graph-based feature detection, along with automated alert triage where possible (based on machine confidence in a prediction), significantly reduces the overall analyst workload for the EDR system. Even if a machine-based prediction doesn't have sufficient confidence to allow the analyst to bypass it, the system further provides the analyst with additional context and enrichment to facilitate more timely (or at least more efficient) alert processing.

[0007] The above discussion has set forth some of the particularly relevant features of the disclosed subject matter. These features should be understood as merely illustrative. As described below, many other advantageous results can be achieved by applying the disclosed subject matter in other ways or by modifying the subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] For a more complete understanding of the subject matter described herein and the attendant advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: Fig. 1 depicts an exemplary block diagram of a data processing system in which exemplary aspects of the illustrative embodiments may be implemented; Fig. 2 illustrates a representative EDR system in which the methods of this disclosure may be implemented; Fig. 3 is a general illustration of the architecture of this disclosure for automated threat processing for endpoint and network assets; Fig. 4 shows a detailed representation of a preferred processing sequence; Fig. 5 represents a representative implementation of the system as containerised, cloud-native applications that are portable and arbitrarily scalable and can be deployed across multiple clusters and regions, e.g. as a cloud-based solution; Fig. 6 represents the solution implemented as a service-oriented architecture (SOA); Fig. 7 represents a representative EDR-generated warning message; Fig. 8 represents a set of observations associated with an alert and enriched with threat data; Fig. 9 represents a generalized, generic graph data model for entities (nodes) and relationships for a customer alert; and Fig. 10 shows a visualization of the customer alert data model using a Neo4J browser. DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

[0009] Various aspects of the present disclosure are described by descriptive text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flowchart, depending on the technology involved, the operations may be performed in a different order than shown in a particular flowchart. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order or as a single, integrated step, concurrently, or in a manner that at least partially overlaps in time.

[0010] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in the present disclosure to describe any set of one or more storage media (also referred to as "media") collectively included in a set of one or more storage units that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations described in a particular CPP claim. A "storage unit" is any tangible unit that can contain and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination thereof.Some known types of storage devices containing these media include: a floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a compact disc read-only memory (CD-ROM), a DVD (digital versatile disc), a memory stick, a floppy disk, a mechanically encoded device (e.g., punched cards or pits / ridges on a larger surface of a storage medium), or any suitable combination thereof. A computer-readable storage medium, as used in the present disclosure, is not intended to be construed as storage in the form of transitory signals per se, e.g.,Radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses traveling through a fiber optic cable, electrical signals transmitted through a wire, and / or other transmission media. It will be apparent to those skilled in the art that data is typically moved at certain times during normal operation of a storage device, e.g., during access, defragmentation, or when performing a cleanup function. However, this does not render the storage device transitory, since the data is not transitory while it is being stored.

[0011] A data processing environment 100 includes an example of an environment for executing at least a portion of the computer code involved in performing the inventive methods, e.g.an automated threat handler code 200 of this disclosure that uses a combination of automated observation detection, threat data enrichment, graph analysis, and supervised machine learning to machine-predict analyst behavior in classifying the EDR alerts (as "true" or "false" positives) and to (i) support automated suppression of those alerts that the system classifies with sufficient confidence as either true or false, or (ii) for those alerts that cannot be so classified, support providing recommendations to analysts to facilitate their activities, all according to the description contained below.In addition to block 200, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remotely located server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), a data transmission structure 111, volatile memory 112, persistent storage 113 (including an operating system 122 and block 200, as identified above), a peripheral device set 114 (including a user interface (UI) device set 123, a memory 124, and an Internet of Things (IoT) sensor set 125. and a network module 115. The remote server 104 contains a remote database 130.The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a physical host machine set 142, a virtual machine set 143, and a container set 144.

[0012] Computer 101 may be in the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, a mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of executing a program, accessing a network, or retrieving a database such as remote database 130. As is well known in computer technology, and depending on the technology, the performance of a computer-implemented process may be distributed across multiple computers and / or multiple locations. However, in this discussion of computing environment 100, the detailed discussion will focus on a single computer, specifically computer 101, to keep the discussion as simple as possible.The computer 101 may be located in a cloud even though it is in . Fig. 1 is not shown in a cloud. However, computer 101 does not necessarily have to be located in a cloud unless explicitly described as such.

[0013] Processor set 110 includes one or more computer processors of any type currently known or developed in the future. Processing circuitry 120 may be distributed across multiple packages, for example, multiple coordinated integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores executing in processor set 110. Cache memories are typically organized into multiple levels, depending on their relative proximity to the processing circuitry. Alternatively, all or part of the cache for the processor set may be located "off-chip."In some computing environments, the processor set 110 may be configured to process qubits and perform quantum computing.

[0014] Computer-readable program instructions are typically read into computer 101 to cause a sequence of operations to be performed by processor set 110 of computer 101, thereby effecting a computer-implemented method, such that the instructions executed thereby instantiate the methods detailed in flowcharts and / or explanatory descriptions of computer-implemented methods included in this document (collectively, "the inventive methods"). These computer-readable program instructions are stored in various types of computer-readable storage media, e.g., cache 121 and the other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the performance of the inventive methods.In the data processing environment 100, at least some of the instructions for performing the inventive methods in block 200 may be stored in the persistent memory 113.

[0015] The data transmission structure 111 forms the signal transmission path that enables the various components of the computer 110 to exchange data with each other. This structure typically consists of switches and electrically conductive paths, e.g., the switches and electrically conductive paths that form buses, bridges, physical input / output ports, and the like. Other types of signal transmission paths may also be used, e.g., fiber optic data transmission paths and / or wireless data transmission paths.

[0016] The volatile memory 112 is any type of volatile memory currently known or developed in the future. Examples include dynamic-type random access memory (RAM) or static-type RAM. Typically, the volatile memory 112 is characterized by random access, but this need not be the case unless expressly described as such. In the computer 101, the volatile memory 112 is in a single package and is located within the computer 101; however, alternatively or additionally, the volatile memory may be distributed across multiple packages and / or may be located external to the computer 101.

[0017] Persistent memory 113 is any form of non-volatile computer memory currently known or developed in the future. The non-volatility of this memory means that the stored data is retained regardless of whether power is applied to computer 101 and / or persistent memory 113 directly. Persistent memory 113 may be read-only memory (ROM), but typically at least a portion of the persistent memory allows for data writing, data deletion, and data rewriting. Certain common forms of persistent memory include magnetic disks and semiconductor memory devices. Operating system 122 may take several forms, such as Linux, various well-known proprietary operating systems, or open-source POSIX (Portable Operating System Interface)-type operating systems that utilize a kernel.The code contained in block 200 typically includes at least a portion of the computer code involved in performing the inventive methods.

[0018] The peripheral unit set 114 contains the set of peripheral units of the computer 101. Data transmission connections between the peripheral units and the other components of the computer 101 can be implemented in various ways, e.g., as Bluetooth connections, near-field communication (NFC) connections, connections via cables (e.g., USB (Universal Serial Bus) type cables), insert-type connections (e.g., Secure Digital (SD) cards), connections via local data transmission networks, and even connections via wide area networks such as the Internet. In various embodiments, the UI unit set 123 can include components such as a display screen, a speaker, a microphone, wearable devices (e.g., glasses and smartwatches), a keyboard, a mouse, a printer, a touchpad, game controllers, and haptic devices. The memory 124 is an external memory, e.g.,an external hard disk drive, or a deployable memory, e.g., an SD card. Memory 124 may be persistent and / or volatile. In some embodiments, memory 124 may be in the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 requires a large amount of memory (e.g., where computer 101 stores and manages a large database locally), this memory may then be provided by peripheral storage devices designed to store very large amounts of data, e.g., a storage area network (SAN) shared by numerous geographically distributed computers. IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer, and another sensor may be a motion detector.

[0019] The network module 115 is the collection of computer software, hardware, and firmware that enables the computer 101 to communicate with other computers over the WAN 102. The network module 115 may include hardware, such as modems or WLAN signal transceivers, software for packing and / or unpacking data for transmission over a data transmission network, and / or web browser software for transmitting data over the Internet. In some embodiments, network control functions and network forwarding functions of the network module 115 are performed in the same physical hardware unit. In other embodiments (for example, embodiments using software-defined networking (SDN)), the control and forwarding functions of the network module 115 are performed in physically separate units so that the control functions can manage multiple different hardware network units.Computer-readable program instructions for performing the inventive methods can typically be downloaded to the computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0020] The WAN 102 is a wide area network (e.g., the Internet) capable of transmitting computer data over distances beyond the local area using any data transmission technology currently known or developed in the future. In some embodiments, the WAN 102 may be replaced and / or supplemented by local area networks (LANs) designed to transmit data between devices located within a local area, e.g., a wireless network. The WAN and / or LANs may typically include computer hardware such as copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0021] The end-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of a company operating the computer 101) and may take any of the forms discussed above in connection with the computer 101. The EUD 103 typically receives helpful and useful data from the operation of the computer 101. For example, in a hypothetical case where the computer 101 is configured to provide a recommendation to an end user, that recommendation is typically transmitted from the network module 115 of the computer 101 to the EUD 103 over the WAN 102. In this way, the EUD 103 may display or otherwise present the recommendation to an end user. In some embodiments, the EUD 103 may be a client device, e.g., a thin client, a heavy client, a mainframe computer, a desktop computer, and so on.

[0022] The remote server 104 is any computer system that provides at least some data and / or functionality to the computer 101. The remote server 104 may be controlled and used by the same entity that operates the computer 101. The remote server 104 represents the one or more machines that collect and store helpful and useful data for use by other computers, e.g., the computer 101. In a hypothetical case where the computer 101 is designed and programmed to provide a recommendation based on historical data, this historical data may be provided to the computer 101, for example, from a remote database 130 of the remote server 104.

[0023] The public cloud 105 is any computer system available for use by multiple entities and that provides on-demand availability of computer system resources, particularly data storage (cloud storage) and computing power, without direct, active management by the user. Cloud computing typically relies on resource sharing to achieve consistency and economies of scale. The direct and active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141.The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the computers of the physical host machine set 142, which is the set of physical computers present in and / or available to the public cloud 105. The virtual computing environments (VCEs) typically take the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. It is understood that these VCEs can be stored as images and transferred within and between the various physical host machines, either as images or after instantiating the VCE.The cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. The gateway 140 is the collection of computer software, hardware, and firmware that enables the public cloud 105 to exchange data over the WAN 102.

[0024] The following provides a more detailed explanation of virtualized computing environments (VCEs). VCEs can be stored as "images." A new active instance of the VCE can be instantiated from the image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like real computers from the perspective of programs running within them. A computer program running in a common operating system can use all of the resources of the corresponding computer, such as connected devices, files and folders, shared network space, CPU power, and quantifiable hardware capabilities.However, programs running inside a container can only use the contents of the container and units assigned to that container, a feature known as containerization.

[0025] Private cloud 106 is similar to public cloud 105 except that the computing resources are available for use by only a single enterprise. Although private cloud 106 is described as communicating with WAN 102, in other embodiments, a private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public), often implemented by different providers. Each of the multiple clouds remains a separate and distinct entity, but the larger hybrid cloud architecture is held together by standardized or proprietary technology that enables orchestration, management, and / or data / application portability between the multiple participating clouds.In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud. Endpoint detection and response (EDR) systems

[0026] Fig. Figure 2 depicts a representative, well-known endpoint detection and response (EDR) system 200. EDR is software designed to protect an organization's end users, endpoint devices, and IT assets against cyber threats that surpass antivirus software and other conventional endpoint security tools. It is typically deployed by a service provider as a service managed on behalf of an enterprise customer. A representative service of this type is IBM. ®Managed Security Services (MSS). EDR continuously collects data from all endpoints in the customer network—desktop and laptop computers, servers, mobile devices, IoT (Internet of Things) devices, etc. It analyzes this data in real time for indications of known or suspected cyber threats and can automatically respond to prevent or minimize damage from any threats it identifies. EDR's threat detection analytics and automated response capabilities can identify and contain potential threats that cross the network perimeter before they can cause serious damage, and these capabilities often require no human intervention. EDR can also provide tools that security teams can use to autonomously detect, investigate, and prevent suspected and emerging threats.

[0027] Specifically, EDR systems typically provide continuous endpoint data collection, real-time analysis and threat detection, automated threat response, threat isolation and remediation, and threat tracking support. To this end, the EDR system 200 includes a set of components, as shown, specifically, a system event aggregator 202, a system correlator 204, a rules library 206, an alert generator 208, data analytics 210, and a management console 212. The system aggregator 202 receives events from connected endpoints. An endpoint (not shown) is a networked device executing system management code (software) that enables management and monitoring of the endpoint by the EDR system. The endpoint is typically a data processing system.The system event aggregator continuously collects data from each endpoint device on the network—data related to processes, performance, configuration changes, network connections, file and data downloads or transfers, and end-user or device behavior. The data is stored in a central database or data lake, typically hosted in the cloud. Most EDR security solutions collect this data by installing a lightweight data collection tool or agent on each endpoint device; some may instead leverage capabilities in the endpoint operating system. EDR uses advanced analytics and machine learning algorithms to identify patterns in real time that indicate known threats or suspicious activity while they are still emerging.In general, EDR looks for two types of indicators: Indicators of Compromise (IOCs), which are actions or events corresponding to a potential attack or breach; and Indicators of Attack (IOAs), which are actions or events associated with known cyber threats or cyber criminals. To identify these indicators, EDR correlates its own endpoint data, using system correlator 204, in real time with data from threat intelligence services (not shown), which provide continuously updated information on new and current cyber threats—the tactics they use, the endpoint or IT infrastructure vulnerabilities they exploit, and so on. Threat intelligence services can be proprietary (operated by the service provider), affiliated with a third party, or community-based.In addition, many EDR solutions can also map data to Mitre ATT&CK, a global knowledge base of cyber threat tactics and methods used by hackers, to which the U.S. government contributes. Data analytics 210 features units and algorithms that conduct their own investigations, comparing real-time data with historical data and established baselines to identify suspicious activity, anomalous end-user activity, and anything that could indicate a cybersecurity incident or threat. They can also distinguish "signals" or legitimate threats from "noise" or false positives, allowing security analysts to focus on the truly important incidents. EDR consolidates key data and analysis results into the central management console 212, which also serves as the solution's user interface (UI).From the console, security team members gain full visibility into every endpoint and endpoint security issue across the organization and initiate investigations, threat responses, and remediations across all endpoints.

[0028] Automation ensures rapid EDR responsiveness. Specifically, based on predefined rules in the rule library 206, which are defined by the security team or learned over time through machine learning algorithms, the EDR solution can automatically alert security analysts to specific threats or suspicious activity through the alert generator 208. For example, the alert generator 208 can automatically generate a "backtracking report" that tracks every stage of an incident or threat in the network up to its resolution.trace its root cause, disconnect an endpoint device or log an end user off the network, stop system or endpoint processes, prevent an endpoint from executing ("firing") a malicious or suspicious file or email attachment, cause anti-virus or anti-malware software to scan other endpoints on the network for the same threat, etc. After isolating a threat, EDR provides capabilities that security analysts can use to further investigate the threat.For example, forensic analysis can help security analysts determine the root cause of a threat, identify the various files affected by it, and identify the vulnerability or thresholds the attacker exploited to penetrate and navigate the network, gain access to credentials for authorization, or perform other malicious activities. With this information, analysts can use threat remediation tools to eliminate the threat. Remediation may involve destroying malicious files and deleting them from endpoints; restoring corrupted configurations, registry entries, data, and application files; applying updates or fixes to address vulnerabilities; and updating detection rules to prevent recurrence.

[0029] As also mentioned, the EDR system can include support for threat intelligence (also known as cyber threat intelligence). Threat intelligence is a proactive security measure in which a security analyst scans the network for unknown threats or known threats that have yet to be detected or remediated by the company's automated cybersecurity tools. Threat investigators use a variety of tactics and methods, typically leveraging the same data sources, analysis, and automation capabilities that EDR uses for threat detection, response, and remediation. To support threat intelligence, EDR provides these capabilities to security analysts through UI-based or programmatic means, allowing them to perform ad hoc searches, data queries, correlations with threat data, and other investigations.EDR tools specifically designed for threat investigation include everything from simple scripting languages ​​(for automating common tasks) to natural language query tools.

[0030] As mentioned above, while EDR solutions offer considerable advantages, they also have certain disadvantages, predominantly due to the high number of alerts, the presence of many false positives, and the lack of enrichment or contextualization of alerts. These problems lead to analyst fatigue and delayed investigations into more relevant alerts. The methods in this disclosure address these and other disadvantages of known EDR solutions. Automated detection of observations and automated rejection of alerts using machine learning

[0031] With the above in mind, the methods of this disclosure will now be described. As will become clear below, the approach described herein is typically used in conjunction with a (e.g., Fig. 2) to provide an automated threat handler for endpoint and network assets. The solution can be an add-on to the EDR system, it can be integrated into the EDR system, or it can be deployed as a standalone system or function, e.g., as a microservice.As described below, the system uses a combination of automated observation detection, threat data enrichment, graph analytics, and supervised machine learning to machine-predict analyst behavior in classifying alerts generated by an EDR system (as "true" or "false" positives) and to (i) support automated alert suppression for those alerts that can be classified with sufficient confidence, or (ii) for those alerts that cannot be classified with sufficient confidence, to support the provision of recommendations to analysts to enable their response activities.

[0032] Specifically, the approach described herein provides a method, apparatus, and computer program product for suppressing the number of alerts and reducing alert processing time in conjunction with an endpoint detection and response (EDR) system. These benefits are achieved using a machine-based prediction service (e.g., a microservice) operating in conjunction with or as part of the EDR system. In response to receiving an alert from the EDR system, the alert content is analyzed to detect one or more "observations" in the alert that indicate potentially suspicious activity. Representative observations include, for example, high-risk hash functions, encrypted commands, a number of command scripts, the presence of IP addresses in command lines, the presence of a shell script, and the like.The set of one or more observations identified in the alert content (e.g., the value of a hash function, a specific IP address identified in a command line, etc.) is then evaluated using a threat intelligence service, which returns the set of observations (or at least one of them) enriched with additional information (obtained from the threat intelligence service) useful for assessing the level of risk posed by the threat. The set of threats and their enrichment provided by a threat intelligence service exhibit a pattern. An observation may sometimes be referred to herein as a "feature." An additional enrichment level is then performed on one or more (or all) of the enriched observations in the pattern using graph-based analytics.

[0033] For this purpose, the enriched observations (as a sample) are then provided to a graph database, for which graph analysis is performed to identify a set of graph features that constitute a complete set of enriched features for the EDR alert. Representative graph features typically include alert-related data (e.g., the number of alerts, the number of alerts within a given time period, the number of entities associated with the alerts, the percentage of escalated alerts, and the like) as well as one or more graph-related metrics such as PageRank, community, centrality, proximity, and degree for each node in the sample. Some or all of the information obtained from the graph-related enrichments is then incorporated into the alert.The output of this alert processing pipeline is a normalized EDR alert, which is then applied to a machine learning model previously trained on previous EDR alerts collected and processed in a similar way. The result is a prediction for the alert in question.

[0034] The prediction preferably classifies the alert as either a "true" positive or a "false" positive, along with a confidence level that represents the degree of confidence in the machine-generated prediction. Depending on the machine confidence, the system then processes the alert without making the alert available to an analyst. As mentioned above, this is an automated triage. If the machine confidence level is sufficiently high, e.g., at or above a configurable threshold such as 90%, the system thus performs an automated action. For example, for a "true" positive, the system automatically triages the alert by, for example,escalated by providing tools with a command or control to initiate automated remediation, or the like; conversely, if the machine confidence is sufficiently high for a "false" positive, the system automatically closes the alert. In both cases, the number of alerts is reduced because the alert does not need to be processed directly by an analyst. This is referred to above as alert suppression. However, if the machine confidence is not sufficiently high, instead of performing automated remediation, the system issues an alert prediction for the EDR alert, e.g., to an analyst dashboard.To facilitate the processing of alerts for which machine confidence is not sufficiently high to trigger automated rejection, the alert prediction preferably contains various types of information to assist the analyst in expeditiously processing the alert. This information includes, for example, the observations detected in the alert content, a historical analysis explaining the machine decision, and an identification of past behaviors (e.g., rare events).

[0035] Automated detection of observations for graph-based feature detection, along with automated alert triage where possible (based on machine confidence in a prediction), significantly reduces the overall analyst workload for the EDR system. Even if a machine-based prediction doesn't have sufficient confidence to allow the analyst to bypass it, the system further provides the analyst with additional context and enrichment to facilitate more timely (or at least more efficient) alert processing.

[0036] Fig. 3 is a general illustration of the threat processing solution 300 of this disclosure. As described below, in one embodiment, this solution is implemented as a microservice associated with the EDR system. Microservices is an application architecture in which an application is composed of many separate, network-connected components called microservices. This type of architecture allows large, monolithic applications to be divided into smaller services. A single, network-accessible service is the smallest deployable unit for a microservice application. Each service executes in its own process, e.g., a container or other lightweight deployment mechanism.

[0037] As shown, the solution is based on the warning message generator of the EDR system (e.g. generator 208 from Fig. 2) and receives a stream of MDR (Managed Detection and Response) alerts 302. Specifically, an alert received from the source EDR system is received and forwarded by the alert generator to the automated threat handler microservice of this disclosure. In this example embodiment, the alert undergoes feature engineering, represented by reference numeral 304. As described in detail below, feature engineering 304 involves identifying / detecting observations in the alert and associating contextual information and enrichment to the alert based on these detected observations. Observations are typically hidden within the alert content, but may also be present directly within the alert content.Observations include, but are not limited to, suspicious IP addresses, high-risk hash values ​​such as MD5 or SHA256, embedded encoded commands, download commands, and suspicious shell scripts (e.g., PowerShell scripts). While these are the primary features used for data enrichment and feature engineering, they are not intended to be limiting. The first part of Feature Engineering 304 includes automated detection of observations for this purpose, e.g., in the command line of the input data, as identified in the alert. As described in . Fig. 3, and after identifying the observations, the observations (or their values) are then processed by a threat intelligence service 306 (e.g., IBM X-Force Exchange (XFE)) to determine whether there is any known threat intelligence related to the observation(s). IBM X-Force Exchange is a cloud-based threat intelligence platform that, powered by human- and machine-generated data, enables users to use, share, and act on threat intelligence. Other threat intelligence services (e.g., AlienVault, now AT&T ® Cybersecurity) can also be used for this purpose.

[0038] Access to the threat intelligence service 306 is typically automated, e.g., via an application programming interface (API). The threat intelligence service 306 analyzes and normalizes alert data received in the alert and returns baseline data (the one or more observations) augmented with the threat intelligence. The observations, now augmented with threat intelligence, are then used as one or more additional inputs to a next stage of feature engineering, which includes graph analysis. According to this aspect, the observations are provided to a pipeline 308, which cleans the observations and formats them as a pattern (an alert graph) and loads the data into a graph database 310 (DB) for graph analysis.This part of feature engineering involves computing graph features that identify relationships between and within the nodes of the pattern graph, as well as the importance of each node in the graph. The graph analysis of feature engineering yields a set of graph features. Without being intended as a limitation, graph features include alert-related data (e.g., the number of alerts, the number of alerts within a given time period, the number of entities associated with the alerts, the percentage of escalated alerts, and the like) as well as one or more graph-related metrics such as PageRank, community, centrality, proximity, and degree for each node in the pattern. As mentioned above, some or all of the information obtained from the graph-related enrichments is incorporated into the alert.The output of this alert processing pipeline 308 (which includes the threat data and the graph analysis enrichments applied to the detected observations) is sometimes referred to herein as an EDR-normalized alert.

[0039] As illustrated, the EDR-normalized alert is then provided as a request to a prediction microservice 312. The prediction microservice 312 has an associated model 314 created by supervised machine learning 316 using training data collected from past analyst behavior and stored in a KI database 318. The past analyst behavior is the record of past alerts previously detected by the system over a specific period of time (e.g., measured in days, weeks, months, and the like), along with their associated "labels" and related confidence level information. In other words, supervised machine learning is performed on the dataset, with the enriched features serving as the predictors and the past analyst behavior serving as the labels.The result of machine learning is pre-computed scoring models that predict the alert outcome as either "true" or "false" positive. As described below, the system also provides machine confidence and, under certain circumstances, additional information, such as key observations, an easy-to-understand explanation of the recommendations, and a statistical analysis of similar behavior observed in the past.

[0040] With further reference to Fig. 3, in response to receiving the request, the prediction microservice 312 applies the EDR-normalized alert to the machine learning model 314 and generates a prediction for the alert in question (an "alert prediction"). Each alert prediction includes an indication of whether the alert is considered a "true" or "false" positive by the system, as well as a level of confidence the machine assigns to that prediction. Depending on the machine's confidence in the prediction, one of several actions is performed. Specifically, if the machine's confidence in the prediction is below a configurable confidence threshold, the alert prediction is further enriched and passed through the pipeline 308 to an analyst dashboard in a unified console 320.The unified console 320 is typically a dashboard shared by a group of analysts responsible for processing EDR alerts. As illustrated, in this scenario, the alert prediction typically includes additional information (e.g., the observations, the machine's conclusions, historical or statistical information on similar alerts or events, and the like) that can be used to assist an analyst in processing the alert.

[0041] However, if the machine's confidence in the prediction is sufficiently high, there is no reason to forward the alert for processing by an analyst. In such a case, the pipeline 308 is further configured according to this disclosure to perform automated alert triage. In this way, the alert is suppressed, reducing the total number of alerts presented to the group of analysts via the dashboard or otherwise.

[0042] When deployed in an EDR environment (or more generally in conjunction with a managed security system), the method described above reduces the overall workload of analysts by suppressing the number of alerts. For alerts not subject to automated triage, the system also reduces alert processing time by providing threat intelligence-enriched data with automatically detected observations and machine recommendations.

[0043] Fig. Figure 4 provides a more detailed illustration of the automated processing described above. As mentioned above, the system receives alerts from an EDR alert controller 400. The one or more alerts are received in the prediction microservice 402. The prediction microservice 402 forwards the alerts for data cleansing and transformation 404 as needed to facilitate further processing. After data cleansing and transformation, feature engineering 406 is initiated to detect the observations in the alert. At 408, the alert is enriched by providing the identified observations to the threat intelligence service 409. The resulting threat intelligence-enriched observations comprise the pattern (of observations) for the alert, and this dataset is then loaded into the graph database 411 for graph feature extraction at a step 410.Using graph analysis 412, graph features are generated. Coding and normalization 414 are then performed on the generated graph features to facilitate subsequent prediction using machine learning. For this purpose, one or more models 415 are available to the prediction system, which were previously trained with historical data, as described. The models are updated regularly or continuously, e.g., when the system generates predictions. In 416, a prediction operation is performed on the current data set using the models 415 to generate the prediction for the current alert being processed. As mentioned, the prediction (whether the alert is a "true" or "false" positive) also includes a machine confidence regarding this prediction. In 418, the system also generates additional information, e.g.,an explanation, a statistical analysis of similar behavior observed in the past, and the like. At 420, the system generates a recommendation for processing, which is returned to the prediction microservice 402. Whether the alert in question is suppressed (automatically triaged) or returned for analyst processing typically depends, as mentioned above, on the machine confidence level associated with the alert prediction. If the alert is not automatically triaged, it is provided to the analyst console 422 for display, where it is then selected for processing by an analyst 424.

[0044] In one non-limiting embodiment, the solution described above may be implemented as a set of containerized, cloud-native applications that are portable and can be freely scaled and deployed across multiple clusters and regions. Fig. Figure 5 illustrates a representative architecture. In this embodiment, two different modules are deployable: a Python-based microservice 502 and a Neo4J graph database 504. Deployment is preferably automated, flexible, and oriented toward an on-demand infrastructure. For example, and without limitation, deployment may be achieved through a container platform 500, e.g., Red Hat ® OpenShift ®, and a continuous delivery infrastructure 506, e.g., Weaveworks Flux, as well as GitHub pull requests, a Kubernetes cluster management approach, and application delivery called GitOps 505. This approach to deployment gives an organization more control and ownership over the release process, enabling true continuous delivery with low risk, a highly granular audit trail, and increased operational velocity. To this end, a YAML file (a human-readable data serialization language) in a GitHub repository deployed as a managed service enforces system conformance for each deployable module, ensuring that the OpenShift cluster configuration matches the configuration in the repository, and automates deployment by using an operator 508 in the cluster to trigger deployments within OpenShift.The operator manages all relevant image repositories 510, detects new images, triggers deployments, and updates the desired executed configurations based on this file. After deployment, a scheduled scheduling activity is preferably also configured in the cluster to run regularly (e.g., daily) and provide model training. The model training is then pushed to a persistent volume (PV) of the OpenShift cluster and stored there. The PV is accessed by the Python microservice, which retrieves the most accurate version of the model.

[0045] Fig. Figure 6 depicts the solution implemented as a service-oriented architecture (SOA). Specifically, the processing pipeline is divided into different modules to provide a loose connection. Each module has a set of procedures (services) exposed as procedure APIs. The modules exchange data with each other through these APIs. A representative architecture is as follows: The Resources Director module 600 contains training and prediction-related resources, such as Cypher queries and SQL queries. Resources such as models and dictionaries are created and then used during prediction. They are located in a resource directory.

[0046] The mdr_aedpr module 602 is the main module containing the main pipelines for training and prediction. This module has two submodules: mdr_aedrp.train and mdr_aedpr.run. The mdr_aedrp.train submodule 604 supports the training pipeline. From this training pipeline, other modules necessary to generate the training module are called sequentially and as needed. This pipeline also generates the model, which is stored in the resource directory. The mdr_aedpr.run submodule 606 is used to design the prediction pipeline. From here, all other modules related to prediction are called sequentially and as needed. This submodule also generates a set of answers for a part of the prediction.

[0047] The mdr_aedpr_ingest module 608 is used to assist in generating / preparing training data by retrieving this data from a database.

[0048] The mdrbase module 610 contains the utility scripts required by the various modules in the architecture.

[0049] The mdr_spikedetection module 612 is used to remove spikes detected in the training data and, in response, return data without spikes. This eliminates any bias in the training data.

[0050] The mdr_aedpr_db module 614 provides all the APIs for connecting to the database (SQL / Neo4j, etc.), along with the scripts required to create database (DB) clients.

[0051] The mdr_aedpr_graph_analytics module 616 comprises the APIs related to graph analytics. This includes ingesting data into Neo4j, performing graph analysis on the ingested data, and returning features using machine learning (e.g., PageRank, community detection, etc.) for training.

[0052] The mdr_aedpr_explainmodel module 618 includes the APIs related to model explanation. It provides the APIs related to model explanation. Specifically, it provides the explanation of the model's alert prediction. The explanation typically includes specific observations made during the prediction, along with a historical analysis of similar alerts identified in the overall training data or on a client-by-client basis.

[0053] The web module 620 exposes the system as a Python microservice. This module receives an alert request from the alert controller, which in turn sends an alert to the prediction pipeline and compiles an API response with the results received from the prediction pipeline. The final response is then sent back to either the controller or the display.

[0054] The Fig. 5 and Fig. The implementations presented in 6 are not intended as a limitation.

[0055] The managed service (or the automated threat handler itself) typically implements a comprehensive review process to ensure that accurate and timely feedback is provided to the machine learning of this disclosure. Specifically, when making a deprecation decision based on the information provided by the system, analysts can rate the machine recommendations and supporting recommendations as "positive" or "negative," thereby providing input for future learning. In addition, regular (e.g., daily) review is preferably performed, e.g., for high-confidence alerts, to ensure that the solution does not automate deprecations incorrectly. As mentioned, review feedback is preferably integrated into the learning process. Example of alert processing

[0056] To illustrate the processing described above, Fig. 7 illustrates an example EDR alert 700. As illustrated, the alert has a set of attributes on the left and the values ​​of the attributes on the right. As illustrated, some of the values ​​may be masked. Once the alert data is received in the system, it is automatically enriched, supplemented with threat intelligence, and contextualized to detect specific attributes, i.e., the observations, as previously described. Fig. Figure 8 illustrates the observations 800, an indication or counter 802 for each observation, and the threat data 804. In the example, the MD5_Risk observation is classified as "high" because 21 instances of the MD5 signature were detected in the threat data. The data also shows that there are no PowerShell or shell scripts, downloads, or CURL scripts in the command line (cmdline). One command script was identified. As mentioned above, the next stage of enrichment and feature engineering occurs through graph analysis. In one embodiment, the system uses Neo4J as the downstream graph database, but this is not a limitation, as the solution can be implemented using any graph database. A general graph data model 900 for entities (nodes) and relationships for a typical customer alert is shown in Fig. 9. As shown, the Cmd node refers to the command line, and the observations (shell / PS script detected, download detected, encoded command detected, IP address detected, number of scripts, IP reputation, etc.) are listed as properties of the Cmd node. Fig. Figure 10 illustrates the customer alert data model 1000 using a Neo4J browser used for visualization.

[0057] The methods described herein have significant advantages. They enable a unique application of machine learning and graph data science to reduce the number of alerts by automatically triaging alerts for EDR systems. The approach uses graph data science and analytics to identify community behaviors and relationships using the identified features and improve prediction accuracy with machine learning. The system automatically detects relevant objects (observations) in EDR alerts, helping both a machine and an analyst make faster decisions. Furthermore, rare event detections and automatically generated explanations are provided to support machine recommendations.The approach described herein leverages supervised machine learning for analyst actions to determine threat severity. More generally, the approach provides alert detection and triage based on supervised methods using machine learning and graph analytics. Supervised machine learning and graph analytics are used to establish relationships between nodes in a graph and use these features to guide analyst behavior. As described, the approach enables supervised machine learning and graph analytics for violation / alert triage.

[0058] Generally speaking, the method according to this disclosure may be implemented as a standalone approach, e.g., as a software-based function executed by a processor, or it may be available as a managed service (e.g., as a web service via a SOAP / XML interface). The respective hardware and software implementation details described herein are for illustrative purposes only and are not intended to limit the scope of the described subject matter.

[0059] More generally, data processing units in connection with the disclosed subject matter are each a data processing system (as described, for example, in Fig. 1), comprising hardware and software, where these entities exchange data with each other over a network such as the Internet, an intranet, an extranet, a private network, or any other data transmission medium or data connection. The applications in the data processing system provide native support for Web and other well-known services and protocols, including, but not limited to, support for HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL. Information on SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information on HTTP, FTP, SMTP, and XML is available from the Internet Engineering Task Force (IETF). Familiarity with these well-known standards and protocols is assumed.

[0060] As in Fig.1, the scheme described herein may be implemented in or in conjunction with various server-side architectures, such as simple N-tier architectures, web portals, federated systems, and the like. The methods described herein may also be implemented, in whole or in part, in a loosely coupled server environment (including a cloud-based environment).

[0061] More generally, the subject matter described herein may be in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that includes both hardware and software elements. In a preferred embodiment, the functionality is implemented in software, including, but not limited to, firmware, in-memory software, microcode, and the like. Furthermore, as noted above, the functionality described above may be in the form of a computer program product accessible via a computer-usable or computer-readable medium that provides program code usable by or in connection with a computer or any other instruction execution system.For the purposes of this specification, a computer-usable or computer-readable medium can be any device that can contain or store the program used by or in connection with the system, apparatus, or device for instruction execution. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or corresponding device or device). Examples of a computer-readable medium include semiconductor or solid-state memory, magnetic tape, a removable computer diskette, random access memory (RAM), read-only memory (ROM), a magnetic hard disk, and an optical disk. Current examples of optical disks include compact disk read-only memory (CD-ROM), compact disk read / write (CD-R / W), and DVD. The computer-readable medium is a tangible item.

[0062] In a representative embodiment, the code (a combination of automated observation detection, threat intelligence enrichment, graph analysis, supervised machine learning, and alert processing) of this disclosure is implemented in a special-purpose computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with the one or more processors, and the software may be implemented as one or more computer programs. Taken together, this special-purpose hardware and software comprises the system described above.

[0063] Although the above describes a particular order of operations performed by particular embodiments of the disclosed subject matter, it should be understood that such an order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc. References in the specification to a particular embodiment mean that the described embodiment may include a particular feature, structure, or characterizing element, but not every embodiment necessarily includes the particular feature, structure, or characterizing element.

[0064] Finally, although certain components of the system have been described separately, those skilled in the art will appreciate that some of the functions may be combined or used together in certain instructions, program sequences, code sections, and the like.

[0065] Although the methods described herein are particularly well-suited for EDR alert processing, this is not a limitation. The alert in question may be generated by a different type of security service, security system, security unit, or solution.

[0066] When used as described, the methods described herein provide improvements to a broader technological or technical field, specifically EDR systems, as well as improvements to the operational capabilities of such systems.

[0067] Following the description of the subject matter, the following is now claimed.

Claims

[1] A method for a threat response associated with an endpoint detection and response system, EDR system, wherein a threat is identified in an alert, comprising: in response to receiving an alert, automatically detecting one or more observations in the alert, where an observation is information that potentially indicates suspicious activity; Enriching the one or more observations detected in the alert by using threat intelligence to generate a pattern; Applying the pattern through graph analysis to identify a set of one or more graph features associated with the pattern; Applying the set of one or more graph features by a machine learning model trained to classify past analyst behavior and machine-generating a prediction, wherein the machine-generated prediction has a confidence level associated with it; and based at least in part on the confidence level, performing an action that is one of the following: automated suppression of the alert and returning the prediction along with additional contextual information to facilitate alert processing. [2] The method of claim 1, wherein the observations are detected within input data related to the alert message and are one of the following observations: IP addresses, hash values, embedded commands, download commands, command scripts, a presence of a shell script, command scripts detected within input data related to the alert message. [3] The method of claim 1, wherein the one or more graph features are one of the following graph features: PageRank, community, centrality, closeness, and degree for one or more nodes in a graph associated with the pattern. [4] The method of claim 1, wherein the machine-generated prediction is that the alert is one of the following alerts: a true positive alert or a false positive alert. [5] The method of claim 1, further comprising training the machine learning model in a supervised manner by using past analyst behavior as labels and the set of graph features as predictors. [6] The method of claim 1, wherein the additional context information includes one or more of the following context information: the observations detected in the alert content, a historical analysis explaining the machine-generated prediction, and an identification of behaviors or events that have occurred in the past. [7] The method of claim 1, wherein the method is implemented as a microservice in conjunction with the EDR system. [8] Device comprising: a processor; a computer memory having computer program instructions executed by the processor for a threat response associated with an Endpoint Detection and Response (EDR) system, wherein a threat is identified in an alert, the computer program instructions comprising program code configured to: in response to receiving an alert, automatically detect one or more observations in the alert, where an observation is information that potentially indicates suspicious activity; enrich the one or more observations detected in the alert by using threat intelligence to generate a pattern; apply the pattern through graph analysis to identify a set of one or more graph features associated with the pattern; applying the set of one or more graph features by a machine learning model trained to classify past analyst behavior and machine-generating a prediction, wherein the machine-generated prediction has an associated confidence level; and based at least in part on the confidence level, perform an action that is one of the following: automated suppression of the alert and returning the prediction along with additional contextual information to facilitate alert processing. [9] The apparatus of claim 8, wherein the observations are detected within input data related to the alert message and are one of the following observations: IP addresses, hash values, embedded commands, download commands, command scripts, a presence of a shell script, command scripts detected within input data related to the alert message. [10] The apparatus of claim 8, wherein the one or more graph features are one of the following graph features: PageRank, community, centrality, proximity, and degree for one or more nodes in a graph associated with the pattern. [11] The apparatus of claim 8, wherein the machine-generated prediction is that the alert is one of the following alerts: a true positive alert or a false positive alert. [12] The apparatus of claim 8, wherein the program code is further configured to train the machine learning model in a supervised manner by using past analyst behavior as labels and the set of graph features as predictors. [13] The apparatus of claim 8, wherein the additional context information includes one or more of the following context information: the observations detected in the alert content, a historical analysis explaining the machine-generated prediction, and an identification of behaviors or events that have occurred in the past. [14] The apparatus of claim 8, wherein the method is implemented as a microservice in conjunction with the EDR system. [15] A computer program product in a computer-readable medium, the computer program product comprising computer program instructions executed by a processor for a threat response associated with an endpoint detection and response (EDR) system, wherein a threat is identified in an alert, the computer program instructions comprising program code configured to: in response to receiving an alert, automatically detect one or more observations in the alert, where an observation is information that potentially indicates suspicious activity; enrich the one or more observations detected in the alert by using threat intelligence to generate a pattern; apply the pattern through graph analysis to identify a set of one or more graph features associated with the pattern; applying the set of one or more graph features by a machine learning model trained to classify past analyst behavior and machine-generating a prediction, wherein the machine-generated prediction has an associated confidence level; and based at least in part on the confidence level, perform an action that is one of the following: automated suppression of the alert and returning the prediction along with additional contextual information to facilitate alert processing. [16] The computer program product of claim 15, wherein the observations are detected within input data relating to the alert message and are one of the following observations: IP addresses, hash values, embedded commands, download commands, command scripts, a presence of a shell script, command scripts detected within input data relating to the alert message. [17] The computer program product of claim 15, wherein the one or more graph features are one of the following graph features: PageRank, community, centrality, closeness, and degree for one or more nodes in a graph associated with the pattern. [18] The computer program product of claim 15, wherein the machine-generated prediction is that the alert is one of the following alerts: a true positive alert or a false positive alert. [19] The computer program product of claim 15, wherein the program code is further configured to train the machine learning model in a supervised manner by using past analyst behavior as labels and the set of graph features as predictors. [20] The computer program product of claim 15, wherein the additional context information includes one or more of the following context information: the observations detected in the alert content, a historical analysis explaining the machine-generated prediction, and an identification of behaviors or events that have occurred in the past.

Images