Secure storage device

[0019] In the following description, it should be understood that all the stated connections between structures may be direct operative connections or indirect operative connections through intermediate structures. The component set contains one or more components. Any description of an element should be understood as referring to at least one element. The plurality of elements includes at least two elements. Unless otherwise required, it is not necessary to perform any described method steps in the specific illustrated order. Deriving the first element (eg, data) from the second element encompasses that the first element is equal to the second element, and the first element is generated by processing the second element and optionally other data. Making a determination or decision based on parameters encompasses making a determination or decision based on parameters and optionally other data. Unless otherwise specified, the indicator of a certain quantity/data may be the quantity/data itself, or an indicator different from the quantity/data itself. A computer program is a series of processor instructions that perform tasks. The computer program described in some embodiments of the present invention may be an independent software entity or a sub-entity (eg, subroutine, library) of other computer programs. Computer-readable media encompasses non-transitory media, such as magnetic, optical, and semiconductor storage media (eg, hard drives, optical disks, flash memory, DRAM), and communication links such as conductive cables and fiber optic links. According to some embodiments, the present invention particularly provides a computer system that includes hardware (eg, one or more processors) programmed to perform the method described herein, and computer-readable media code to perform the method described herein instruction.

[0020] The following description illustrates the embodiments of the present invention by way of examples and not necessarily by limitation.

[0021] figure 1 An exemplary hardware configuration of a host system 10 protected from computer security threats according to some embodiments of the present invention is shown. Exemplary host system 10 includes computers (for example, personal computers, company servers, etc.), mobile computing devices (for example, notebook computers, tablet PCs), telecommunication devices (for example, smart phones), digital appliances (TV, game consoles, etc.) ), a wearable computing device (for example, a smart watch), or any other electronic device that has a processor and a memory and requires computer security protection. For simplicity, the illustrated host system is a computer system; the hardware configuration of other host systems such as mobile phones, smart watches, etc. may be slightly different from the illustrated configuration.

[0022] The host system 10 includes a set of physical devices including a hardware processor 16 and a memory unit 18. In some embodiments, the processor 16 includes a physical device (such as a microprocessor, a multi-core integrated circuit formed on a semiconductor substrate, etc.) that is configured to perform calculations and/or logic with a set of signals and/or data operating. In some embodiments, such operations are delivered to the processor 16 in the form of a sequence of processor instructions (eg, machine code or other types of encoding). The memory unit 18 may include a volatile computer-readable medium (e.g., DRAM, SRAM) that stores instructions and/or data accessed or generated by the processor 16.

[0023] The input device 20 may include a device that enables a user to import data and/or instructions into the host system 10, and a corresponding hardware interface and/or adapter that makes such introduction possible. Exemplary input devices include buttons, keyboard, mouse, joystick, touch screen, microphone, camera, game controller, gesture detection system, motion detection sensor, etc. The output device 22 may include a display device such as a monitor and a speaker, and a hardware interface/adapter such as a graphics card, which allows the host system 10 to transmit data to the user. In some embodiments, such as in the case of a touch screen device, the input device 20 and the output device 22 may share a common hardware part. The network adapter 26 enables the host system 10 to be connected to a communication network, such as a local area network (LAN), and/or to other devices/computer systems.

[0024] The secure storage device 24 includes a computer-readable medium that implements non-volatile storage, reading, and writing of software instructions and/or other data. Exemplary storage devices 24 include magnetic disks, optical disks, and flash memory devices, as well as removable media such as CD and/or DVD disks and drives. In some embodiments, as shown in detail below, the secure storage device 24 has other hardware and software components specifically configured to enhance the security of the stored data.

[0025] In some embodiments, the controller hub 28 contains multiple system, peripheral, and/or chipset buses, and/or all other circuits that enable communication between the processor 16 and the devices 18, 20, 22, 24, and 26. Exemplary components of the controller hub 28 include a memory controller, an input/output (I/O) controller, and an interrupt controller. Depending on the hardware manufacturer and device, some or all of these controllers may be incorporated into a single integrated circuit, and/or may be integrated with the processor 16. In some embodiments, some other devices such as a graphics adapter forming part of the output device 22 may also be integrated with the processor 16.

[0026] figure 2 An exemplary hardware configuration of the secure storage device 24 according to some embodiments of the present invention is shown. Some embodiments mitigate the risk caused by malware by pairing a conventional storage device, namely the main storage device 30 (for example, a magnetic or solid-state drive) with a dedicated security processor 116 separate from the main processor of the host 10. This auxiliary processor can be integrated with storage units and/or additional hardware on a common printed circuit board assuming the external dimensions of a conventional hard disk drive. In another exemplary embodiment, the secure storage device 24 may be packaged as an external mass storage device (e.g., flash drive, external hard drive), which may be via, for example, a universal serial bus (USB) or The conventional interface of the interface/connector is connected to the host system.

[0027] The main storage 30 may serve as the actual storage device for the host system 10. Thus, the main storage 30 may store codes and/or data belonging to the operating system and/or other software applications executed on the host processor 16, as well as user data, such as documents, images, sound files, and the like.

[0028] The security processor 116 includes a physical electronic circuit (eg, an integrated circuit formed on a semiconductor substrate) that is configured to perform mathematical and/or logical operations with a set of signals and/or data. In some embodiments, the processor 116 is a general purpose microprocessor of the type used as a central processing unit (CPU) in a personal computer and/or mobile phone. Examples of such processors come from for example with The manufacturer’s conventional processor. In an alternative embodiment, the processor 116 includes customized electronic circuitry, such as an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). Other embodiments of the processor 116 include a graphics processing unit (GPU), or a combination of the above. The use of such specialized processors can be advantageous because its architecture can be particularly elaborately crafted and optimized for parallel computing and certain specialized tasks. As described further below, a parallel specialized architecture can benefit applications such as encryption/decryption.

[0029] Additional hardware components of the secure storage device 24 may include a secure memory 118, which provides a volatile computer-readable medium (eg, DRAM, SRAM) for storing instructions and/or data accessed or generated by the processor 116. The device 24 may additionally include a security controller 34, which generally represents a bus and/or all other circuits that interconnect the hardware components of the device 24. The secure storage device 24 may be further connected to the controller hub 28 of the host system 10 by means of a storage interface 36 (for example, a serial AT attachment-SATA, or a PCI high-speed interface and/or connector).

[0030] In some embodiments, the secure storage device 24 may additionally include a secondary storage device 32, which includes a non-volatile computer-readable medium. In some embodiments, the primary storage device 30 and the secondary storage device 32 are implemented as different logical partitions of a single physical mass storage device (magnetic, optical, or solid-state drive). The secondary storage device 32 may be invisible to the software executed on the processor 16 and can only access the software executed on the auxiliary security processor 116. This type of isolation can be achieved using hardware logic (circuits of the security controller 34) configured to expose a limited range of storage addresses to the host processor 16.

[0031] The secondary storage device 32 can be used to store security codes and data, such as signatures indicating malicious programs. The secondary storage device 32 may additionally store codes to be executed by the processor 116 at startup (startup). As shown in more detail below, some embodiments of the secure storage device 24 use the secondary storage device 32 to store the encoding of the file system semantic mapping. Other embodiments of the storage device 32 may store a partial copy (e.g., backup) of the data stored in the main storage device 30.

[0032] In some embodiments, the primary storage device 30 and the secondary storage device 32 are addressable via a set of location indicators (addresses). Depending on the implementation, the storage devices 30, 32 may be divided into individual addressable units, such as sectors, blocks, and/or clusters.

[0033] Figure 3-A Exemplary software components executing on the host processor 16 according to some embodiments of the invention are shown. An operating system (OS) 40 includes a set of computer programs that provide an interface between the hardware of the host system 10 and other software such as application programs 41a-b. OS 40 may include any widely available operating system, such as or Wait. The application programs 41a-b generally represent any computer program, including word processors, spreadsheet applications, imaging applications, games, browsers, electronic communication applications, and so on.

[0034] Some embodiments of the present invention additionally include a computer security module (CSM) 44, which includes software to protect the host system 10 from malicious programs. The CSM 44 may contain, for example, a computer program for detecting malware, and/or a computer program for disabling such software. Such components can use any computer security method known in the art. In some embodiments, the CSM 44 additionally includes a storage intermediary component 42 that operates as an interface between the OS 40 and the secure storage device 24. The exemplary storage intermediary 42 is operable as a storage drive that enables reading data from and writing data to the main storage device 30. As shown in more detail below, the storage intermediary 42 may be further configured to exchange messages and/or data with software executing on the security processor 116.

[0035] Figure 3-B Shown are alternative embodiments that operate in a hardware virtualization environment, such as a cloud computing application. A virtual machine (VM) is a term used in the field to describe the simulation of an actual physical machine/computer system. The VM can run an operating system and other applications. A hypervisor includes software that is configured to generate or enable multiple virtualized devices such as virtual processors and virtual MMUs and present such virtualized devices to software instead of real physical devices of the host system 10. This type of operation is often referred to as exposing a virtual machine. The hypervisor can enable multiple virtual machines to share the hardware resources of the host system 10, and can additionally manage such multiplexing, so that each VM operates independently and is unaware of other VMs simultaneously executing on the corresponding host. Examples of commonly used hypervisors include VMware vSphere from VMware TM And open-source Xen hypervisor and so on. In the description of the present invention, the software is said to be executed in the virtual machine when executed on the virtual processor of the corresponding virtual machine.

[0036] in Figure 3-B In the exemplary configuration illustrated in, the hypervisor 46 exposes the guest VM 48a. The operating system and a set of user applications are executed in the guest virtual machine 48a, while the CSM 44 is executed in a dedicated security virtual machine 48b separate from the guest VM 48a. Right Figure 3-B In an alternative embodiment, the CSM 44 and/or the storage intermediary 42 may include a set of libraries loaded/called by the hypervisor 46. Thus, the CSM 44 and/or the storage intermediary 42 can be under the guest VM 48a, at the processor authority level of the hypervisor 46 (e.g., Ring 1 or VMXroot) execution on the platform. E.g Figure 3-B The configuration described in can be compared to Figure 3-A The configuration described in is preferred. The virtual environments of the guest VM 48a and the security VM 48b can be relatively well isolated from each other, so that the malware executed in the guest VM 48a cannot infect or otherwise interfere with the software executed in the security VM 48b.

[0037] Figure 4 An exemplary set of software components executing within the secure storage device 24 (ie, on the processor 116) according to some embodiments of the invention is shown. The illustrated software includes a storage security agent 50 and an encryption engine 52. The proxy 50 may be configured to maintain the file system semantic mapping of the main storage device 30 and apply a set of heuristics (eg, decision rules) to determine whether a request for access to the main storage device 30 by software executing on the host processor 16 indicates Computer security threats. The engine 52 may be configured to perform encryption and/or decryption operations on data packets to and from the main storage device 30. The operation of the components 50 and 52 will be detailed below.

[0038] In some embodiments, the CSM 44 cooperates with software executing within the secure storage device 24 (e.g., the security agent 50), for example, by exchanging notifications/signals via a communication channel managed by the storage intermediary 42. An exemplary notification from the processor 16 to the secure storage device 24 (referred to herein as a downlink notification) contains an indicator of the operation to be performed by the processor 116, and other data such as file name, encryption key, A set of flags, etc. As described in further detail below, CSM 44 may also send downlink notifications in response to certain security related events.

[0039] An exemplary communication channel may use conventional devices that transfer data between the processor and the mass storage unit. For example, the CSM 44 and the security agent 50 may exchange messages according to a storage transfer protocol (such as Serial ATA or Small Computer System Interface (SCSI) protocol). The storage transport protocol establishes the format of communication via the storage interface, the size and content of the frame/packet, the count, size, order and/or format of the header and/or payload, the significance of each control bit and data field, and the order Encoding etc.

[0040] In some embodiments, the downlink notification is disguised as a fake access request. Fake access request herein refers to a storage device access request that is properly formatted according to the communication protocol (for example, a well-formed SATA command), but should not be executed by itself, but is instead interpreted as a notified storage device access request. The term "false" is used to distinguish this type of request from a "real" or "true" storage device access request that represents a storage device access operation intended to be performed by itself.

[0041] In some embodiments, a fake request is an invalid storage device access request from the perspective of an abnormality/failure caused by executing such a fake request. In such cases, the fault handler can intercept the corresponding fault and determine that the request that caused the corresponding fault is a downlink notification. In other embodiments, the fake request is not the fault itself, but may include a specific, abnormal, or contradictory parameter value (flag) combination. In still other embodiments, fake requests may include valid regular requests; such fake requests may thus be identified, for example, based on the content of the payload or the content of other data fields defined by the storage communication protocol.

[0042] An example of a fake access request includes a request to access an out-of-range address (ie, an address outside the normal addressable range of the main storage device 30). Examples include'read block B'or'write payload P at address A', where the address of block B and address A are outside the normal addressable range of the main storage device 30. Each such address (a specific value of A and/or B) may correspond to a specific instruction or event transmitted to the software executed inside the secure storage device 24. In another example, the downlink notification may be disguised as a request to access the storage device at an address that is not normally accessed during normal operation, although within the normal addressable range. For example, for writing to the current master boot record (MBR) or key OS components (for example, The request for the storage location of NTOSKRNL.EXE) can be intercepted by the secure storage device 24 and interpreted as a downlink notification from the CSM 44.

[0043] In yet another example, a fake access request may be identified based on specific payload content (e.g., a specific bit pattern or signature). In such embodiments, the software component executing on the security processor 116 can parse the payload content to detect fake access requests. Various payloads P may correspond to various notifications/commands issued to the secure storage device 24.

[0044] In yet another example, the fake access request itself may be based on the content of another data field defined by the storage communication protocol, for example, based on the content of the'command' and/or'auxiliary' field specified in the serial ATA protocol. Recognition. In one such example, the command to update the signature of the malicious program can be encoded into the'command' field of the fake access request issued by the CSM 44. The actual signature can be transmitted as the payload of another fake access request.

[0045] Some other examples of downlink notifications include instructions to scan data stored at a specific storage location: the corresponding location can be encoded into the payload of the fake access request. In yet another example, a fake write request including a different address A may indicate different anti-malware program methods or parameters. Each address or range in address A may indicate a different heuristic or a different group of signatures indicating malicious programs.

[0046] In turn, the storage intermediary 42 may receive a notification/signal from the device 24 via a response and/or another form of response to the downlink notification, such as via a hardware interrupt (IRQ) (referred to herein as an uplink notification) ), or receive an asynchronous SATA notification sent by the device 24 and handled by the storage intermediary 42 and/or by another event handler of the OS 40. Exemplary uplink notifications include security alerts, etc., such as indicators of possible ransomware attacks, and indicators of attempts to update the firmware of the storage device 24.

[0047] Yet another exemplary uplink notification includes a request for an encryption key. In one such example, the security agent 50 may detect attempts to write encrypted data packets. Such attempts can instruct automatic encryption of disk data (for example, from of Technology). In response, some embodiments may request the encryption key from CSM 44. More details of this method are given further below.

[0048] Some embodiments use a downlink-uplink notification sequence to implement a version of repeated malware detection. In one such example, the downlink notification instructs the storage security agent 50 to scan specific files for malicious programs. The agent 50 may then transmit the result of the scan to the CSM 44, which may select another file or folder based on the result of the first scan and transmit the new scan target to the security agent 50 via a new downlink notification, etc. . This type of iterative scheme can enable a rather complex malicious program detection program that must install complex software on the secure storage device 24.

[0049] Figure 5 An exemplary sequence of steps performed by the CSM 44 according to some embodiments of the invention is shown. The CSM 44 can aggregate security-related data from multiple sources within the host system 10, and can receive notifications about the occurrence of certain events during software execution. An exemplary source is the system call function of the OS 40, which is modified by hooking to a signal sent to the CSM 44 whenever a corresponding system call occurs. Other exemplary sources of security information and notifications include OS minifilters. In some embodiments, the CSM 44 may further receive uplink notifications from around the secure storage device 24. In response to detecting the occurrence of the event, in step 206, the CSM 44 may apply a set of heuristics to determine whether the host system 10 is currently being attacked. When the analysis shows that a malicious program is suspected, the CSM 44 can take appropriate anti-malware program measures (steps 212-214), such as blocking or otherwise preventing the execution of the malicious processing program, and alerting the user or administrator of the host system 10 to it. Some detected events guarantee a downlink notification to the secure storage device 24. In one such example, CSM 44 may direct security agent 50 to perform an investigation of storage device access attempts. Downlink notification at Figure 5 Steps 208-210 are described in.

[0050] In some embodiments, the storage security agent 50 regenerates the semantics of the file system used by the OS 40 from the metadata stored on the storage device 30 in a manner independent of the file system of the OS 40. In other words, the agent 50 maintains a file system semantic knowledge base that is equivalent to the replacement or shadow of the file system of the OS 40. In conventional computer systems, at the hardware level, data is stored as blocks without semantic information. For example, it is not clear which piece of data belongs to which file/folder. A further complication is fragmentation, in which the data of a single file is not stored continuously, but scattered in various locations throughout the storage medium. The OS usually takes the bookkeeping task of associating assets with storage locations and transforming hardware-level information into meaningful data. The OS manages such tasks by maintaining a specialized data structure called a file system, which is encoded as metadata and stored in a specific section of a storage medium. Exemplary file systems include FAT, FAT32, NTFS, and so on.

[0051] In some embodiments, the file system semantic mapping includes encoding of the mapping between the section of the main storage device 30 and the item of the file system of the OS 40. Exemplary file system items include directories and files. The exemplary semantic mapping item associates an address range [A1 A2] with the file F (where F can be expressed as a path, such as C:\user\docs\Letter.txt or /home/user/docs/Letter.txt). This type of association actually indicates that the data stored in the corresponding address range forms part of the file F. Another exemplary file system semantic mapping item specifies an address range [A3 A4] to store file system metadata. Yet another exemplary file system semantic mapping item associates individually addressable units (eg, storage blocks or partitions, as opposed to address ranges) with file system items. The semantic mapping data can be encoded using any method known in the art, such as encoding as a bitmap, a linked list, etc.

[0052] Image 6 An exemplary sequence of steps performed by the storage security agent 50 according to some embodiments of the present invention is shown. The agent 50 receives a storage device access request from the OS 40 via the storage interface 36. A typical request includes operation (read, write) indicator, address indicator, and payload. An exemplary storage device access request has the semantics of “read N-byte block at address A” and “write payload P at address A”. The access request may additionally include a set of parameter values ​​(for example, flags, attributes) of the corresponding request. The actual format and encoding of storage device access requests can be changed among hardware and software implementations.

[0053] When an access request arrives at the device 24, the proxy 50 can determine whether the corresponding request indicates a real storage device access or a fake storage device access (that is, a notification from the CSM 44) according to the requested parameters. In an exemplary embodiment, a request to access an out-of-range address may indicate such notification. When the corresponding access request includes a downlink notification, step 236 may select and execute a specific action according to the parameters of the corresponding request (see some examples below).

[0054] In the sequence of steps 228-230, the security agent 50 may further decode the semantics of the corresponding storage device access request according to the semantic mapping. For example, the agent 50 can determine whether the metadata or the actual file is being written, whether a new file is being generated, which specific file is currently being written or read, and so on. Another step 232 can apply a set of access heuristics to determine whether the requested access indicates a computer security threat. When not, the agent 50 may allow the corresponding access to continue. When the heuristically indicates that the requested access request guarantees notification to the computer security module 44, the agent 50 may perform an uplink notification equivalent to a security alert.

[0055] Figure 7 An exemplary sequence of steps performed by the storage security agent 50 to maintain the file system semantic mapping is shown. The mapping creation can be initiated at startup, for example. In some embodiments, the agent 50 may determine the location on the main storage device 30 where the file system metadata used by the OS 40 is stored. Several methods for achieving this are known in the field of computer forensics. Some embodiments use software components executing on the host (eg, CSM 44) to determine the location of file system data. The CSM 44 can then use downlink notifications to communicate the corresponding location to the security agent 50.

[0056] In the sequence of steps 254-256, the agent 50 parses the file system metadata stored in the main storage device 30 and assembles a semantic map according to the corresponding metadata. Some embodiments store the determined semantic mapping data (ie, the shadow file system) in the security memory 118 and/or the secondary storage device 32. Then, during the execution of the software on the processor 16, the agent 50 may listen to storage device access requests and determine whether such requests indicate changes in metadata (for example, file/directory creation or deletion). When yes, the agent 50 can update the semantic mapping accordingly ( Figure 7 Steps 260-262-264 in ).

[0057] The notification and heuristic system described can be used in a variety of applications, some examples of which are given below.

[0058] Command filtering to protect hardware

[0059] Elaborate malware can use some features of the ATA command set (for example, the DOWNFOAD MICROCODE command) to secretly update the firmware of the storage device, thereby introducing hardware-level malicious programs into the device itself. One such exemplary malicious program is a backdoor program, which can be used by software executing on the host to change the behavior of the corresponding storage device and/or control the corresponding storage device.

[0060] To prevent such advanced attacks, in some embodiments, the storage security agent 50 is configured to filter storage device access requests received via the storage interface 36. Filtering rules can be based, such as allowing only the most common access requests (for example, commands for reading, writing, identifying devices, etc.) to be executed, and blocking all other commands/requests. Other embodiments may implement more complex filtering heuristics, such as filtering rules suitable for the current context. In another example, the security agent 50 may adjust the execution of certain ATA commands/access requests based on explicit confirmation from the administrator of the host system 10.

[0061] In some embodiments, certain commands/requests are not blocked, but instead are simulated by software executing on the security processor 116 (eg, by the security agent 50) and further analyzed. In response to receiving such a command, the security software may return a human response to induce the software executing on the host processor 16 to believe that the corresponding command/access request was successfully performed. The security agent 50 may additionally record such commands to assist the research of anti-malware programs.

[0062] Event interception and interpretation at the hardware level

[0063] Maintaining a semantic mapping (shadow file system) enables the storage security agent 50 to detect security-related events that occur during the execution of the software on the processor 16 in response to receiving an access request. For example, in response to a write request, the agent 50 may determine whether the metadata or actual content of the file is being written, whether the corresponding write is for an empty storage section or overwrite existing information, and the corresponding write is true write It is also the downlink notification from the processor 16 and so on.

[0064] File system events such as file creation, file deletion, and file rewriting are performed based on event-specific sequence of operations. An exemplary pattern may include metadata reading, followed by metadata writing, followed by payload writing. The agent 50 may use a set of heuristics encoding such patterns to identify the type of each file system event. In addition, the agent 50 can identify the target of each read/write operation, such as which file the device writes to and which file is being read.

[0065] Contrary to conventional computer security systems/methods, this type of event interception occurs almost without knowing the software executing on the processor 16. Therefore, malware may not prevent or otherwise interfere with event detection. For example, the security software of the agent 50 may then use uplink notifications to notify the CSM 44 of the occurrence of certain events that are considered security-related.

[0066] Malware scanning on access

[0067] The security agent 50 may detect attempts to open files and/or attempts to execute executable files. Other operations that can be detected in this way include file attachment and storage allocation for subsequent writes. Each such event can be used as a trigger to start scanning of the corresponding file, or to trigger the scanning of resources (main executable library, etc.) belonging to the processing program that sorts the access to the corresponding storage device. The scanning can be performed when the processing program that issues the storage device access request is suspended, or offline when the corresponding processing program is allowed to continue.

[0068] The scanning may be performed according to any method known in the field of computer security, for example, by matching the content of the corresponding file with a library indicating a signature or code pattern of a malicious program. For this purpose, a library indicating the signature of the malicious program can be stored on the secondary storage device 32. The library can be kept up to date via periodic or on-demand updates. Some embodiments update the signature library and/or other software executing on the secure storage device 24 via a set of downlink notifications (eg, fake storage device access requests).

[0069] In a variant of scanning on access, the agent 50 may use a set of heuristics to detect the boot sequence of the host system 10 and/or OS 40. In other words, by analyzing the storage device access request sequence, the agent 50 can determine that the host system 10 is currently in the process of startup (ie, hardware and/or software initialization). An exemplary startup sequence usually begins with a read request sequence from a location where a data structure called a master boot record (MBR) or GUID partition table (GPT) is stored.

[0070] Identification device

[0071]

[0072] The following describes an exemplary storage device access request sequence indicating that the OS 40 has started loading:

[0073] Identification device

[0074]

[0075] Another typical feature of the activation sequence of an access request includes a very long read request sequence interspersed with short 2-5 write request sequences (for example, 2-3000 continuous read requests). Such modes can be OS-specific. The pattern analysis can combine the count of continuous read/write requests with the analysis of address information and/or other parameter values ​​to infer the various stages of the startup process.

[0076] Some embodiments may combine access request pattern matching with semantic mapping information to detect the initialization of the OS 40. In one such example, the security agent 50 may perform an iterative process to capture information about the type and/or location of software executing on the host processor 16 directly from the storage device access event. By detecting access to the master boot record, the agent 50 can determine the partition information. Next, make a series of read requests target the volume header. The agent 50 can determine and verify information about the corresponding volume from such requests. Next, the agent 50 may follow the read and/or write sequence accompanying the startup to automatically identify a set of important OS files (for example, resources loaded by the OS 40 immediately after initialization, for example The storage location of NTOSKRNF.EXE). The corresponding boot sequence may also show the type of operating system (for example, the version of OS 40, etc.).

[0077] Some embodiments may then scan each file opened during a period of time (e.g., a few seconds) following the detected startup/initialization phase. The scanning may include integrity verification, that is, to determine whether the content of the file has been corrupted, for example, by malware. Integrity verification may include comparing the hash of the current content of the corresponding file with a reference hash stored on the secondary storage device 32.

[0078] In yet another exemplary application related to the boot sequence, some embodiments may use the secure storage device 24 as a proxy executing outside the OS 40 and configured to test the integrity and/or trustworthiness of the OS 40. For example, the agent 50 can automatically detect a request to restart the host system 10. Then, in response to detecting that the restart is actually in progress (e.g., slave device detection and initialization operations, or in response to a downlink notification made by the CSM 44), the agent 50 may suspend the normal startup sequence and expose the configuration to scan the OS The data structure of 40 and/or the alternative OS or security agent of the boot area of ​​the main storage device 30. When the scan is completed and the system is deemed safe, the agent 50 can resume the activation of the OS 40.

[0079] Protect stored assets

[0080] The boot area of ​​the main storage device 30 generally stores resources that are read before the OS is loaded. By maintaining the semantic mapping, the agent 50 can determine whether the write request targets the corresponding start area, and in response, can block the corresponding write and/or notify the CSM 44. Similar strategies can be used to protect valuable assets of the OS 40 or other applications, such as certain files, libraries, etc.

[0081] Operate with encrypted data

[0082] Some versions of OS 40 have the option of keeping data in encrypted form on the main storage device 30. One such example is of feature. When the stored data is encrypted, entities executing outside the OS 40 (including the storage security agent 50) may not access the corresponding data, or allow the construction of system metadata of the file system semantic mapping.

[0083] However, the agent 50 may cooperate with the CSM 44 to obtain the encryption key, or information that helps to derive the corresponding key. This type of information may include, for example, passwords, secrets, temporary numbers, etc., and is therefore called encryption key material. The CSM 44 may expose a user interface requesting a user password or another secret used when the corresponding key is involved, and transmit the password/secret to the agent 50. In another embodiment, the CSM 44 can directly communicate with the encryption agent of the OS (for example, Module) interface to obtain key material. In response to obtaining the key material, the CSM 44 may transmit the key material itself, or the storage location of the key material, to the agent 50 via a downlink notification (eg, a fake storage device access request).

[0084] Once in possession of the encryption key, the agent 50 can use the encryption engine 52 to decrypt the stored data in order to construct and/or maintain the file system semantic mapping. In some embodiments, the agent 50 may further use the encryption key to perform online scanning/analysis of data services to and from the main storage device 30, and has little knowledge of the OS 40 or other software executed on the host processor 16. In one example, in response to intercepting the write request, the security agent 50 may decrypt and analyze the corresponding payload before writing the original (encrypted) payload to the predetermined address. In some embodiments, in response to the decryption Corresponding to the payload, the agent 50 can save the unencrypted version of the payload to the secondary storage device 32.

[0085] Universal encryption detection

[0086] Some embodiments of the storage security agent 50 can automatically determine whether the data stored in a section (eg, block, partition, etc.) of the storage device 30 is encrypted. This type of determination can use information complexity measures, such as entropy or other methods known in the art. To avoid false positives, some embodiments may use metadata available for the corresponding file to determine whether the corresponding file may have high entropy without necessarily being encrypted. Such examples include data compressed according to formats such as MP3, JPG, MPG, ZIP, etc. To determine whether the corresponding file belongs to one of these categories, some embodiments may locate the header part of the corresponding file according to metadata, and search for file type information in the corresponding header.

[0087] In some embodiments, each entry of the file system semantic mapping can be expanded with a set of flags, indicating, for example, whether the corresponding file system item (file, folder, etc.) is encrypted, whether the corresponding file system item is compressed, etc. The agent 50 can maintain the flag and the remainder of the semantic mapping data.

[0088] Detection of advanced ransomware

[0089] The system and method described herein allow automatic detection of attempts to encrypt stored data. The detection is independent of the software execution on the processor 16, and cannot actually be detected by the software. Useful applications of this type of automatic encryption detection include the detection of ransomware and other types of malware whose actions include unauthorized or undesired encryption of user data.

[0090] An exemplary detection heuristic includes detecting attempts to overwrite unencrypted content with encrypted content. Another set of detection heuristics uses statistical data to compare the current flow of storage device access requests with the "normal" mode corresponding to a particular user and/or running application. To implement detection, some embodiments determine a set of user profiles and/or application profiles indicating, for example, which applications/processing programs may be launched by a specific user, which storage locations the corresponding user usually accesses, and each What are the typical patterns of storage requests associated with processing programs/applications, etc. When the current storage device access request sequence leaves the "normal distribution" mode, for example, when the agent 50 detects an abnormal spike in the file creation activity, where the content of the corresponding file is encrypted, the agent 50 can determine that the ransomware attack is underway processing.

[0091] When the agent 50 detects suspicious encryption activity, the agent 50 may suspend the corresponding activity (for example, block a group of suspicious writes), and/or use an uplink notification mechanism to signal the CSM 44. In turn, the CSM 44 may use the notification as an alert of a possible attack, or may apply additional heuristics, such as the event notified by the agent 50 and other indications that occur on the host system 10 or other computers connected to the host system 10 via a communication network Events related to malicious programs.

[0092] For example, software versioning and backup application asset shadowing

[0093] In some embodiments, the storage security agent 50 automatically detects attempts to delete or overwrite files, and in response, saves a copy of the deleted/overwritten data to the primary storage device 30 or a separate secondary storage device 32 position. The shadow copy of the file being deleted or overwritten is therefore kept with the newly written data. Some embodiments save more than two consecutive versions of the same file, where at least one of the corresponding versions is not encrypted. This mechanism may allow safe restoration of data by any of the possible restoration of the corresponding file to the saved version.

[0094] Possible applications of such asset shadowing include security, backup, software versioning, and so on. In a computer security embodiment, the agent 50 may detect that a specific file is repeatedly overwritten in a relatively short time interval, for example. Such file activity can indicate malicious programs. Some embodiments may compare consecutive versions of the same file to determine, for example, whether a newer version is encrypted and an older version is not. As mentioned earlier, this type of encryption change can indicate a ransomware attack. More generally, for example, keeping backup copies of files may be possible to prevent malicious software from modifying important assets, thus preventing malicious hooking of OS functions. When such modification is detected, the agent 50 may notify the CSM 44. In turn, the CSM 44 may instruct the agent 50 to roll back the changes of a particular file.

[0095] optimization

[0096] Some embodiments may be further optimized to reduce the additional computational burden of interpreting the semantics of the file system from the level of the secure storage device 24. In a hybrid embodiment, the semantic indicator is delivered from the CSM 44 to the security agent 50, and the agent 50 can intercept and resist malicious storage events, such as file deletion, file overwriting, unauthorized data encryption, and so on. In such embodiments, CSM 44 may include a lightweight storage device access filter, which has a The functionality of the micro filter in the file system. The storage device access filter can determine, for example, an attempt to write to a file, the name and/or disk location of the corresponding data/file, and the identity of the processing program that performs the write operation, and so on. Then, the storage device access filter may transmit such semantic information to the storage security agent 50 via a downlink notification. The agent 50 may respond to the reception using a response packet or uplink notification. In some embodiments, downlink notifications are added to the notification queue.

[0097] At the level of the secure storage device 24, the agent 50 can recognize an attempt to write and try to match the corresponding attempt with data from the downlink notification queue. A successful match allows the agent 50 to determine the semantics of the corresponding write attempt, and may allow the agent 50 to apply more complex heuristics to determine whether the corresponding write attempt is suspicious, whether it needs to be blocked, etc. Failure to match write attempts detected at the hardware level (ie, from specific metadata changes) to write attempts communicated via downlink notifications may indicate that detection by the storage device access microfilter of OS 40 can be avoided Malware. In such cases, the security agent 50 may block the corresponding write attempt and/or notify the CSM 44 via the uplink.

[0098] The present invention relates to a system and method for protecting a host system from computer security threats such as malware. The described system and method are particularly suitable for protecting host systems (eg, computers, mobile communication devices, etc.) from complex malicious programs that can resist conventional defenses. Exemplary applications include protection against ransomware and theft of proprietary, private and/or confidential data.

[0099] Some embodiments of the invention rely on the observation that malware can successfully interfere with data traffic between the host system's processor and non-volatile storage devices (eg, magnetic, optical, or solid-state drives). Whether the security software executed on the corresponding processor can block or prevent all such interference, which brings a significant risk of data theft or loss. To solve this problem, the exemplary embodiment of the present invention shifts part of the security software onto a separate processor that is configured to intercept, analyze, and/or selectively block the main processor and storage of the host system Data service between devices. The auxiliary security processor may be integrated with, for example, a storage device and/or additional hardware on a common printed circuit board to form an enhanced security storage device. The secure storage device may assume a conventional appearance size of a hard disk drive or other non-volatile storage, and may be connected via a conventional storage interface/connector (such as serial AT attachment (SATA) or peripheral component interconnect (PCI) high speed interface/ Connector) is connected to the rest of the hardware of the host system. In an alternative embodiment, the secure storage device (ie storage + auxiliary processor) may be packaged as an external drive, for example connected to the host system by means of a universal serial bus (USB) or another conventional interface/connector.

[0100] In conventional anti-malware program systems, blocking, detection, and prevention measures are implemented in software executed on the same physical processor that also runs malicious code. Furthermore, in conventional systems, both malicious programs and legitimate software can access the same physical storage device (e.g., hard drive). This type of configuration may allow carefully crafted malicious code to secretly damage the security software. In contrast, in some embodiments of the invention, access to the physical storage device is controlled by an auxiliary processor that is different from the main processor running the user application (and possibly malicious code). The security software executed on the auxiliary processor is therefore not within the reach of malicious programs.

[0101] It will be clear to those skilled in the art that the above embodiments can be modified in many ways without departing from the scope of the present invention. Therefore, the scope of the present invention should be determined by the appended claims and their legal equivalents.