Abstract: In a threat management platform, a number of endpoints log events in an event data recorder. A local agent filters this data and feeds a filtered data stream to a central threat management facility. The central threat management facility can locally or globally tune filtering by local agents based on the current data stream, and can query local event data recorders for additional information where necessary or helpful in threat detection or forensic analysis. The central threat management facility also stores and deploys a number of security tools such as a web-based user interface supported by machine learning models to identify potential threats requiring human intervention and other models to provide human-readable context for evaluating potential threats.

Abstract: In a threat management platform, a number of endpoints log events in an event data recorder. A local agent filters this data and feeds a filtered data stream to a central threat management facility. The central threat management facility can locally or globally tune filtering by local agents based on the current data stream, and can query local event data recorders for additional information where necessary or helpful in threat detection or forensic analysis. The central threat management facility also stores and deploys a number of security tools such as a web-based user interface supported by machine learning models to identify potential threats requiring human intervention and other models to provide human-readable context for evaluating potential threats.

Abstract: An endpoint coupled in a communicating relationship with an enterprise network may include a data recorder configured to store an event stream of data indicating events on the endpoint including types of changes to computing objects, a filter configured to locally process the event stream into a filtered event stream including a subset of types of changes to the computing objects, and a local security agent. The local security agent may be configured to transmit the filtered event stream to a threat management facility, respond to a filter adjustment from the threat management facility by adjusting the filter to modify the subset of types of changes included in the filtered event stream, and respond to a query from the threat management facility by retrieving data stored in the data recorder over a time window before the query and excluded from the filtered event stream.

Abstract: An endpoint coupled in a communicating relationship with an enterprise network may include a data recorder configured to store an event stream of data indicating events on the endpoint including types of changes to computing objects, a filter configured to locally process the event stream into a filtered event stream including a subset of types of changes to the computing objects, and a local security agent. The local security agent may be configured to transmit the filtered event stream to a threat management facility, respond to a filter adjustment from the threat management facility by adjusting the filter to modify the subset of types of changes included in the filtered event stream, and respond to a query from the threat management facility by retrieving data stored in the data recorder over a time window before the query and excluded from the filtered event stream.

Abstract: In a threat management platform, a number of endpoints log events in an event data recorder. A local agent filters this data and feeds a filtered data stream to a central threat management facility. The central threat management facility can locally or globally tune filtering by local agents based on the current data stream, and can query local event data recorders for additional information where necessary or helpful in threat detection or forensic analysis. The central threat management facility also stores and deploys a number of security tools such as a web-based user interface supported by machine learning models to identify potential threats requiring human intervention and other models to provide human-readable context for evaluating potential threats.

Abstract: An endpoint coupled in a communicating relationship with an enterprise network may include a data recorder configured to store an event stream of data indicating events on the endpoint including types of changes to computing objects, a filter configured to locally process the event stream into a filtered event stream including a subset of types of changes to the computing objects, and a local security agent. The local security agent may be configured to transmit the filtered event stream to a threat management facility, respond to a filter adjustment from the threat management facility by adjusting the filter to modify the subset of types of changes included in the filtered event stream, and respond to a query from the threat management facility by retrieving data stored in the data recorder over a time window before the query and excluded from the filtered event stream.

Abstract: A honeypot file is cryptographically secured with a cryptographic key. The key, or related key material, is then placed on a central keystore and the file is placed on a data store within the enterprise network. Unauthorized access to the honeypot file can then be detecting by monitoring use of the associated key material, which usefully facilitates detection of file access at any time when, and from any location where, cryptographic access to the file is initiated.

Abstract: A honeypot file is cryptographically secured with a cryptographic key. The key, or related key material, is then placed on a central keystore and the file is placed on a data store within the enterprise network. Unauthorized access to the honeypot file can then be detecting by monitoring use of the associated key material, which usefully facilitates detection of file access at any time when, and from any location where, cryptographic access to the file is initiated.

Abstract: A honeypot file is cryptographically secured with a cryptographic key. The key, or related key material, is then placed on a central keystore and the file is placed on a data store within the enterprise network. Unauthorized access to the honeypot file can then be detecting by monitoring use of the associated key material, which usefully facilitates detection of file access at any time when, and from any location where, cryptographic access to the file is initiated.

Abstract: Threat detection instrumentation is simplified by providing and updating labels for computing objects in a context-sensitive manner. This may include simple labeling schemes to distinguish between objects, e.g., trusted/untrusted processes or corporate/private data. This may also include more granular labeling schemes such as a three-tiered scheme that identifies a category (e.g., financial, e-mail, game), static threat detection attributes (e.g., signatures, hashes, API calls), and explicit identification (e.g., what a file or process calls itself). By tracking such data for various computing objects and correlating these labels to malware occurrences, rules can be written for distribution to endpoints to facilitate threat detection based on, e.g., interactions of labeled objects, changes to object labels, and so forth.

Abstract: Threat detection instrumentation is simplified by providing and updating labels for computing objects in a context-sensitive manner. This may include simple labeling schemes to distinguish between objects, e.g., trusted/untrusted processes or corporate/private data. This may also include more granular labeling schemes such as a three-tiered scheme that identifies a category (e.g., financial, e-mail, game), static threat detection attributes (e.g., signatures, hashes, API calls), and explicit identification (e.g., what a file or process calls itself). By tracking such data for various computing objects and correlating these labels to malware occurrences, rules can be written for distribution to endpoints to facilitate threat detection based on, e.g., interactions of labeled objects, changes to object labels, and so forth.

Abstract: A security agent conditionally hooks a process for malware monitoring based on a persistent hook state for the process that may be stored, for example, in a process cache. When a process launches in a backoff state indicating that the process previously crashed after hooking, the security agent may further conditionally hook the process based on a reputation of the process or any other relevant contextual information.

Abstract: Threat detection instrumentation is simplified by providing and updating labels for computing objects in a context-sensitive manner. This may include simple labeling schemes to distinguish between objects, e.g., trusted/untrusted processes or corporate/private data. This may also include more granular labeling schemes such as a three-tiered scheme that identifies a category (e.g., financial, e-mail, game), static threat detection attributes (e.g., signatures, hashes, API calls), and explicit identification (e.g., what a file or process calls itself). By tracking such data for various computing objects and correlating these labels to malware occurrences, rules can be written for distribution to endpoints to facilitate threat detection based on, e.g., interactions of labeled objects, changes to object labels, and so forth.

Abstract: A honeypot file is cryptographically secured with a cryptographic key. The key, or related key material, is then placed on a central keystore and the file is placed on a data store within the enterprise network. Unauthorized access to the honeypot file can then be detecting by monitoring use of the associated key material, which usefully facilitates detection of file access at any time when, and from any location where, cryptographic access to the file is initiated.

Abstract: A threat management facility that remotely stores global reputation information for network content can be used in combination with a recognition engine such as a machine learning classifier that is locally deployed on endpoints within an enterprise network. More specifically, the recognition engine can locally evaluate reputation for a network address being accessed by an endpoint, and this reputation information can be used to dynamically establish a timeout for a request from the endpoint to the threat management facility for corresponding global reputation information.

Abstract: Threat detection instrumentation is simplified by providing and updating labels for computing objects in a context-sensitive manner. This may include simple labeling schemes to distinguish between objects, e.g., trusted/untrusted processes or corporate/private data. This may also include more granular labeling schemes such as a three-tiered scheme that identifies a category (e.g., financial, e-mail, game), static threat detection attributes (e.g., signatures, hashes, API calls), and explicit identification (e.g., what a file or process calls itself). By tracking such data for various computing objects and correlating these labels to malware occurrences, rules can be written for distribution to endpoints to facilitate threat detection based on, e.g., interactions of labeled objects, changes to object labels, and so forth.

Abstract: A security agent conditionally hooks a process for malware monitoring based on a persistent hook state for the process that may be stored, for example, in a process cache. When a process launches in a backoff state indicating that the process previously crashed after hooking, the security agent may further conditionally hook the process based on a reputation of the process or any other relevant contextual information.

Abstract: A threat management facility that remotely stores global reputation information for network content can be used in combination with a recognition engine such as a machine learning classifier that is locally deployed on endpoints within an enterprise network. More specifically, the recognition engine can locally evaluate reputation for a network address being accessed by an endpoint, and this reputation information can be used to dynamically establish a timeout for a request from the endpoint to the threat management facility for corresponding global reputation information.

Abstract: Threat detection is improved by monitoring variations in observable events and correlating these variations to malicious activity. The disclosed techniques can be usefully employed with any attribute or other metric that can be instrumented on an endpoint and tracked over time including observable events such as changes to files, data, software configurations, operating systems, and so forth. Correlations may be based on historical data for a particular machine, or a group of machines such as similarly configured endpoints. Similar inferences of malicious activity can be based on the nature of a variation, including specific patterns of variation known to be associated with malware and any other unexpected patterns that deviate from normal behavior. Embodiments described herein use variations in, e.g., server software updates or URL cache hits on an endpoint, but the techniques are more generally applicable to any endpoint attribute that varies in a manner correlated with malicious activity.

Abstract: Threat detection instrumentation is simplified by providing and updating labels for computing objects in a context-sensitive manner. This may include simple labeling schemes to distinguish between objects, e.g., trusted/untrusted processes or corporate/private data. This may also include more granular labeling schemes such as a three-tiered scheme that identifies a category (e.g., financial, e-mail, game), static threat detection attributes (e.g., signatures, hashes, API calls), and explicit identification (e.g., what a file or process calls itself). By tracking such data for various computing objects and correlating these labels to malware occurrences, rules can be written for distribution to endpoints to facilitate threat detection based on, e.g., interactions of labeled objects, changes to object labels, and so forth.