DETAILED ACTION
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 .
This communication is in response to the application filed on 09/25/2023. Claims 1-27 are currently pending in the application.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-6, 10-16, 18-19, and 24-27 rejected under 35 U.S.C. 102(a)(2) as being anticipated by U.S. PGPub. No. 20210334374 to Vasudeva et al. (hereinafter Vasudeva).
Regarding claim 1, Vasudeva discloses a method of managing data security events, the method comprising (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”):
accessing, with a data security management (DSM) system, one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
each of the client files includes primary file content separate from the associated client file event record (¶0095-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereby making the provisional detection an official or corroborated detection. This corroborated detection may be considered a “confirmation,” with an acceptable degree of certainty, that the malware attack is underway…”), sending information to a client computing environment that causes a client-side data security event confirmation and response (CDSECR) system to inspect the one or more client files associated with the potential data security event to determine whether an actual data security event occurred and initiate a responsive action when the CDSECR determines an occurrence of an actual data security event (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0083.
Regarding claim 2, Vasudeva discloses the method of claim 1 wherein each cloud file event record contains a file name, file path, client node identifier, user entity, event, event details, and file size (¶0078-¶0082, “…the suspicious file entry 400 may include one or more of the following fields: file name 410, path 412, inode number 414, encrypted data block numbers 416, write event time 418, user identifier (UID) 420, group identifier (GID) 422, and network session identifier 424, though any appropriate number or type of fields may be used…”).
Regarding claim 3, Vasudeva discloses the method of claim 2 wherein each client file event record is a record in an event audit table (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner...”), (¶0064, “the data storage node 304 takes the form of an external storage array. In these examples, a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”). See also FIGs 4-5 and ¶0080-¶0082.
Regarding claim 5, Vasudeva discloses the method of claim 1 wherein if inspection-of the client file data record indicates malicious tampering, activating a client taking protective action (¶0016, “…When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0098, “if the malware attack is confirmed as being underway, a notification is generated, and any previously generated snapshots are locked (operation 724). In other examples, only the most recent snapshot or recent few snapshots may be locked. In one or more examples, the notification that is generated may be visually presented via a user interface to, for example, a storage administrator, to allow the user to determine whether to restore any impacted files from one or more of the previously generated snapshots or from the deleted files directory.”). See also ¶0080.
Regarding claim 6, Vasudeva discloses the method of claim 1 wherein the data security event is an anomalous activity that comprises at least one of:
a. a content mismatch in the client file between a type of content of the client file and an extension of a name of the client file;
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
c. at least one of the client files is encoded in a binary file format and the client files are unintelligible;
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
e. at least one of the client files has an extension known to correspond to an extension associated with a ransomware attack; and
f a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”).
Regarding claim 10, Vasudeva discloses the method of claim 1 wherein the responsive action comprises at least one of:
a. sending an alert (¶0016, “When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface…”);
b. restricting access to the client node used by a most recent user entity connected to the data security event;
c. taking a snapshot of the metadata of each of the one or more client files (¶0017, “Thus, the methods, systems, and machine-readable media described herein enable early detection of malware attacks, such as ransomware attacks, as well as data loss mitigation via special snapshot creation and/or notification of the detected malware attacks.”), (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack. Accordingly, this signal may trigger the generation of a snapshot 314 of the volume 309 by the protection agent 300…”);
taking a snapshot of a mapping of each of the one or more client files to blocks of memory; and
utilizing the snapshot to revert the one or-more client files to a pre-data security event backup copy (¶0075, “…The protection agent 300, the storage administrator, or a combination of the two may determine whether a given impacted file should be restored from a snapshot or from the deleted files directory 320. For example, if the deleted files directory 320 contains a version of the impacted file at a timepoint that is closer to when the malware attack is determined to have begun or when the malware attack was detected as compared to the snapshot, the impacted file may be restored from the deleted files directory 320.”).
Regarding claim 23, Vasudeva discloses the system of claim 14 further comprising a client-side data security event confirmation and response system (CDSECR) (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0082, wherein the CDSECR system includes one or more processors and a memory, coupled to the one or more processors, that includes code that when executed by the one or more processors causes the one or-more processors to perform operations comprising (claim 14, “… and a processor coupled to the at least one memory, the at least one processor configured to execute the machine-executable code to cause the processor to: detect an incoming request to write a file to a storage node…”):
receiving the information from the DSM (¶0075, “…the protection agent 300 employs a user interface 324 that is displayed on client 305 to present information about the one or more files that are potentially impacted to, for example, the storage administrator…”), (¶0080, “…an identification of the source may be used to block any further file requests from the source, may be included in an alert and/or a report generated in response to the corroborated detection of the malware attack, may be used in one or more mitigation techniques, or a combination thereof.”); and
performing a response action (¶0080, “…an identification of the source may be used to block any further file requests from the source, may be included in an alert and/or a report generated in response to the corroborated detection of the malware attack, may be used in one or more mitigation techniques, or a combination thereof.”), wherein the responsive action comprises:
determining if an actual data security event occurred (¶0072, “the protection agent 300 uses pattern analyzer 319 to analyze the suspicious file log 310, the file event log 318, or both to determine whether the provisional detection can be corroborated and thereby confirm, with an acceptable degree of certainty, that a malware attack is underway whether a malware attack is underway. The pattern analyzer 319 evaluates the file activity over a plurality of files stored in the volume 309 (e.g., by reference to the file event log 318) to determine whether the volume 309 has a malware attack underway…”); and
when an actual data security event occurs, performing one or more responsive actions (¶0075, “When the protection agent 300 has made a corroborated detection of a malware attack (e.g., confirmed that a malware attack is underway with an acceptable degree of certainty), the protection agent 300 uses the suspicious file log 310, the file event log 318, or both to identify the one or more files that are potentially impacted. In one or more examples, the protection agent 300 employs a user interface 324 that is displayed on client 305 to present information about the one or more files that are potentially impacted to, for example, the storage administrator. The protection agent 300 may also identify and present recovery options for the one or more files that are potentially impacted.”) comprising:
a. sending an alert (¶0016, “When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface…”);
b. restricting access to the client node used by a most recent user entity connected to the data security event;
c. taking a snapshot of the metadata of each of the one or more client files (¶0017, “Thus, the methods, systems, and machine-readable media described herein enable early detection of malware attacks, such as ransomware attacks, as well as data loss mitigation via special snapshot creation and/or notification of the detected malware attacks.”), (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack. Accordingly, this signal may trigger the generation of a snapshot 314 of the volume 309 by the protection agent 300…”);
taking a snapshot of a mapping of each of the one or more client files to blocks of memory; and
utilizing the snapshot to revert the one or-more client files to a pre-data security event backup copy (¶0074, “…The protection agent 300, the storage administrator, or a combination of the two may determine whether a given impacted file should be restored from a snapshot or from the deleted files directory 320. For example, if the deleted files directory 320 contains a version of the impacted file at a timepoint that is closer to when the malware attack is determined to have begun or when the malware attack was detected as compared to the snapshot, the impacted file may be restored from the deleted files directory 320.”).
Regarding claim 11, Vasudeva discloses the method of claim 1 wherein the data security event is a ransomware attack (¶0076, “For example, the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”). See also ¶0066, ¶0111 and ¶0065 for ransomware attack.
Regarding claim 24, Vasudeva discloses the system of claim 14 wherein the data security event is a ransomware attack (¶0076, “For example, the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”). See also ¶0066, ¶0111 and ¶0065 for ransomware attack.
Regarding claim 12, Vasudeva discloses the method of claim 1 wherein the one or more client file event records are created by the client node and stored in an audit table in a folder shared by the DSM system and the client node (¶0064-¶0065, FIGs. 2 and 3, “…a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”, wherein node 304 with different directories/folders is interpreted as the audit table, and wherein agent 300 and client node 305 are collocated within node 304), (¶0019, “For example, the client node 128 may transmit operations, such as data operations to read data and write data and metadata operations (e.g., a create file operation, a rename directory operation, a resize operation, a set attribute operation, etc.), over a network 126 to the first node 130 for implementation by the first node 130 upon storage…”), (¶0054, “…Volumes 218(1)-218(n) can span a portion of a disk or other storage device, a collection of disks, or portions of disks, for example, and typically define an overall logical arrangement of data storage. In one example volumes 218(1)-218(n) can include stored user data as one or more files, blocks, or objects that may reside in a hierarchical directory structure within the volumes 218(1)-218(n).”) and accessing the one or more client file event records comprises:
accessing the audit table in the shared folder (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312…”).
Regarding claim 25, Vasudeva discloses the system of claim 14 wherein the one or more client file event records are created by the client node and stored in an audit table in a folder shared by the DSM system and the client node (¶0064-¶0065, FIGs. 2 and 3, “…a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”, wherein node 304 with different directories/folders is interpreted as the audit table, and wherein agent 300 and client node 305 are collocated within node 304), (¶0019, “For example, the client node 128 may transmit operations, such as data operations to read data and write data and metadata operations (e.g., a create file operation, a rename directory operation, a resize operation, a set attribute operation, etc.), over a network 126 to the first node 130 for implementation by the first node 130 upon storage…”), (¶0054, “…Volumes 218(1)-218(n) can span a portion of a disk or other storage device, a collection of disks, or portions of disks, for example, and typically define an overall logical arrangement of data storage. In one example volumes 218(1)-218(n) can include stored user data as one or more files, blocks, or objects that may reside in a hierarchical directory structure within the volumes 218(1)-218(n).”) and accessing the one or more client file event records comprises:
accessing the audit table in the shared folder (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312…”).
Regarding claim 13, Vasudeva discloses the method of claim 1 further comprising:
inspecting in the client node the one or more client files directly to determine whether an existence of an actual data security event occurred (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”); and
generating the responsive action if the client node detects the actual data security event (¶0015, “…The protection agent can quickly identify when files that are being requested to be written to the storage node are suspicious and can generate a snapshot of at least a portion of the storage node (e.g., a volume of the storage node to which the file was to be written) in response to detecting suspicious files. A suspicious file may be a file that is associated with a malware attack risk…”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond. Additionally, one or more of the fields may be used by the protection agent 300 to suggest options to the administrator (e.g., by displaying via the user interface 324) for protecting against the malware attack or for fixing the file 306. For example, the inode number 414 may be matched to a snapshot or another copy of the data, thereby allowing the snapshot or other copy to be used as an alternative to data that may be surreptitiously encrypted…”).
Regarding claim 26, Vasudeva discloses the-system of claim 14 further comprising a client-side data security event confirmation and response system (CDSECR) (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)), wherein the CDSECR system includes one or more processors and a memory, coupled to the one or more processors, that includes code that when executed by the one or more processors causes the one or more processors to perform operations (claim 14, “…and a processor coupled to the memory, the processor configured to execute the machine-executable code to: analyze data in a file associated with a write request to the storage node to determine whether the file is associated with a malware attack risk, the analysis comprising…”) comprising:
inspecting in the client node the one or more client files directly to determine whether an existence of an actual data security event occurred (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”); and
generating the responsive action if the client node detects the actual data security event (¶0015, “…The protection agent can quickly identify when files that are being requested to be written to the storage node are suspicious and can generate a snapshot of at least a portion of the storage node (e.g., a volume of the storage node to which the file was to be written) in response to detecting suspicious files. A suspicious file may be a file that is associated with a malware attack risk…”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond. Additionally, one or more of the fields may be used by the protection agent 300 to suggest options to the administrator (e.g., by displaying via the user interface 324) for protecting against the malware attack or for fixing the file 306. For example, the inode number 414 may be matched to a snapshot or another copy of the data, thereby allowing the snapshot or other copy to be used as an alternative to data that may be surreptitiously encrypted…”).
Regarding claim 14, Vasudeva discloses data security management (DSM) system (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”) comprising one or more processors and a memory, coupled to one or more processors, wherein the memory includes stored code that when executed by the one or more processors causes the DSM system to perform operations comprising (claim 14, “…and a processor coupled to the memory, the processor configured to execute the machine-executable code to: analyze data in a file associated with a write request to the storage node to determine whether the file is associated with a malware attack risk, the analysis comprising…”):
accessing one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
each of the client files includes primary file content separate from the associated client file event record (¶0096-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack…”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereby making the provisional detection an official or corroborated detection. This corroborated detection may be considered a “confirmation,” with an acceptable degree of certainty, that the malware attack is underway…”), sending information to a client computing environment that causes a client-side data security event confirmation and response (CDSECR) system to inspect the one or more client files associated with the potential data security event to determine whether an actual data security event occurred and initiate a responsive action when the CDSECR determines an occurrence of an actual data security event (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0083.
Regarding claim 15, Vasudeva discloses the method of claim 14 wherein each cloud file event record contains a file name, file path, client node identifier, user entity, event, event details, and file size (¶0078-¶0082, “…the suspicious file entry 400 may include one or more of the following fields: file name 410, path 412, inode number 414, encrypted data block numbers 416, write event time 418, user identifier (UID) 420, group identifier (GID) 422, and network session identifier 424, though any appropriate number or type of fields may be used…”).
Regarding claim 16, Vasudeva discloses the system of claim 14 wherein each client-file event record is a record in an event audit table (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner...”), (¶0064, “the data storage node 304 takes the form of an external storage array. In these examples, a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”). See also FIGs 4-5 and ¶0080-¶0082.
Regarding claim 18, Vasudeva discloses the system of claim 14 wherein if inspection-of the client file data record indicates malicious tampering, activating a client taking protective action (¶0016, “…When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0098, “if the malware attack is confirmed as being underway, a notification is generated, and any previously generated snapshots are locked (operation 724). In other examples, only the most recent snapshot or recent few snapshots may be locked. In one or more examples, the notification that is generated may be visually presented via a user interface to, for example, a storage administrator, to allow the user to determine whether to restore any impacted files from one or more of the previously generated snapshots or from the deleted files directory.”). See also ¶0080.
Regarding claim 19, Vasudeva discloses the method of claim 14 wherein the data security event is an anomalous activity that comprises at least one of:
a. a content mismatch in the client file between a type of content of the client file and an extension of a name of the client file;
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
c. at least one of the client files is encoded in a binary file format and the client files are unintelligible;
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
e. at least one of the client files has an extension known to correspond to an extension associated with a ransomware attack; and
f a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”).
Regarding claim 27, Vasudeva discloses a non-transitory, computer readable medium having code stored therein to manage data security events, wherein when execution of the code by one or more processors causes the one or more processors to perform operations comprising (¶0112, “…it is understood that any operation of the computing systems of the computing environment 100, the network environment 200, and the storage node 304 may be implemented by a computing system using corresponding instructions stored on or in a non-transitory computer-readable medium accessible by a processing system…”), (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”):
accessing, with a data security management (DSM) system, one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
each of the client files includes primary file content separate from the associated client file event record (¶0096-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack…”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereb