Securing institutional data

Abstract

Embodiments include systems and methods for automated routine generation and execution. In some embodiments, an exemplary method includes examining a plurality of files related to a user account; identifying, from the plurality of files, at least one file to be protected; restricting access to the at least one file to an escrow account; allowing access by an application to the at least one file; and restoring the access restriction to the at least one file after the application has closed the file. In some embodiments, another exemplary method includes acquiring data related to a file operation; generating an encrypted version of the acquired data; determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; and determining a protective action based on the classification.

Description

TAU-002PCSECURING INSTITUTIONAL DATA CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of and priority to United States Provisional Application No. 63 / 748,496, filed on January 23, 2025, and United States Provisional Application No. 63 / 883,482, filed on September 17, 2025, the entire disclosure of each of which is hereby incorporated by reference as if set forth in its entirety herein.TECHNICAL FIELD

[0002] Embodiments described herein generally relate to systems and methods for securing institutional data, and more particularly but not exclusively, to systems and methods for protecting institutional data using escrow accounts and detecting malware attacks in real-time.BACKGROUND

[0003] Modem healthcare organizations, such as hospitals and clinics, produce enormous volumes of digital data for patients. While some data is stored in structured environments such as electronic medical records (EMR), an increasing percentage of the data is stored as unstructured files, such as text documents, spreadsheets, images, and diagnostic outputs. The files are often stored across a wide range of computing devices and systems, such as network-attached storage (NAS) systems, local drives, endpoint laptops, kiosks, and shared cloud folders. This makes it difficult to maintain an accurate inventory given the diverse operating environments used.

[0004] Moreover, clinicians and researchers often act as data custodians of their own unstructured files. In clinical practice, for example, the responsibility for managing data often falls to the originator of the data. Clinicians, however, tend to lack the time to review and delete stale information. Older files may also still contain information of potential medical, legal, or audit value. Accordingly, clinicians typically prefer to retain all available records, sometimes for more than a decade.

[0005] Such factors make healthcare organizations ideal targets for cybersecurity attacks. Attackers can employ a range of strategies to infiltrate healthcare networks, including phishing and social-engineering campaigns, planted insiders, theft of IT hardware, and compromise through extortion or bribery. Once inside, attackers can ransom sensitive data using either remote control tools (e.g., hands on keyboards) and / or autonomous programs. These attacks, called ransomware attacks, are often carried out in stages, starting with locating sensitive data and then bulk encrypting them so no one can access them without a decryption key. Because administrative accounts in typical operating systems carry backup, restore, take-ownership, and debug privileges,TAU-002PCadversaries can bypass discretionary access-control lists (DACLs) and obtain unrestricted read / write / delete rights.

[0006] Healthcare IT departments, however, often lack the resources, automation tools, and forensic expertise needed to effectively safeguard data from such attacks. Some IT departments can respond by re-imaging endpoints and restoring systems from backup to resume basic functionality. However, the dispersed nature of healthcare data makes it difficult to restore databases, obtain forensic evidence of the attacks, and identify affected patient records.

[0007] Traditional approaches to secure healthcare data, such as network segmentation, endpoint backup, and antivirus scanning, fail to address the unique challenges of securing unstructured data in the healthcare sector. In particular, healthcare providers often demand uninterrupted access to data without any interference, as many clinical processes are time-critical.

[0008] Accordingly, there exists a need for improved methods and systems for securing unstructured data.SUMMARY

[0009] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section. This summary is not intended to identify or exclude key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0010] In one aspect, the techniques described herein relate to a computer-implemented method for file access, including: examining a plurality of files related to a user account; identifying, from the plurality of files, at least one file to be protected; restricting access to the at least one file to an escrow account; allowing access by an application to the at least one file; and restoring the access restriction to the at least one file after the application has closed the file.

[0011] In some embodiments, allowing access to the at least one file includes transferring ownership of the at least one file to an original owner.

[0012] In some embodiments, restricting access to the escrow account includes adding a deny-everyone access control entry to an access control list.

[0013] In some embodiments, allowing access to the at least one file includes removing the deny-everyone access control entry from the access control list.

[0014] In some embodiments, at least one file is identified using at least one factor associated with the plurality of files.TAU-002PC

[0015] In some embodiments, at least one factor relates to at least one of a file attribute, a user identity, a user group association, a creation date, or a file content tag.

[0016] In some embodiments, the method further includes receiving, via the application, a request from a user to access unstructured data at the at least one file.

[0017] In some embodiments, the request includes an attempt by the user to open the at least one file.

[0018] In some embodiments, the escrow account is secured from unauthorized use.

[0019] In some embodiments, allowing access to the at least one file includes determining an access level based on an authorization policy.

[0020] In some embodiments, the authorization policy uses historical file usage patterns to determine the access level.

[0021] In some embodiments, the method further includes performing an entropy calculation while the at least one file is being accessed.

[0022] In some embodiments, the method further includes restoring the access restriction to the at least one file based on the entropy calculation.

[0023] In another aspect, the techniques described herein relate to a system for file access including: memory storing instructions; and a processor executing the instructions to perform the steps of: examining a plurality of files related to a user account; identifying, from the plurality of files, at least one file to be protected; restricting access to the at least one file to an escrow account; allowing access by an application to the at least one file; and restoring the access restriction to the at least one file after the application has closed the file.

[0024] In some embodiments, allowing access to the at least one file includes transferring ownership of the at least one file to an original owner.

[0025] In some embodiments, restricting access to the escrow account includes adding a deny-everyone access control entry to an access control list.

[0026] In some embodiments, at least one file is identified using at least one factor associated with the plurality of files.

[0027] In some embodiments, the processor further executes the instructions to perform the step of receiving, via the application, a request from a user to access unstructured data at the at least one file.TAU-002PC

[0028] In some embodiments, the processor further executes the instructions to perform the steps of: receiving an authorization policy from a policy management tool; and determining an access level based on the authorization policy.

[0029] In yet another aspect, the techniques described herein relate to a computer program product for file access embodied in a non-transitory computer readable storage medium and including computer instructions for: examining a plurality of files related to a user account; identifying, from the plurality of files, at least one file to be protected; restricting access to the at least one file to an escrow account; allowing access by an application to the at least one file; and restoring the access restriction to the at least one file after the application has closed the file.

[0030] In yet another aspect, the techniques described herein relate to a computer-implemented method for securing files, including: acquiring data related to a file operation; generating an encrypted version of the acquired data; determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; and determining a protective action based on the classification.

[0031] In some embodiments, determining the entropy profiles includes determining sliding and fixed window entropy characteristics.

[0032] In some embodiments, the method further includes comparing the entropy profiles, wherein the classification is based on the comparison.

[0033] In some embodiments, comparing the entropy profiles includes determining sliding and fixed window differences between the entropy profiles.

[0034] In some embodiments, the method further includes detecting use of anti-forensic masking using the entropy profiles; and removing at least one masking portion from the acquired data and the encrypted version before classifying the file operation.

[0035] In some embodiments, the method further includes recomputing entropy profiles for the acquired data and the encrypted version after the at least one masking portion has been removed; and comparing the recomputed entropy profiles.

[0036] In some embodiments, the method further includes determining at least one entropy feature based on the entropy profiles; determining at least one usage feature based on metadata associated with the file operation, wherein the classification is based on the at least one entropy feature and the at least one usage feature.

[0037] In some embodiments, the classifying the file operation is performed using a machine learning model trained on known malicious data.TAU-002PC

[0038] In some embodiments, the machine learning model includes a decision forest learning model.

[0039] In some embodiments, the method further includes aggregating the classification with at least one additional classification; and determining a session-level likelihood of malicious activity.

[0040] In some embodiments, the protective action includes at least one of monitoring additional file operations or suspending an offending process.

[0041] In yet another aspect, the techniques described herein relate to a system for securing files including: memory storing instructions; and a processor executing the instructions to perform the steps of: acquiring data related to a file operation; generating an encrypted version of the acquired data; determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; and determining a protective action based on the classification.

[0042] In some embodiments, the processor is configured to perform the steps using SIMD-accelerated processing.

[0043] In some embodiments, determining the entropy profiles includes determining sliding and fixed window entropy characteristics.

[0044] In some embodiments, the processor further executes the instructions to perform the step of comparing the entropy profiles, wherein the classification is based on the comparison.

[0045] In some embodiments, the processor further executes the instructions to perform the steps of: detecting use of anti -forensic masking using the entropy profiles; and removing at least one masking portion from the acquired data and the encrypted version before classifying the file operation.

[0046] In some embodiments, the processor further executes the instructions to perform the steps of: determining at least one entropy feature based on the entropy profiles; determining at least one usage feature based on metadata associated with the file operation, wherein the classification is based on the at least one entropy feature and the at least one usage feature.

[0047] In some embodiments, the classifying the file operation is performed using a machine learning model trained on known malicious data.

[0048] In some embodiments, the processor further executes the instructions to perform the steps of: aggregating the classification with at least one additional classification; and determining a session-level likelihood of malicious activity.TAU-002PC

[0049] In yet another aspect, the techniques described herein relate to a computer program product for securing files embodied in a non-transitory computer readable storage medium and including computer instructions for: acquiring data related to a file operation; generating an encrypted version of the acquired data; determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; and determining a protective action based on the classification.BRIEF DESCRIPTION OF DRAWINGS

[0050] Non-limiting and non-exhaustive embodiments of the invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

[0051] FIG. 1 illustrates a system for securing institutional data in accordance with one embodiment.

[0052] FIG. 2 illustrates a flowchart of a method for automated routine generation in accordance with one embodiment.

[0053] FIG. 3 illustrates another system for securing institutional data in accordance with one embodiment.

[0054] FIG. 4A illustrates a plot including entropy profiles for a non-ransomed file and an encrypted version of the file.

[0055] FIG. 4B illustrates an alternate embodiment of the plot illustrated in FIG. 4A.

[0056] FIG. 4C illustrates another alternate embodiment of the plot illustrated in FIG. 4C.

[0057] FIG. 5 illustrates a pipeline for entropy-based malware detection in accordance with one embodiment.

[0058] FIG. 6 illustrates a flowchart of a method for entropy-based malware detection in accordance with one embodiment.

[0059] FIG. 7 illustrates a flowchart of a method for entropy-based malware detection in accordance with one embodiment.

[0060] FIG. 8 illustrates a flowchart of a method for training models for malware detection in accordance with one embodiment.

[0061] FIG. 9 illustrates a flowchart of a method for malware mitigation in accordance with one embodiment.TAU-002PC

[0062] FIG. 10A illustrates a system for entropy -based malware detection in accordance with one embodiment.

[0063] FIG. 10B illustrates an alternate embodiment of the system illustrated in FIG. 10 A.

[0064] FIG. 10C illustrates another alternate embodiment of the system illustrated in FIG.10 A.DETAILED DESCRIPTION

[0065] Various embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments. However, the concepts of the present disclosure may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided as part of a thorough and complete disclosure, to fully convey the scope of the concepts, techniques and implementations of the present disclosure to those skilled in the art. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.

[0066] Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one example implementation or technique in accordance with the present disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. The appearances of the phrase “in some embodiments” in various places in the specification are not necessarily all referring to the same embodiments.

[0067] Some portions of the description that follow are presented in terms of symbolic representations of operations on non-transient signals stored within a computer memory. These descriptions and representations are used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. Such operations typically require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic or optical signals capable of being stored, transferred, combined, compared and otherwise manipulated. It is convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. Furthermore, it is also convenient at times, to refer toTAU-002PCcertain arrangements of steps requiring physical manipulations of physical quantities as modules or code devices, without loss of generality.

[0068] However, all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission or display devices. Portions of the present disclosure include processes and instructions that may be embodied in software, firmware or hardware, and when embodied in software, may be downloaded to reside on and be operated from different platforms used by a variety of operating systems.

[0069] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0070] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform one or more method steps. The structure for a variety of these systems is discussed in the description below. In addition, any particular programming language that is sufficient for achieving the techniques and implementations of the present disclosure may be used. A variety of programming languages may be used to implement the present disclosure as discussed herein.

[0071] In addition, the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribeTAU-002PCthe disclosed subject matter. Accordingly, the present disclosure is intended to be illustrative, and not limiting, of the scope of the concepts discussed herein.

[0072] Embodiments described herein include systems and methods for securing unstructured data, such as unstructured healthcare data, by governing the access privileges of user applications and detecting potential malicious activity. For example, an exemplary embodiment may use a contextually aware authorization strategy to determine whether an application should be granted access to sensitive data. This may prevent wholesale data loss from cybersecurity attacks, such as ransomware and exfiltration.

[0073] In traditional operating environments, such attacks may have unrestricted read and / or write access due to the legacy administrative rights that are automatically assigned to administrator accounts handled by the operating system. In contrast, described embodiments may use a zero¬ trust authorization model that checks, at the time of file use by an applica tion, whe ther a file should be allowed access based on additional contextual and historical attributes. This model may limit the effect of cybersecurity attacks by selectively granting file level access to an application based on risk potential rather than based on user-assigned rights.

[0074] Described embodiments may use an on-demand unprotect strategy to limit the effect of cybersecurity attacks. The strategy may protect data without the need to copy or move any sensitive files.

[0075] FIG. 1 illustrates a system 100 for securing institutional data in accordance with one embodiment. The system 100 may include any number of components for performing operations related to securing data. As shown, for example, the system may include an endpoint device 102 and an administrative device 104.

[0076] The endpoint device 102 may include any type or form of device that a user can interact with to perform one or more functions or operations. Exemplary user devices may include, but are not limited to, smartphones, tablets, personal computers (e.g., laptops, desktops, etc.), smartwatches, fitness trackers, and / or television sets.

[0077] In some embodiments, the endpoint device 102 may store data related to the user. The data may include structured and / or unstructured data related to a user account, such as an account belonging to the user. The data may be related to any suitable domain, such as healthcare, pharmaceuticals, technology, business, finance, and / or manufacturing. For example, the data may include patient records for a healthcare organization, such as a hospital. The data may include sensitive and / or confidential data, such as protected health information (PHI) or personally identifiable information (PII).TAU-002PC

[0078] As shown, the data may be stored as files managed by a file system 106. The file system 106 may be implemented using any suitable file system technologies. For example, the file system 106 may be implemented using file allocation tables (FAT), new technology file system (NTFS), hierarchical file system plus (HFS+), extended file system (EXT), and / or resilient file system (ReFS). The file system 106 may organize data stored at the endpoint device 102 as files in various directories and / or subdirectories. While the file system 106 is illustrated as storing local data, it is to be appreciated that the file system 106 may be a remote file system managing data stored at a remote data store, such as a cloud server.

[0079] In some embodiments, the endpoint device 102 may be configured to execute at least one application, such as applications 108. The applications 108 may include any type of application, such as containerized applications, web programs, deployment tools, security services, data services, database applications, and / or data analytics platforms. The applications 108 may provide a user interface that allows the user to interact with the rest of the system 100. The user interface may receive inputs from the user, such as requests to access patient records or other sensitive data.

[0080] In some embodiments, the system 100 may include an administrative device 104. The administrative device 104 may include any type or form of device that an administrator may interact with to perform one or more functions or operations. Exemplary administrative devices may include, but are not limited to, smartphones, tablets, personal computers (e.g., laptops, desktops, etc.), smartwatches, fitness trackers, and / or television sets. The administrative device 104 may be in communication with the endpoint device 102, such as by using a network or any other suitable communication method. The administrative device 104 may be associated with the same organization or entity as the endpoint device 102. For example, the administrative device 104 and the endpoint device 102 may be connected to a network for the same hospital or any other healthcare organization.

[0081] In some embodiments, the administrative device 104 may allow an administrator of the system 100 to interact with other components of the system 100, such as the endpoint device 102. For example, the administrative device 104 may allow the administrator to set various policy configurations related to data at the file system 106 and / or any other file systems in communication with the administrative device 104.

[0082] In some embodiments, the system 100 may manage sensitive or confidential files requiring protection from unwanted access. The system 100 may be configured to secure the data. For example, as described in detail herein, the system 100 may protect the data using escrow accounts and / or perform real-time detection of malware attacks.TAU-002PC

[0083] FIG. 2 illustrates a flowchart of a method 200 for securing institutional data in accordance with one embodiment. While FIG. 2 shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, and / or modify any of the operations depicted in FIG. 2. Moreover, each of the operations depicted in FIG. 2 may be performed in any of the ways described herein. The operations depicted in FIG. 2 may be performed by any of the illustrative systems described herein, such as the system 100. For example, any of the operations may be performed at and / or directed by the endpoint device 102.

[0084] Operation 202 may include examining a plurality of files associated with a user account. The files may include data related to a healthcare organization, such as unstructured data at a hospital or clinic. The user account may belong to a clinician or any other individual related to the healthcare organization. The owner of the files may be the user of the user account, the originator of the files, and / or any other suitable individual or entity. The files may include confidential or otherwise sensitive data, such as confidential patient records.

[0085] In some embodiments, the files may be stored at a suitable file system, such as the file system 106. The file system 106 may organize the files using various directories or subdirectories. The files may be examined by examining various file paths at a file system (e.g., the file system 106), such as by recursively traversing all accessible file paths. The file paths may be traversed periodically (e.g., weekly) and / or based on an occurrence of an event, such as the creation of a new user account or file path.

[0086] Operation 204 may include identifying, from the plurality of files, at least one file to be protected. The file may be identified as requiring protection from unwanted access. For example, the file may contain confidential or otherwise sensitive information that should not be accessed by the general public.

[0087] The file may be identified using any suitable technique. For example, the system may use at least one criterion for identifying the file. Exemplary criteria may include, but are not limited to, file attributes (e.g., file type, extension, etc.), user identities (e.g., owner, creator, shared user, etc.), user group associations (e.g., legal, finance, IT, etc.), creation date, last use date, modification date, privacy settings (e.g., anonymous, secured, etc.), and / or file content tags.

[0088] In some embodiments, the file content tags may be automatically defined. For example, the system may use machine learning models or rule-based models to evaluate file contents and classify the contents based on sensitivity. The models may assign sensitivity scores to the contents, with sensitivity scores exceeding a threshold indicating files that should be prioritized for protection. In some embodiments, the file content tags may be manually defined (e.g., by the owner) using label frameworks or embedded metadata.TAU-002PC

[0089] Operation 206 may include restricting access to the at least one file to an escrow account. As used herein, the escrow account may be a secured system account created to hold ownership and control over protected files. The escrow account may hold exclusive privileges for accessing, modifying, and / or restoring protected files.

[0090] In some embodiments, the access restriction may include adding a “deny-everyone” access control entry (ACE) to the access control list (ACL) of the file. The ACE may block all other users and groups from performing operations on or otherwise accessing the file. This may prevent unauthorized access without the need to modify, copy, and / or move the file itself.

[0091] In some embodiments, the access restriction may be logged and / or cryptographically signed to ensure non-repudiation and allow later reconstruction of access restriction events.

[0092] In some embodiments, newly created files may be protected using escrow accounts as soon as the files are not being accessed by any applications or services. This may prevent attackers from opportunistically targeting newly created files.

[0093] In some embodiments, the escrow account may be protected using advanced security features, such as hardware-based Trusted Platform Module (TPM) protection of account credentials and / or operating system features. For example, the features may include security controls such as enabling Windows Credential Guard and / or Local Security Authority (LSASS) process protection. This may prevent unwanted extraction of credentials from system memory. In some examples, the escrow account may be a Windows Protected Users account. In some examples, the escrow account may be implemented as a group of multiple identities, such as a domain-level group of managed identities.

[0094] In some embodiments, the use of legacy privileges that allow accounts to bypass file system access controls may be restricted. These legacy privileges may present a significant security exposure because they may be used to override file ACLs. Individuals that still need the legacy privileges (e.g., administrators) may access them through a Privileged Access Management (PAM) system.

[0095] In some embodiments, multiple escrow accounts may be maintained for a user device. A particular escrow account may be designated as the primary account, with the remaining escrow accounts designated as secondary accounts. When the primary account becomes unavailable, a secondary account may be designated as the primary account. This process may be triggered manually by an administrator and / or automatically in response to abnormal failures or time-based expiration policies.TAU-002PC

[0096] Operation 208 may include allowing access by an application to the at least one file based on an access request. For example, the access request may be the application attempting to open the file and / or the application making a formal request to access the file.

[0097] In some embodiments, access may be allowed by removing the “deny-everyone” ACE from the file ACL and reverting ownership from the escrow account back to the original user or creator. This may allow the application to access the file normally as if the access restriction did not occur.

[0098] Operation 210 may include restoring the access restriction to the at least one file after the application has closed the file. The access restriction may be restored in a similar manner as to the original access restriction. For example, ownership of the file may be restored to the escrow account and the “deny-everyone” ACE may be re-inserted into the file.

[0099] In some embodiments, the access restriction may be automatically restored after a particular event, such as the application closing the file or otherwise relinquishing control of the file. The restoration may occur immediately after the event, which may ensure that the file is vulnerable to attack for as short of a duration as possible.

[0100] As described above, sensitive files may be protected by default using an escrow account and unprotected only when necessary. In some embodiments, the system may use zero-trust principles for allowing access to protected files. Zero-trust principles assume there is no implicit trust granted to users based solely on their physical or network location (e.g., local area networks versus the internet). Rather, access may be dynamically granted based on various factors such as historical usage factors.

[0101] In contrast, many conventional systems are overly reliant on user authentication (e.g., multifactor authentication) to grant access to files. In such systems, access is determined solely by file ACLs with no additional determinations made based on context, historical usage, and / or potential risk. A suitable zero-trust policy that blocks access to an application opening thousands of files at a high rate may, for example, stop the potential loss of millions of files in a ransomware attack.

[0102] Accordingly, in some embodiments, a zero-trust authorization policy may be used to determine when an application should be given access to a protected file (e.g., a file protected by an escrow account) and what the appropriate access level should be. The authorization policy may be implemented with various rules, logic, and / or models for determining access levels for protected files. The authorization policy may be specific to a particular user or group.TAU-002PC

[0103] In some embodiments, the determination may be performed in real-time, such as immediately after an application attempts to open a protected file. For example, a file filter driver for a file system may intercept an API call made by the application so that the authorization policy may be applied.

[0104] In some embodiments, the determination may include selecting among multiple access levels using the authorization policy. For example, unrestricted access may be granted for low-risk access attempts. Unrestricted access may correspond to using the original ACL for the file. In some embodiments, the authorization policy may specify a time-based allowance for specific processes such as maintenance routines or backups. Conditional access may be granted based on successful user reauthentication, as according to the authorization policy. Access may be denied for high-risk access attempts or unsuccessful reauthentication attempts.

[0105] Any suitable reauthentication method may be required for conditional access, such as passwords, PINs, security questions, badge taps, Bluetooth or NFC proximity devices, devices using built in authenticators, and / or mobile push notifications requesting confirmation to grant access. In some embodiments, the reauthentication method may be dynamically selected based on contextual factors, such as the risk level of the access attempt, sensitivity level of the data, number of files accessed within a time period, rate of file access events, device location, user identity, group identity, application attributes, and / or any other suitable factors described herein. For example, stricter reauthentication methods may be required for unknown applications accessing a large volume of highly sensitive files. In some embodiments, reauthentication policies may be manually customized by suitable individuals such as administrators.

[0106] In some embodiments, the authorization policy may use various factors for determining an access level for the application. Exemplary factors may include, but are not limited to file content (e.g., how sensitive the content is), file attributes, file users (e.g., what groups the users belong to, what roles the users have, etc.), file creation dates, file last use dates, file modification dates, application attributes (e.g., whether the application is trusted, whether the application is known, application age, whether the application is widely deployed, whether the application is frequently used, an application type such as an interactive application, what privileges the application uses, etc.), access request attributes (e.g., whether the request is a read request or write request, whether security attributes are being overwritten, whether enhanced file open options are being specified, etc.), user authentication status (e.g., whether the user identify was verified, when the user identify was verified, etc.), session attributes (e.g., a session type such as an interactive session, whether the user is running locally or remotely, a login date, etc.), and / or file activity (e.g.,TAU-002PCwhat access modes the application requesting, whether files are being moved or copied to external devices, etc.).

[0107] In some embodiments, the authorization policy may use past file usage patterns for determining the access level. The system may collect past file usage data from past access attempts. The past file usage data may characterize normal usage behavior by the corresponding population. Examples of past file usage data may include, but are not limited to, number of files accessed within a time period, when the files were accessed (e.g., time of day, time periods, etc.), frequency of file access events, devices used to access the files, applications used to access the files, types of files, age of files, most recent time of access, sources or destinations of file accesses, and / or types of file access events.

[0108] The past file usage data may be collected across any suitable time period. For example, file usage data may be collected for a single session or aggregated over a longer time period. The past file usage data may be collected for any suitable set of individuals, such as a single user, a group of users, and / or all users within an environment or organization (e.g., a hospital). The past file usage data may be collected for a single device and / or aggregated over multiple devices. The file usage model may be periodically updated as new file usage data is collected.

[0109] In some embodiments, statistical descriptors may be generated from the past file usage data, such as mean, median, standard deviation, variance, skewness, and / or time series approximations. In some embodiments, the statistical descriptors may include rolling metrics. The statistical descriptors may be used to determine the access level.

[0110] In some embodiments, the past file usage data may be used to build a unified model indicating typical usage behavior by the corresponding population. For example, the system may aggregate the past file usage data into a concatenated feature vector, a multimodal embedding (e.g., using machine learning models), and / or a graph structure representing usage relationships.[OHl] The access level may be determined using any of the described factors. For example, in some embodiments, current data relating to the factors (e.g., current file usage data) may be collected and compared to baseline data or any other data indicating typical behavior, such as the past file usage data. If the current data sufficiently corresponds to the values (e.g., falls within normal ranges), then unrestricted or conditional access may be granted. Otherwise, access may be denied. The baseline data may be identified based on past sessions, such as with the past file usage data.

[0112] In some embodiments, a score (e.g., a similarity score, a confidence level, a risk score, etc.) may be calculated to determine the access level. For example, a similarity score may beTAU-002PCcalculated based on a comparison between the current data and baseline data. Any suitable similarity metric may be used, such as Euclidian distance metrics, Mahalanobis distance metrics, and / or cosine similarity metrics. If the score exceeds a first threshold, then unrestricted access may be granted. If the score exceeds a second threshold but not the first threshold, conditional access may be granted. Otherwise, access may be denied.

[0113] In some embodiments, the authentication decision may be a one-time decision for a given period, such as a user session. In some embodiments, the authentication decision may be continuously updated, such as in response to continuously incoming data such as file usage data. The authentication decision may be updated each time new data is collected (or after a predetermined number of data collection events). For example, an application may initially be granted access to a protected file but then be denied access or asked to reauthenticate after exhibiting anomalous or suspicious behavior while the file is being accessed. In some embodiments, the application may be denied access or asked to reauthenticate after opening at least a predetermined number of sensitive files within a session (e.g., after opening at least 50 files), after the session duration exceeding a normal range, and / or after attempting to change the entropy profile of a file. This may limit the number of compromised files in a security attack while preventing undue delays or disruptions on organizational workflows.

[0114] FIG. 3 illustrates a system 300 for securing institutional data in accordance with one embodiment. The system 300 may include any number of components for performing operations related to structured language query generation. As shown, for example, the system may include the endpoint device 102 and the administrative device 104.

[0115] As described with respect to FIG. 1, the endpoint device 102 may be configured to manage data stored locally and / or at remote data stores. For example, the endpoint device 102 may protect sensitive files using escrow accounts. The applications 108 may request access to protected files managed by the file system 106. The applications 108 may issue file access requests via API calls, which may be intercepted at a file filter driver 302. The file filter driver 302 may be a kernel-mode driver configured to filter or otherwise handle file access requests between usermode applications (e.g., the applications 108) and the file system 106. For example, the file filter driver 302 may translate file access requests into physical reads and writes directed to storage targets, such as local files or remote files.

[0116] In some embodiments, the file filter driver 302 may extract various metadata regarding the access request, such as the file name, access mode, process name, and / or user identity. The file filter driver 302 may send the metadata to an authorization tool 304. The authorization tool 304 may evaluate the access request using policy files 306 and usage files 308. The policy filesTAU-002PC306 may include various authorization policies for access requests. The usage files 308 may include contextual data related to any of the authorization factors described herein, such as past file usage data. The policy files 306 and / or usage files 308 may be maintained locally at the endpoint device 102 and / or stored remotely for multiple devices or systems.

[0117] In some embodiments, the authorization tool 304 may determine an authentication decision based on the policy files 306 and usage files 308. The authorization tool 304 may grant unrestricted access, conditionally grant access, and / or deny access completely. An access decision may prompt a file system driver 310 to unprotect the requested files by transferring file ownership out of the escrow account.

[0118] In some embodiments, communication channels between the file filter driver 302 and other components of the system 300 (e.g., the authorization tool 304) may be cryptographically secured. For example, the file filter driver 302 may confirm the digital certificate of any callers. This may prevent malware software from implementing a man-in-the-middle attack and altering API calls to and / or from the file filter driver 302.

[0119] In some embodiments, various policy settings may be configured by the administrative device 104. For example, an administrator may configure policy settings and distribute the settings to various directories using a policy management tool. In some embodiments, the policy management tool may be a Group Policy Object (GPO) management tool configured to distribute policy settings as GPOs within a domain. This may ensure that policy settings are kept up to date for multiple endpoint devices within an organization or network. The distribution may occur within any suitable domain, such as an entire organization, a unit of an organization, and / or a particular device or user.

[0120] In some embodiments, the policy management tool may secure the policy settings from unwanted access or bogus alterations. For example, the policy management tool may determine that an attempt to change a policy setting is suspicious or bogus and revert the policy setting to a default value.

[0121] Any of the operations described above may be performed using a machine learning model. For example, a model may be used to calculate a score for determining the access level. The model may be configured to implement one or more decision tree learning algorithms, association rule learning algorithms, artificial neural network learning algorithms, deep learning algorithms, bitmap algorithms, and / or any other suitable data analysis technique as may serve a particular implementation. In some embodiments, the model may be implemented by one or more neural networks, such as one or more deep convolutional neural networks (CNN) using internal memories of its respective kernels (filters), recurrent neural networks (RNN), and / or long / shortTAU-002PCterm memory neural networks (LSTM). The model may be multi-layer. For example, the model may be implemented by a neural network that includes an input layer, one or more hidden layers, and / or an output layer. The model may be trained on past access events using past file usage data.

[0122] As described above, sensitive files may be protected using escrow accounts and zerotrust authentication decisions. Protected files, however, remain vulnerable to malicious activity while an application is accessing the files. A particularly damaging form of malicious activity, ransomware, continues to be pervasive among IT systems, including IT systems at healthcare organizations. Ransomware involves an attacker encrypting files and then demanding a ransom payment in exchange for access to the files. This form of attack is often executed after an attacker has gained unauthorized access to a system endpoint or compromised a secure account.

[0123] Once an attacker has gained access to a system, the attacker may identify accessible storage locations and selectively encrypt files, often those possessing high commercial, operational, and / or clinical value. The resulting extortion process may escalate through timesensitive ransom demands, automatic data destruction threats, and / or continuous monitoring for recovery attempts. Unlike with legitimate encryption mechanisms designed to protect confidentiality, ransomware attackers often withhold or destroy the encryption key, effectively rendering the victim’s data inaccessible. Recovery is frequently possible only by obtaining a decryptor tool from the attacker.

[0124] Healthcare and life-science IT environments are particularly vulnerable to ransomware attacks. Clinical workflows and research studies generate vast quantities of unstructured data, such as medical imaging (MRI, CT, and X-ray scans), digital pathology reports, and / or physiological waveform recordings (e.g., EKGZECG). These types of data are often distributed across disparate endpoints, making the data difficult to inventory, monitor, or protect using conventional security controls.

[0125] The cost of losing such data or even temporary inaccessibility can be substantial. Many clinical studies cannot be repeated due to patient unavailability, ethical constraints, or timesensitive conditions. Furthermore, clinicians typically retain data indefinitely, often without purging stale content, and may override automated access decisions based on clinical judgment. This may cause legacy files to accumulate, thus expanding the potential attack area. These conditions collectively create an environment in which ransomware can propagate rapidly, disrupt critical operations, and evade traditional defenses. Attackers increasingly exploit the complexity of such environments by deploying autonomous ransomware variants capable of operating without direct user interaction. Such programs perform bulk encryption across high-value data stores and employ anti-forensic techniques to avoid detection.TAU-002PC

[0126] The growing sophistication and frequency of ransomware attacks, combined with the broad diversity of IT environments, has exposed weaknesses in traditional signature-based and behavior-based defense strategies. Signature-based approaches fail to identify novel or polymorphic ransomware strains, while behavior-based models often rely on user activity, file access history, or learned baselines that may be unavailable, incomplete, or easily manipulated by adversaries.

[0127] Entropy analysis, however, has emerged as a promising solution for detecting ransomware attacks and other malicious activity. Entropy refers to a quantitative measure of the amount of randomness or uncertainty present in a system. With digital data, entropy represents the degree of unpredictability or variation among the possible values that a data element, such as a byte, may assume. A higher entropy value generally signifies a more disordered or randomized distribution of data values, whereas lower entropy indicates more structured or predictable content.

[0128] For most unencrypted files, not all of the possible byte values are used uniformly. Consequently, unencrypted files often exhibit lower entropy per byte than purely random data. By contrast, encrypted data, including data encrypted legitimately or maliciously by ransomware, often exhibits high entropy, as the encryption process intentionally randomizes the data to prevent recovery of the original content.

[0129] Existing entropy-based methods for ransomware detection often attempt to exploit this distinction by computing and comparing file-level entropy values. However, traditional techniques typically require precomputing the entropy profiles of each file, recomputing entropy profiles when the files change, and then comparing the recomputed profiles and precomputed profiles to detect suspicious changes. This process introduces computational overhead and remains vulnerable to false positives caused by legitimate encryption, compression, or data obfuscation operations.

[0130] Accordingly, embodiments described herein include improved systems and methods for entropy-based malware detection. The described embodiments recognize that entropy often varies naturally within a file depending on its structure, encoding format, and intended use. For example, the header portion of a typical file may contain information needed to parse the body of the file. A compressed file may keep the variable length code table used to decode the body of the file. The trailer portion of the file may contain information used to validate the integrity of the file or to track changes to the file. The differences in the type of information stored throughout the file may result in localized variations seen in normal files. Ransomed files, in comparison, may have consistently high entropy throughout the file as their only purpose is to obfuscate the data.TAU-002PC

[0131] As described in more detail herein, the described embodiments may analyze the entropy profiles of data prior to its commitment to persistent storage. By examining byte-level entropy patterns within in-memory data streams, the described embodiments may identify encryption indicative of ransomware activity before file writes complete, thereby preventing irreversible data loss. The described embodiments may operate without relying on historical baselines, signature databases, and / or user-specific behavioral models. The described embodiments may function across diverse operating environments (e.g., endpoints, servers, NAS devices, cloud platforms, etc.) and may be well-suited for healthcare settings where the protection of unstructured clinical data is essential.

[0132] FIG. 4A illustrates a plot 400 including entropy profiles for a non-ransomed file and an encrypted version of the file. As shown, the encrypted entropy profile shows uniformly high entropy within the encrypted version, while the non-ransomed entropy profile is much more variable.

[0133] FIG. 4B illustrates the plot 400 including entropy profiles for a ransomed file and an encrypted version of the ransomed file. As shown, the two entropy profiles are substantially similar, with both exhibiting uniformly high entropy.

[0134] FIG. 4C illustrates the plot 400 including entropy profiles for a ransomed file with entropy masking bands applied and an encrypted version of the ransomed file. The masking bands may artificially lower specific regions of an entropy profile. Attackers may use the masking bands to circumvent conventional entropy-based malware detection methods.

[0135] As described in detail herein, the described embodiments may use differences in entropy profiles of ransomed files and non-ransomed files to detect if a process has applied encryption in a manner consistent with malware attacks. In some embodiments, to counter efforts to evade detection with masking bands, the entropy masking bands may be detected and excluded in the detection process.

[0136] FIG. 5 illustrates a pipeline 500 for entropy-based malware detection in accordance with one embodiment. The pipeline 500 may be a digital signal processing (DSP) pipeline configured to receive an input stream 502 relating to at least one file operation and output a classification 504 of whether the file operation is part of a malware attack.

[0137] In some embodiments, the pipeline 500 may include various processing stages relating to entropy-based malware detection. As shown, for example, the pipeline 500 may include a stream encryption stage 506, an entropy profiling stage 508, a median filtering stage 510, a maskTAU-002PCdetection stage 512, and a mask removal stage 514. The depicted processing stages are described in further detail herein.

[0138] In some embodiments, the pipeline 500 may allow for parallel and / or concurrent processing of the processing stages. For example, the pipeline 500 may be configured to use Single Instruction, Multiple Data (SIMD) architectures available in modem central processing units (CPUs). SIMD allows for the simultaneous execution of operations across multiple data elements within a single instruction cycle, thereby increasing throughput and reducing latency in entropy analysis.

[0139] In some embodiments, each core of a multi-core CPU processing the pipeline 500 may contain up to sixteen 256-bit registers (e.g., YMM0 to YMM15). Each register may be capable of operating on multiple data elements in parallel. Multiple sets of registers may be concurrently available, permitting concurrent execution of DSP routines across multiple threads. The pipeline 500 may use multithreading to concurrently perform processing stages, allowing real-time analysis of high-volume unstructured data. This may be particularly beneficial in healthcare environments, where large volumes of diagnostic files (e.g., imaging, waveform traces, pathology reports, etc.) often need to be inspected rapidly and non-disruptively to ensure data integrity and regulatory compliance.

[0140] FIG. 6 illustrates a flowchart of a method 600 for entropy-based malware detection in accordance with one embodiment. While FIG. 6 shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, and / or modify any of the operations depicted in FIG. 6. Moreover, each of the operations depicted in FIG. 6 may be performed in any of the ways described herein. The operations depicted in FIG. 6 may be performed by any of the illustrative systems described herein, such as the system 100. For example, any of the operations may be performed at and / or directed by the endpoint device 102.

[0141] Operation 602 may include acquiring data related to a file operation. File operations occurring at a file system (e.g., the file system 106) may be continuously or periodically monitored. The data may be acquired for a read operation as a data read from a file and / or for a write operation as an intercepted cache write. The data may be continuously acquired as a data stream. The acquired data may be transferred immediately to a processing queue and analyzed asynchronously.

[0142] In some embodiments, the file may be a sensitive or confidential file that has been unrestricted temporarily for a user related to the file operation. For example, the file operation may have occurred after ownership of the file has been transferred out of a secured escrow account (e.g., after the operation 208).TAU-002PC

[0143] Operation 604 may include generating an encrypted version of the acquired data. The acquired data may be encrypted using an encryption algorithm in real time to produce the encrypted version. For example, the encryption algorithm may use symmetric blocks or stream ciphers and may be implemented in a deterministic and reversible manner. The encrypted version may be generated as a separate version without modifying the original data.

[0144] In some embodiments, the acquired data may be encrypted as the data is acquired to produce an encryption stream. The data acquisition and data encryption may be performed in parallel across multiple threads. As the data arrives, encryption keys and initialization vectors may be generated dynamically and applied on a per-segment basis to preserve synchronization between the encrypted stream and the acquired data.

[0145] Operation 606 may include determining entropy profiles for the acquired data and the encrypted version. The entropy profiles may be quantitative representations of randomness across the acquired data and the encrypted version. As described above, the encrypted version is expected to have a uniformly high entropy profile. The entropy profiles may be determined using any suitable technique. For example, as described in detail herein, sliding and / or fixed window entropy profiles may be calculated.

[0146] Operation 608 may include classifying the file operation based on the entropy profiles. The classification may indicate whether the file operation should be considered malicious activity (e.g., part of a ransomware attack) or benign. As described in detail herein, machine learning models such as decision trees may be used to classify the file operation.

[0147] Operation 610 may include determining a protective action based on the classification. The protective action may be determined in response to the classification indicating malicious activity. As described in detail herein, the protective action may serve to contain the malicious activity and / or preserve forensic evidence.

[0148] FIG. 7 illustrates a flowchart of a method 700 for entropy-based malware detection in accordance with one embodiment. While FIG. 7 shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, and / or modify any of the operations depicted in FIG. 7. Moreover, each of the operations depicted in FIG. 7 may be performed in any of the ways described herein. The operations depicted in FIG. 7 may be performed by any of the illustrative systems described herein, such as the system 100. For example, any of the operations may be performed at and / or directed by the endpoint device 102.

[0149] At operation 702, the method 700 may include acquiring a data stream related to a file operation. The operation 702 may be similar to the operation 602.1TAU-002PC

[0150] At operation 704, the method 700 may include generating an encrypted data stream from the acquired data stream. The operation 704 may be similar to the operation 604.

[0151] As shown, the acquired data and the encrypted data stream may be further processed in parallel using multiple processing streams. The method 700 may include additional processing streams for anti-forensic masking detection. The method 700 may be structured as a DSP pipeline optimized for SIMD execution.

[0152] At operation 706, the method 700 may include determining entropy profiles for the acquired data stream and encrypted data stream. The operation 706 may be performed concurrently for the acquired data stream and encrypted data stream.

[0153] The entropy profiles may be computed using any suitable technique. For example, sliding and / or fixed window entropy profiles may be computed. Using multiple windows may enable capturing both localized fluctuations in randomness and global entropy trends across the file. The sliding window may have multiple adjustable widths (e.g., 512 bytes, 1 kilobytes, 4 kilobytes, etc.).

[0154] At operation 708, the method 700 may include computing a difference stream based on the entropy profiles for the acquired data stream and encrypted data stream. The difference stream may be a continuous signal that captures differences in entropy between the acquired data stream and encrypted data stream. The difference stream may be computed using the sliding and / or fixed window entropy profiles.

[0155] At operation 710, the method 700 may include detecting the use of anti-forensic masking. The detection may include applying median filtering and / or a constant run detection process to the difference stream to detect potential masking runs. The median filtering may suppress transient fluctuations and enhance longer plateaus that represent genuine structural anomalies rather than noise. Various attributes regarding the detected runs may be computed, such as length, amplitude, and / or pitch spacing.

[0156] In some embodiments, the detected runs may be correlated across the difference stream according to the computed attributes. The correlation may highlight any periodicity or structural regularity consistent with anti-forensic masking. The correlation may be used to produce a masking confidence score indicating the likelihood of anti-forensic masking.

[0157] At operation 712, the method 700 may include removing identified masked portions from the acquired data stream and encrypted data stream. Removing the masked portions may negate the influence of the applied anti-forensic making. The removal may produce unmaskedTAU-002PCdata streams with their entropy profiles left intact. The operation 712 may be performed concurrently for the acquired data stream and encrypted data stream.

[0158] At operation 714, the method 700 may include recomputing entropy profiles for the unmasked data streams. The operation 714 may be similar to the operation 706. The operation 714 may be performed concurrently for the acquired data stream and encrypted data stream.

[0159] At operation 716, the method 700 may include recomputing a difference stream based on the recomputed entropy profiles. The operation 716 may be similar to the operation 708.

[0160] At operation 718, the method 700 may include generating features for classifying the file operation. The features may be generated from the difference stream and / or metadata relating to the file operation. Exemplary features generated from the difference stream may include mean, variance, kurtosis, slope, and / or run length. The metadata may include contextual data relating to the device, the file, the process reading or writing the file, the session where the file operation took place, and / or the user. Exemplary features generated from the metadata may include process identifiers, executable names, digital signature statuses, device types, network locations, user session attributes, historical activity patterns, and / or any other suitable features. The features may include categorical values that may be treated as continuous features values through a lookup process.

[0161] At operation 720, the method 700 may include determining a classification using a machine learning model. The classification may indicate whether the file operation is considered malicious activity. The model may receive the generated features as input and output a classification. In some embodiments, the model may output a confidence value for the classification.

[0162] In some embodiments, the model may be implemented by a decision forest learning model configured to detect malware attacks. In some embodiments, the generated features may be evaluated with multiple decision trees to produce individual classifications. Decision nodes may compare the value of a feature against a reference threshold to determine which child node to evaluate next. An individual classification may be produced (optionally with a confidence probability) when a leaf node is reached.

[0163] In some embodiments, the decision forest learning model may aggregate the individual classifications to produce the final classification. For example, the decision forest learning model may use a majority vote rule where the individual classification receiving the greatest number of votes is selected as the final classification. In some examples, the decision forest learning modelTAU-002PCmay use a maximum confidence rule where the individual classification having the highest confidence score is selected as the final classification.

[0164] It is to be appreciated, however, that the model may be configured to implement any suitable data analysis algorithm, such as association rule learning algorithms, artificial neural network learning algorithms, deep learning algorithms, and / or bitmap algorithms. In some embodiments, the model may be implemented by at least one neural network, such as deep convolutional neural networks (CNN) using internal memories of its respective kernels (filters), recurrent neural networks (RNN), and / or long / short term memory neural networks (LSTM).

[0165] At operation 722, the method 700 may include determining a likelihood that the file operation is part of a malware attack (e.g., a ransomware attack) based on the classification result. For example, a Bayesian inference model may be used to aggregate file-level classifications to detect overarching malware attacks. File-level classifications may be treated as individual pieces of evidence toward a broader hypothesis that malware is actively executing within processes tied to a user session. The Bayesian inference model may evaluate the likelihood of the hypothesis being true. The Bayesian inference model may be defined by the following equation:Pr(F) = Pr(E\H)Pr H) + Pr(F|~H)Pr(~H), where Pr(E refers to the probability of observing a positive detection result, Pr(FT) refers to the prior probability of the hypothesis being true, Pr(E\FT) refers to the probability that the evidence is correctly identified as ransomware given that ransomware is present, and Pr( / i |~H) refers to the probability that the evidence is incorrectly identified as ransomware when no ransomware is present.

[0166] The probability of a correct hypothesis conditional on evidence may be defined by the following equation:

[0167] The chain rule may improve on the above equation by aggregating the results of multiple independent detection results, resulting in the following equation:where n is the number of files tested and Pr H\E0, El, ...Eri) is the posterior probability that ransomware is active given n positive detections.

[0168] The above equation may allow confidence in the hypothesis to be accumulated as more evidence is collected. This allows session-level threat detection where protective actions may beTAU-002PCtriggered based on aggregated evidence. The probability of an active ransomware attack may increase with each successive detection, enabling early and accurate identification of coordinated attacks.

[0169] At operation 724, the method 700 may include determining a protection action based on the likelihood indicating a likely malware attack. A malware attack may be considered likely if the likelihood exceeds a threshold. If the likelihood indicates that a malware attack is unlikely, then additional file operations may be monitored and analyzed to detect other potential malware attacks.

[0170] As described above, a machine learning model, such as a decision forest learning model, may be trained to classify file operations as malicious or benign activity. FIG. 8 illustrates a flowchart of a method 800 for training models for malware detection in accordance with one embodiment. While FIG. 8 shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, and / or modify any of the operations depicted in FIG. 8. Moreover, each of the operations depicted in FIG. 8 may be performed in any of the ways described herein. The operations depicted in FIG. 8 may be performed by any of the illustrative systems described herein, such as the system 100. For example, any of the operations may be performed at and / or directed by the endpoint device 102.

[0171] At operation 802, the method 800 may include collecting known ransomed data. The known ransomed data may be collected from verified incidents in the wild and / or from controlled laboratory (clean-room) conditions.

[0172] At operation 804, the method 800 may include collecting known non-ransomed data. The known non-ransomed data may include domain-specific non-ransomed files (e.g., DICOM images, EKG files, etc.) and / or general business documents (e.g., policy documents, training manuals, financial spreadsheets, etc.).

[0173] At operation 806, the method 800 may include encrypting at least a portion of the known non-ransomed data. The encrypted portion may be capable of emulating the cryptographic behavior of at least one ransomware strain. The encrypted portion may be labeled so that the portion is treated identically to real ransomware samples during model training and validation.

[0174] At operation 808, the method 800 may include generating features based on the known non-ransomed and ransomed data. In this manner, the features may be labeled as features corresponding to known ransomed data or non-ransomed data. The features may be generated using any of the operations described herein, such as the operation 718.TAU-002PC

[0175] At operation 810, the method 800 may include training a machine learning model using at least a portion of the labeled features. Training the machine learning model may generate an initial set of training parameters. For example, for a decision forest learning model, the training parameters may include parameters such as tree depths, number of trees, and / or minimum leaf sample counts.

[0176] At operation 812, the method 800 may include evaluating the machine learning model using the remaining portion of the labeled features. Exemplary evaluation criteria may include precision, recall, F-score, and / or area-under-curve (AUC). If the machine learning model is not deemed satisfactory, then the parameters may be further adjusted (e.g., by repeatedly iterating through the operations 810 and 812). Otherwise, the machine learning model may be accepted and used for future malware detection processes.

[0177] As described above, various protective actions may be initiated based on a determination that a malware attack is likely. The protective actions may aim to actively contain the malware attack, prevent further damage, and / or preserve forensic evidence.

[0178] FIG. 9 illustrates a flowchart of a method 900 for malware attack mitigation in accordance with one embodiment. While FIG. 9 shows illustrative operations according to one embodiment, other embodiments may omit, add to, reorder, and / or modify any of the operations depicted in FIG. 9. Moreover, each of the operations depicted in FIG. 9 may be performed in any of the ways described herein. The operations depicted in FIG. 9 may be performed by any of the illustrative systems described herein, such as the system 100. For example, any of the operations may be performed at and / or directed by the endpoint device 102.

[0179] At operation 902, the method 900 may include determining that a write operation is likely part of a malware attack. In some embodiments, the determination may be based on entropybased detection methods, such as the method 600. In some embodiments, the determination may be outputted by a machine learning model, such a trained decision forest learning model.

[0180] At operation 904, the method 900 may include logging the write operation. The log data may include metadata such as a process identifier, a file path, an entropy profile, a timestamp, a user session, and / or a device identifier. The log data may form a forensic evidence trail and may be transmitted to a centralized security information and event-management (SIEM) platform.

[0181] At operation 906, the method 900 may include saving the original content of the file targeted by the file operation. The content may be saved to a Write-Once, Read-Many (WORM) medium and / or any other immutable storage medium. This may guarantee availability of an uncompromised copy for restoration and evidentiary purposes.TAU-002PC

[0182] At operation 908, the method 900 may include determining whether the number of similar suspicious events exceeds a threshold. Similar suspicious events may include suspicious events occurring on the same endpoint device, originating from the same process, and / or relating to the same user account. Detection of multiple correlated anomalies may increase the probability that an active malware attack is underway.

[0183] If the number of similar suspicious events does not exceed the threshold, the method 900 may proceed to operation 910. At operation 910, the method may include monitoring additional file operations. The monitoring may result in detections of additional suspicious events.

[0184] If the number of similar suspicious events exceeds the threshold, the method 900 may proceed to operation 912. At operation 912, the method 900 may include triggering further protective actions. For example, the offending process may be suspended. A memory image of the process (e.g., registers, heap, stack, open handles, loaded modules, etc.) may be captured for forensic reconstruction. In some examples, the process may be terminated and prevented from restarting by modifying system execution policies, disabling scheduled or autorun tasks, and / or applying endpoint-protection or group-policy rules. In some embodiments, hash-based or signature-based deny-lists may be dynamically updated to block future execution of similar processes across a system or organization.

[0185] Although the number of similar suspicious events is described as the criterion used to trigger further protective actions, it is to be appreciated that any suitable criteria may be used. Exemplary criteria may include the confidence level of a classification decision (e.g., from a machine learning model), the confidence level of a likelihood that the file operation is part of a malware attack, the number of affected files, the amount of affected data, the number of affected devices or systems, use of anti-forensic masking, and / or the frequency of suspicious events. Any of the described criteria may be compared to a suitable threshold to trigger further protective actions.

[0186] FIG. 10A illustrates a system 1000 for entropy -based malware detection in accordance with one embodiment. The system 1000 may include any number of components for performing operations related to entropy -based malware detection.

[0187] In some embodiments, the system 1000 may be configured to monitor file operations related to various components. As shown, for example, the system 1000 may monitor local file operations at the endpoint device 102. While a single endpoint device is depicted, it is to be appreciated that the system 1000 may include any number of suitable endpoint devices.TAU-002PC

[0188] As described with respect to FIG. 1, the endpoint device 102 may execute the applications 108 via various application processes, which may read and / or write data managed by the file system 106 via the file filter driver 302.

[0189] As shown, the endpoint device 102 may execute a detection engine 1002. The detection engine 1002 may be compiled into a compact Software Development Kit (SDK). The SDK may use compiler intrinsics to access SIMD registers and vector instructions from high-level languages such as C, C++, and / or Rust. The detection engine 1002 may execute as a background service that continuously or periodically monitors file operations at the endpoint device 102. The detection engine 1002 may perform any of the methods described herein, such as the method 700. For example, the detection engine 1002 may determine that a file operation at the file system 106 is part of a ransomware attack. The detection engine 1002 may initiate a protective action, such as halting suspicious processes.

[0190] FIG. 10B illustrates an alternate embodiment of the system 1000. As shown, the detection engine 1002 may monitor file operations related to various remote devices, such as a remote client device 1004. While a single remote device is depicted, it is to be appreciated that the system 1000 may include any number of suitable devices. The detection engine 1002 may execute within any suitable computing environment or system separate from the remote client device 1004, such as a centralized inspection server and / or a network appliance (e.g., a router, a proxy server, etc.). As shown, for example, the detection engine may execute at a file server 1006.

[0191] In some embodiments, the remote client device 1004 may read and / or write data stored at the file server 1006 (and / or any other remote file server). The remote client device 1004 may execute remote applications 1008 via various application processes, which may send file access requests to the file server 1006. The file server 1006 may manage data using a remote file system 1010. A server filter driver 1012 may intercept the file access requests from the remote client device 1004. The remote client device 1004 may send the access requests using any suitable file protocol, such as server message block (SMB) and / or New Technology File System (NTFS). Offloading execution of the detection engine 1002 to a remote system in this manner may be beneficial in situations where endpoint resources are limited or constrained, such as situations involving virtual desktop infrastructures (VDI), clinical workstations, and / or mobile devices.

[0192] While not shown, in some embodiments, the system 1000 may use Internet Content Adaptation Protocol (ICAP) to intercept file transfers between the remote client device 1004 and the file server 1006, such as file uploads, email attachments, web downloads, and / or cloud-storage synchronizations. Various ICAP servers may intercept and analyze file content in transit, enabling malware detection across web gateways, email servers, and / or cloud interfaces. In someTAU-002PCembodiments, the ICAP servers may support REQMOD (request modification) and / or RESPMOD (response modification) modes.

[0193] FIG. 10C illustrates another alternate embodiment of the system 1000. In some embodiments, the system 1000 may be configured to inspect large volumes of files using SIMD processing and / or multithreading. As shown, for example, the detection engine 1002 may be executed as multiple detection threads 1014. Each thread 1014 may be executed at a separate CPU core. Files from multiple file servers 1006 may be routed through a file discovery module 1016, which may identify available files at the file servers 1006 and route the files to the threads 1014 (e.g., using a load balancer). The threads 1014 may concurrently inspect their respective files for potential malware attacks.

[0194] In some embodiments, the threads 1014 may generate audit data 1018, which may be aggregated and stored at a centralized repository. The audit data 1018 may relate to any of the operations described herein, such as allowing access to a protected file and / or classifying a file operation based on entropy profiles. The audit data 1018 may include timestamped data, such as a timestamped sequence of data entries representing the unprotecting and re-protecting of a file. The audit data 1018 may be stored at the file system 106 and / or a remote file system. For example, audit data from multiple endpoint devices may be aggregated at a central file server for further processing or analysis. Aggregated audit data may be converted into summarized descriptions and presented to suitable individuals such as administrators.

[0195] In some embodiments, the audit data 1018 may incorporate sub-file granularity to capture specific portions of a file accessed during a file operation. For example, the audit data may include byte-range indicators, file operation types (read, write, delete, etc.), and / or entropy deltas for the modified regions of files.

[0196] In some embodiments, the threads 1014 may scan files before the files are committed to backup media. Benign files may be archived at a suitable repository. Suspicious files may not be backed up at all and / or archived at a separate repository.

[0197] The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and that various steps may be added, omitted, or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.TAU-002PC

[0198] Embodiments of the present disclosure, for example, are described above with reference to block diagrams and / or operational illustrations of methods, systems, and computer program products according to embodiments of the present disclosure. The functions / acts noted in the blocks may occur out of the order as shown in any flowchart. For example, two blocks shown in succession may in fact be executed substantially concurrent or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Additionally, or alternatively, not all of the blocks shown in any flowchart need to be performed and / or executed. For example, if a given flowchart has five blocks containing functions / acts, it may be the case that only three of the five blocks are performed and / or executed. In this example, any of the three of the five blocks may be performed and / or executed.

[0199] A statement that a value exceeds (or is more than) a first threshold value is equivalent to a statement that the value meets or exceeds a second threshold value that is slightly greater than the first threshold value, e.g., the second threshold value being one value higher than the first threshold value in the resolution of a relevant system. A statement that a value is less than (or is within) a first threshold value is equivalent to a statement that the value is less than or equal to a second threshold value that is slightly lower than the first threshold value, e.g., the second threshold value being one value lower than the first threshold value in the resolution of the relevant system.

[0200] Specific details are given in the description to provide a thorough understanding of example configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

[0201] Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of various implementations or techniques of the present disclosure. Also, a number of steps may be undertaken before, during, or after the above elements are considered.TAU-002PC

[0202] Having been provided with the description and illustration of the present application, one skilled in the art may envision variations, modifications, and alternate embodiments falling within the general inventive concept discussed in this application that do not depart from the scope of the following claims.

Claims

TAU-002PCCLAIMSWhat is claimed is:

1. A computer-implemented method for file access, comprising:examining a plurality of files related to a user account;identifying, from the plurality of files, at least one file to be protected;restricting access to the at least one file to an escrow account;allowing access by an application to the at least one file; andrestoring the access restriction to the at least one file after the application has closed the file.

2. The computer-implemented method of claim 1, wherein allowing access to the at least one file comprises transferring ownership of the at least one file to an original owner.

3. The computer-implemented method of claim 1, wherein restricting access to the escrow account comprises adding a deny-everyone access control entry to an access control list.

4. The computer-implemented method of claim 3, wherein allowing access to the at least one file comprises removing the deny-everyone access control entry from the access control list.

5. The computer-implemented method of claim 1, wherein at least one file is identified using at least one factor associated with the plurality of files.

6. The computer-implemented method of claim 5, wherein at least one factor relates to at least one of a file attribute, a user identity, a user group association, a creation date, or a file content tag.

7. The computer-implemented method of claim 1, further comprising receiving, via the application, a request from a user to access unstructured data at the at least one file.

8. The computer-implemented method of claim 7, wherein the request comprises an attempt by the user to open the at least one file.

9. The computer-implemented method of claim 1, wherein the escrow account is secured from unauthorized use.TAU-002PC10. The computer-implemented method of claim 1, wherein allowing access to the at least one file comprises determining an access level based on an authorization policy.

11. The computer-implemented method of claim 10, wherein the authorization policy uses historical file usage patterns to determine the access level.

12. The computer-implemented method of claim 1, further comprising performing an entropy calculation while the at least one file is being accessed.

13. The computer-implemented method of claim 12, further comprising restoring the access restriction to the at least one file based on the entropy calculation.

14. A system for file access comprising:memory storing instructions; anda processor executing the instructions to perform the steps of:examining a plurality of files related to a user account;identifying, from the plurality of files, at least one file to be protected; restricting access to the at least one file to an escrow account;allowing access by an application to the at least one file; andrestoring the access restriction to the at least one file after the application has closed the file.

15. The system of claim 14, wherein allowing access to the at least one file comprises transferring ownership of the at least one file to an original owner.

16. The system of claim 14, wherein restricting access to the escrow account comprises adding a deny-everyone access control entry to an access control list.

17. The system of claim 14, wherein at least one file is identified using at least one factor associated with the plurality of files.

18. The system of claim 14, wherein the processor further executes the instructions to perform the step of receiving, via the application, a request from a user to access unstructured data at the at least one file.TAU-002PC19. The system of claim 14, wherein the processor further executes the instructions to perform the steps of:receiving an authorization policy from a policy management tool; anddetermining an access level based on the authorization policy.

20. A computer program product for file access embodied in a non-transitory computer readable storage medium and comprising computer instructions for:examining a plurality of files related to a user account;identifying, from the plurality of files, at least one file to be protected;restricting access to the at least one file to an escrow account;allowing access by an application to the at least one file; andrestoring the access restriction to the at least one file after the application has closed the file.

21. A computer-implemented method for securing files, comprising:acquiring data related to a file operation;generating an encrypted version of the acquired data;determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; anddetermining a protective action based on the classification.

22. The computer-implemented method of claim 21, wherein determining the entropy profiles comprises determining sliding and fixed window entropy characteristics.

23. The computer-implemented method of claim 21, further comprising comparing the entropy profiles, wherein the classification is based on the comparison.

24. The computer-implemented method of claim 23, wherein comparing the entropy profiles comprises determining sliding and fixed window differences between the entropy profiles.

25. The computer-implemented method of claim 21, further comprising:detecting use of anti-forensic masking using the entropy profiles; andremoving at least one masking portion from the acquired data and the encrypted version before classifying the file operation.TAU-002PC26. The computer-implemented method of claim 25, further comprising:recomputing entropy profiles for the acquired data and the encrypted version after the at least one masking portion has been removed; andcomparing the recomputed entropy profiles.

27. The computer-implemented method of claim 21, further comprising:determining at least one entropy feature based on the entropy profiles;determining at least one usage feature based on metadata associated with the file operation,wherein the classification is based on the at least one entropy feature and the at least one usage feature.

28. The computer-implemented method of claim 21, wherein the classifying the file operation is performed using a machine learning model trained on known malicious data.

29. The computer-implemented method of claim 28, wherein the machine learning model comprises a decision forest learning model.

30. The computer-implemented method of claim 21, further comprising:aggregating the classification with at least one additional classification; and determining a session-level likelihood of malicious activity.

31. The computer-implemented method of claim 21, wherein the protective action comprises at least one of monitoring additional file operations or suspending an offending process.

32. A system for securing files comprising:memory storing instructions; anda processor executing the instructions to perform the steps of:acquiring data related to a file operation;generating an encrypted version of the acquired data;determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; anddetermining a protective action based on the classification.TAU-002PC33. The system of claim 32, wherein the processor is configured to perform the steps using SIMD-accelerated processing.

34. The system of claim 32, wherein determining the entropy profiles comprises determining sliding and fixed window entropy characteristics.

35. The system of claim 32, wherein the processor further executes the instructions to perform the step of comparing the entropy profiles, wherein the classification is based on the comparison.

36. The system of claim 32, wherein the processor further executes the instructions to perform the steps of:detecting use of anti-forensic masking using the entropy profiles; andremoving at least one masking portion from the acquired data and the encrypted version before classifying the file operation.

37. The system of claim 32, wherein the processor further executes the instructions to perform the steps of:determining at least one entropy feature based on the entropy profiles;determining at least one usage feature based on metadata associated with the file operation,wherein the classification is based on the at least one entropy feature and the at least one usage feature.

38. The system of claim 32, wherein the classifying the file operation is performed using a machine learning model trained on known malicious data.

39. The system of claim 32, wherein the processor further executes the instructions to perform the steps of:aggregating the classification with at least one additional classification; and determining a session-level likelihood of malicious activity.

40. A computer program product for securing files embodied in a non-transitory computer readable storage medium and comprising computer instructions for:acquiring data related to a file operation;TAU-002PCgenerating an encrypted version of the acquired data;determining entropy profiles for the acquired data and the encrypted version; classifying the file operation based on the entropy profiles; and determining a protective action based on the classification.

Images