Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Oath/Declaration
Applicant’s oath/declaration filed on 10/15/2024 has been reviewed by the examiner and is found to conform to the requirements prescribed in 37 C.F.R. 1.63.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/18/2024 and 04/24/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings submitted on 10/15/2024 with the instant application are acceptable for examination purposes.
Specification
The specification submitted on 10/15/2024 with the instant application are acceptable for examination purposes.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-4, 6-7, 15-17, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit (US 11349855 B1), hereinafter Amit, in view of Brandwine (US 12086250 B1), hereinafter Brandwine.
Regarding Claim 1:
Amit teaches A non-transitory machine-readable storage medium comprising instructions that upon execution cause a system to (Amit – Col. 4, Line 64-67: In some examples, a non-transitory computer-readable medium is disclosed storing instructions that, when executed by a processor, cause the processor to perform any method of this disclosure): identify a first [block] input/output (I/O) operation relating to writing metadata for a data object (Amit – Col. 5, Line 36-46: A Realtime/near-Realtime module can be included for handling I/O operations, including: an Audit log … The Audit log serves both the Realtime modules, (every Single I/O operation and context is logged in Realtime)), the metadata of the first [block] I/O operation comprising first object type information (Amit – Col. 3, Line 24-28: In some examples, the audit log is associated with a respective context for the Rename I/O operations, wherein records within the audit log include one or more of context parameters including a timestamp, an old file name, a new file name, an auditing and a change of extension only; Examiner’s Comment: a file name and extension are interpreted as object type information, in accordance with at least paragraph [0073] of the instant specification, which recites “the metadata of the first block I/O operation including first object type information. For example, the metadata can include an object name of an object, where the object name includes a type extension indicating a type of the object”), and generate, based on a header of a second [block] I/O operation relating to writing object content to a target data object, second object type information relating to an object type of the target data object (Amit – Col. 4, Line 30-35: In some examples, for every Write I/O operation, one or more records within the audit log include one or more of context parameters including Changed Offset address(s), File signature, Process Image, Process Name, Process ID, Parent Process ID, Timestamp, File Path, UHash, FHash, Logon type, Entropy, User, Domain; and Col. and Col. 13, Line 26-33: For every Change (Write) I/O operation the records within the log may include one or more of the following context parameters: … (b) File signature—the file type as defined in the first 512 bytes; Examiner’s Comment: the file type defined by file signature in the leading bytes of the write I/O operation is interpreted to represent the claimed object type information based on a header of a second I/O operation. In view of at least paragraphs [0046] and [0047] of the instant specification, the header containing a metadata prefix (e.g. FILE, PK…, %PDF…) is observable at the file level, and thus is not to be strictly interpreted as a structural element of an I/O operation); compare the first object type information in the metadata of the first [block] I/O operation to the second object type information (Amit – Col. 18, Line 53-67 and Col. 19, Line 1-19: The system may also monitor one or more of the following issues (unless otherwise indicated, the monitoring of the following issues is performed by near real-time module 1040): (b) File Created\Renamed with custom extension\unmatched file signature (Or ransomware known extension). Most known ransomware use custom file extensions different from the original file's extension. Following the encryption of a file, the ransomware either rename the encrypted file, or create a new file with a different extension after erasing the original file. Some of the ransomware uses known extensions associated with ransomware and some are custom extensions. Known file types are typically targeted (namely, office docs, PDF, images etc.) have a signature property embedded in the file's header which suggests the file type regardless of the file extension, as well as other indicators such as file metadata. With the file being encrypted and the extension changed—the signature and the extension do not match the original); and based on the comparing, determine whether an anomaly relating to data has occurred (Amit – Col. 19, Line 11-19: Some of the ransomware uses known extensions associated with ransomware and some are custom extensions. Known file types are typically targeted (namely, office docs, PDF, images etc.) have a signature property embedded in the file's header which suggests the file type regardless of the file extension, as well as other indicators such as file metadata. With the file being encrypted and the extension changed—the signature and the extension do not match the original).
Amit does not expressly teach block input/output (I/O) operation.
However, Brandwine teaches block input/output (I/O) operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit, further incorporating Brandwine to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Brandwine’s teaching to monitor block I/Os to identify patterns indicative of ransomware into Amit’s anomaly detection based on I/O comparisons. This combined functionality provides a granular capability to observe individual I/O characteristics to identify potentially unauthorized activity.
Regarding Claim 3:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
Amit further teaches detect a signature relating to the object type of the target data object in the header of the second [block] I/O operation, wherein the generated second object type information is based on the signature (Amit – Col. 13, Line 26-33: For every Change (Write) I/O operation the records within the log may include one or more of the following context parameters: … (b) File signature—the file type as defined in the first 512 bytes).
Brandwine further teaches block I/O operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 3.
Amit further teaches wherein different object types of data objects are associated with different signatures (Amit – Col. 19, Line 13-17: Known file types are typically targeted (namely, office docs, PDF, images etc.) have a signature property embedded in the file's header which suggests the file type regardless of the file extension, as well as other indicators such as file metadata).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
Amit further teaches wherein the target data object includes a file, and the metadata of the first [block] I/O operation is for a file (Amit – Col. 3, Line 24-28: In some examples, the audit log is associated with a respective context for the Rename I/O operations, wherein records within the audit log include one or more of context parameters including a timestamp, an old file name, a new file name, an auditing and a change of extension only).
Brandwine further teaches block I/O operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 6.
Amit further teaches wherein the first block I/O operation relates to writing the metadata of a file record in a file system (Amit – Col. 3, Line 24-28: In some examples, the audit log is associated with a respective context for the Rename I/O operations, wherein records within the audit log include one or more of context parameters including a timestamp, an old file name, a new file name, an auditing and a change of extension only).
Brandwine further teaches block I/O operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 15:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
Amit further teaches wherein the anomaly relating to data comprises an unauthorized encryption of data (Amit – Col. 18, Line 53-67 and Col. 19, Line 1-19: The system may also monitor one or more of the following issues (unless otherwise indicated, the monitoring of the following issues is performed by near real-time module 1040): … (b) File Created\Renamed with custom extension\unmatched file signature (Or ransomware known extension). Most known ransomware use custom file extensions different from the original file's extension. Following the encryption of a file, the ransomware either rename the encrypted file, or create a new file with a different extension after erasing the original file. Some of the ransomware uses known extensions associated with ransomware and some are custom extensions. Known file types are typically targeted (namely, office docs, PDF, images etc.) have a signature property embedded in the file's header which suggests the file type regardless of the file extension, as well as other indicators such as file metadata. With the file being encrypted and the extension changed—the signature and the extension do not match the original).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 16:
Claim 16 is a system claim with limitations corresponding to those of non-transitory machine-readable storage medium Claim 1. Therefore, Claim 16 is rejected with the same combination and rationale.
Amit further teaches the additional limitations a system comprising: a hardware processor (Amit Col. 4, Line 64-67: In some examples, a non-transitory computer-readable medium is disclosed storing instructions that, when executed by a processor, cause the processor to perform any method of this disclosure).
Regarding Claim 17:
The combination of Amit and Brandwine teaches the system of claim 16.
Amit further teaches wherein the second object type information is generated based on a signature of a recognized object type in the header of the object [block] I/O operation (Amit – Col. 13, Line 26-33: For every Change (Write) I/O operation the records within the log may include one or more of the following context parameters: … (b) File signature—the file type as defined in the first 512 bytes).
Brandwine further teaches block I/O operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
The motivation to combine the arts is the same as that of Claim 16.
Regarding Claim 19:
Claim 19 is a method claim with limitations corresponding to those of non-transitory machine-readable storage medium Claim 1 and system Claim 16. Therefore, Claim 19 is rejected with the same combination and rationale.
Brandwine further teaches the additional limitations a method comprising: receiving a plurality of write block input/output (I/O) operations that write data blocks to a storage system (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
Regarding Claim 20:
The combination of Amit and Brandwine teaches the method of claim 19.
Brandwine further teaches comprising: replicating, by the system, the plurality of write block I/O operations to a recovery storage system, wherein the identifying of the metadata write block I/O operation, the extracting of the first object type information, the identifying of the object write block I/O operation, the generating of the second object type information, the comparing, and the determining are performed in conjunction with the replicating (Brandwine – Figure 6: diagram of environment that enables rollback of storage, including snapshots and a journal; and Col. 20, Line 51-67 and Col. 21, Line 1-12: the computer system 600 provides access to the storage volume 610, including an indication of a pointer in the log that precedes an estimated time at which a potential ransomware attack or other malicious activity was believed to be initiated. For example, the journal 612 includes pre-ransomware journal 616 entries (e.g., including log entries reflecting changes to the volume prior to the malicious process 604 performing operations to carry out a ransomware attack), ransomware writes 618 reflecting journal entries caused by write operations initiated by the malicious process, and possibly other non-malicious writes 620 caused by other processes editing data while a ransomware attack is in progress. In this example, the computer system 600 can provide access to the storage volume 610 with a pointer to a journal entry reflecting a point in time before the ransomware writes 618 started (e.g., one of the journal entries including pre-ransomware journal 616). In this manner, the same computer system 600 or another computer system 600 can access the volume with the provided pointer in the log, which reflects at a point prior to when the ransomware attack began, thereby enabling the recovery of data before it is modified by the malicious process. In some embodiments, a security posture management service 136 or other service can also enable the incremental restoration of a volume using incremental log pointers reflecting the log at various points in time in the journal 612 to enable users to potentially recover data that was written after a ransomware attack started by other non-malicious processes).
The motivation to combine the arts is the same as that of Claim 19.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit in view of Brandwine and Dubeyko et al. (US 20170322927 A1), hereinafter Dubeyko.
Regarding Claim 2:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
The combination of Amit and Brandwine does not expressly teach wherein the identifying of the first block I/O operation relating to writing the metadata comprises detecting a metadata prefix in a header of the first block I/O operation.
However, Dubeyko teaches wherein the identifying of the first block I/O operation relating to writing the metadata comprises detecting a metadata prefix in a header of the first block I/O operation (Dubeyko – Paragraph [0007]: the write request includes a logical block address, a magic signature, and a data type flag … the data type flag comprising a metadata type … responsive to the write request comprising a valid magic signature, a valid number of blocks, and a valid size, determine that the write request is valid).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit and Brandwine, further incorporating Dubeyko to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dubeyko’s teaching of a metadata type flag as an element of a metadata write request into Amit and Brandwine’s combined anomaly detection based on I/O comparisons. This addition provides type identification of each write operation, enabling efficient verification of the operations.
Claim(s) 5 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit in view of Brandwine and Hansen (US 20200387609 A1), hereinafter Hansen.
Regarding Claim 5:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
The combination of Amit and Brandwine does not expressly teach wherein the generated second object type information indicates an unrecognized object type responsive to the second block I/O operation not including any signature relating to a recognized object type.
However, Hansen teaches wherein the generated second object type information indicates an unrecognized object type responsive to the second block I/O operation not including any signature relating to a recognized object type (Hansen – Paragraph [0037]: A weighted hint in the update analysis is provided by a relatively small database maintained with a subset of known, common filetypes and associated extensions, and an indication of the use of particular file types for a file, as well as whether the file types are known or unknown. A file update pattern is analyzed on a server by means of a “watcher,” that monitors file commands arriving from a computing device via its agent module; and Paragraph [0091]: Many common file formats include a small signature of 2 bytes or more in the header and taken together with the file extension identifies the file as being of a certain filetype. When a file is encrypted by ransomware, this relationship is destroyed because the signature may be overwritten, and the file extension is changed to something ‘unknown’ to the system).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit and Brandwine, further incorporating Dubeyko to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dubeyko’s teaching of a metadata type flag as an element of a metadata write request into Amit and Brandwine’s combined anomaly detection based on I/O comparisons. This addition provides type identification of each write operation, enabling efficient verification of the operations.
Regarding Claim 18:
The combination of Amit and Brandwine teaches the system of claim 16.
The combination of Amit and Brandwine does not expressly teach wherein the second object type information indicates an unrecognized object type based on the header of the object block I/O operation not including any signature of a recognized object type.
However, Hansen teaches wherein the second object type information indicates an unrecognized object type based on the header of the object block I/O operation not including any signature of a recognized object type (Hansen – Paragraph [0037]: A weighted hint in the update analysis is provided by a relatively small database maintained with a subset of known, common filetypes and associated extensions, and an indication of the use of particular file types for a file, as well as whether the file types are known or unknown. A file update pattern is analyzed on a server by means of a “watcher,” that monitors file commands arriving from a computing device via its agent module; and Paragraph [0091]: Many common file formats include a small signature of 2 bytes or more in the header and taken together with the file extension identifies the file as being of a certain filetype. When a file is encrypted by ransomware, this relationship is destroyed because the signature may be overwritten, and the file extension is changed to something ‘unknown’ to the system).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit and Brandwine, further incorporating Dubeyko to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Dubeyko’s teaching of a metadata type flag as an element of a metadata write request into Amit and Brandwine’s combined anomaly detection based on I/O comparisons. This addition provides type identification of each write operation, enabling efficient verification of the operations.
Claim(s) 8-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit in view of Brandwine and Zhu et al. (Zhu, Weidong, Hernandez, Grant, Garcia, Washington, Tian, Dave Jing, Rampazzi, Sara, and Butler, Kevin (June 4, 2024). Minding the Semantic Gap for Effective Storage-Based Ransomware Defense. Retrieved from https://par.nsf.gov/biblio/10559373), hereinafter Zhu.
Regarding Claim 8:
The combination of Amit and Brandwine teaches the non-transitory machine-readable storage medium of claim 1.
The combination of Amit and Brandwine does not expressly teach wherein the instructions upon execution cause the system to: extract, from the metadata of the first block I/O operation, a first data offset relating to where the data object associated with the metadata is stored in a storage system; and determine a second data offset relating to where the target data object is written by the second block I/O operation in the storage system, wherein the comparing of the first object type information to the second object type information is responsive to the first data offset matching the second data offset.
However, Zhu teaches wherein the instructions upon execution cause the system to: extract, from the metadata of the first block I/O operation, a first data offset relating to where the data object associated with the metadata is stored in a storage system (Zhu – P. 6, Right Col.: Through the filesystem parser, a filesystem metadata table (FMT) is created, and each entry of it includes a key value pair, where the index is the first LBA (LBAFirst) of the file followed by its metadata1, including file length (FileLength), file type, and file type change flag2 (TypeFlag)); and determine a second data offset relating to where the target data object is written by the second block I/O operation in the storage system (Zhu – P. 4, Right Col.: Our Ransomware Finder operates within the SSD as a part of the FTL. All incoming I/O requests are collected by the FTL, starting with logical block addresses (LBAs), which can be used to reason the physical page address (PPA) of data by searching a logical-to-physical (L2P) address mapping table. Figure2shows the workflow of Ransomware Finder, which records the metadata of the incoming I/O requests in I/O replay table (IRT), allowing the upper classification enclave to pull and analyze the state of storage for ransomware judgment. The metadata of each entry (i.e., I/O request) in IRT consists of LBA, operation type (e.g., read/write), and an indicator flag of read-before-overwrite (RBO) operation), wherein the comparing of the first object type information to the second object type information is responsive to the first data offset matching the second data offset (Zhu – P. 6, Right Col.: Given that files tend to maintain their types even after the content modification, our methodology includes monitoring the modification of file types, with any alteration deemed as suspicious. Therefore, our classification tracks the file type change for each read request, which can be processed by ra(n)somware for victim files, in an IRT. For the LBA of each IRT read entry, if it falls within the range [LBAFirst, LBAFirst+FileLength] of an FMT entry, the filesystem metadata of the LBA can be located and the TypeFlag is used to indicate the file type change).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit and Brandwine, further incorporating Zhu to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Zhu’s teaching to compare data derived from I/O operations occurring in corresponding storage locations in order to detect unauthorized/unexpected file changes into Amit and Brandwine’s combined anomaly detection based on I/O comparisons. This combination enhances the method by providing a focal point at which to detect suspicious activity among I/O operations.
Regarding Claim 9:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 8.
Amit further teaches the first object type information (Amit – Col. 3, Line 24-28: In some examples, the audit log is associated with a respective context for the Rename I/O operations, wherein records within the audit log include one or more of context parameters including a timestamp, an old file name, a new file name, an auditing and a change of extension only).
Zhu further teaches wherein the instructions upon execution cause the system to: add the first data offset [and the first object type information] to an entry of a first data structure (Zhu – P. 6, Right Col.: Through the filesystem parser, a filesystem metadata table (FMT) is created, and each entry of it includes a key value pair, where the index is the first LBA (LBAFirst) of the file followed by its metadata1, including file length (FileLength), file type, and file type change flag2 (TypeFlag)); and add the second data offset and the second object type information to an entry of a second data structure (Zhu – P. 4, Right Col.: Our Ransomware Finder operates within the SSD as a part of the FTL. All incoming I/O requests are collected by the FTL, starting with logical block addresses (LBAs), which can be used to reason the physical page address (PPA) of data by searching a logical-to-physical (L2P) address mapping table. Figure2shows the workflow of Ransomware Finder, which records the metadata of the incoming I/O requests in I/O replay table (IRT), allowing the upper classification enclave to pull and analyze the state of storage for ransomware judgment. The metadata of each entry (i.e., I/O request) in IRT consists of LBA, operation type (e.g., read/write), and an indicator flag of read-before-overwrite (RBO) operation), wherein the comparing is based on identifying the entries of the first data structure and the second data structure with the matching first and second data offsets (Zhu – P. 6, Right Col.: Given that files tend to maintain their types even after the content modification, our methodology includes monitoring the modification of file types, with any alteration deemed as suspicious. Therefore, our classification tracks the file type change for each read request, which can be processed by ra(n)somware for victim files, in an IRT. For the LBA of each IRT read entry, if it falls within the range [LBAFirst, LBAFirst+FileLength] of an FMT entry, the filesystem metadata of the LBA can be located and the TypeFlag is used to indicate the file type change).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 10:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 9.
Zhu further teaches wherein the instructions upon execution cause the system to: in response to detecting an update of one of the first data structure and the second data structure, compare entries of the first data structure and the second data structure to identify any matching data offsets (Zhu – P. 6, Right Col.: Given that files tend to maintain their types even after the content modification, our methodology includes monitoring the modification of file types, with any alteration deemed as suspicious. Therefore, our classification tracks the file type change for each read request, which can be processed by ra(n)somware for victim files, in an IRT. For the LBA of each IRT read entry, if it falls within the range [LBAFirst, LBAFirst+FileLength] of an FMT entry, the filesystem metadata of the LBA can be located and the TypeFlag is used to indicate the file type change); and based on identifying a first entry of the first data structure and a second entry of the second data structure with matching data offsets, compare object type information in the first entry to object type information in the second entry (Zhu – P. 6, Right Col.: Given that files tend to maintain their types even after the content modification, our methodology includes monitoring the modification of file types, with any alteration deemed as suspicious. Therefore, our classification tracks the file type change for each read request, which can be processed by ra(n)somware for victim files, in an IRT. For the LBA of each IRT read entry, if it falls within the range [LBAFirst, LBAFirst+FileLength] of an FMT entry, the filesystem metadata of the LBA can be located and the TypeFlag is used to indicate the file type change).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 11:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 10.
Zhu further teaches wherein the instructions upon execution cause the system to: indicate occurrence of the anomaly relating to data responsive to the object type information in the first entry not matching the object type information in the second entry (Zhu – P. 6, Right Col.: V. RANSOMWARE CLASSIFICATION This section illustrates how to devise an accurate ransomware detection while bridging the semantic gap on SrFTL … Then, our classification selects two file-based heuristics through the parsed metadata. File type changes … For the LBA of each IRT read entry, if it falls within the range [LBAFirst, LBAFirst+FileLength] of an FMT entry, the filesystem metadata of the LBA can be located and the TypeFlag is used to indicate the file type change; and P. 7, Figure 6: illustration of a trained decision tree that includes detecting ransomware when a file type change is determined).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 12:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 9.
Zhu further teaches wherein the instructions upon execution cause the system to: remove an entry from the first data structure or the second data structure based on an age of the entry (Zhu – P. 4, Right Col.: Our Ransomware Finder operates within the SSD as a part of the FTL. All incoming I/O requests are collected by the FTL … Ransomware Finder, which records the metadata of the incoming I/O requests in I/O replay table (IRT) … Once an IRT is full, SrFTL sends it to the classification enclave over a secure channel. We set the size of the IRT to 1000 entries, which achieves the best trade-off between the table size and detection granularity).
The motivation to combine the arts is the same as that of Claim 8.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit in view of Brandwine, Zhu, and Krywaniuk (US 20070168547 A1), hereinafter Krywaniuk.
Regarding Claim 13:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 9.
The combination of Amit, Brandwine, and Zhu does not expressly teach wherein the instructions upon execution cause the system to: remove an entry from the first data structure or the second data structure according to a least recently used criterion.
However Krywaniuk teaches wherein the instructions upon execution cause the system to: remove an entry from the first data structure or the second data structure according to a least recently used criterion (Krywaniuk – Paragraph [0045]: Because the number of active log files and sockets may exceed the limit of the operating system, an embodiment of the logging server 308 keeps a table of open file descriptors for each active log file, and closes the file descriptors of inactive log files, as dictated by an Least Recently Used (LRU) algorithm, well known to persons of skill in the art).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit, Brandwine, and Zhu, further incorporating Krywaniuk to arrive at the conclusion of the claimed invention. Krywaniuk is directed to anti-malware scanning for network communications. However, Krywaniuk demonstrates a known technique to remove outdated or expired data entries in structures used for detecting malicious activity based on some LRU algorithm. Thus, LRU would have been an obvious implementation choice to apply to at least the fixed-size IRT tables taught by Zhu. This combination would result in the obvious benefit of maintaining up-to-date data structures for detecting malicious activity based on collections of data determined to be the most relevant.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amit in view of Brandwine, Zhu, and Karnik et al. (US 20210182397 A1), hereinafter Karnik.
Regarding Claim 14:
The combination of Amit, Brandwine, and Zhu teaches the non-transitory machine-readable storage medium of claim 8.
Amit further teaches wherein the first [block] I/O operation is a metadata [block] I/O operation (Amit – Col. 5, Line 36-46: A Realtime/near-Realtime module can be included for handling I/O operations, including: an Audit log … The Audit log serves both the Realtime modules, (every Single I/O operation and context is logged in Realtime)), and the second [block] I/O operation is an object [block] I/O operation (Amit – Col. 4, Line 30-35: In some examples, for every Write I/O operation, one or more records within the audit log include one or more of context parameters including Changed Offset address(s), File signature, Process Image, Process Name, Process ID, Parent Process ID, Timestamp, File Path, UHash, FHash, Logon type, Entropy, User, Domain).
Brandwine further teaches block I/O operation (Brandwine – Col. 12, Line 66-67, and Col. 13, Line 1-18: As indicated, in the example of FIG. 1, the I/O request messages 134 include I/O operations performed by a malicious process that is executing upon the hardware processing element(s) 116A (e.g., reading data stored on a volume provided by a data storage device, modifying the data by encrypting the contents, and writing the data back to the data storage volume, etc.) … each I/O request message 134 can be packetized and include information identifying a storage location to which the request relates (e.g., a physical page, a location of a block as an offset into the page, a length of the block from a given offset, a file identifier, etc.), a type of operation (e.g., a read, a modify, or a write operation), data associated with the request (e.g., a block of data or file to be written to the data storage device), among other possible information; and Col. 13, Line 37-48: as I/O messages 134 pass through the I/O proxy device 118, an I/O analyzer 122 executing on the I/O proxy device 118 analyzes the I/O messages for anomalous patterns of I/O activity. For example, a malicious process carrying out a ransomware attack typically begins encrypting the files on a disk, or the entire disk itself at the block level, in rapid succession. The I/O pattern thus involves a succession of read-modify-write type operations (e.g., to read a block or other portion of a data volume, modify the block or portion of data based on the malicious process encrypting the data, and write the modified block or other data back to storage volume)).
The combination of Amit, Brandwine, and Zhu does not expressly teach and wherein the instructions upon execution cause the system to: track a count of occurrences of mismatches of object types in further metadata and file block I/O operations; compare the count to a threshold; and based on the count exceeding the threshold, indicate occurrence of the anomaly relating to data.
However, Karnik teaches and wherein the instructions upon execution cause the system to: track a count of occurrences of mismatches of object types in further metadata and file [block] I/O operations; compare the count to a threshold; and based on the count exceeding the threshold, indicate occurrence of the anomaly relating to data (Karnik – Paragraph [0098]: At decision block 660, the system determines whether the process has been monitored for greater than or equal to n create/modify events that have a mismatched file type in block 628 … if a process creates a large number of mismatched files in a short time, this may be indicative of a potential ransomware attack. The specific threshold number, as well as the threshold time within which that number of files is to be created, may be determined heuristically based on the system profile).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Amit, Brandwine, and Zhu, further incorporating Karnik to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Karnik’s teaching to monitor file modifications over time and determine whether a threshold number of file mismatches was exceeded into Amit, Brandwine, and Zhu’s combined anomaly detection based on I/O comparisons. This further consideration could help reduce false positive ransomware detection as some file extension mismatches may be expected during authorized file activity.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yelheri et al. (US 20220138152 A1) teaches methods for scanning data objects in a storage, the scans observing I/O operations to slots and usable for integrity checking of file/object contents
Mehta et al. (US 20240346139 A1) teaches a system for detecting ransomware based on changes to a file type
Natanzon et al. (US 10078459 B1) teaches a system and method for detecting ransomware based on comparisons of structures listing observed I/O activity and structures listing historical I/O activity
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at 571-272-8878. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights