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: Activity on an endpoint is monitored in two stages with a local agent. In a first stage, particular computing objects on the endpoint are selected for tracking. In a second stage, particular types of changes to those objects are selected. By selecting objects and object changes in this manner, a compact data stream of information highly relevant to threat detection can be provided from an endpoint to a central threat management facility. At the same time, a local data recorder creates a local record of a wider range of objects and changes. The system may support forensic activity by facilitating queries to the local data recorder on the endpoint to retrieve more complete records of local activity when the compact data stream does not adequately characterize a particular context.

Abstract: An automated system attempts to characterize code as safe or unsafe. For intermediate code samples not placed with sufficient confidence in either category, human-readable analysis is automatically generated to assist a human reviewer in reaching a final disposition. For example, a random forest over human-interpretable features may be created and used to identify suspicious features in a manner that is understandable to, and actionable by, a human reviewer. Similarly, a k-nearest neighbor algorithm may be used to identify similar samples of known safe and unsafe code based on a model for, e.g., a file path, a URL, an executable, and so forth. Similar code may then be displayed (with other information) to a user for evaluation in a user interface. This comparative information can improve the speed and accuracy of human interventions by providing richer context for human review of potential threats.

Abstract: A data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files. When a security event is detected, an event graph may be generated based on these causal relationships among the computing objects. For a root cause analysis, the event graph may be traversed in a reverse order from the point of an identified security event (e.g., a malware detection event) to preceding computing objects, while applying one or more cause identification rules to identify a root cause of the security event. Once a root cause is identified, the event graph may be traversed forward from the root cause to identify other computing objects that are potentially compromised by the root cause.

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: In embodiments of the present invention, a framework for an extensible, file-based security system is described for determining an appropriate application, application environment, and/or access or security control measure based at least in part on a file's reputation. In response to the selection of a file, an application controller may be used to select a software application from two or more software applications to open the selected file, based at least in part on the selected file's reputation. If launched, a software application may be configured to open the file in an environment, such as a virtual machine, quarantined environment, and the like, that is appropriate for the file based at least in part on the reputation information. A software application may be a secure software application configured to manage secure files, or an insecure software application configured to manage insecure files.

Abstract: A data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files. When a security event is detected, an event graph may be generated based on these causal relationships among the computing objects. For a root cause analysis, the event graph may be traversed in a reverse order from the point of an identified security event (e.g., a malware detection event) to preceding computing objects, while applying one or more cause identification rules to identify a root cause of the security event. Once a root cause is identified, the event graph may be traversed forward from the root cause to identify other computing objects that are potentially compromised by the root cause.

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 data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files, and patterns within this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time.

Abstract: A data recorder stores endpoint activity on an ongoing basis as sequences of events that causally relate computer objects such as processes and files, and patterns within this event graph can be used to detect the presence of malware on the endpoint. The underlying recording process may be dynamically adjusted in order to vary the amount and location of recording as the security state of the endpoint changes over time.

Abstract: An interface for a threat management facility of an enterprise network supports the use of third-party security products within the enterprise network by providing access to relevant internal instrumentation and/or a programmatic interface for direct or indirect access to local security agents on compute instances within the enterprise network.

Abstract: A security platform uses a sensor-event-analysis-response methodology to iteratively adapt to a changing security environment by continuously creating and updating entity models based on observed activities and detecting patterns of events that deviate from these entity models.

Abstract: A threat management facility stores a number of entity models that characterize reportable events from one or more entities. A stream of events from compute instances within an enterprise network can then be analyzed using these entity models to detect behavior that is inconsistent or anomalous for one or more of the entities that are currently active within the enterprise network.

Abstract: Entity models are used to evaluate potential risk of entities, either individually or in groups, in order to evaluate suspiciousness within an enterprise network. These individual or aggregated risk assessments can be used to adjust the security policy for compute instances within the enterprise network. A security policy may specify security settings such as network speed, filtering levels, network isolation, levels of privilege, and the like.

Abstract: A collection of documents or other files and the like within an enterprise network are labelled according to an enterprise document classification scheme, and then a recognition model such as a neural network or other machine learning model can be used to automatically label other files throughout the enterprise network. In this manner, documents and the like throughout an enterprise can be automatically identified and managed according to features such as confidentiality, sensitivity, security risk, business value, and so forth.

Abstract: A ledger stores chain of custody information for files throughout an enterprise network. By identifying files with a homologous identifier such as a fuzzy hash that permits piecewise evaluation of similarity, the ledger can be used to track a chain of custody over a sequence of changes in content, ownership, and file properties. The ledger can be used, e.g., to evaluate trustworthiness of a file the first time it is encountered by an endpoint, or to apply enterprise policies based on trust.

Abstract: An authentication model dynamically adjusts authentication factors required for access to a remote resource based on changes to a risk score for a user, a device, or some combination of these. For example, the authentication model may conditionally specify the number and type of authentication factors required by a user/device pair, and may dynamically alter authentication requirements based on changes to a current risk assessment for the user/device while the remote resource is in use.

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: Network devices within an enterprise are configured to pass out-of-band security information such as heartbeats, notifications of compromise, device identification information, and so forth between logical or physical network partitions such as subnets, routing domains, access points, and so forth. This technique can advantageously facilitate integrated management of endpoints across network boundaries that might otherwise interfere with the identification and management of specific devices.

Abstract: Endpoints within a subnet of a heterogeneous network are configured to cooperatively respond to internal or external notifications of compromise in order to protect the endpoints within the subnet and throughout the enterprise network. For example, each endpoint may be configured to self-isolate when a local security agent detects a compromise, and to shun one of the other endpoints in response to a corresponding notification of compromise in order to prevent the other, compromised endpoint from communicating with other endpoints and further compromising other endpoints either within the subnet or throughout the enterprise network.