DETAILED ACTION
Claim Amendments
The amendments to claims 4, 9, 13, 14 and 18 overcome the 112(b) rejections raised in the previous office action. However, in view of the amendments to the independent claims, all claims are newly rejected under 112(a) and 112(b).
In view of the claim amendments, claims 1, 3-10, and 12-20 are rejected under a revised 103 rejection. See below. The 103 rejections of dependent claims 2 and 11 are withdrawn.
Response to Arguments
Applicant argues that Kraemer ‘978 does not disclose the limitation “collecting a context of the process, the context including at least a security context based on the static and dynamic analysis, and a backup archive context based on attributes of the backup archive.” See Applicant’s Remarks on page 13. In particular, applicant argues that Kraemer ‘978 does not disclose “deriving a security context for a given process, and moreover, is simply silent as to a backup archive context.” Applicant’s argument is not persuasive as Kraemer ‘978 discloses a tracking module, including a behavior tracking module, that monitors specific events and maintains threat profiles for the computational entities that perform the monitored actions; these profiles may include data indicating one or more profile states of the computational entity. Para 0052-53. These profile states are generated based on both static analysis and dynamic analysis. See e.g., para 0053 (tracking behavior of computational entities), para 0054 (augmenting data corresponding to tracked events with additional static and/or dynamic information) and para 0122 (reputation of CEs). In addition, the tracking module may map events to internally tracked states. Para 0054. Kraemer ‘978 provides further elaboration of steps to associate data to a profile state and map events to tracked states (see e.g., para 0162, “At step 343, the behavioral security engine 100 adds the directory to a set of enumerated directories in the CE's profile state,” para 0167, “At step 358, the tracking module 110 maps attributes of the file and the event (e.g., file type, etc.) to heuristic states”). Finally, Kraemer ‘978 discloses that each identified category of ransomware identified with a CE can be based on an action with a backup file: category A (para 0062-64: enumerating filesystems within a backup), category B (para 0060: encrypting entire backup drive) and category C (para 0061, disabling system backups). See rejection below for additional citations to Kraemer ‘978 in view of the new claim limitation, which further limits the backup archive context.
Applicant further argues that neither Kraemer ‘978 nor Dar ‘557 discloses the claim element “wherein the access control machine-learning model is trained on aggregated contexts of a plurality of previously-collected testing process samples, including security contexts and backup archive contexts.” See Applicant’s Remarks on page 14. Applicant’s argument is not persuasive. As outlined in the 103 rejection below, this limitation is taught by the combination of Kraemer ‘978 and Dar ‘557. Dar ‘557 discloses using various reports that describe monitored events and data related to ransomware alerts to tune their machine learning model. See para 0067. Moreover, Dar ‘557 discloses their ML model uses IO features associated with a storage object to detect an attack and that the ransomware detection process uses a supervised machine learning classification model as attacks occur. See para 0054. In para 0052, Dar ‘557 describes conventional aspects of supervised learning: “A machine learning model may generally include an algorithm or combination of algorithms that has been trained to recognize certain types of patterns. For example, machine learning approaches may be generally divided into three categories, depending on the nature of the signal available: supervised learning, unsupervised learning, and reinforcement learning. Supervised learning may include presenting a computing device with example inputs and their desired outputs, given by a “teacher”, where the goal is to learn a general rule that maps inputs to outputs.” Hence, Dar ‘557’s supervised ML models are trained to recognize certain types of patterns, in particular IO features associated with a storage object during an attack, and moreover, are tuned using various reports that describe monitored events and data related to ransomware alerts. To the extent that the backup archive contexts (plural) now also require the new limitations that further limit the previously recited backup archive context (singular), these limitations are suggested by the combination of Kraemer ‘978 as modified by Dar ‘557. Because ML model accuracy is generally correlated with larger and more relevant training sets, it would have been obvious to one of ordinary skill in the art to use the data collected by the tracking module of Kraemer ‘978 as it applies to CE actions to a backup file in order to train the ML model taught by Dar ‘557. Such a modification would have been desirable to tailor the supervised learning model to recognize and detect attack patterns as identified by Kraemer ‘978.
Claim Rejections – 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The independent claims have been amended to recite the limitation “only upon a successful determination that the file is a backup archive, collecting a context of the process …” The relevant portion of the specification, paragraph 57, describes: “Upon the identification of a file as a backup, whether full or incremental, the access control unit 240 combines a context of the process and backup file from security module 250 and format recognition unit 260 …” The new claim term “only upon” requires that the first action of determining that the file is a backup is a strict condition for the second action of collecting a context of the process. However, the specification does not define a strict condition, and furthermore, only describes combining a context of the process as an action that occurs after the determining step. The dependent claims inherit the defect of the independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The independent claims now recite “wherein the backup archive context is generated by synthesizing information about how the backup archive is stored, how the backup archive is accessed, and backup data stored from original data in the backup archive”; however, it is unclear whether the limitation “including security contexts and backup archive contexts” (recited later in the claims) require that each of the plurality of backup archive contexts are further limited by this new limitation. The dependent claims inherit the defect of the independent claims.
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.
Claims 1, 7, 10, 13, 16, 19 and 20 are rejected under 103 as being unpatentable over Kraemer et al. US 20190121978 (hereinafter Kraemer ‘978) in view of Chen US 10210330 (hereinafter Chen ‘330) and Dar et al. US 20240370557 (hereinafter Dar ‘557).
As per claim 1, Kraemer ‘978 discloses a computer implemented method for immutability assurance of backup data based on comprehensive threat detection (para. 0010, “The inventors have recognized and appreciated that the aforementioned improvement(s) in the efficiency of behavioral ransomware detection can be achieved using the following, adaptive technique. Initially, a security engine may monitor a computational entity for behavior associated with encrypting a file, encrypting a storage device, and/or disabling a backup file.”; figs. 3A-C) comprising:
performing static analysis and dynamic analysis of a process executing on the computing device (para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities”; para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event.”; para. 0099-0100, 0122, “In some embodiments, the behavior scoring module 130 may receive a notification from the score increasing module 126 of the heuristics module 120 when one or more of the following score-increasing heuristics triggers (e.g., for a computational entity that has already been assigned a potential ransomware category): [0100] Computational entity modifies multiple files. In some embodiments, the higher the number of files modified by the potential ransomware entity, the greater the increase in the threat score. [0122] Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority.”);
registering an operation of the process with a file on a storage communicatively coupled to the computing device (para. 0059-0061, “Category A: Encrypting files on local, remote (network), or external drives; Category B: Encrypting raw storage device or parts of it (e.g., master boot record (MBR) sector on boot drive, or entire backup drive); and/or, Category C: Disabling system backups. A suspicious computational entity that exhibits behaviors associated with two or ransomware categories may be assigned to all of the corresponding ransomware categories at the same time.”; para. 0075, “A computational entity may be assigned to ransomware Category C if the entity exhibits behaviors associated with disabling a computer system's backup capabilities, including, without limitation, deleting/disabling backup files and/or disabling backup/restore functionality.”; para. 0160, ”Referring to FIG. 3C, a process 233 for handling an event associated with accessing a backup file may include steps 331-335. At step 331, if the event indicates that the CE is attempting to modify the backup capabilities of the computer system (e.g., by disabling the backup functionality, deleting a backup file, modifying a backup file, etc.), the process 233 proceeds from step 331 to step 332. At step 332, the tracking module 110 determines whether the CE is part of a larger computational entity, and if so, links the computational entities. At step 333, the categorization module 122 assigns potential ransomware Category C to the CE.”);
determining that the file is a backup archive including comparing at least one file characteristic to predefined backup format definitions (para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups)”; para. 0087, “Tracking of a computational entity's modifications of files in directories and subdirectories that the entity previously enumerated during discovery stage. [0090] Filtering file modifications based on file location. The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities. For example, events associated with known backup software modifying files on backup store may be filtered out.”; para 0091, “Filtering file modifications based on file location and file type. More weight may be assigned to modification of non-data files on non-local drives (e.g., network drives, external drives, etc.). This method may increase detection sensitivity and reduce data-loss when ransomware attempts to encrypt non-data files on non-local drives. Non-local drives can be particularly vulnerable to ransomware because (1) ransomware can generally encrypt such drives entirely without taking away a mechanism to deliver a ransom message to the user, and (2) network shares and backup drives may be of especially high value to the user.”; fig. 3C, reference no. 331 “Backup modification”);
only upon a successful determination that the file is a backup archive collecting a context of the process, the context including at least a security context based on the static and dynamic analysis, and a backup archive context based on attributes of the backup archive (Examiner’s note: Kraemer ‘978 discloses scoring operations are based on collected event information, which encompass both security context and backup archive context information;
para 0056, “From time to time (e.g., periodically or in response to specific events), the heuristics module 120 may query the behavior tracking module 114 to determine the profile states of a computational entity, and may notify the behavior scoring module 130 when a heuristic that affects a computational entity's category, subcategory, and/or score is triggered (e.g., by a change in the state of the computational entity.”;
para 0064, “In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups), user folders, and several well-known subfolders under the user folders.”
para 0077-78, “Examples of behaviors associated with disabling system backups may include (1) deleting, encrypting, or otherwise modifying backup files, and (2) disabling a computer system's ability to create new backups or restore data and settings from existing backups. In the case of a computational entity that includes a related set of computational units, the effective actor may be determined to derive intent and avoid triggering false positives in legitimate use-cases (e.g., when a user is re-configuring backups). [0078] Since some of these behaviors could be also exhibited by legitimate software, additional heuristic techniques (described below) may be by the categorization module 122 to further increase detection and prevention accuracy and reduce the false positive rate.”;
para 0079, “When a ransomware category is assigned to a computational entity, the behavior scoring module 130 may use scoring heuristics specific to that category to determine an initial threat score for the computational entity. Suitable scoring heuristics for computational entities assigned to ransomware Categories A, B, B1, B2, and/or C are described in further detail below.”;
para. 0099-0100, 0122, “In some embodiments, the behavior scoring module 130 may receive a notification from the score increasing module 126 of the heuristics module 120 when one or more of the following score-increasing heuristics triggers (e.g., for a computational entity that has already been assigned a potential ransomware category): [0100] Computational entity modifies multiple files. In some embodiments, the higher the number of files modified by the potential ransomware entity, the greater the increase in the threat score. [0122] Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority.”);
para. 0052, “The tracking module 110 may monitor events occurring in the computer system and track the behavior of computational entities in the computer system based on the monitored events. A computational entity may be, for example, a thread, a process, an application, or a related set of two or more threads, processes, and/or applications. The tracking module 110 may include an event monitoring module 112, which may monitor low-level events in the computer system. In some embodiments, the event monitoring module 112 tracks events from one or more layers of the operating system (“OS”) of a computer system in real-time, within the context of a computational entity, and analyzes the monitored events. The types of events monitored may include, without limitation: (1) computational unit creation events, (2) script and/or library load events, (3) file input/output (“I/O”) events (e.g., directory read/enumerate; file read, write, create, delete, rename/move; etc.), (4) network events (e.g., create incoming and/or outgoing network connections, etc.), and (5) system calls and/or calls made by a process to an application programming interface (“API”) of the OS. Some examples of API calls that may be monitored include, without limitation, (1) API calls related to searching a filesystem, gathering system information, disabling backups, or mounting a disk partition; (2) API calls characteristic to code injection (e.g., from a malicious actor into ransomware host process); and (3) API calls querying system information.”;
para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities. Each computational entity's threat profile may include data indicating one or more profile states of the computational entity. The behavior tracking module 114 may update a computational entity's threat profile (e.g., update the profile states in the threat profile) based on monitored events associated with the computational entity, thereby mapping the events to corresponding states.”;
para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event. The behavior tracking module 114 may map events to internally tracked states that include additional metadata (e.g., counters and/or timestamps). Such states may be tracked on different levels, for example, (1) per computational entity performing the action, for example, a process enumerating directories, reading and writing files; (2) per unique application identifier (e.g., sha256 file hash), to track behavior of an application across processes, and (3) on system level (e.g., system states impacting or responding to application behavior).”;
para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups)”);
wherein the backup archive context is generated by synthesizing information about how the backup archive is stored, how the backup archive is accessed, and backup data stored from original data in the backup archive (para 0064, “ In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups), user folders, and several well-known subfolders under the user folders. ”; para 0066, “In some embodiments, after a computational entity enumerates a starting point directory, the descendant directories may be recursively monitored for enumeration to establish whether a continuous recursive directory enumeration occurred all the way down to a directory in which a potential file encryption operation is detected.”; para 0075, “A computational entity may be assigned to ransomware Category C if the entity exhibits behaviors associated with disabling a computer system's backup capabilities, including, without limitation, deleting/disabling backup files and/or disabling backup/restore functionality.”; para 0077, “Examples of behaviors associated with disabling system backups may include (1) deleting, encrypting, or otherwise modifying backup files … In the case of a computational entity that includes a related set of computational units, the effective actor may be determined to derive intent and avoid triggering false positives in legitimate use-cases (e.g., when a user is re-configuring backups).”; para 0080, “Category A ransomware may be divided into subcategories based on any suitable criteria, including but not limited to: (1) whether the computational entity encrypts files in-place, out-of-place, or both”; para 0093, “Tracking of file IO operation patterns indicating legitimate applications, to lower the false positive rate. If a computational entity exhibits specific sequences or patterns of file IO operations (e.g., read, create, write, and/or delete), the heuristics module 120 may determine that the entity is non-threatening, and the tracking module 110 may filters out IO operations of such entities.”; para 0095, “For detection and categorization of Class B ransomware, the categorization module 122 may determine the region of the storage device being modified and correlate that region with the storage device type…For a non-boot-type storage device (e.g., a backup device), modification of any portion of the raw device may be suspicious.”; para 0162, “At step 343, the behavioral security engine 100 adds the directory to a set of enumerated directories in the CE's profile state,” para 0167, “At step 358, the tracking module 110 maps attributes of the file and the event (e.g., file type, etc.) to heuristic states);
analyzing the operation with the file using an access control machine-learning model that calculates an immutability rate based on the collected context as an input, wherein the access control machine-learning model is trained on aggregated contexts of a plurality of previously-collected testing process samples, including security contexts and backup archive contexts (para 0056, “In some embodiments, the heuristics module 120 implements processes (e.g., heuristic processes) for assigning threatware categories (e.g., ransomware categories) to computational entities, assigning threatware subcategories (e.g., ransomware subcategories) to computational entities, and/or adjusting threat scores of computational entities.”; para. 0057, “The heuristic module's categorization module 122 may implement categorization heuristics suitable for assigning threat categories to computational entities based on their behavior. In some embodiments, the categorization module 122 may assign a computational entity the threat category that matches (e.g., most closely matches) the computational entity's current set of profile states.”); and
granting the process access to modify the file when the immutability rate is within a predetermined threshold, or blocking the process access to the backup archive when the immutability rate exceeds the predetermined threshold, wherein the predetermined threshold is indicative of a likelihood that the process operation with the file is authorized and does not pose a threat to the integrity of the file (para. 0136, “The policy module 150 may store policy settings retrieved from the configuration module 140. The policy module 150 may receive a notification from the behavior scoring module 130 when an entity's threat score exceeds and associated threshold. In some embodiments, the policy module 150 determines which protection/mitigation action (e.g., terminate, isolate, or log) to perform based on the policy settings and/or the entity's reputation. In some embodiments, the policy module 150 notifies the protection and mitigation module 160 to perform the selected protection/mitigation action”; para. 0137, “The protection and mitigation module 160 may enforce protection and mitigation policies in response to receipt of a corresponding notification from the policy module 150. In some embodiments, the protection and mitigation module 160 has the ability to enforce a policy action by denying completion of a file operation, network operation, and/or process creation operation in-line with the operation being requested. In some embodiments, the protection and mitigation module 160 may communicate with the OS to terminate or isolate a running process.”; para. 0160, “Referring to FIG. 3C, a process 233 for handling an event associated with accessing a backup file may include steps 331-335. … At step 335, the behavioral security engine 100 performs a process 250 for evaluating the CE's threat score and applying a corresponding policy, if any.”).
Kraemer ‘978 further discloses their system identifies different categories of ransomware directed to backup files: category A (para 0062-64: enumerating filesystems within a backup), category B (para 0060: encrypting entire backup drive) and category C (para 0061, disabling system backups). However, Kraemer ‘978 does not disclose, but Chen ‘330 discloses determining that the file is a backup archive including comparing at least one file characteristic to predefined backup format definitions; only upon a successful determination that the file is a backup archive collecting a context of the process (col. 5, lines 33-47, “For example, identification module 104 may be part of a security application that monitors a variety of activity for signs of malware. In other embodiments, identification module 104 may be part of a specialized application that only monitors activity relating to backup files. In some embodiments, identification module 104 may automatically detect backup files based on various characteristics (e.g., file type, location, and/or program created by). In other embodiments, a user may direct identification module 104 to any backup files that the user desires to have monitored. (21) At step 304, one or more of the systems described herein may detect an attempt to alter the backup file by a process that is not the backup process. For example, detection module 106 may, as part of computing device 202 in FIG. 2, detect an attempt to alter backup file 208 by process 212 that is not backup process 210; col. 6, lines 29-38, “Determination module 108 may determine that the process is malicious in a variety of ways. For example, determination module 108 may determine that any process that is not expected to interact with backup files and that attempts to alter a backup file is a malicious process. In other embodiments, determination module 108 may perform further checks on a process before determining the process to be malicious. For example, determination module 108 may check the reputation of the process, determine the origin of the process, and/or analyze previous actions of the process.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack detection method of Kraemer ‘978 by focusing monitoring to activities on file backups as taught by Chen ‘330. One would have been motivated to do so to focus malware detection resources on a computer system’s core capability to restore files.
Kraemer ‘978 does not disclose, but Dar ‘557 discloses analyzing the operation with the file using an access control machine-learning model that calculates an immutability rate based on the collected context as an input, wherein the access control machine-learning model is trained on aggregated contexts of a plurality of previously-collected testing process samples, including security contexts and backup archive contexts (para 0052, “A machine learning model may generally include an algorithm or combination of algorithms that has been trained to recognize certain types of patterns. For example, machine learning approaches may be generally divided into three categories, depending on the nature of the signal available: supervised learning, unsupervised learning, and reinforcement learning. Supervised learning may include presenting a computing device with example inputs and their desired outputs, given by a “teacher”, where the goal is to learn a general rule that maps inputs to outputs.”; para 0054, “ransomware detection process 10 analyzes the stream of input/output (IO) operations issued from the host to the storage system (i.e., dynamic analysis), and also the resulting changes in the data that is stored (i.e., static analysis) to generate IO features. Ransomware detection process 10 uses a supervised machine learning classification model to detect ransomware attacks on storage systems as they are occurring, with high accuracy. In this manner, “real-time” or “near real-time” monitoring means monitoring and detecting ransomware attacks as they are occurring and within the time for processing the plurality of IO requests, generating the plurality of IO features, and processing the plurality of IO features using the machine learning model.”; para. 0055, “As shown in FIG. 4, ransomware detection process 10 monitors 300 for a potential ransomware attack on the storage system in real-time based upon, at least in part, the processing of the plurality of IO features (e.g., IO features 418, 420, 422, 424) using the machine learning model (e.g., machine learning model 426). In some implementations, monitoring 306 for a ransomware attack on the storage system in real-time includes using the plurality of IO features (e.g., IO features 418, 420, 422, 424) to generate a ransomware attack probability score (e.g., ransomware attack probability score 428).”; para 0067, “In some implementations, the storage system may report (e.g., to various computing devices, monitoring systems, etc.) instances of ransomware alert firing, along with detailed ransomware data, and/or feedback, indicating whether the alert was deemed correct (i.e., a true positive) or not (i.e., a false positive). Ransomware detection process 10 may also send a similar report if a user reports on a ransomware attack on the storage system that was not alerted (i.e., a false negative). In some implementations, these reports may be used tune the machine learning model to improve its accuracy.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack detection method of Kraemer ‘978 by using an access control machine learning model as disclosed by Dar ‘557. Because ML model accuracy is generally correlated with larger and more relevant training sets, such a modification would have incorporated the data collected by the tracking module of Kraemer ‘978 to train and to use the trained ML model to detect attacks targeting backup files. One would have been motivated to do so to enable the flexibilities and efficiency of a machine learning model in order to evaluate the threat score of a detected malware. Moreover, such a modification would have been desirable to tailor the supervised learning model to recognize and detect attack patterns as identified by Kraemer ‘978.
As per claim 7, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the method of claim 1 (supra). In addition, Kraemer ‘978 discloses wherein the security context includes at least one of outcomes of antivirus scans, malware detection verdicts, intrusion detection system alerts, firewall logs, vulnerability assessment verdicts, behavior analysis flags, security ratings based on the process actions compared to known threat patterns, or statistical analysis of security events related to the process (para. 0051, “In some embodiments, the behavioral security engine 100 may perform the following actions: (1) the event monitoring module 112 may track low-level events in a computer system; (2) the behavior tracking module 114 may map events to states and track them; (3) the categorization module 122 may assign a threat category (e.g., a ransomware category) to a potential threat and update the threat category as more events in the computer system are tracked; (4) the subcategorization module 124 may assign a threat subcategory (e.g., a ransomware category) to a potential threat and update the threat subcategory as more events in the computer system are tracked….”).
As per claim 10, Kraemer ‘978 discloses a system for immutability assurance of backup data based on comprehensive threat detection (para. 0010, “The inventors have recognized and appreciated that the aforementioned improvement(s) in the efficiency of behavioral ransomware detection can be achieved using the following, adaptive technique. Initially, a security engine may monitor a computational entity for behavior associated with encrypting a file, encrypting a storage device, and/or disabling a backup file.”; figs. 3A-C), the system comprising:
at least one processor; a security module comprising instructions that, when executed on the at least one processor, cause the at least one processor to perform static analysis and dynamic analysis of a process executing on the computing device, providing a comprehensive security assessment of the process prior to and during its operation (para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities. Each computational entity's threat profile may include data indicating one or more profile states of the computational entity. The behavior tracking module 114 may update a computational entity's threat profile (e.g., update the profile states in the threat profile) based on monitored events associated with the computational entity, thereby mapping the events to corresponding states”; para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event.”; para. 0099-0100, 0122, “In some embodiments, the behavior scoring module 130 may receive a notification from the score increasing module 126 of the heuristics module 120 when one or more of the following score-increasing heuristics triggers (e.g., for a computational entity that has already been assigned a potential ransomware category): [0100] Computational entity modifies multiple files. In some embodiments, the higher the number of files modified by the potential ransomware entity, the greater the increase in the threat score. [0122] Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority.”; fig. 5 and related text);
a filter driver, configured to register an operation of the process with a file on a storage communicatively coupled to the computing device (para. 0059-0061, “Category A: Encrypting files on local, remote (network), or external drives; Category B: Encrypting raw storage device or parts of it (e.g., master boot record (MBR) sector on boot drive, or entire backup drive); and/or, Category C: Disabling system backups. A suspicious computational entity that exhibits behaviors associated with two or ransomware categories may be assigned to all of the corresponding ransomware categories at the same time.”; para. 0075, “A computational entity may be assigned to ransomware Category C if the entity exhibits behaviors associated with disabling a computer system's backup capabilities, including, without limitation, deleting/disabling backup files and/or disabling backup/restore functionality.”; para. 0146, “The security engine 100 may notify the data backup and recovery module (which may be embedded within or external to the security engine 100) when to start performing backups of files affected by a potentially malicious application. For example, the security engine 100 can send the notification early, when a sample has been pre-categorized as potentially malicious, but before any data loss occurred. From that point onwards, the data backup and recovery module may monitor file operations performed by the application/process (or process chain). The data backup and recovery module may be capable of stalling the original file I/O operation (operation requested by the monitored application), for example write or delete, creating a copy of each file that the monitored application is preparing to modify or delete, and storing the copies in a backup area. The file backup operation can be implemented either directly in the file-filter driver or in a user-space agent, as long as the original operation is stalled until the file backup is complete.”; para. 0160, ”Referring to FIG. 3C, a process 233 for handling an event associated with accessing a backup file may include steps 331-335. At step 331, if the event indicates that the CE is attempting to modify the backup capabilities of the computer system (e.g., by disabling the backup functionality, deleting a backup file, modifying a backup file, etc.), the process 233 proceeds from step 331 to step 332. At step 332, the tracking module 110 determines whether the CE is part of a larger computational entity, and if so, links the computational entities. At step 333, the categorization module 122 assigns potential ransomware Category C to the CE.”);
a format recognition unit comprising instructions that, when executed on the at least one processor, cause the at least one processor to determine that the file is a backup archive including comparing at least one file characteristic to predefined backup format definitions (para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups),”; para. 0087, “Tracking of a computational entity's modifications of files in directories and subdirectories that the entity previously enumerated during discovery stage. [0090] Filtering file modifications based on file location. The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities. For example, events associated with known backup software modifying files on backup store may be filtered out.”; para 0091, “Filtering file modifications based on file location and file type. More weight may be assigned to modification of non-data files on non-local drives (e.g., network drives, external drives, etc.). This method may increase detection sensitivity and reduce data-loss when ransomware attempts to encrypt non-data files on non-local drives. Non-local drives can be particularly vulnerable to ransomware because (1) ransomware can generally encrypt such drives entirely without taking away a mechanism to deliver a ransom message to the user, and (2) network shares and backup drives may be of especially high value to the user.”; fig. 3C, reference no. 331 “Backup modification”; fig. 5 and related text);
an access control unit (fig. 5 and related text) incorporating an access control machine-learning model, the access control unit comprising instructions that, when executed on the at least one processor, cause the at least one processor to:
only upon a successful determination that the file is a backup archive collect a context of the process, including at least a security context derived from the security module static and dynamic analysis, and a backup archive context based on attributes of the file identified by the format recognition unit, wherein the backup archive context is generated by synthesizing information about how the backup archive is stored, how the backup archive is accessed, and backup data stored from original data in the backup archive (Examiner’s note: Kraemer ‘978 discloses scoring operations are based on collected event information, which encompass both security context and backup archive context information;
para 0056, “From time to time (e.g., periodically or in response to specific events), the heuristics module 120 may query the behavior tracking module 114 to determine the profile states of a computational entity, and may notify the behavior scoring module 130 when a heuristic that affects a computational entity's category, subcategory, and/or score is triggered (e.g., by a change in the state of the computational entity.”;
para 0064, “In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups), user folders, and several well-known subfolders under the user folders.”
para 0077-78, “Examples of behaviors associated with disabling system backups may include (1) deleting, encrypting, or otherwise modifying backup files, and (2) disabling a computer system's ability to create new backups or restore data and settings from existing backups. In the case of a computational entity that includes a related set of computational units, the effective actor may be determined to derive intent and avoid triggering false positives in legitimate use-cases (e.g., when a user is re-configuring backups). [0078] Since some of these behaviors could be also exhibited by legitimate software, additional heuristic techniques (described below) may be by the categorization module 122 to further increase detection and prevention accuracy and reduce the false positive rate.”;
para 0079, “When a ransomware category is assigned to a computational entity, the behavior scoring module 130 may use scoring heuristics specific to that category to determine an initial threat score for the computational entity. Suitable scoring heuristics for computational entities assigned to ransomware Categories A, B, B1, B2, and/or C are described in further detail below.”;
para. 0099-0100, 0122, “In some embodiments, the behavior scoring module 130 may receive a notification from the score increasing module 126 of the heuristics module 120 when one or more of the following score-increasing heuristics triggers (e.g., for a computational entity that has already been assigned a potential ransomware category): [0100] Computational entity modifies multiple files. In some embodiments, the higher the number of files modified by the potential ransomware entity, the greater the increase in the threat score. [0122] Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority.”);
para. 0052, “The tracking module 110 may monitor events occurring in the computer system and track the behavior of computational entities in the computer system based on the monitored events. A computational entity may be, for example, a thread, a process, an application, or a related set of two or more threads, processes, and/or applications. The tracking module 110 may include an event monitoring module 112, which may monitor low-level events in the computer system. In some embodiments, the event monitoring module 112 tracks events from one or more layers of the operating system (“OS”) of a computer system in real-time, within the context of a computational entity, and analyzes the monitored events. The types of events monitored may include, without limitation: (1) computational unit creation events, (2) script and/or library load events, (3) file input/output (“I/O”) events (e.g., directory read/enumerate; file read, write, create, delete, rename/move; etc.), (4) network events (e.g., create incoming and/or outgoing network connections, etc.), and (5) system calls and/or calls made by a process to an application programming interface (“API”) of the OS. Some examples of API calls that may be monitored include, without limitation, (1) API calls related to searching a filesystem, gathering system information, disabling backups, or mounting a disk partition; (2) API calls characteristic to code injection (e.g., from a malicious actor into ransomware host process); and (3) API calls querying system information.”;
para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities. Each computational entity's threat profile may include data indicating one or more profile states of the computational entity. The behavior tracking module 114 may update a computational entity's threat profile (e.g., update the profile states in the threat profile) based on monitored events associated with the computational entity, thereby mapping the events to corresponding states.”;
para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event. The behavior tracking module 114 may map events to internally tracked states that include additional metadata (e.g., counters and/or timestamps). Such states may be tracked on different levels, for example, (1) per computational entity performing the action, for example, a process enumerating directories, reading and writing files; (2) per unique application identifier (e.g., sha256 file hash), to track behavior of an application across processes, and (3) on system level (e.g., system states impacting or responding to application behavior).”;
para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups));
para 0162, “At step 343, the behavioral security engine 100 adds the directory to a set of enumerated directories in the CE's profile state,”
para 0167, “At step 358, the tracking module 110 maps attributes of the file and the event (e.g., file type, etc.) to heuristic states.
analyze the process operation with the file, calculating an immutability rate based on the collected context (para 0056, “In some embodiments, the heuristics module 120 implements processes (e.g., heuristic processes) for assigning threatware categories (e.g., ransomware categories) to computational entities, assigning threatware subcategories (e.g., ransomware subcategories) to computational entities, and/or adjusting threat scores of computational entities.”; para. 0057, “The heuristic module's categorization module 122 may implement categorization heuristics suitable for assigning threat categories to computational entities based on their behavior. In some embodiments, the categorization module 122 may assign a computational entity the threat category that matches (e.g., most closely matches) the computational entity's current set of profile states.”),
grant the process access to modify the file when the immutability rate is within a predetermined threshold, or block the process access to the file when the immutability rate exceeds the predetermined threshold, where the predetermined threshold indicates a likelihood that the process operation with the file is authorized and does not pose a threat to the integrity of the file wherein the access control machine-learning model is trained on aggregated contexts of a plurality of previously-collected testing process samples, including security contexts and backup archive contexts. (para. 0136, “The policy module 150 may store policy settings retrieved from the configuration module 140. The policy module 150 may receive a notification from the behavior scoring module 130 when an entity's threat score exceeds and associated threshold. In some embodiments, the policy module 150 determines which protection/mitigation action (e.g., terminate, isolate, or log) to perform based on the policy settings and/or the entity's reputation. In some embodiments, the policy module 150 notifies the protection and mitigation module 160 to perform the selected protection/mitigation action”; para. 0137, “The protection and mitigation module 160 may enforce protection and mitigation policies in response to receipt of a corresponding notification from the policy module 150. In some embodiments, the protection and mitigation module 160 has the ability to enforce a policy action by denying completion of a file operation, network operation, and/or process creation operation in-line with the operation being requested. In some embodiments, the protection and mitigation module 160 may communicate with the OS to terminate or isolate a running process.”; para. 0160, “Referring to FIG. 3C, a process 233 for handling an event associated with accessing a backup file may include steps 331-335. … At step 335, the behavioral security engine 100 performs a process 250 for evaluating the CE's threat score and applying a corresponding policy, if any.”).
Kraemer ‘978 further discloses their system identifies different categories of ransomware directed to backup files: category A (para 0062-64: enumerating filesystems within a backup), category B (para 0060: encrypting entire backup drive) and category C (para 0061, disabling system backups). However, Kraemer ‘978 does not disclose, but Chen ‘330 discloses determining that the file is a backup archive including comparing at least one file characteristic to predefined backup format definitions; only upon a successful determination that the file is a backup archive collecting a context of the process (col. 5, lines 33-47, “For example, identification module 104 may be part of a security application that monitors a variety of activity for signs of malware. In other embodiments, identification module 104 may be part of a specialized application that only monitors activity relating to backup files. In some embodiments, identification module 104 may automatically detect backup files based on various characteristics (e.g., file type, location, and/or program created by). In other embodiments, a user may direct identification module 104 to any backup files that the user desires to have monitored. (21) At step 304, one or more of the systems described herein may detect an attempt to alter the backup file by a process that is not the backup process. For example, detection module 106 may, as part of computing device 202 in FIG. 2, detect an attempt to alter backup file 208 by process 212 that is not backup process 210; col. 6, lines 29-38, “Determination module 108 may determine that the process is malicious in a variety of ways. For example, determination module 108 may determine that any process that is not expected to interact with backup files and that attempts to alter a backup file is a malicious process. In other embodiments, determination module 108 may perform further checks on a process before determining the process to be malicious. For example, determination module 108 may check the reputation of the process, determine the origin of the process, and/or analyze previous actions of the process.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack detection method of Kraemer ‘978 by focusing monitoring to activities on file backups as taught by Chen ‘330. One would have been motivated to do so to focus malware detection resources on a computer system’s core capability to restore files.
Kraemer ‘978 in view of Chen ‘330 do not disclose, but Dar ‘557 discloses an access control unit incorporating an access control machine-learning model … wherein the access control machine-learning model is trained on aggregated contexts of a plurality of previously-collected testing process samples, including security contexts and backup archive contexts (para 0052, “A machine learning model may generally include an algorithm or combination of algorithms that has been trained to recognize certain types of patterns. For example, machine learning approaches may be generally divided into three categories, depending on the nature of the signal available: supervised learning, unsupervised learning, and reinforcement learning. Supervised learning may include presenting a computing device with example inputs and their desired outputs, given by a “teacher”, where the goal is to learn a general rule that maps inputs to outputs.”; para 0054, “ransomware detection process 10 analyzes the stream of input/output (IO) operations issued from the host to the storage system (i.e., dynamic analysis), and also the resulting changes in the data that is stored (i.e., static analysis) to generate IO features. Ransomware detection process 10 uses a supervised machine learning classification model to detect ransomware attacks on storage systems as they are occurring, with high accuracy. In this manner, “real-time” or “near real-time” monitoring means monitoring and detecting ransomware attacks as they are occurring and within the time for processing the plurality of IO requests, generating the plurality of IO features, and processing the plurality of IO features using the machine learning model.”; para. 0055, “As shown in FIG. 4, ransomware detection process 10 monitors 300 for a potential ransomware attack on the storage system in real-time based upon, at least in part, the processing of the plurality of IO features (e.g., IO features 418, 420, 422, 424) using the machine learning model (e.g., machine learning model 426). In some implementations, monitoring 306 for a ransomware attack on the storage system in real-time includes using the plurality of IO features (e.g., IO features 418, 420, 422, 424) to generate a ransomware attack probability score (e.g., ransomware attack probability score 428).”; para 0067, “In some implementations, the storage system may report (e.g., to various computing devices, monitoring systems, etc.) instances of ransomware alert firing, along with detailed ransomware data, and/or feedback, indicating whether the alert was deemed correct (i.e., a true positive) or not (i.e., a false positive). Ransomware detection process 10 may also send a similar report if a user reports on a ransomware attack on the storage system that was not alerted (i.e., a false negative). In some implementations, these reports may be used tune the machine learning model to improve its accuracy.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack detection method of Kraemer ‘978 by using an access control machine learning model as disclosed by Dar ‘557. Because ML model accuracy is generally correlated with larger and more relevant training sets, such a modification would have incorporated the data collected by the tracking module of Kraemer ‘978 to train and to use the trained ML model to detect attacks targeting backup files. One would have been motivated to do so to enable the flexibilities and efficiency of a machine learning model in order to evaluate the threat score of a detected malware. Moreover, such a modification would have been desirable to tailor the supervised learning model to recognize and detect attack patterns as identified by Kraemer ‘978.
As per claim 13, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 discloses wherein the access control unit with the access control ML model is further configured to profile the process based on a set of process attributes to generate a process profile, thereby integrating the generated process profile into the context of the process (Kraemer ‘978, para. 0020, “The actions of the method may further include assigning at least one potential ransomware subcategory to the computational entity based on the detected instances of the second behaviors.”; para. 0023, “the second behavior includes persistently scheduling the computational entity, creating a network connection, querying the computer system for system information, exhibiting suspicious provenance, obfuscating the computational entity, and/or parallelizing the computational entity”; para. 0080, “After a ransomware category is assigned to a computational entity, the subcategorization module 124 may use subcategorization heuristics specific to the assigned category to further classify potential ransomware into subcategories. These heuristic methods may factor in complexity and uncertainty characteristics to detection of different malicious techniques. For example, Category A ransomware may be divided into subcategories based on any suitable criteria, including but not limited to: (1) whether the computational entity encrypts files in-place, out-of-place, or both, (2) whether the computational entity has multiple computational units or a single computational unit, and (3) whether the computational entity utilizes built-in system utilities”; para. 0081, “When a ransomware subcategory is assigned to a computational entity, the behavior scoring module 130 may use scoring heuristics specific to that subcategory to adjust the threat score for the computational entity”; para. 0122, “Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority”; para. 0130, “In multi-process chain, a method is used to determine if the effective actor in control is part of the operating system. The method uses a combination of file path, verified certificate and file reputation.”; Dar ‘557, para 0054, “ransomware detection process 10 analyzes the stream of input/output (IO) operations issued from the host to the storage system (i.e., dynamic analysis), and also the resulting changes in the data that is stored (i.e., static analysis) to generate IO features. Ransomware detection process 10 uses a supervised machine learning classification model to detect ransomware attacks on storage systems as they are occurring, with high accuracy. In this manner, “real-time” or “near real-time” monitoring means monitoring and detecting ransomware attacks as they are occurring and within the time for processing the plurality of IO requests, generating the plurality of IO features, and processing the plurality of IO features using the machine learning model.”).
As per claim 16, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). In addition, Kraemer ‘978 discloses wherein the security context includes at least one of outcomes of antivirus scans, malware detection verdicts, intrusion detection system alerts, firewall logs, vulnerability assessment verdicts, behavior analysis flags, security ratings based on the process actions compared to known threat patterns, or statistical analysis of security events related to the process (para. 0051, “In some embodiments, the behavioral security engine 100 may perform the following actions: (1) the event monitoring module 112 may track low-level events in a computer system; (2) the behavior tracking module 114 may map events to states and track them; (3) the categorization module 122 may assign a threat category (e.g., a ransomware category) to a potential threat and update the threat category as more events in the computer system are tracked; (4) the subcategorization module 124 may assign a threat subcategory (e.g., a ransomware category) to a potential threat and update the threat subcategory as more events in the computer system are tracked….”).
Claims 19 and 20 are access control device claims that correspond to the system claims 10 and 13. Therefore, claims 19 and 20 are rejected over Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 for the same reasons as claims 10 and 13.
Claims 3 and 12 are rejected under 103 as being unpatentable over Kraemer ‘978 in view of Chen ‘330 and Dar ’557, and further in view of Shachar US20220358215 (hereinafter Shachar ‘215) and Ezrielev et al. US20240330461 (hereinafter Ezrielev ‘461).
As per claim 3, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the method of claim 1 (supra). Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Shachar ‘215 discloses the method further comprising labeling data within the file in accordance with backup archive structure and content type, wherein the labeling includes assigning a criticality level to the data, wherein labeled data is a part of the backup archive context (para. 0045, “Additionally, the backup server 105 and/or the backup device 130 can have an associated backup metadata database 106 configured to store metadata for each stored backup file, such as a signature, a digest value, a fingerprint and/or a hash value (e.g., a 20-byte SHA-1) of the corresponding stored backup file, and/or indexing information that relates to or describes the corresponding stored backup file in one example. Although the backup metadata database 106 is shown in FIG. 1 as a separate component, in other embodiments, an additional or alternative instance of the backup metadata database 106, or portions thereof, may be incorporated into the backup server 105 and/or the backup device 130. The indexing information may describe the content of the corresponding stored backup file. The indexing information may describe or identify each corresponding stored backup file (e.g., file name, size, type), a location of each corresponding stored backup file (e.g., on the client and/or in the storage of the data backup device 130), a timestamp, a path name, a client name or identifier, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 by incorporating the additional backup archive labeled data as disclosed by Shachar ‘215. One would have been motivated to do so in order to detect anomalous stored backup files. Shachar ‘215, para. 0046.
Kraemer ‘978 in view of Chen ‘330, Dar ‘557 and Shachar ‘215 do not disclose, but Ezrielev ‘461 discloses wherein the labeling includes assigning a criticality level to the data (para. 0037, “The process of detecting malware based on detecting system call patterns can be further enhanced by tracking and maintaining the estimated value of the files. A computing system may associate each file with a type. For example, if the system believes that malware would target a first file and not target a second file, the first file may be labeled as valuable and the second file is labeled as not valuable or is not labeled. In one example, these labels or types are generated in advance such that the labels exist before the malware beings to operate. This allows a process to be evaluated in the context of file types being accessed with system calls. When a process is associated with performing a pattern of system calls to a specific type of file (e.g., the valuable files), the score may be increased more quickly or in larger amounts. This allows the processes to be tracked with respect to files even in the event that the process deviates from the pattern and performs other system calls such as rename operations.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 by incorporating labeled data that describes a criticality level as disclosed by Ezrielev ‘461. One would have been motivated to do so in order to better track a malicious process even though it may deviate from a previously recognized pattern. Ezrielev ‘461, para. 0037.
As per claim 12, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Shachar ‘215 discloses the format recognition unit is further configured to label data within the file in accordance with backup archive structure and content type, assigning a criticality level to the data as part of the backup archive context (para. 0045, “Additionally, the backup server 105 and/or the backup device 130 can have an associated backup metadata database 106 configured to store metadata for each stored backup file, such as a signature, a digest value, a fingerprint and/or a hash value (e.g., a 20-byte SHA-1) of the corresponding stored backup file, and/or indexing information that relates to or describes the corresponding stored backup file in one example. Although the backup metadata database 106 is shown in FIG. 1 as a separate component, in other embodiments, an additional or alternative instance of the backup metadata database 106, or portions thereof, may be incorporated into the backup server 105 and/or the backup device 130. The indexing information may describe the content of the corresponding stored backup file. The indexing information may describe or identify each corresponding stored backup file (e.g., file name, size, type), a location of each corresponding stored backup file (e.g., on the client and/or in the storage of the data backup device 130), a timestamp, a path name, a client name or identifier, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention system of Kraemer ‘978 by incorporating the additional backup archive labeled data as disclosed by Shachar ‘215. One would have been motivated to do so in order to detect anomalous stored backup files. Shachar ‘215, para. 0046.
Kraemer ‘978 in view of Chen ‘330, Dar ‘557 and Shachar ‘215 do not disclose, but Ezrielev ‘461 discloses assigning a criticality level to the data (para. 0037, “The process of detecting malware based on detecting system call patterns can be further enhanced by tracking and maintaining the estimated value of the files. A computing system may associate each file with a type. For example, if the system believes that malware would target a first file and not target a second file, the first file may be labeled as valuable and the second file is labeled as not valuable or is not labeled. In one example, these labels or types are generated in advance such that the labels exist before the malware beings to operate. This allows a process to be evaluated in the context of file types being accessed with system calls. When a process is associated with performing a pattern of system calls to a specific type of file (e.g., the valuable files), the score may be increased more quickly or in larger amounts. This allows the processes to be tracked with respect to files even in the event that the process deviates from the pattern and performs other system calls such as rename operations.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention system of Kraemer ‘978 by incorporating labeled data that describes a criticality level as disclosed by Ezrielev ‘461. One would have been motivated to do so in order to better track a malicious process even though it may deviate from a previously recognized pattern. Ezrielev ‘461, para. 0037.
Claims 4-6, 14 and 15 are rejected under 103 as being unpatentable over Kraemer ‘978 in view of Chen ‘330 and Dar ’557, and further in view of Cai et al. US20220067146 (hereinafter Cai ‘146).
As per claim 4, Kraemer ‘978 in view of Chen, ‘330 and Dar ‘557 disclose the method of claim 1 (supra). In addition, Kraemer ‘978 discloses the method further comprising profiling the process based on a set of process attributes to generate a process profile, including a process digital certificate, historical behavior, resource usage, and network activity, wherein the generated process profile is integrated into the context of the process, wherein the access control machine-learning model is further configured to calculate the immutability rate based on the process profile. (Kraemer ‘978, para. 0020, “The actions of the method may further include assigning at least one potential ransomware subcategory to the computational entity based on the detected instances of the second behaviors.”; para 0021, “The actions of the method may further include assigning a score to the computational entity based on the assigned potential ransomware category, the assigned potential ransomware subcategory, and/or the detected instances of the second behaviors.”; para. 0023, “the second behavior includes persistently scheduling the computational entity, creating a network connection, querying the computer system for system information, exhibiting suspicious provenance, obfuscating the computational entity, and/or parallelizing the computational entity”; para. 0080, “After a ransomware category is assigned to a computational entity, the subcategorization module 124 may use subcategorization heuristics specific to the assigned category to further classify potential ransomware into subcategories. These heuristic methods may factor in complexity and uncertainty characteristics to detection of different malicious techniques. For example, Category A ransomware may be divided into subcategories based on any suitable criteria, including but not limited to: (1) whether the computational entity encrypts files in-place, out-of-place, or both, (2) whether the computational entity has multiple computational units or a single computational unit, and (3) whether the computational entity utilizes built-in system utilities”; para. 0081, “When a ransomware subcategory is assigned to a computational entity, the behavior scoring module 130 may use scoring heuristics specific to that subcategory to adjust the threat score for the computational entity”; para. 0122, “Application reputation: applications that are not yet widely known and appear to be potential 0-day attacks, or applications that are not signed by a trusted and verified authority”; para. 0130, “In multi-process chain, a method is used to determine if the effective actor in control is part of the operating system. The method uses a combination of file path, verified certificate and file reputation.”).
Furthermore, Dar ‘557 discloses wherein the access control machine-learning model is further configured to calculate the immutability rate based on the process profile (para 0054, “ransomware detection process 10 analyzes the stream of input/output (IO) operations issued from the host to the storage system (i.e., dynamic analysis), and also the resulting changes in the data that is stored (i.e., static analysis) to generate IO features. Ransomware detection process 10 uses a supervised machine learning classification model to detect ransomware attacks on storage systems as they are occurring, with high accuracy. In this manner, “real-time” or “near real-time” monitoring means monitoring and detecting ransomware attacks as they are occurring and within the time for processing the plurality of IO requests, generating the plurality of IO features, and processing the plurality of IO features using the machine learning model.”; para. 0055, “As shown in FIG. 4, ransomware detection process 10 monitors 300 for a potential ransomware attack on the storage system in real-time based upon, at least in part, the processing of the plurality of IO features (e.g., IO features 418, 420, 422, 424) using the machine learning model (e.g., machine learning model 426). In some implementations, monitoring 306 for a ransomware attack on the storage system in real-time includes using the plurality of IO features (e.g., IO features 418, 420, 422, 424) to generate a ransomware attack probability score (e.g., ransomware attack probability score 428).”; para 0067, “In some implementations, the storage system may report (e.g., to various computing devices, monitoring systems, etc.) instances of ransomware alert firing, along with detailed ransomware data, and/or feedback, indicating whether the alert was deemed correct (i.e., a true positive) or not (i.e., a false positive). Ransomware detection process 10 may also send a similar report if a user reports on a ransomware attack on the storage system that was not alerted (i.e., a false negative). In some implementations, these reports may be used tune the machine learning model to improve its accuracy.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Cai ‘146 discloses wherein the access control machine-learning model is further configured to calculate the immutability rate based on the process profile (para. 0048, “As shown in FIG. 4, a set of pre-classified data samples 402, which includes pre-classified (known) benign files and malicious files, are fed to a parser 404. The parser 404 extracts static features from these data samples 402 and creates feature vectors, which are fed to the machine learning model 406, also referred to as a machine learning based pre-filter. The machine learning model 406 it trained based on these feature vectors associated with pre-classified data samples 402. In an embodiment, once trained the machine learning model 406 may receive a file 408, from a network device, extract static attributes of the file 408, create feature vector and predict whether the file is benign 410 or malware 412.”; para. 0058, “At blocks 708, the machine learning model classifies the file as benign or malware based on the feature vector by applying the trained machine learning model.”; para. 0059, “At block 710, if the file is classified as benign or as malware with a sufficient level of confidence, for example, satisfying a predetermined or configurable confidence score, then the file can be handled in accordance with the classification”; fig. 7, references nos. 714 and 716 [ML model trained based on feedback from sandbox of behaviors of executable file under test]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the machine learning model of the cyberattack prevention method of Kraemer ‘978 in view of Dar ‘557 such that the threat/attack probability scores are based on the distinct process profiles as taught by Cai ‘146. One would have been motivated to do so to fine tune the detection capabilities of the machine learning model based on the unique characteristics of benign files and malware.
As per claim 5, Kraemer ‘978 in view of Chen ‘330, Dar ‘557, and Cai ‘146 disclose the method of claim 4 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose wherein the access control machine-learning model is trained for each distinct process profile, and upon profiling a process, the specifically trained model for that profile is chosen to calculate the immutability rate such that each immutability rate is profile-specific and reflects unique attributes and historical behaviors of each process (Kraemer ‘978, para 0021, “The actions of the method may further include assigning a score to the computational entity based on the assigned potential ransomware category, the assigned potential ransomware subcategory, and/or the detected instances of the second behaviors.”; Dar ‘557, para. 0050, “In some implementations, ransomware detection process 10 generates 310 the plurality of IO features by extracting salient data elements (e.g., one or more IO properties) such as volume ID, timestamp, IO command type (e.g. read, write, unmap, etc.), logical block address (LBA) (i.e., an offset in the data path's thin address space), length, pattern (e.g., sequential, random, caterpillar, IO-stride), etc. from the plurality of IO requests.“; para. 0052, “In some implementations, ransomware detection process 10 processes the plurality of IO features using a machine learning model. A machine learning model may generally include an algorithm or combination of algorithms that has been trained to recognize certain types of patterns; para. 0055, “As shown in FIG. 4, ransomware detection process 10 monitors 300 for a potential ransomware attack on the storage system in real-time based upon, at least in part, the processing of the plurality of IO features (e.g., IO features 418, 420, 422, 424) using the machine learning model (e.g., machine learning model 426). In some implementations, monitoring 306 for a ransomware attack on the storage system in real-time includes using the plurality of IO features (e.g., IO features 418, 420, 422, 424) to generate a ransomware attack probability score (e.g., ransomware attack probability score 428). In some implementations, ransomware attack probability score 428 is a score ranging from zero to one indicating a probability that a ransomware attack is occurring involving the storage object. In some implementations, ransomware detection process 10 uses ransomware attack probability score 428 to distinguish normal IO request workloads from potential ransomware attacks.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Cai ‘146 discloses the access control machine-learning model is trained for each distinct process profile (para. 0048, “As shown in FIG. 4, a set of pre-classified data samples 402, which includes pre-classified (known) benign files and malicious files, are fed to a parser 404. The parser 404 extracts static features from these data samples 402 and creates feature vectors, which are fed to the machine learning model 406, also referred to as a machine learning based pre-filter. The machine learning model 406 it trained based on these feature vectors associated with pre-classified data samples 402. In an embodiment, once trained the machine learning model 406 may receive a file 408, from a network device, extract static attributes of the file 408, create feature vector and predict whether the file is benign 410 or malware 412.”; fig. 7, references nos. 714 and 716 [ML model trained based on feedback from sandbox of behaviors of executable file under test]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the machine learning model of the cyberattack prevention method of Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 by training the model with distinct process profiles as taught by Cai ‘146. One would have been motivated to do so to fine tune the detection capabilities of the machine learning model based on the unique characteristics of benign files and malware.
As per claim 6, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the method of claim 1 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose wherein performing static and dynamic analysis of a process includes examining executable code of the process before the executable code runs to identify known malicious patterns or vulnerabilities, and observing the behavior of the process in real-time as the process interacts with system resources, network connections, and other processes to detect malicious activities (Kraemer ‘978, para. 0052, “The tracking module 110 may monitor events occurring in the computer system and track the behavior of computational entities in the computer system based on the monitored events. A computational entity may be, for example, a thread, a process, an application, or a related set of two or more threads, processes, and/or applications. The tracking module 110 may include an event monitoring module 112, which may monitor low-level events in the computer system. In some embodiments, the event monitoring module 112 tracks events from one or more layers of the operating system (“OS”) of a computer system in real-time, within the context of a computational entity, and analyzes the monitored events. The types of events monitored may include, without limitation: (1) computational unit creation events, (2) script and/or library load events, (3) file input/output (“I/O”) events (e.g., directory read/enumerate; file read, write, create, delete, rename/move; etc.), (4) network events (e.g., create incoming and/or outgoing network connections, etc.), and (5) system calls and/or calls made by a process to an application programming interface (“API”) of the OS. Some examples of API calls that may be monitored include, without limitation, (1) API calls related to searching a filesystem, gathering system information, disabling backups, or mounting a disk partition; (2) API calls characteristic to code injection (e.g., from a malicious actor into ransomware host process); and (3) API calls querying system information.”; para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities”; para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Cai ‘146 discloses wherein performing static and dynamic analysis of a process includes examining executable code of the process before the executable code runs to identify known malicious patterns or vulnerabilities (para. 0039, “The network device 202 includes a machine-learning model training module 210 configured to received training samples (also referred interchangeably as files) classified as clean and malicious, and train a machine-learning model for classifying a new file into either benign or malicious. The machine-learning model training module 210 may use static features of pre-classified samples for training the machine-learning model. Non-limiting examples of static features include the size of the file, entropy of the file, a certificate associated with the file, API functions imported by the file, an icon present within the file, a .NET header of the file, version information associated with the file, registry keys, import tables, packing methods used by samples, programming languages used, version and type of linker used, presence of byte streams used by common libraries for encryption of files, compilation time of the sample, suspicious printable characters in byte stream, a number of imported API calls, number of data directories used, number of imported libraries, largest length of consecutive American Standard Code for Information Interchange (ASCII) characters, largest length of Hexadecimal (HEX) bytes, and length of copyright field.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 such that the static analysis of a process includes examining executable code associated with the process as taught by Cai ‘146. One would have been motivated to do so in order to fine tune the detection capabilities of the learning model based on the unique features of benign files and malware.
As per claim 14, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 13 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose wherein the access control ML model within the access control unit is specifically trained for each distinct process profile such that each immutability rate is profile-specific that reflects unique attributes and historical behaviors of each process. (Kraemer ‘978, para 0021, “The actions of the method may further include assigning a score to the computational entity based on the assigned potential ransomware category, the assigned potential ransomware subcategory, and/or the detected instances of the second behaviors.”; Dar ‘557, para. 0050, “In some implementations, ransomware detection process 10 generates 310 the plurality of IO features by extracting salient data elements (e.g., one or more IO properties) such as volume ID, timestamp, IO command type (e.g. read, write, unmap, etc.), logical block address (LBA) (i.e., an offset in the data path's thin address space), length, pattern (e.g., sequential, random, caterpillar, IO-stride), etc. from the plurality of IO requests.“; para. 0052, “In some implementations, ransomware detection process 10 processes the plurality of IO features using a machine learning model. A machine learning model may generally include an algorithm or combination of algorithms that has been trained to recognize certain types of patterns; para. 0055, “As shown in FIG. 4, ransomware detection process 10 monitors 300 for a potential ransomware attack on the storage system in real-time based upon, at least in part, the processing of the plurality of IO features (e.g., IO features 418, 420, 422, 424) using the machine learning model (e.g., machine learning model 426). In some implementations, monitoring 306 for a ransomware attack on the storage system in real-time includes using the plurality of IO features (e.g., IO features 418, 420, 422, 424) to generate a ransomware attack probability score (e.g., ransomware attack probability score 428). In some implementations, ransomware attack probability score 428 is a score ranging from zero to one indicating a probability that a ransomware attack is occurring involving the storage object. In some implementations, ransomware detection process 10 uses ransomware attack probability score 428 to distinguish normal IO request workloads from potential ransomware attacks.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Cai ‘146 discloses the access control machine-learning model is specifically trained for each distinct process profile (para. 0048, “As shown in FIG. 4, a set of pre-classified data samples 402, which includes pre-classified (known) benign files and malicious files, are fed to a parser 404. The parser 404 extracts static features from these data samples 402 and creates feature vectors, which are fed to the machine learning model 406, also referred to as a machine learning based pre-filter. The machine learning model 406 it trained based on these feature vectors associated with pre-classified data samples 402. In an embodiment, once trained the machine learning model 406 may receive a file 408, from a network device, extract static attributes of the file 408, create feature vector and predict whether the file is benign 410 or malware 412.”; fig. 7, references nos. 714 and 716 [ML model trained based on feedback from sandbox of behaviors of executable file under test]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the machine learning model of the cyberattack prevention system of Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 by training the model with distinct process profiles as taught by Cai ‘146. One would have been motivated to do so to fine tune the detection capabilities of the machine learning model based on the unique characteristics of benign files and malware.
As per claim 15, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose wherein the security module is further configured to perform static analysis by examining the executable code of the process before the executable code runs to identify known malicious patterns or vulnerabilities, and dynamic analysis by observing the behavior of the process in real-time as the process interacts with system resources, network connections, and other processes to detect any malicious activities (Kraemer ‘978, para. 0052, “The tracking module 110 may monitor events occurring in the computer system and track the behavior of computational entities in the computer system based on the monitored events. A computational entity may be, for example, a thread, a process, an application, or a related set of two or more threads, processes, and/or applications. The tracking module 110 may include an event monitoring module 112, which may monitor low-level events in the computer system. In some embodiments, the event monitoring module 112 tracks events from one or more layers of the operating system (“OS”) of a computer system in real-time, within the context of a computational entity, and analyzes the monitored events. The types of events monitored may include, without limitation: (1) computational unit creation events, (2) script and/or library load events, (3) file input/output (“I/O”) events (e.g., directory read/enumerate; file read, write, create, delete, rename/move; etc.), (4) network events (e.g., create incoming and/or outgoing network connections, etc.), and (5) system calls and/or calls made by a process to an application programming interface (“API”) of the OS. Some examples of API calls that may be monitored include, without limitation, (1) API calls related to searching a filesystem, gathering system information, disabling backups, or mounting a disk partition; (2) API calls characteristic to code injection (e.g., from a malicious actor into ransomware host process); and (3) API calls querying system information.”; para. 0053, “The tracking module 110 may also include a behavior tracking module 114, which may receive data relating to monitored events from the event monitoring module 112. The behavior tracking module 114 may track the behavior of computational entities and maintain threat profiles for the computational entities”; para. 0054, “In some embodiments, the behavior tracking module 114 augments data corresponding to tracked events with additional static and/or dynamic information including, without limitation, context details and/or state information associated with the event.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Cai ‘146 discloses wherein performing static analysis by examining the executable code of the process before the executable code runs to identify known malicious patterns or vulnerabilities (para. 0039, “The network device 202 includes a machine-learning model training module 210 configured to received training samples (also referred interchangeably as files) classified as clean and malicious, and train a machine-learning model for classifying a new file into either benign or malicious. The machine-learning model training module 210 may use static features of pre-classified samples for training the machine-learning model. Non-limiting examples of static features include the size of the file, entropy of the file, a certificate associated with the file, API functions imported by the file, an icon present within the file, a .NET header of the file, version information associated with the file, registry keys, import tables, packing methods used by samples, programming languages used, version and type of linker used, presence of byte streams used by common libraries for encryption of files, compilation time of the sample, suspicious printable characters in byte stream, a number of imported API calls, number of data directories used, number of imported libraries, largest length of consecutive American Standard Code for Information Interchange (ASCII) characters, largest length of Hexadecimal (HEX) bytes, and length of copyright field.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention system of Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 such that the static analysis of a process includes examining executable code associated with the process as taught by Cai ‘146. One would have been motivated to do so in order to fine tune the detection capabilities of the learning model based on the unique features of benign files and malware.
Claims 8 and 17 are rejected under 103 as being unpatentable over Kraemer ‘978 in view of Chen ‘330 and Dar ’557, and further in view of Yadav et al. US20230333937 (hereinafter Yadav ‘937).
As per claim 8, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the method of claim 1 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 discloses wherein determining that the file corresponds to a backup archive includes identifying the file as part of a full-backup archive, an incremental backup archive, a local backup, or a cloud backup (Kraemer ‘978, para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups), user folders, and several well-known subfolders under the user folders.”; para. 0091, “Filtering file modifications based on file location and file type. More weight may be assigned to modification of non-data files on non-local drives (e.g., network drives, external drives, etc.). This method may increase detection sensitivity and reduce data-loss when ransomware attempts to encrypt non-data files on non-local drives. Non-local drives can be particularly vulnerable to ransomware because (1) ransomware can generally encrypt such drives entirely without taking away a mechanism to deliver a ransom message to the user, and (2) network shares and backup drives may be of especially high value to the user.”; para. 189, “In some examples, some or all of the data described above can be stored on a personal computing device, in data storage hosted on one or more centralized computing devices, or via cloud-based storage. In some examples, some data are stored in one location and other data are stored in another location.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Yadav ‘937 discloses wherein determining that the file corresponds to a backup archive includes identifying the file as part of a full-backup archive, an incremental backup archive (para. 0064, “Based on the identification or other characteristics of the file or folder can determine whether a file is to be backed-up or skipped. Other details of the files and/or folders can be determined which will be written to the backup's meta-data and/or a separate file such as the skipped files meta-data, which will be discussed in more detail with regards to steps 304 and 306.”; para. 0072, “In one or more embodiments of the invention, the backup agent generates a backup, including meta-data associated with the backup, using the multiple change lists, and stores the backup and the historical meta-data in a backup storage of the backup storages. The backup can take the form of a full back up or an incremental backup. When performing the backup, the backup agent can use previous skipped files meta-data to determine files to try to include in the incremental backup. Other resources can be used for performing the backup such as backup meta-data and file system meta-data.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 such that the file is identified as part of a full backup archive or an incremental backup archive as disclosed by Yadav ‘937. One would have been motivated to do so to determine the type of backup and to identify gaps in data protection for the corresponding backup type. Yadav ‘937, para. 0014 and 0087.
As per claim 17, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). In addition, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 discloses wherein the format recognition unit is configured to identify the file as part of a full-backup archive, an incremental backup archive, a local backup, or a cloud backup (Kraemer ‘978, para. 0064, “Heuristics for detecting enumeration of a storage device (e.g., disk) or directory may take advantage of the observation that ransomware generally has a starting point during a search to locate data files. The starting point generally includes, but is not limited to, well-known top-level directories (e.g., the driver letter root, user folder, user's documents and desktop, etc.). In some embodiments, several top level directories on the endpoint device are monitored for enumeration, including the root of each mount point (internal, external drives, network shares, backups), user folders, and several well-known subfolders under the user folders.”; para. 0091, “Filtering file modifications based on file location and file type. More weight may be assigned to modification of non-data files on non-local drives (e.g., network drives, external drives, etc.). This method may increase detection sensitivity and reduce data-loss when ransomware attempts to encrypt non-data files on non-local drives. Non-local drives can be particularly vulnerable to ransomware because (1) ransomware can generally encrypt such drives entirely without taking away a mechanism to deliver a ransom message to the user, and (2) network shares and backup drives may be of especially high value to the user.”; para. 189, “In some examples, some or all of the data described above can be stored on a personal computing device, in data storage hosted on one or more centralized computing devices, or via cloud-based storage. In some examples, some data are stored in one location and other data are stored in another location.”).
Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Yadav ‘937 discloses wherein determining that the file corresponds to a backup archive includes identifying the file as part of a full-backup archive, an incremental backup archive (para. 0064, “Based on the identification or other characteristics of the file or folder can determine whether a file is to be backed-up or skipped. Other details of the files and/or folders can be determined which will be written to the backup's meta-data and/or a separate file such as the skipped files meta-data, which will be discussed in more detail with regards to steps 304 and 306.”; para. 0072, “In one or more embodiments of the invention, the backup agent generates a backup, including meta-data associated with the backup, using the multiple change lists, and stores the backup and the historical meta-data in a backup storage of the backup storages. The backup can take the form of a full back up or an incremental backup. When performing the backup, the backup agent can use previous skipped files meta-data to determine files to try to include in the incremental backup. Other resources can be used for performing the backup such as backup meta-data and file system meta-data.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 such that the file is identified as part of a full backup archive or an incremental backup archive as disclosed by Yadav ‘937. One would have been motivated to do so to determine the type of backup and to identify gaps in data protection for the corresponding backup type. Yadav ‘937, para. 0014 and 0087. Yadav ‘937, para. 0014 and 0087.
Claims 9 and 18 are rejected under 103 as being unpatentable over Kraemer ‘978 in view of Chen ‘330 and Dar ’557, and further in view of Shachar ‘215.
As per claim 9, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the method of claim 1 (supra). Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Shachar ‘215 discloses wherein the backup archive context includes at least one of backup type, backup metadata, content data, indexing data, or integrity verification data (para. 0045, “Additionally, the backup server 105 and/or the backup device 130 can have an associated backup metadata database 106 configured to store metadata for each stored backup file, such as a signature, a digest value, a fingerprint and/or a hash value (e.g., a 20-byte SHA-1) of the corresponding stored backup file, and/or indexing information that relates to or describes the corresponding stored backup file in one example. Although the backup metadata database 106 is shown in FIG. 1 as a separate component, in other embodiments, an additional or alternative instance of the backup metadata database 106, or portions thereof, may be incorporated into the backup server 105 and/or the backup device 130. The indexing information may describe the content of the corresponding stored backup file. The indexing information may describe or identify each corresponding stored backup file (e.g., file name, size, type), a location of each corresponding stored backup file (e.g., on the client and/or in the storage of the data backup device 130), a timestamp, a path name, a client name or identifier, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention method of Kraemer ‘978 by incorporating the additional backup archive context information of stored backup files as disclosed by Shachar ‘215. One would have been motivated to do so in order to detect anomalous stored backup files. Shachar ‘215, para. 0046.
As per claim 18, Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 disclose the system of claim 10 (supra). Kraemer ‘978 in view of Chen ‘330 and Dar ‘557 do not disclose, but Shachar ‘215 discloses wherein the backup archive context includes at least one of backup type, backup metadata, content data, indexing data, or integrity verification data (para. 0045, “Additionally, the backup server 105 and/or the backup device 130 can have an associated backup metadata database 106 configured to store metadata for each stored backup file, such as a signature, a digest value, a fingerprint and/or a hash value (e.g., a 20-byte SHA-1) of the corresponding stored backup file, and/or indexing information that relates to or describes the corresponding stored backup file in one example. Although the backup metadata database 106 is shown in FIG. 1 as a separate component, in other embodiments, an additional or alternative instance of the backup metadata database 106, or portions thereof, may be incorporated into the backup server 105 and/or the backup device 130. The indexing information may describe the content of the corresponding stored backup file. The indexing information may describe or identify each corresponding stored backup file (e.g., file name, size, type), a location of each corresponding stored backup file (e.g., on the client and/or in the storage of the data backup device 130), a timestamp, a path name, a client name or identifier, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the cyberattack prevention system of Kraemer ‘978 by incorporating the additional backup archive context information of stored backup files as disclosed by Shachar ‘215. One would have been motivated to do so in order to detect anomalous stored backup files. Shachar ‘215, para. 0046.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNG W KIM whose telephone number is (571)272-3804. The examiner can normally be reached Monday-Friday, 10 a.m. - 6 p.m..
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, Amy Cohen Johnson can be reached at 571-272-2238. 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.
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
Prosecution Insights