Sophos Limited

Harald Schütz

Kenneth D Ray

Anthony John Merry

Andreas Berger

Andrew James Thomas

Russell Humphries

John Edward Tyrone Shaw

Daniel Salvatore Schiappa

Mark David Harris

Simon Neil Reed

Neil Robert Tyndale Watkiss

Robert Wendell Cook

Gordon Sullivan

Markus Hein

Gerald Wintersberger

Norbert Gruber

Artur Wenzel

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.

Intrusion detection with honeypot keys

A file system extension for an endpoint controls access to files by selectively decrypting files under certain conditions. Where a pattern of access to the files suggests malicious and/or automated file access activity, the file system extension may limit the rate of file access by regulating the rate at which decryption is provided to requesting processes.

Key throttling to mitigate unauthorized file access

Rules are applied at a network perimeter to outbound network communications that contain file attachments. The rules may, in a variety of circumstances, require wrapping of an outbound file from the endpoint in a portable encrypted container. The network perimeter may be enforced locally at the endpoint, or at any network device between the endpoint and a recipient.

Perimeter enforcement of encryption rules

Securing an endpoint against exposure to unsafe content includes encrypting files to prevent unauthorized access, and monitoring an exposure state of a process to potentially unsafe content by applying behavioral rules to determine whether the exposure state is either exposed or secure, where (1) the process is initially identified as secure, (2) the process is identified as exposed when the process opens a network connection to a URL that is not internal to an enterprise network of the endpoint and that has a poor reputation, (3) the process is identified as exposed when it opens a file identified as exposed, and (4) the process is identified as exposed when another exposed process opens a handle to the process. Access to the files may be restricted when the process is exposed by controlling access through a file system filter that conditionally decrypts files for the process according to its exposure state.

Behavioral-based control of access to encrypted content by a process

An endpoint encrypts local files with a key to protect file contents. If the endpoint or processes on the endpoint becomes exposed to potentially harmful locations or resources, the key can be revoked to prevent access to encrypted files on the endpoint. In order to facilitate continued operation of the endpoint, files that are currently open can be encrypted with a second key so that the corresponding data is isolated from the other encrypted files while remaining accessible to current users.

Intermediate encryption for exposed content

Securing an endpoint against malicious activity includes encrypting a plurality of files on an endpoint to prevent unauthorized access to the plurality of files, receiving a request to access a file from a process executing on the endpoint, decrypting the file for the process, and monitoring a security state of the process. If the security state becomes a compromised state, a technique involves maintaining access to any open files (including the file decrypted for the process), prohibiting access to other files, and initiating a remediation of the process by facilitating a restart of the process. If the remediation is successful, access by the process to the plurality of files may be restored.

Process-level control of encrypted content

On an endpoint that encrypts local files to protect against data leakage and other harmful malware events, newly detected files are dynamically encrypted when they are detected as long as the endpoint is not compromised. If a compromised state is detected, the newly detected file will not be added to the encrypted files until the endpoint can be remediated and the compromised state resolved.

Just-in-time encryption

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. In this manner, threat detection based on complex interactions of computing objects can be characterized in a platform independent manner and pre-processed on endpoints without requiring significant communications overhead with a remote threat management facility.

Growing community of inventors

Linz, Austria

Harald Schütz