Adaptive data collection for alarms

Abstract

Embodiments of the present disclosure relate to adaptive data collection for alarms. In some examples, a system monitors operations in at least one electronic device that an entity is initiated, created, or modified, and generates an alert based on the monitoring. The system adapts the amount of data collected based on contextual information associated with the alert, wherein adapting the amount of data collected includes determining whether to include or exclude data associated with the subset of entities based on any relationship of the subset of entities with entities associated with the alert.

Description

Background Art

[0001] Electronic devices may experience various security issues that may cause electronic devices to malfunction or data to be lost or stolen. For example, electronic devices may be the target of attacks by various malicious entities, including people, programs (e.g., viruses, worms, malware, etc.), and / or machines. Other types of security issues that electronic devices may experience include electronic devices accessing potentially malicious or infected online resources (e.g., websites with low reputation scores, certain social media sites, etc.), electronic devices transmitting sensitive data in an unsecured manner or with unauthorized entities, electronic devices accessing programs on unknown networks, electronic devices updating programs or failing to update programs to a specific version, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some implementations of the present disclosure are described with respect to the following figures.

[0003] Figure 1 is a block diagram of an example arrangement including a security system coupled with various electronic devices according to some examples.

[0004] Figure 2-Figure 3 is a diagram illustrating an example of adaptive data collection by a security system according to some implementations of the present disclosure.

[0005] Figure 4-Figure 5 is a diagram illustrating an example of an intelligent response of a security system to a corresponding alarm according to some implementations of the present disclosure.

[0006] Figure 6 is a block diagram of a security system according to some examples.

[0007] Figure 7 is a flow diagram of a process according to some examples.

[0008] Throughout the drawings, the same reference numerals denote similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the dimensions of some components may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0009] The security system may generate an alert in response to detecting an event indicative of a potential security issue. In some cases, the security system may include an endpoint security mechanism as part of an electronic device. The endpoint security mechanism runs locally in the respective electronic device to detect events indicative of a potential security issue. Examples of endpoint security mechanisms may include malware scanners capable of detecting the presence of malware (e.g., viruses, worms, malware, etc.), user and entity behavior analysis (UEBA) mechanisms for detecting anomalies in the behavior of users or other entities, lateral movement detectors, and the like.

[0010] The security system may generate an alert due to an operation in the electronic device, where the operation may include activities associated with one or more entities in the electronic device. An entity may include any one or some combination of a process, an object, a resource, a user, etc.

[0011] A "process" may refer to a program (including machine-readable instructions) executed in an electronic device. A process in an electronic device may cause execution of another process in the electronic device (or another electronic device).

[0012] Additionally, a process may create or modify an object in an electronic device. As an example, an "object" may refer to an artifact, configuration information, a network connection, a scheduled task such as in a queue or an application programming interface (API) or library call, a user account.

[0013] An artifact may refer to a file, a database, or any other type of data that is created or modified (updated or deleted) as part of a process operation. Configuration information relates to the configuration of an electronic device or a component in an electronic device. In one example, a registry (such as associated with an operating system (OS) of an electronic device) may include configuration information related to settings, options, or other values ​​of hardware and software components in the electronic device. A process may create a registry or modify a registry. A registry may include multiple registry entries related to different settings, options, or other values ​​of hardware and software.

[0014] A process can also establish, modify, or tear down a network connection. Additionally, a process can add a scheduled task to a queue, or make calls to an API or library.

[0015] A resource may refer to a website, a domain name system (DNS) server, or any other type of resource that can be accessed by an electronic device. A file may be downloaded from a website. A process may interact with a website. An electronic device may interact with a DNS server to obtain an Internet Protocol (IP) address associated with a domain name. There are many other examples of resources that may interact with an electronic device.

[0016] The security system can collect various data related to the operation of the electronic device for analysis to determine whether an attack is occurring and what remedial actions to take if an alarm occurs. The collected data may include information related to the entity group associated with the alarm and information about other entities that may be directly or indirectly related to the entity associated with the alarm. An entity group is "associated with an alarm" if activities involving the entity group cause the security system to issue an alarm. The alarm provides an indication that a problem has been detected that may indicate an attack has occurred in the electronic device. In some examples, the collection of data can be triggered by the occurrence of one or more alarms. The data collection triggered by one or more alarms can be in addition to the data collected in the electronic device as part of the operation of the electronic device.

[0017] There may be a difficult balance between collecting enough data so that meaningful analysis can be performed in response to one or more alerts, but not collecting too much data, thereby wasting system resources and potentially causing the amount of data collected to exceed one or more target data volume thresholds. One or more target data volume thresholds may be preconfigured and may be specified by a human administrator, a program, or a machine. In one example, one or more target data volume thresholds may include a soft target data volume threshold and a hard target data volume threshold for a given time interval (e.g., a 24-hour time interval, a weekly time interval, etc.). If the amount of data collected in a given time interval exceeds the soft target data volume threshold, the security system may reduce the amount of data collected after the soft target data volume threshold is exceeded. If the amount of data collected in a given time interval exceeds the hard target data volume threshold, the security system may stop collecting any other data in the given time interval.

[0018] For example, if a given time interval is 24 hours, collecting too much data early in the 24 hour interval may cause the electronic device to be more risky later in the 24 hour interval because the security system is forced to collect less data or is prevented from collecting any further data because one or more target data volume thresholds have been exceeded.

[0019] According to some implementations of the present disclosure, an adaptive data collector is provided for adapting the amount of data collected in an electronic device (or multiple electronic devices) based on contextual information associated with a detected alarm. Adaptive data collection based on contextual information allows the amount of data collected to vary based on various indicated contexts.

[0020] Examples of context that may be represented by context information may include any one or some combination of the following: a severity context for indicating the severity of an alert, a risk context for indicating the risk of an alert, an exception context for indicating the uniqueness of an exception associated with an alert, a type context for indicating the type of an alert, an intelligence context for indicating intelligence associated with an alert, a unified context relating to events occurring across multiple electronic devices, and the like.

[0021] The data collected by the adaptive data collector relates to the operation of an entity in a system including one or more electronic devices and a network to which the one or more electronic devices are connected. Examples of data that can be adaptively collected by the adaptive data collector in association with an alert can include any one or some combination of the following: the type of program that started the process or the identity of the program; the type of object that was created or modified or the identity of the object; the type of resource involved in the operation of one or more electronic devices or the identity of the resource; the type of operation involved (e.g., a write to a disk, an unmap or map operation, access to an external network location, a copy or move of an object such as a sensitive file has been performed, etc.); time information associated with the activity of the entity; location data related to the entity (e.g., geographic data such as global positioning system (GPS) data, whether the entity was inside or outside a geofence when the entity attempted to access an object or resource, etc.); information about the network to which the entity is currently connected or is attempting to access; information about relationships between entities (e.g., a first process starts a second process, a process creates or modifies an object, an artifact contains program image data for a program, etc.); and various other types of information.

[0022] Figure 1 1 is a block diagram of an example arrangement including a security system for protecting various electronic devices. The security system includes a central security service 102 and endpoint security engines 104-1 to 104-N (N≥1) included in respective electronic devices 106-1 to 106-N.

[0023] Examples of electronic devices include any one or some combination of the following: a desktop computer, a notebook computer, a tablet computer, a server computer, a smart phone, an Internet of Things (IoT) device, a home appliance, a game console, a vehicle or a vehicle controller, a storage system, a communication node, etc. For example, electronic devices 106-1 to 106-N may be located in a network of an enterprise. "Enterprise" may refer to a commercial enterprise, an educational organization, a government agency, an individual, any user group, or any other organization. An enterprise network may include a local area network (LAN), a wide area network (WAN), etc. Some electronic devices may be coupled to an enterprise network via a public network such as the Internet.

[0024] The endpoint security engines 104-1 to 104-N run locally in the electronic devices 106-1 to 106-N to detect events indicating potential security issues. Examples of endpoint security engines may include malware scanners capable of detecting the presence of malware (e.g., viruses, worms, malware, etc.), user and entity behavior analysis (UEBA) mechanisms that detect anomalies in the behavior of users or other entities, lateral movement detectors that detect lateral movement of attacking entities across electronic devices in a network, and the like.

[0025] Each endpoint security engine 104-i (i=1 to N) can be implemented using one or more agents, where "agent" can refer to a software module that is executed in the electronic device 106-i to perform security functions. The (multiple) agents of the endpoint security engine can be executed on a hardware processing circuit, which can include any one or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0026] exist Figure 1 In the example of , endpoint security engines 104-1 to 104-N can interact with a central security service 102 to enable the central security service 102 to provide protection for multiple electronic devices. A "central" security service can refer to any service that can interact with one or more electronic devices to provide security services, thereby protecting one or more electronic devices from attacks. The central security service can be provided in the cloud, at a server, or at any other centralized location that allows the central security service to interact with multiple electronic devices.

[0027] According to some implementations of the present disclosure, each endpoint security engine 104-i includes a corresponding adaptive data collector 150-i, which adaptively collects data related to operations in the electronic device 106-i based on context information 152-i in response to an alert. For example, the endpoint security engine 104-1 includes an adaptive data collector 150-1, which adaptively collects data based on context information 152-1 received by the adaptive data collector 150-1. The endpoint security engine 104-N includes an adaptive data collector 150-N, which adaptively collects data based on context information 152-N received by the adaptive data collector 150-N in response to an alert.

[0028] The central security service 102 similarly includes an adaptive data collector 154 that adaptively collects data based on contextual information 156 received by the adaptive data collector 154. Each adaptive data collector 150-i may include machine-readable instructions as part of the corresponding endpoint security engine 104-i, and the adaptive data collector 154 may include machine-readable instructions as part of the central security service 102.

[0029] In some examples, each endpoint security engine 104-i also includes a corresponding intelligence response module 108-i, which can include machine-readable instructions as part of the corresponding endpoint security engine 104-i. The central security service 102 can also include an intelligence response module 110, which can include machine-readable instructions as part of the central security service 102.

[0030] The intelligence response module (any one or a combination of 108-1 to 108-N and 110) can detect that an alarm has been generated in one or more electronic devices, identify any entities outside the alarm range, and determine whether any remedial action should be taken relative to these entities outside the alarm range. The alarm can be generated by the security system (central security service 102 and / or endpoint security engine 104-1 to 104-N) based on the alarm generation rule. In some examples, the security system can apply machine learning to generate the alarm. Upon detecting one or more alarms, the intelligence response module 108-1 to 108-N and 110 can trigger the adaptive data collector 150-1 to 150-N and 154 to collect data. The data collected by the adaptive data collector 150-1 to 150-N and 154 can be fed to the intelligence response module 108-1 to 108-N and 110. The intelligence response module 108-1 to 108-N and 110 processes the collected data to identify entities outside the alarm range and determine any remedial actions taken in response to the alarm.

[0031] Typically, an entity is "outside the scope" of an alert if an alert does not provide any indication of a security issue associated with the entity. For example, an alert may be issued when a first process starts a second process. After the alert is issued, the second process may start a third process, and the third process may create or modify an artifact. The artifact created or modified by the third process may be outside the scope of the alert because the artifact is not directly related to the first process or the second process (e.g., the artifact is not created or modified by the first process or the second process). As a result, the alert may not indicate that the artifact causes a security issue. In another example, if a fourth process is part of a chain of entities that is separate from the chain of entities that includes the first process and the second process, the fourth process may be outside the scope of the alert.

[0032] As yet another example, a registry entry or other object may be outside the scope of an alert if it is created or modified by a process that is different from the first process and the second process associated with the alert. If an entity outside the scope of the alert is not investigated for potential security issues, remedial actions are not applied to the entity, and the entity may later cause a malfunction in an electronic device or cause data loss or theft.

[0033] Each electronic device 106-i also includes a corresponding hardware processor 112-i, memory 114-i, storage media 116-i, and a communication interface 118-i. The communication interface 118-i allows the electronic device 106-i to communicate over a network, such as with the central security service 102 or another electronic device.

[0034] The program is executed on the processor 112-i in the electronic device 106-i. Figure 1 Only one hardware processor is depicted in FIG. 1 , but the electronic device 106-i may include multiple hardware processors. Programs that may be executed on the hardware processor 112-i include an operating system (OS) 120-i, firmware 122-i (e.g., basic input / output system (BIOS) code), and application programs 124-i. Processes in the electronic device 106-i include processes associated with the OS 120-i, firmware 122-i, application programs 124-i, or any other program executed in the electronic device 106-i.

[0035] The hardware processor may include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. The memory may be implemented using one or more memory devices, such as a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, etc.

[0036] The storage medium may include persistent storage, such as one or more disk-based storage devices, solid-state drives, etc. The communication interface may include a transceiver to transmit and receive signals, as well as any protocol layers (implemented using machine-readable instructions and / or hardware) that implement a communication protocol associated with communicating over the network.

[0037] Figure 2 is an example diagram illustrating various entities involved in the operation of an electronic device 106, which may be Figure 1 Any of the electronic devices 106-1 to 106-N. Figure 2 Operations are shown involving processes and artifacts, but it should be noted that in other examples, the operations may involve other types of entities.

[0038] exist Figure 2 In the example of , process P1 starts process P2, which in turn creates artifact A1. For example, process P1 may issue a command to start process P2. For example, artifact A1 created by process P2 may be a file.

[0039] The endpoint security engine 104 (any of the endpoint security engines 104-1 to 104-N) in the electronic device 106 may issue an alert 202 based on information associated with the process P2 (launched by P1) that created the artifact A1 according to the security alert criteria. For example, the security warning criteria may specify that a process of a particular type of program launched by a process of another type of program should not create an artifact type corresponding to A1.

[0040] like Figure 2 As further shown in the example of , process P2 starts process P3, which in turn starts process P4. Process P4 starts process P5 and process P9. Additionally, process P4 creates artifacts A2, A3, A4, and A5. Process P5 starts process P6, which starts process P7. Process P7 starts processes P8 and P10.

[0041] Process P9 creates artifact A6, process P7 creates artifact A7, and process P10 creates artifact A8. Figure 2 As further shown in , process P11 which does not have any direct relationship with any of processes P1 to P10 also creates artifact A9. If a first process is not started or modified by a second process, then the first process is not directly related to the second process, and vice versa.

[0042] The adaptive data collector 150 ( Figure 1 Any of the adaptive data collectors 150-1 to 150-N) may be based on context information 152 (e.g., Figure 1 Any of the context information 152-1 to 152-N) is adaptively collected and Figure 2 Data about the various entities depicted in .

[0043] For example, context information 152 may specify a severity context indicating the severity of alert 202. The severity may be any of a plurality of severity levels, including high, medium, low, and reportable, wherein the reportable level is the lowest severity level. In other examples, the severity level may be represented using numerical values ​​indicating the respective different severities of the alert.

[0044] In one example, if the severity level is medium, the adaptive data collector 150 may collect data associated with processes P1 to P10 and artifacts A1 to A8. However, data associated with process P11 and artifact A9 is not collected because P11 and A9 are not related to Figure 2 There does not appear to be any direct relationship between the other entities depicted in. On the other hand, if the severity level is high, the adaptive data collector 150 may collect data associated with all of the processes P1 to P11 and artifacts A1 to A9.

[0045] If the severity level is reportable, the adaptive data collector may collect data associated only with P1 , P2 , and A1 , since these are the entities associated with alert 202 .

[0046] Examples of data collected associated with a process or artifact may include any one or some combination of the following: the type of program that initiated the process or the identity of the program, the type of artifact that was created or modified or the identity of the artifact, the type of operations involved, time information associated with the activities of the process or artifact, location data related to the process or artifact, information about the network to which the process or artifact is currently connected or attempting to access, information about the relationship between the process or artifact and other entities, and various other types of information.

[0047] More generally, based on the context (e.g., severity level) specified by context information 152, adaptive data collector 150 may select a group of entities for which to collect data (selected from a larger group of entities involved in various operations that occurred when the alert was generated and / or after the alert was generated). The selected group of entities may include or exclude data associated with a given subset of entities of the larger group of entities. Figure 2 In the example of , if the severity level is medium, data related to the entity subset consisting of P11 and A9 will be excluded from collection. On the other hand, if the severity level is high, data related to the entity subset consisting of P11 and A9 will be included in the collection by the adaptive data collector 150. If the severity level is reportable, data related to the entity subset consisting of P3-P11 and A2-A9 will be excluded from collection.

[0048] The determination of data related to the subset of entities to be included or excluded by adaptive data collector 150 may be based on predefined rules. For example, predefined rules may be set as follows: (1) if the severity level is high, data related to entities that are linked to each other (e.g., links between P1 to P10 and A1-A8) and data related to entities that have potential indirect relationships (e.g., time relationships, source relationships, etc.) with respect to alert 202 are collected (e.g., P11 is initiated and creates A9 within a specified time interval of alert 202, or P11 and A9 are from a common source, etc.), (2) if the severity level is medium, data related to entities that are linked to each other are collected, but data related to entities that have no direct relationship with the linked entities are excluded, (3) if the severity level is low, data related to entities that are linked together and meet a standard (e.g., a time standard or another standard) are collected (e.g., data related to entities that are linked together and initiated, created, or modified within a specified time interval of alert 202 are collected), and (4) if the severity level is reportable, data related to entities associated with alert 202 (e.g., P1, P2, and A1) are collected.

[0049] Although examples of predefined rules based on severity levels are mentioned above, in other examples, other rules can be specified for adaptive data collection based on the severity of the alert.

[0050] Entities that are linked together (or linked to each other) may be referred to as a chain of directly related entities. A "directly related entity" chain refers to entities where there is a direct relationship between consecutive entities in a sequence. A direct relationship exists between a first entity and a second entity if the first entity affects the operation of the second entity (e.g., one process starts another process) or the first entity creates or modifies the second entity, or if the second entity affects the operation of the first entity or the second entity creates or modifies the first entity.

[0051] In another example, for an alert, the adaptive data collector 150 can adaptively collect data related to various entities based on the anomaly context specified by the context information 152. The anomaly context represents the uniqueness of the anomaly represented by the alert. More unique anomalies are more likely to be associated with malicious activity than less unique anomalies. The anomaly context can also represent the frequency of occurrence of the anomaly represented by the alert. Even if not unique, more frequent anomalies may be associated with malicious activity.

[0052] The uniqueness of the anomaly represented by the alert is based on the pattern associated with the alert. A "pattern" refers to the collection of entities associated with the alert and how the entities interact with each other. For example, process P1 starts process P2, which in turn creates artifact A1 is an example of a pattern. Such a pattern includes P1, P2, and A1 and activities including P1 starting P2 and P2 creating A1. In other examples, more complex patterns can be associated with alerts, where the more complex patterns can involve more entities and interactions between entities.

[0053] Adaptive data collector 150 compares the pattern associated with alert 202 to previously encountered patterns. Information of previous abnormal patterns 210 may be stored in repository 212, which may be in the form of a database or other data structure. Repository 212 may be stored on a storage medium.

[0054] The uniqueness of a given pattern may be based on whether the pattern exists in the information of previous anomaly patterns 210. If the given pattern does not match any pattern in the information of previous anomaly patterns 210, adaptive data collector 150 may identify the given pattern as a unique pattern. If the given pattern matches any pattern in the information of previous anomaly patterns 210, adaptive data collector 150 may identify the given pattern as non-unique.

[0055] In other examples, the adaptive data collector 150 may assign a uniqueness indicator to a pattern, rather than binary classifying the pattern as unique or non-unique. The indicator of uniqueness may be set at one of a plurality of uniqueness levels: including high, medium, and low. In other examples, the uniqueness level may be represented using a numerical value indicating a respective different uniqueness of the alert.

[0056] As an example, if the number of occurrences of a given pattern in the information of previous anomaly patterns 210 is less than a first threshold, the given pattern has high uniqueness. If the number of occurrences of a given pattern in the information of previous anomaly patterns 210 exceeds a second threshold that is greater than the first threshold, the given pattern has low uniqueness. If the number of occurrences of a given pattern in the information of previous anomaly patterns 210 is greater than the first threshold but less than the second threshold, the given pattern has medium uniqueness.

[0057] Based on the level of uniqueness of the pattern associated with alert 202, adaptive data collector 150 may select a group of entities for which to collect data (selected from a larger group of entities involved in various operations that occurred when the alert was generated and / or after the alert was generated). The selected group of entities may include or exclude data associated with a given subset of entities of the larger group of entities. Typically, data associated with a greater number of entities is collected by adaptive data collector 150 for alerts associated with more unique patterns.

[0058] In addition to uniqueness, another measure of the anomaly represented by the alarm is the frequency of occurrence of the pattern associated with the alarm. The frequency of occurrence of a pattern refers to the number of occurrences of the pattern per unit time. If a larger number of patterns occur per unit time, a higher frequency pattern is encountered. The information of previous anomaly patterns 210 may also include timestamp information for each pattern previously encountered. The timestamp information may be used to determine when the corresponding previous pattern was encountered so that the adaptive data collector 150 can calculate the frequency of occurrence of the pattern.

[0059] In an example, if a pattern has low uniqueness but high frequency, the adaptive data collector 150 can collect more data about the entity than when the pattern has low uniqueness but low frequency. The frequency of the pattern can be classified into multiple frequency levels, including, for example, high frequency, medium frequency, and low frequency. For example, the frequency level assigned to the pattern is based on comparing the number of occurrences of the pattern to a corresponding threshold.

[0060] More generally, based on the anomaly context (including uniqueness level and frequency level) specified by context information 152, adaptive data collector 150 may select a group of entities for which to collect data (selected from a larger group of entities involved in various operations that occurred when the alert was generated and / or after the alert was generated). Determining data related to a subset of entities to be included or excluded by adaptive data collector 150 based on uniqueness and / or frequency may be based on predefined rules.

[0061] Figure 3 An example of how risk context affects the amount of data collected by an adaptive data collector for an alert is shown. The risk of an alert can be based on the number of alerts that occur within a time interval of a specified length (i.e., the alert rate). Figure 3 In the example of , process P9 that created artifact A6 caused endpoint security engine 104 to generate alert 302, and process P7 that created artifact A7 caused endpoint security engine 104 to generate alert 304. Alerts 202, 302, and 304 may all occur within a time interval of a specified length.

[0062] If the number of alerts within a time interval of a specified length is greater than a threshold number, an elevated risk is indicated. If the number of alerts occurring within a time interval of a specified length is less than a threshold, a lower risk level is indicated. Thus, even if alerts 202, 302, and 304 are individual alerts of a low or medium severity level, the combination of alerts 202, 302, and 304 occurring within a relatively short amount of time of each other may indicate an elevated risk.

[0063] More generally, the risk level may be indicated by the number of alarms within a time interval of a specified length, where the risk level is proportional to the number of alarms within the time interval of the specified length. If the risk level is high, the adaptive data collector 150 may collect data related to Figure 3 On the other hand, if the risk level is low, the adaptive data collector 150 may collect data related to the entity being profiled. Figure 3 A smaller amount of data related to the entity shown.

[0064] More generally, adaptive data collector 150 may select a group of entities for which to collect data (selected from a larger group of entities involved in various operations that occurred when an alert was generated and / or after an alert was generated) based on the risk context specified by context information 152. Determining data related to a subset of entities to be included or excluded by adaptive data collector 150 based on risk may be based on predefined rules.

[0065] The context information 152 may also specify a type context for the alert. The type context indicates the type of the alert. Example types of alerts may include any of the following: a detection type, an observation type, a telemetry type, and an anomaly type.

[0066] The detection type indicates that a possible security event has occurred. The observation type indicates that a possible security event has occurred (less likely than the detection type). The telemetry type indicates that a generally useful event with some specific scope has been observed from a security perspective. The anomaly type indicates that a unique pattern has been observed. In some examples, the adaptive data collector 150 can collect different amounts of data for different alert types. For example, more data can be collected for the detection type and the anomaly type than for the observation type and the telemetry type.

[0067] Examples of detection types can include alerts based on: a malicious file being written to storage media; a process having modified the registry to force persistence of an unsigned process (a process not signed with a digital signature); a user attempting to access a resource (e.g., a website) from a restricted geographic location; an attempt to send a sensitive file to a file sharing service; a user installing a malicious application, etc.

[0068] Examples of observation types can include alerts based on: suspicious memory events observed from a signed process (a process unmapped remote memory); a network connection made from an unsigned process to an Internet Protocol (IP) address outside the network; a user navigated to a website with a medium or low reputation score; a sensitive file has been compressed; a user has accessed an application from an unknown network, etc.

[0069] Examples of telemetry types may include alerts based on: a specified script running on an electronic device; a process being started; a user visiting a social media site; a sensitive file being moved from one folder to another; a user having updated the operating system (OS) from a previous version to a newer version, etc.

[0070] Examples of anomaly types may include alerts based on: an interaction between two processes occurring in a unique context (e.g., using command line arguments); a DNS server responding with a unique IP address for a well-known domain name (where the unique IP address deviates from a previous IP address for the domain name returned by the DNS server); a user has opened a sensitive file for the first time; a user has performed actions with sensitive data that are well outside of the user's normal baseline, etc.

[0071] In other examples, the adaptive data collector 150 can adapt the collected data based on the intelligence context specified by the context information 152. The intelligence context indicates the intelligence associated with the alert. The intelligence associated with the alert can refer to threat intelligence. In some examples, the definition of threat intelligence can be provided by an open source knowledge base such as MITRE ATT&CK. Alternatively, the definition of threat intelligence can be provided by a proprietary knowledge base available via a paid subscription, such as the Cylance Cyber ​​Threat Intel Report from BlackBerry. The definition of threat intelligence can be obtained from other sources. Typically, threat intelligence includes a list of known bad indicators of compromise (IOCs), which can include any one or a combination of the following items: a cryptographic hash of a file, a file path, a registry key, a domain name, an IP address, etc.

[0072] If the intelligence context includes threat intelligence indicating that the alert is associated with an entity with a known bad IOC, then adaptive data collector 150 may collect more data (e.g., data related to a greater number of entities). Any alert involving an entity with a known bad IOC may be considered a higher risk alert.

[0073] In another example, the adaptive data collector 154 of the central security service 102 can adaptively control the collection of data based on a unified context associated with multiple electronic devices. Since the central security service 102 can reside in the cloud or in a cloud that allows the central security service 102 to communicate with multiple electronic devices (e.g., Figure 1At another location of the communication between the adaptive data collector 154 and the multiple electronic devices (106-1 to 106-N), the adaptive data collector 154 can receive context information 156 specifying a unified context. The unified context can include information about events from multiple electronic devices (including alarms, operations of processes, creation / modification of objects, etc.). The adaptive data collector 154 can correlate the event information from multiple electronic devices to assess whether an attack may have occurred. If so, the adaptive data collector 154 can trigger multiple electronic devices to collect more data about the entity.

[0074] For example, the adaptive data collector 154 may detect the occurrence of a relatively large number of alarms in one or more electronic devices. Such alarms may be mapped to a specific threat actor group, such as a nation or criminal organization. Due to the detection of alarms occurring in one or more electronic devices, the adaptive data collector 154 may trigger additional electronic devices to collect more data related to entities in the additional electronic devices, even if no alarms were detected in the additional electronic devices. Note that some entities in the additional electronic devices may be due to malicious attacks that may not have been detected earlier in other ways. This may allow the security system to detect potential malicious intent earlier based on activities occurring on a smaller number of electronic devices, so that earlier remedial actions may be taken.

[0075] The following discussion Figure 1 The tasks of intelligence response modules 108 - 1 through 108 -N and 110 are depicted.

[0076] Figure 4 is an example diagram illustrating various entities involved in the operation of an electronic device 106, which may be Figure 1 Any one of the electronic devices 106-1 to 106-N. Figure 4 In the example of , process P1 starts process P2. For example, process P1 may issue a command to start process P2. The endpoint security engine 104 (any of endpoint security engines 104-1 to 104-N) in the electronic device 106 may issue an alert 402 based on the information associated with P1 starting P2 meeting the security alert criteria. For example, the security alert criteria may specify that a process of a given first program should not start a process of a given second program during a specific time interval or under conditions currently existing in the electronic device 106.

[0077] like Figure 4As further shown in , process P2 starts process P3, which in turn creates or modifies file 404 (an example of an artifact). Processes P1 through P3 and file 404 are part of a chain of directly related entities 406, where the chain includes a sequence of entities that are created or modified in the order depicted (either chronological or causal order). A "directly related entity" chain refers to entities where there is a direct relationship between consecutive entities in the sequence. A direct relationship exists between a first entity and a second entity if the first entity affects the operation of the second entity (e.g., one process starts another process) or the first entity creates or modifies the second entity, or if the second entity affects the operation of the first entity or the second entity creates or modifies the first entity.

[0078] Figure 4 Another chain of directly related entities 408 is shown, including processes P1, P4, and P5 (eg, P1 starts P4, and P4 starts P5). Figure 4 Another directly related entity chain 410 is also shown, which includes file 404, processes P6, P7, P8, and P9, and registry 412. In some examples, if file 404 contains an image (including machine-readable instructions) for process P6, then file 404 can be directly related to process P6. In other words, file 404 contains machine-readable instructions of a program that, when executed, causes process P6. In directly related entity chain 410, process P6 starts process P7, process P7 starts process P8, and process P8 starts process P9. Process P9 updates registry 412, such as by adding or modifying an entry of registry 412.

[0079] When the alert 402 is generated, the process P3 may have been started and the file 404 may have been created by the process P3. The file 404 may in turn cause the process P6 to be started, and the process P6 triggers the modification of the corresponding processes P7, P8 and P9 and the registry 412.

[0080] exist Figure 4 In the example of FIG. 4 , processes P1 and P2 are associated with alert 402 because process P1 initiated process P2, causing endpoint security engine 104 to issue alert 402. Process P3 is within the scope of alert 402 because process P3 is initiated by process P2, which is associated with alert 402. However, in directly related entity chain 406, file 404 is outside the scope of alert 402 because file 404 is not directly related to processes P1 and P2 associated with alert 402.

[0081] Even if the remedial action is applied with respect to processes P1, P2, and P3 (e.g., by terminating processes P1, P2, and P3), which are processes within the scope of alert 402, conventional security systems may not determine that the remedial action should be applied to file 404 outside the scope of alert 402. Similarly, conventional security systems may not determine that the remedial action should be applied to processes P4, P5, P6, P7, P8, P9, and registry 412, which are also outside the scope of alert 402.

[0082] If remedial action is not taken with respect to entities outside the scope of alert 402, security issues may arise later because one or more of file 404, processes P4, P5, P6, P7, P8, P9, and registry 412 may cause a malfunction in electronic device 106 or result in loss or theft of data in electronic device 106.

[0083] A human analyst may manually study the operation of the electronic device 106 to attempt to determine which entities may be outside the scope of the alert 402 and, if so, what remedial actions should be taken. However, such manual analysis is time consuming and the human analyst may miss certain entities that may be malicious. Furthermore, the time delay involved in performing manual analysis may allow the malicious entity to perform its corresponding activities in the electronic device 106.

[0084] According to some implementations of the present disclosure, the intelligence response module 108 in the electronic device 106 (which can be any one of the intelligence response modules 108-1 to 108-N) can automatically determine appropriate remedial actions to resolve entities outside the scope of the alert 402. Note that the data analyzed by the intelligence response module 108 is provided from the adaptive data collector. The intelligence response module 108 is capable of discovering all malicious parent processes, child processes, sibling processes, other indirectly related processes, objects, and resources that may be directly or indirectly related to the alert 402 (based on the data collected by the adaptive data collector). The intelligence response module 108 can dynamically determine appropriate remedial actions for each corresponding entity based on the type of the corresponding entity, the relationship between the corresponding entity and the entity associated with the alert, the context of the alert, the expected remedial action instructions of the customer, etc. (for example, the intelligence response module can be provided with information on preferred remedial actions from the user of the electronic device). In this way, the intelligence response module 108 can eliminate the burden on the user and can also automatically process remedial actions that will be applied to downstream threats that cannot be known at the time of the alert. The remedial actions to be applied can be based on predefined rules or based on applied machine learning.

[0085] Although the present example involves intelligence response module 108 determining what remedial action to apply in response to an alert, in other examples, intelligence response module 110 in central security service 102 may determine what remedial action to apply in response to an alert. In yet another example, determining the remedial action to apply may be based on collaboration between multiple intelligence response modules (any combination of 110 and 108-1 to 108-N).

[0086] The remedial action to be applied may be based on the type of entity. For example, a remedial action for a process may include a terminate action that stops the execution of the process and dismantles the process so that the process cannot be restarted again.

[0087] Remedial actions for an artifact such as a file can be any of the following or some combination thereof: delete (remove the artifact from storage), quarantine (place the artifact in an isolated location to prevent access to the artifact and prevent the artifact from triggering any activity), rollback (place the artifact in a previous state, such as restoring a file version to a previous version), add to watch list (place the artifact on a list to be watched), etc.

[0088] The remedial action for a resource, such as a website, domain, may be any one or some combination of: terminating the connection to the resource, blocking the resource, blocking an IP address associated with the resource, adding the resource to a watch list, and the like.

[0089] A remedial action for configuration information (eg, a registry or a registry entry) is to restore the configuration information from a current state to a previous state, or to delete the configuration information.

[0090] The remedial action for the user is to prevent the user from accessing the electronic device or network, such as by invalidating the credentials for the user or locking the user account.

[0091] In some examples, each type of entity can be associated with a set of potential remedial actions that can be applied. The set of potential remedial actions associated with each type of entity can be stored in a data structure (e.g., a database, library, etc.) accessible to the intelligence response module.

[0092] Examples of relationships between entities may include parent, child, and sibling relationships. A "parent" process may be a process that starts another process. Figure 4 In the example of , process P1 is the parent of process P2, and process P2 is the parent of process P3. A "child" process is a process started by another process. Figure 4In the example of , process P2 is a child process of process P1, and process P3 is a child process of process P2. The parent process and the child process have a direct lineage to each other. If a remedial action is applied to the parent process (e.g., shutting down the parent process), the intelligence response module 108 will also determine that the same remedial action is applied to the child process based on the direct lineage.

[0093] More generally, a "lineage" may refer to a link between entities that is part of a chain of directly related entities, such as chain 406. Figure 4 If the graph of is a tree, then links 406, 408, and 410 are branches of the tree. Entities in the branches of the tree have direct lineages to each other.

[0094] "Sibling" processes are processes that share a common parent process. Figure 4 In the example of , process P2 and process P4 are sibling processes because they share a common parent process P1. Processes P3 and P5 are also sibling processes because they share a common grandparent process P1. Processes P2 and P4 have a sibling relationship with each other. Similarly, processes P3 and P5 have a sibling relationship with each other. Based on the sibling relationship, if a remedial action is identified for process P2, intelligence response module 108 will determine that the remedial action must be applied to process P4.

[0095] Another type of relationship includes a relationship where a process is caused based on an artifact (e.g., a file contains an image of a process) or a relationship where the behavior of a process is affected by another object (e.g., a registry entry). Such relationships are examples of functional relationships between different types of entities (process and artifact or process and registry).

[0096] Another type of relationship is an interaction relationship, such as in examples where a file is downloaded from a website or obtained from another resource, or where a process interacts with a website or another resource.

[0097] Although some examples of relationships are mentioned above, many other types of relationships may exist between entities. Remedial actions may be applied based on relationships between entities.

[0098] The context of the alert may include any one or some combination of the following: severity of the alert, risk of the alert, uniqueness of the anomaly associated with the alert, intelligence associated with the alert, etc. The security system (e.g., endpoint security engines 104-1 to 104-N and / or central security service 102) may classify the severity of the alert into a plurality of severity categories (e.g., high, medium, low, or values ​​from a numerical range). The severity category of the alert may be based on the type of activity involved between the entities causing the alert. For example, a modification of a registry entry for an OS may be classified as a high severity category, while sending an email may be classified as a low severity category.

[0099] The security system can classify the risk of the alarm into multiple risk categories (e.g., high, medium, low, or a value from a numerical range). If the alarm is part of a collection of alarms that occurred within a relatively short amount of time, the security system can classify the alarm as having a high risk. However, if the alarm is a stand-alone alarm where other alarms that were issued are not close in time to the alarm, the security system can classify the alarm as having a low risk.

[0100] The security system may classify the uniqueness of an alarm based on an abnormal pattern associated with the alarm. The abnormal pattern includes a pattern of the types of entities and activities involved in causing the alarm. The pattern may be compared to past patterns that have been encountered. If the pattern has not been encountered previously or has been encountered with a relatively low frequency, the security system may classify the uniqueness of the alarm as high. On the other hand, if the pattern has been encountered frequently in the past, the security system may classify the uniqueness of the alarm as low. For example, information of the patterns that have been encountered may be stored in a database and compared to the newly encountered patterns that generate the alarm.

[0101] exist Figure 4 In the example of FIG. 1 , the intelligence response module (any one or some combination of 110 and 108-1 to 108-N) may determine the Figure 4 The following potential remediation actions for the various entities are shown: terminating processes P1 through P9 , quarantining files 404 , and restoring registry 412 .

[0102] Based on the context of alert 402, the intelligence response module can determine whether to be more lenient or less lenient. More lenient will cause the intelligence response module to apply remediation actions to a smaller set of entities or to apply less stringent remediation actions, while more lenient will cause the intelligence response module to apply remediation actions to a larger set of entities or to apply more stringent remediation actions.

[0103] Less stringent remediation actions may include adding the artifact to a watch list instead of deleting or restoring the artifact. More stringent remediation actions may include deleting the artifact instead of just isolating the artifact, isolating the electronic device to prevent any communication into or out of the electronic device, shutting down the electronic device, locking a user account.

[0104] Figure 5 is another example diagram illustrating various entities involved in the operation of the electronic device 106 . Figure 5 The diagram includes Figure 4 The processes P1 to P9, file 404 and registry 412 are shown. Additionally, Figure 5 The diagram includes a file 502 downloaded from a website 504 . Figure 5404. The diagram also includes process P10 interacting with website 504 via a network connection. File 502 may contain an image for process P1. Intelligence response module 508 (either by itself or in coordination with another intelligence response module such as 110) may identify additional entities (502, 504, P10) in response to alert 402. Intelligence response module 508 may also determine remedial actions to take with respect to the additional entities, including, for example, quarantining file 502, blocking website 504, and terminating the network connection between process P10 and website 504.

[0105] Figure 6 is included for protecting electronic device 606 (e.g., Figure 1 The security system 600 includes a central security service 102 (which includes an intelligence response module 110 and an adaptive data collector 154) and an endpoint security engine 104 (which includes an intelligence response module 108 and an adaptive data collector 150). Figure 6 Only one endpoint security engine 104 is depicted, but there will be multiple endpoint security engines in the corresponding multiple electronic devices 606.

[0106] The security system 600 includes one or more hardware processors 602 and a memory 604. The central security service 102 and the endpoint security engine 104 may execute on the one or more hardware processors 602. Note that the endpoint security engine 104 may execute on one or more processors in the electronic device 606, and the central security service 102 may execute on one or more processors in a computer (or collection of computers) separate from the electronic device 606. Machine-readable instructions of the central security service 102 and the endpoint security engine 104 may be stored in a non-transitory machine-readable or computer-readable storage medium 608, and the machine-readable instructions may be retrieved from the storage medium 608 for execution on the one or more hardware processors 602.

[0107] In some examples, the machine-readable instructions of the security system 600 may be executed to monitor operations in which entities are initiated, created, or modified in at least one electronic device, and generate an alert based on the monitoring. The machine-readable instructions of the security system 600 may be executed to adapt the amount of data collected based on context information associated with the alert, wherein adapting the amount of data collected includes adapting the amount of data collected based on a subset of entities and entities associated with the alert (e.g., Figure 1 ) to determine whether to include or exclude a subset of entities (e.g., Figure 1 Data associated with P11 and A9 in .

[0108] In some examples, context information associated with the alarm indicates a severity of the alarm, and adapting the amount of data collected includes increasing the amount of data collected in response to a higher severity of the alarm.

[0109] In some examples, context information associated with the alert indicates a risk to at least one electronic device, and adapting the amount of data collected includes increasing the amount of data collected in response to a higher risk to the at least one electronic device.

[0110] In some examples, context information associated with the alert indicates uniqueness of an anomaly indicated by the alert, and adapting the amount of data collected is based on the uniqueness of the anomaly. The uniqueness of the anomaly is based on a pattern of one or more entities causing the alert. If the number of occurrences of the pattern detected in at least one electronic device is low, the anomaly is more unique.

[0111] In some examples, context information associated with the alert indicates a frequency of occurrence of an anomaly indicated by the alert, and adapting the amount of data collected is based on the frequency of occurrence of the anomaly.

[0112] In some examples, the machine-readable instructions classify the alert, and the context information includes a type of alert generated by the classification.

[0113] In some examples, context information associated with the alert indicates intelligence associated with the alert, and adapting the amount of data collected includes increasing the amount of data collected in response to the intelligence indicating that the alert is associated with an entity with a known bad IOC. Any alert involving an entity with a known bad IOC may be considered higher risk.

[0114] In some examples, context information associated with the alert indicates a unified context associated with the event in the plurality of electronic devices. Adapting the amount of data collected includes increasing the amount of data collected in the plurality of electronic devices in response to the unified context indicating that the event is occurring in at least some of the electronic devices.

[0115] In some examples, the machine-readable instructions of the security system 600 can be executed to detect an alarm generated in response to an operation on the electronic device 606, where the operation involves a group of entities (e.g., a first process and a first entity). The first entity can be another process, an object, a resource, or a user.

[0116] In response to the alert, the machine-readable instructions discover a second entity outside of the scope of the alert, and the machine-readable instructions apply a remedial action relative to at least the first process, the first entity, and the second entity to resolve the alert.

[0117] More generally, the machine-readable instructions are capable of discovering an attack chain in response to an alert, wherein the attack chain includes a group of entities associated with the alert and other entities outside the scope of the alert. The machine-readable instructions determine remediation actions to be applied to entities of the attack chain based on multiple factors, including any one or some combination of the following: the type of each respective entity in the attack chain, the relationship of the respective entity to an entity associated with the alert, the context of the alert, the customer's intended remediation action instructions, and the like.

[0118] In one example, the second entity is outside the scope of the alert based on: (1) the first entity is the second process, (2) the alert is caused in response to the first process initiating the second process, and (3) the second entity has a different entity type (e.g., object, resource, user, etc.) than the process. In another example, the second entity is outside the scope of the alert based on the second entity being separated from a chain of directly related entities that includes the first process and the first entity. For example, the chain of directly related entities is a first tree branch of directly related entities (e.g., Figure 4 406 in ), and the second entity is in a second tree branch of directly related entities (e.g., Figure 4 408 or 410 in the response).

[0119] There may be many other examples of entities being outside the scope of an alert, including the examples discussed further above.

[0120] In some examples, discovering the second entity is based on detecting that the second entity is associated with a process (e.g., Figure 4 P3 in the Figure 4 404), the directly related entity chain includes the first process (e.g., Figure 4 P1 in ) and the first entity (e.g., Figure 4 in P2).

[0121] In another example, the second entity is a resource (e.g., Figure 5 504 in the website, and discovering the resource based on detecting that a file is obtained from the resource (e.g., Figure 5 502), the file comprising an image containing machine-readable instructions for a first process.

[0122] In another example, the second entity is a second process and the second process is found based on detecting that the first process and the second process have a common parent process. The common parent process can be an OS component that starts the first and second processes, a file shared by the first and second processes, a web server that starts the first and second processes, a registry entry that both the first and second processes have interacted with, etc.

[0123] In some examples, the alert is in the first device (electronic device) and the discovery of the second entity is by a central service (e.g., Figure 1 For example, the central service discovers the second entity based on information collected from multiple devices connected to the central service. As another example, the second entity is in a second device different from the first device.

[0124] In some examples, the machine-readable instructions of the security system 600 may confirm that all entities in the attack chain (such as Figure 4 or Figure 5 All entities shown) have taken remedial action.

[0125] In some examples, the machine-readable instructions of the security system 600 may determine that a primary remedial action with respect to the second entity is not possible. In response to the determination, the machine-readable instructions of the security system 600 may identify a secondary remedial action to be applied to the second entity. For example, the second entity may be a user, and the primary remedial action may be to log out the user from all user accounts and force the use of a second factor authentication after the user has been logged out. The user account management system responsible for applying the primary remedial action may not respond (e.g., the user account management system is busy or offline or compromised by an attacker). The machine-readable instructions of the security system 600 may identify another management system that is capable of disconnecting the user's access to the electronic device. The secondary remedial action in this example is to disconnect the user's access to the electronic device using another management system.

[0126] In other examples, other secondary remedial actions may be applied in response to determining that the primary remedial action is not available.

[0127] In some examples, the machine-readable instructions of security system 600 may determine the correct order of remediation actions to apply to entities of the attack chain in response to an alert. Figure 6 In the example embodiment, it may be best to first block website 504 and any interaction with website 504 to prevent any further damaged files from being downloaded. Next, security system 600 can quarantine or delete files 404 and 502 to prevent additional processes from being spawned from damaged files 404 and 502. Subsequently, security system 600 can terminate the process.

[0128] Figure 7 700 is a flow chart of a process 700 that can be performed by a security system according to some examples. The process 700 includes monitoring (at 702) operations of entities being initiated, created, or modified in at least one electronic device. The entity can include any one or some combination of a process, an object, a resource, a user, etc.

[0129] The process 700 includes generating (at 704) an alert based on the monitoring, the alert being associated with the entity group. The process 700 includes adapting (at 706) the amount of data collected based on context information associated with the alert. Adapting the amount of data collected includes determining whether to include or exclude data associated with a subset of entities based on any relationship of the subset of entities to the entity group associated with the alert. Examples of context that may be represented by the context information may include any one or some combination of the following: severity context, risk context, anomaly context, type context, intelligence context, unified context, etc.

[0130] Storage media (e.g. Figure 1 116-1 to 116-N or Figure 6 608) may include any one or some combination of the following: a semiconductor memory device, such as a dynamic or static random access memory (DRAM or SRAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and a flash memory or other type of non-volatile memory device; a disk, such as a fixed disk, a floppy disk, and a removable disk; another magnetic medium including a tape; an optical medium, such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system that may have multiple nodes. One or more such computer-readable or machine-readable storage media are considered to be part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more storage media may be located in a machine that runs machine-readable instructions, or at a remote site from which machine-readable instructions may be downloaded over a network for execution.

[0131] In the present disclosure, unless the context clearly indicates otherwise, the use of the terms "a", "an" or "the" is also intended to include plural forms. In addition, the terms "includes, including, comprises, comprising", "have, having" when used in the present disclosure specify the presence of the elements described, but do not exclude the presence or addition of other elements.

[0132] In the foregoing description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations to the above details. The appended claims are intended to cover these modifications and variations.

Claims

1. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a system to: Monitoring the operation of an entity being initiated, created, or modified in at least one electronic device; generating an alert based on said monitoring; as well as An amount of data collected is adapted based on contextual information associated with the alert, wherein adapting the amount of data collected includes determining whether to include or exclude data associated with the subset of entities based on any relationships of the subset of entities to an entity associated with the alert.

2. The non-transitory machine-readable storage medium of claim 1 , wherein the context information associated with the alert indicates a severity of the alert, and wherein adapting the amount of data collected comprises increasing the amount of data collected in response to a higher severity of the alert.

3. A non-transitory machine-readable storage medium according to claim 1, wherein the context information associated with the alert indicates a risk to the at least one electronic device, and wherein adapting the amount of data collected includes increasing the amount of data collected in response to a higher risk to the at least one electronic device. 4 . The non-transitory machine-readable storage medium of claim 3 , wherein the risk to the at least one electronic device is based on a number of alarms that occurred in the at least one electronic device within a time interval.

5. The non-transitory machine-readable storage medium of claim 1, wherein the context information associated with the alert indicates uniqueness of an anomaly indicated by the alert, and wherein adapting the amount of data collected is based on the uniqueness of the anomaly. 6 . The non-transitory machine-readable storage medium of claim 5 , wherein the uniqueness of the anomaly is based on a pattern of one or more entities causing the alert. 7 . The non-transitory machine-readable storage medium of claim 6 , wherein the anomaly is more unique if a lower number of occurrences of the pattern detected in the at least one electronic device is detected.

8. The non-transitory machine-readable storage medium of claim 1, wherein the context information associated with the alert indicates a frequency of occurrence of an anomaly indicated by the alert, and wherein adapting the amount of data collected is based on the frequency of occurrence of the anomaly.

9. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions, when executed, cause the system to: The alert is classified, wherein the context information includes a type of the alert resulting from the classification. 10 . The non-transitory machine-readable storage medium of claim 1 , wherein the alert is generated for a first electronic device, and the adapting the amount of collected data is for data in a second electronic device different from the first electronic device. 11 . The non-transitory machine-readable storage medium of claim 10 , wherein the context information comprises context information associated with the first electronic device.

12. The non-transitory machine-readable storage medium of claim 11, wherein adapting the amount of collected data is performed by the system as part of a cloud service, the cloud service being communicatively coupled to a plurality of electronic devices including the first electronic device and the second electronic device.

13. The non-transitory machine-readable storage medium of claim 1, wherein adapting the amount of data collected is based on an intelligence context specified by the context information.

14. The non-transitory machine-readable storage medium of claim 1, wherein the entity comprises any one or some combination of a process, an object, a resource, and a user.

15. A security system comprising: one or more processors; as well as a non-transitory storage medium storing instructions executable on the one or more processors to: Monitoring the operation of an entity being initiated, created, or modified in at least one electronic device; generating an alert based on the monitoring, the alert being associated with an entity group; and The amount of data collected is adapted based on contextual information associated with the alert, wherein adapting the amount of data collected includes determining whether to include or exclude data associated with the subset of entities based on any relationship of the subset of entities to the group of entities associated with the alert.

16. The security system of claim 15, wherein adapting the amount of collected data comprises excluding the data associated with the subset of the entities in response to: determining that said subset of said entities has no direct relationship to a chain of directly related entities including said group of entities, and The contextual information indicates any of: a lower severity of the alert, a lower risk of the alert, a lower uniqueness of the alert, or a lower frequency of the alert.

17. The security system of claim 15, wherein the context information associated with the alarm indicates a severity of the alarm, and wherein adapting the amount of data collected comprises increasing the amount of data collected in response to a higher severity of the alarm.

18. A security system according to claim 15, wherein the context information associated with the alert indicates a risk to the at least one electronic device, and wherein adapting the amount of data collected includes increasing the amount of data collected in response to a higher risk to the at least one electronic device.

19. The security system of claim 15, wherein the context information associated with the alert indicates uniqueness of an anomaly indicated by the alert, and wherein adapting the amount of data collected is based on the uniqueness of the anomaly.

20. A method of a security system including a hardware processor, the method comprising: Monitoring the operation of an entity being initiated, created, or modified in at least one electronic device; generating an alert based on the monitoring, the alert being associated with an entity group; as well as The amount of data collected is adapted based on contextual information associated with the alert, wherein adapting the amount of data collected includes determining whether to include or exclude data associated with the subset of entities based on any relationship of the subset of entities to the group of entities associated with the alert.

Images