Dynamic adaptation of backup policy schemes based on threat confidence

Abstract

The invention discloses a data backup method and device. A first backup of a computing system is generated at a first time. A first damage level confidence of the computing system for the first time is generated. The first backup is stored with metadata, wherein the metadata includes a first impairment level confidence of the computing system at a first time. In response to evaluating the first impairment level confidence based on one or more backup criteria, a backup policy of the computing system is modified.

Description

Background Technology

[0001] This disclosure relates to computing system data backup, and more specifically, to dynamically adjusting computing system data backup strategies based on threat confidence.

[0002] Conventional data backup systems typically operate based on fixed schedules or specific criteria that trigger their actions. For example, time-based backups are performed according to a fixed schedule and, depending on the requirements of the computing system, initiate backup processes at regular intervals such as daily, weekly, or even hourly. In contrast, event-based backup systems initiate their processes in response to specific events or modifications within the system, such as significant modifications to existing files, a large influx of new data exceeding a predetermined threshold, or the installation of a new software application.

[0003] Despite their respective advantages, both types of systems operate within a rigid framework. In other words, conventional backup systems do not adjust their behavior in response to changes in the system's security environment or potential threats. They operate without considering the system's security status or potential threats, which can lead to backups including compromised data, or uncompromised data being overwritten by compromised data. Given the dynamic and evolving nature of cybersecurity threats, it is becoming increasingly important to develop more responsive and adaptive backup strategies that can dynamically adjust their backup tactics in response to detected potential security threats and vulnerabilities. Summary of the Invention

[0004] One embodiment presented in this disclosure provides a method comprising: generating a first backup of a computing system at a first time; generating a first damage level confidence score for the computing system at the first time; storing the first backup along with metadata including the first damage level confidence score for the computing system at the first time; and modifying a backup strategy for the computing system in response to evaluating the first damage level confidence score based on one or more dynamic backup strategy criteria. One advantage provided by this embodiment is more efficient and security-focused data backup and synchronization.

[0005] In another embodiment, one or more of the following features may be included. The method may further include: storing a first backup and a second backup for forensic analysis when a first damage level confidence level is determined to satisfy one or more dynamic backup strategy criteria, wherein the second backup corresponds to the backup immediately preceding the first backup. The provided embodiments facilitate more efficient identification of potential security risks and also enable detailed forensic analysis using the stored backups.

[0006] In another embodiment, one or more of the following features may be included. The method may also include: retaining a first backup of the data when the confidence level of a first damage level is determined to be the lowest among existing backups of the computing system. The provided embodiments optimize backup storage space and reduce the risk of data loss by retaining backups with relatively low confidence levels of damage levels. In another embodiment, one or more of the following features may be included. The method may also include: notifying one or more other computing systems of the modified backup policy and evaluation results, wherein the one or more other computing systems are in the same cluster system as the computing system, and each of the one or more other computing systems, upon receiving the notification, uses metadata indicating the modified backup policy and evaluation results to tag at least one corresponding backup, and may adjust the frequency of backups in response to the modified backup policy and evaluation results. By sharing evaluation results or changes in backup policies with other computing systems within the network, the provided embodiments enable other systems to respond quickly to potential security risks, thereby enhancing overall network security. Furthermore, in another embodiment, the method may also include: notifying one or more other computing systems of the modified backup policy and evaluation results, wherein the one or more other computing systems share access to data stored in one or more backup sets with the computing system.

[0007] Another embodiment presented in this disclosure provides a method comprising: generating a first backup of a computing system at a first time; generating a first damage level confidence level for the computing system at the first time; storing the first backup together with metadata including the first damage level confidence level of the computing system at the first time; generating a second backup of the computing system at a second time, wherein the second backup is a backup immediately preceding the first backup; storing the second backup together with metadata including a second damage level confidence level of the computing system at the second time; comparing an increase from the second damage level confidence level to the first damage level confidence level with one or more significance criteria; and modifying a backup strategy for the computing system in response to the comparison results. One advantage provided by this embodiment is the ability to monitor dynamic changes in security confidence levels to proactively identify and flag potential risks in the backed-up data and system.

[0008] Other embodiments of this disclosure provide a non-transient computer-readable medium containing computer program code that, when executed by the operation of one or more computer processors, performs operations according to one or more of the methods described above. Other embodiments of this disclosure provide a system including one or more computer processors and one or more memories containing one or more programs that, when executed by one or more computer processors, perform operations according to one or more of the methods described above. Attached Figure Description

[0009] To gain a more detailed understanding of the features described above, reference can be made to the embodiments for a more specific description of the disclosure, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings illustrate typical embodiments and should not be considered limiting; other equivalent embodiments are contemplated.

[0010] Figure 1 An example computing environment is described for executing at least some of the computer code involved in executing the method of the present invention.

[0011] Figure 2 An example environment in which embodiments of the present disclosure may be implemented is described.

[0012] Figures 3A-3B Example methods for dynamic backup management according to some embodiments of this disclosure are described.

[0013] Figure 4 An example method for dynamic backup management based on changes in security confidence is described according to some embodiments of this disclosure.

[0014] Figure 5 A flowchart illustrating an example method for adjusting a backup strategy based on one or more security event indicators, according to some embodiments of the present disclosure, is provided.

[0015] Figure 6 A flowchart is depicted illustrating an example method for adjusting a backup strategy when a significant change in the confidence level of damage level is detected, according to some embodiments of the present disclosure.

[0016] Figure 7 An example computing device for security metric analysis and backup management according to some embodiments of the present disclosure is described.

[0017] For ease of understanding, the same reference numerals are used where possible to indicate the same elements common in the figures. It is anticipated that elements disclosed in one embodiment may be advantageously used in other embodiments without requiring specific description. Detailed Implementation

[0018] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements to existing technologies on the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0019] This document describes a method or system for dynamically adjusting a data backup strategy. In one embodiment, dynamic adjustment can be performed based on collected security event metrics and aggregated damage level confidence scores, both of which are stored in the metadata of each backup. For example, the system can continuously monitor and collect metrics reflecting the security and integrity of the data source system. By aggregating these metrics, the system can generate a damage confidence score (also referred to in some embodiments as a damage level confidence score) representing the overall damage level or insecurity state of the data source system at the time of a particular backup.

[0020] In one embodiment, the score can be compared to one or more backup criteria (e.g., a defined maximum permissible threshold) to determine whether the backup meets the established security standards. If the damage confidence score meets the backup criteria (e.g., exceeds (or equals) the defined maximum permissible threshold), it may indicate that a significant security vulnerability was introduced during the backup process, and / or a potential breach has occurred in the data source system. In response, the system can tag and save the current backup and the backup immediately preceding it for further forensic analysis. In some embodiments, the system can compare the current damage confidence score with scores from all existing data backups. If the current score is the lowest among all existing backups, it may suggest that the current backup is most likely undamaged (or least likely to be damaged), and therefore has relatively high integrity. The system can then maintain the current backup regardless of other backup retention policies (otherwise, the backup may have been deleted). In some embodiments, the system can compare the current damage confidence score with scores from (or more) immediately preceding backups to determine trends in system security. If a significant increase is observed from the immediately preceding backup to the current backup, this may indicate a potential breach and / or a serious security vulnerability in the data source system. In response, the system can tag and save two adjacent backups (e.g., the current and the immediately preceding backup) for further analysis. The continuous monitoring and dynamic adjustments in the disclosed system or method provide a responsive and comprehensive data backup strategy, significantly enhancing overall data security and system reliability.

[0021] Figure 1 An example computing environment 100 is described for executing at least some of the computer code involved in performing the method of the present invention.

[0022] The computing environment 100 includes examples of environments for executing at least some of the computer code involved in performing the methods of the present invention, such as backup management code 180. In addition to backup management code 180, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end-user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including processing circuitry 120 and a cache 121), a communication infrastructure 111, volatile memory 112, persistent storage 113 (including an operating system 122 and the backup management code 180 identified above), a peripheral device set 114 (including a user interface (UI) device set 123, a storage device 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, host physical machine set 142, virtual machine set 143, and container set 144.

[0023] Computer 101 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or to be developed in the future capable of running programs, accessing networks, or querying databases such as remote database 130. As is well known in the field of computer technology, and depending on the technology, the execution of computer-implemented methods can be distributed across multiple computers and / or multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer (specifically computer 101) to keep the presentation as simple as possible. Computer 101 can reside in the cloud, even... Figure 1 It is not shown that it is in the cloud. On the other hand, unless explicitly instructed otherwise, computer 101 is not required to be in the cloud.

[0024] Processor assembly 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, for example, multiple cooperating integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package(s) and is typically used for data or code that should be readily accessible by the threads or cores running on processor assembly 110. Cache memory is typically organized into multiple tiers based on its relative proximity to the processing circuitry. Alternatively, some or all of the caches in the processor assembly may be located “off-chip.” In some computing environments, processor assembly 110 may be designed to process qubits and perform quantum computing.

[0025] Computer-readable program instructions are typically loaded onto computer 101 to cause the processor set 110 of computer 101 to perform a series of operational steps to implement a computer-implemented method, such that the executed instructions instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively, the “method of the invention”). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the method of the invention. In computing environment 100, at least some of the instructions for performing the method of the invention may be stored in backup management code 180 in persistent storage device 113.

[0026] Communication structure 111 is a signal transmission path that allows the various components of computer 101 to communicate with each other. Typically, this structure consists of switches and conductive paths, such as switches and conductive paths forming buses, bridges, physical input / output ports, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0027] Volatile memory 112 is any type of volatile memory now known or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, but this is not required unless explicitly indicated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer 101.

[0028] The persistent storage device 113 is any form of non-volatile storage device for a computer, now known or to be developed in the future. The non-volatility of this storage device means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the persistent storage device 113. The persistent storage device 113 may be a read-only memory (ROM), but typically at least a portion of the persistent storage device allows for data writing, data deletion, and data rewriting. Some common forms of persistent storage devices include hard disks and solid-state storage devices. The operating system 122 may take several forms, such as various known proprietary operating systems or operating systems employing a kernel-based open-source portable operating system interface type. The code included in the backup management code 180 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0029] Peripheral device set 114 includes a set of peripheral devices for computer 101. Data communication connections between peripheral devices and other components of computer 101 can be implemented in various ways, such as Bluetooth connections, near field communication (NFC) connections, connections made of cables (such as Universal Serial Bus (USB) type cables), plug-in connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, UI device set 123 may include components such as displays, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage device 124 is an external storage device (such as an external hard drive) or a pluggable storage device (such as an SD card). Storage device 124 may be persistent and / or volatile. In some embodiments, storage device 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 requires a large amount of storage (e.g., in embodiments where computer 101 locally stores and manages a large database), this storage can be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in IoT applications. For example, one sensor could be a thermometer, while another could be a motion detector.

[0030] Network module 115 is a collection of computer software, hardware, and firmware that allows computer 101 to communicate with other computers via WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi transceiver, software for packetizing and / or depacketizing data transmitted over the communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control and forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer-readable program instructions for performing the methods of the present invention can typically be downloaded to computer 101 from an external computer or external storage device via a network adapter card or network interface included in network module 115.

[0031] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any technology known now or developed in the future for transmitting computer data. In some embodiments, WAN 102 may be replaced by and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include computer hardware such as copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0032] End User Equipment (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 101) and can take any of the forms discussed above in conjunction with computer 101. EUD 103 typically receives helpful and useful data from the operation of computer 101. For example, assuming computer 101 is designed to provide recommendations to the end user, these recommendations are typically transmitted to EUD 103 from network module 115 of computer 101 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 can be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0033] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 can be controlled and used by the same entity operating computer 101. Remote server 104 represents multiple machines that collect and store helpful and useful data used by other computers such as computer 101. For example, in cases where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data can be provided to computer 101 from a remote database 130 of remote server 104.

[0034] Public cloud 105 is any computer system that can be used by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities (especially data storage (cloud storage) and computing power) without the need for direct, active management by users. Cloud computing typically leverages resource sharing to achieve scalability consistency and economy. Direct and active management of the computing resources of public cloud 105 is performed by the computer hardware and / or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented by virtual computing environments running on various computers constituting host physical machine set 142, which is the entire domain of physical computers in and / or available to public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and / or containers from container set 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of VCEs. The cloud orchestration module 141 manages the delivery and storage of images, deploys new instantiations of VCE, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows the public cloud 105 to communicate via WAN 102.

[0035] Now, we will provide some further explanation of Virtualized Computing Environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from this image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows multiple isolated user-space instances, called containers, to exist. From the perspective of the programs running within them, these isolated user-space instances typically appear as actual computers. Computer programs running on a regular operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of that container and the devices allocated to that container; this is a characteristic known as containerization.

[0036] Private cloud 106 is similar to public cloud 105, except that computing resources are available only to a single enterprise. While private cloud 106 is depicted as communicating with WAN 102, in other embodiments, private cloud may be completely disconnected from the Internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types) typically implemented by different vendors. Each of the multiple clouds remains a separate and independent entity, but the larger hybrid cloud architecture is bound together by a standardized or proprietary technology that enables orchestration, management, and / or data / application portability between the multiple component clouds. In this embodiment, both public cloud 105 and private cloud 106 are part of a larger hybrid cloud.

[0037] Figure 2 An example environment 200 in which embodiments of the present disclosure may be implemented is depicted. In the example shown, environment 200 includes one or more backup management servers 205, one or more client devices 210, one or more data source systems 220 (e.g., application / database server 225, standalone computer 230, virtual machine 235, or mobile device 240), and one or more storage devices 215 (e.g., network storage device or cloud storage device).

[0038] In the example shown, the Backup Management Server (BMS) 205 is directly or indirectly coupled to the client device 210, the data source system 220, and the storage device 215 via network 245. That is, the BMS 205, client device 210, data source system 220, and storage device 215 can each be implemented using discrete hardware systems. Network 245 can include or correspond to any combination of a wide area network (WAN), local area network (LAN), Internet, intranet, or suitable available communication media, and can include wired, wireless, or a combination of wired and wireless links. Network 245 can provide connectivity for various systems, components, or resources within environment 200 and can be implemented using protocols such as Transmission Control Protocol (TCP) and / or Internet Protocol (IP). In some embodiments, the BMS 205, client device 210, data source system 220, and storage device 215 may be deployed locally to each other (e.g., within the same local network and / or the same hardware system) and communicate with each other using any suitable local communication medium, such as a local area network (LAN) (including a wireless local area network (WLAN)), hardwired, wireless link, or intranet. In some embodiments, environment 200 may represent a cloud computing environment, and the BMS 205, client device 210, data source system 220, and storage device 215 may operate through a centralized cloud computing platform.

[0039] In the example shown, BMS 205 can coordinate and manage data backups from one or more data source systems 220 to one or more storage devices 215. As used herein, data source system 220 can refer to any computing system, device, or network from which data is collected for generating backups. Data source system 220 can include various types of systems and devices, such as application / database servers 225, standalone computers or workstations 230, virtual machines 235 within a network, and mobile devices 240, etc. BMS 205 can utilize various types of storage devices 215, such as hard disk drives (HDDs), solid-state drives (SSDs), network storage devices (e.g., network attached storage devices (NAS), storage area networks (SANs), direct attached storage devices (DAS)), cloud storage devices, etc. In some embodiments, BMS 205 can perform backup scheduling periodically and automatically. For example, BMS 205 can be programmed to perform backups at specific times or when specific events occur, following the backup policies of the corresponding data source 220. In some embodiments, BMS 205 may continuously collect security event metrics representing the security status of the data source system and aggregate these metrics to generate a damage confidence score. BMS 205 may compare this score with one or more defined thresholds and / or previous backups, and dynamically adjust backup strategies (for each given data source system 220) based on the comparison results. In some embodiments, BMS 205 may store the collected security metrics and the generated damage confidence score as metadata associated with each backup. In some embodiments, BMS 205 may analyze the backups and their associated metadata to identify any potential breaches or intrusions.

[0040] In some embodiments, BMS 205 may allow administrators to define and adjust backup policies via client device 210. Administrators can use client device 210 to send inputs / commands to BMS 205. Within these inputs / commands, administrators can set a schedule for when backups should occur (e.g., at regular intervals or based on certain events), adjust backup frequency, specify which storage devices to use, and / or define how long backups should be retained before being deleted or overwritten.

[0041] In some embodiments, BMS 205 may generate outputs / notifications regarding security event indicators, detected potential breaches or intrusions, and / or comparisons with one or more defined thresholds and / or previous backups. In some embodiments, BMS 205 may transmit the outputs / notifications to client device 210, which informs the administrator (e.g., or other user responsible for security or system administration) of the backup status of the relevant data source, potential security threats or breaches, and / or proactive actions that can be taken in response to potential damage. In some embodiments, BMS 205 may transmit the outputs / notifications to the system logs of the relevant data source system 220. In some embodiments, when the affected data source system is part of a cluster network or environment and shares associations with other computing systems, BMS 205 may send the outputs / notifications to all associated computing systems within the cluster. Upon receiving the outputs / notifications, the associated computing systems can become aware of the potential damage (e.g., potential security threats or breaches) in the affected data source system. Based on this output / notification, the associated computing systems (or BMS 205) may appropriately flag their backups and / or adjust their backup frequency accordingly to reduce the risk of potential damage propagating through the network or cluster. In some embodiments, when example environment 200 is part of a globally redundant system with a disaster recovery failover site, BMS 205 can transmit output / notifications to all other sites within the system, thereby keeping all other sites in the globally redundant system aware of the backup status and / or potential threats or breaches in example environment 200. Based on this output / notification, other sites in the globally redundant system can adjust their synchronization or backup strategies to align with potential risks. For example, if the compromise confidence score of a backup within storage device 215 is higher than the score of backups at other sites (indicating a lower security status), other sites can slow down or suspend data replication with potentially compromised sites(s).

[0042] In some embodiments, when other significant events occur (such as backup failure or an undamaged backup being overwritten), BMS 205 may send alerts to client device 210, the system logs of the data source, or other associated devices.

[0043] Figures 3A-3B Example method 300 for dynamic backup management according to some embodiments of the present disclosure is depicted. In some embodiments, Figure 3A Method 300A and Figure 3B Method 300B (collectively referred to as Method 300) can be executed by one or more backup management systems, such as Figure 1 The computer 101 shown Figure 2 The backup management server (BMS) 205 shown, and / or Figure 7The computing device 700 shown.

[0044] Method 300 begins at box 305, where the backup management system (e.g., Figure 2 205) tracks and collects information about the computing system (also referred to in some embodiments as the data source system) whose data is backed up (e.g., Figure 2 Security event indicators (220) are used as a whole. In some embodiments, these security event indicators may be collected continuously or at predetermined intervals from various sources within the computing system. In some embodiments, security event indicators may include system anomalies, intrusion detection data, damage indicators, and / or other parameters / indicators indicating the security status of the system. As used herein, “system anomaly” may refer to an abnormal or unexpected operation or pattern within the system that deviates from its normal or expected operation, such as a sudden surge in network traffic, an abnormal slowdown, an unexpected restart, an anomaly in data access or usage levels, etc. As used herein, “intrusion detection data” may refer to data collected from an intrusion detection system (IDS) that monitors network or system activity and detects intrusions or policy violations. Intrusion detection data may include network traffic, system logs, and application activity. As used herein, “damage indicators” may refer to data indicating that a security event may have occurred or is currently occurring in the system. Damage indicators may include abnormal outbound network traffic, anomalies in privileged user account activity, geographical irregularities, login red flags, and / or an increase in database reads, etc.

[0045] At box 310, the backup management system checks backup settings to determine whether a backup action has been triggered (e.g., based on predefined triggering criteria). If the system determines that the predefined triggering criteria have been met, method 300 proceeds to box 315, where the backup management system triggers the backup process and performs the actual backup operation. Otherwise, method 300 returns to 305, where the backup management system continues to monitor the data source system and collect security event indicators until the criteria are met. In some embodiments, the predefined triggering criteria may be time-based, occurring at regular time intervals (e.g., hourly, daily, weekly, or monthly). The backup management system may check the clock or internal timer within the system. If the current time matches the scheduled backup time, the backup management system may trigger the backup process. In some embodiments, the predefined triggering criteria may be event-based, where the backup process is triggered when one or more specific events occur. Various events can be set as backup trigger conditions in an event-based system, such as system shutdown, user logout, or the completion of certain tasks. In some embodiments, backups may be triggered based on the aforementioned security indicators (e.g., indicators that suggest a potential security event when the indicator equals or exceeds a defined threshold). For example, when a sudden spike in network activity exceeds a certain limit within a specified time period, it can indicate a potential attack or intrusion, and the backup management system can trigger an immediate backup to prevent potential data loss in the event of a successful attack.

[0046] At box 315, the backup process is triggered. In response, the backup management system performs a backup operation to generate a data source system (e.g., Figure 2 Backup of 220 (e.g., backup N).

[0047] At box 320, the backup management system evaluates the collected security metrics to generate a damage confidence score (also referred to as a damage level confidence score in some embodiments). The damage confidence score serves as a practical measure of the overall security status of the data source system at the time of the current backup (e.g., backup N). In some embodiments, the confidence score can quantify the overall security status of the data source system over the time between a previous backup (e.g., backup N-1) and the current backup (e.g., backup N). In some embodiments, at an operational scale of the damage confidence score, a lower score indicates a lower probability of system damage. In other words, the lower the damage confidence score, the higher the level of confidence that the backup data is undamaged and therefore secure. In some embodiments, the damage confidence score can be calculated based on a single metric (e.g., system anomalies, intrusion detection data, and / or indicators of damage). For example, the damage confidence score can be calculated by considering the presence (or absence) and / or severity of detected system anomalies. In some embodiments, the damage confidence score can be generated based on a combination of various metrics. The algorithm and weights used to calculate this score will be designed based on the infrastructure of the data source system, its risk tolerance, the sensitivity of the data it processes, and / or the specific threat model it uses. For example, for systems with a large number of publicly accessible interfaces, the score may be more biased (or given higher weight) towards network intrusion detection data. Conversely, in systems protected behind firewalls, internal anomalous or anomalous system behavior may be assigned more weight when calculating the final damage confidence score.

[0048] At box 325, the backup management system stores the collected security metrics and / or the generated security confidence scores as metadata associated with the current backup (e.g., backup N). In some embodiments, the stored metadata, along with the actual backup of the data, can be used for further analysis to help the backup management system understand the security status of the data source system at the time of backup.

[0049] At box 330, the backup management system compares the damage confidence score of the current backup (e.g., backup N) with an assessment criterion (also referred to in some embodiments as dynamic backup policy criteria). In some embodiments, the backup criteria may include a defined maximum permissible threshold, which represents the highest acceptable level of damage risk that a particular data source system (or the administrator of the source system) is willing to tolerate. If the damage confidence score of the current backup (e.g., backup N) exceeds (or equals) the threshold, it may indicate a high probability of system damage during the backup, thereby triggering a significant security vulnerability. In response, method 300 proceeds to box 335, where the backup management system marks the current backup (e.g., backup N) and the backup immediately preceding the current backup (e.g., backup N-1), and saves the marked backups for future forensic analysis. That is, the backup management system may avoid deleting or removing the current backup (backup N) and the previous backup (backup N-1), even if existing policies would lead to their deletion (e.g., after a period of time, or after an additional backup has been made). In some embodiments, the system may store associated security metrics, damage confidence scores, and any other relevant metadata along with the backup data for future forensic analysis. In some embodiments, the maximum permissible threshold may be adjusted based on the specific risk tolerance of the backup management system and the data source system, the sensitivity of the data being processed, and / or regulatory requirements. Although marking and retaining two backups (e.g., backup N and backup N-1) is discussed for clarity of concept, in some embodiments, the backup management system may similarly mark and retain additional backups, such as the three most recent backups (e.g., backup N-1, backup N-2, and backup N-3).

[0050] If the damage confidence score does not meet backup criteria (e.g., falls below a defined maximum permissible threshold), it can indicate that the data source system is within an acceptable risk level when the current backup is performed, thus suggesting a low probability of system damage. In response, the method proceeds to box 340, where the backup management system compares the damage confidence score of the current backup (e.g., backup N) with the scores of all existing backups in the system (e.g., previous backups of the same data source system that have not yet been deleted). If the damage confidence score of the current backup (e.g., backup N) is determined to be the lowest among all existing backups (indicating the lowest probability of damage), method 300 moves to box 345, where the backup management system tags and saves the current backup (e.g., backup N). In some embodiments, the backup management system may tag the backup as “highly reliable” or “most secure.” In some embodiments, the backup management system may store the tagged backup in storage, where policies are set to prevent it from being discarded or overwritten by a backup with a higher damage score, regardless of backup retention policies (e.g., which would otherwise lead to the deletion of the oldest backup whenever a new backup is performed). In some embodiments, the backup management system may store associated security metrics, damage confidence scores, and any other relevant metadata along with tagged backup data for future analysis or recovery operations. If the damage confidence score of the current backup (e.g., backup N) is not the lowest among all existing backups (for the same source system), method 300 proceeds to block 350, where the backup management system stores the current backup (e.g., backup N) according to existing policies. In some embodiments, the current backup (e.g., backup N) stored in the storage device may be replaced by a newer backup when a newer backup becomes available or when other policy-based conditions are met (such as when storage space is insufficient or when a purge trigger condition is initiated).

[0051] Returning to box 335, method 300 continues to box 355 (in Figure 3BIn this system, a backup management system performs detailed forensic analysis on tagged backups (e.g., the current backup N and the backup immediately preceding it (N-1)) and their respective metadata (e.g., security incident metrics, damage confidence scores). The forensic analysis is configured to detect or determine whether a security breach or intrusion has occurred and / or whether a specific security vulnerability and its corresponding impact have been identified. In some embodiments, forensic analysis may involve comparing the states of two adjacent backups to identify significant changes, and / or analyzing these changes to identify potential security events. In some embodiments, forensic analysis may involve using advanced algorithms or machine learning (ML) models to detect breaches or intrusions. For example, an ML model may be trained on a relatively large amount of data to learn normal behavioral patterns within a data source system. At runtime, the trained ML model can take the tagged backups (e.g., backups N and (N-1)) and their associated metadata (e.g., security incident metrics, damage confidence scores) as input. The ML model can process this data to identify patterns that deviate from normal expected behavior, which may indicate a breach or security issue. In some embodiments, the output of the ML model may be a prediction of the likelihood of a leak or intrusion (such as a probability score), where a higher value indicates a higher likelihood of a leak or intrusion. In some embodiments, the output of the ML model may be a binary classification. For example, the output may classify the current state of a backup as "normal" or "abnormal," where an "abnormal" output would indicate the presence of a leak or intrusion. In some embodiments, the output of the ML model may also include recommended proactive actions that should be taken in response to a detected leak or intrusion. For example, if a high likelihood of a leak is determined, the model may recommend generating an immediate backup of the data source system, initiating an immediate investigation, and / or sending an alert to the relevant responsible parties.

[0052] At box 360, the backup management system determines whether a breach or intrusion has occurred (or the likelihood of a breach or intrusion occurring) based on analysis of the backup and its associated metadata. If the system determines that some breach or intrusion may have occurred (e.g., the likelihood of a breach or intrusion exceeding a defined threshold, or classifying the current backup as “abnormal”), method 300 proceeds to box 365, where the backup management system generates a notification. Otherwise, method 300 returns to box 305, where the backup system continues to monitor data sources and collect security event metrics. In some embodiments, the process depicted from box 305 to box 365 may be repeated for each of the N+1 backups, and the backup strategy of the computing system may be modified when assessing and comparing the confidence levels of the damage levels.

[0053] In some embodiments, method 300 may skip box 360, where the backup management system generates a notification regardless of any potential breach or intrusion detected. In some embodiments, the notification may include security event metrics for the tagged backup, detection results for any potential breach or intrusion, and / or a comparison of the damage score with one or more defined thresholds (e.g., a comparison of the damage score of backup N with a predefined maximum permissible threshold, or a comparison of the damage score of backup N with damage scores from all existing backups). In some embodiments, the notification may also include recommended proactive actions to be taken in response to a potential threat or breach.

[0054] The generated notification can be transmitted to the respective recipients. For example, in some embodiments, the notification can be transmitted to the client device (e.g., Figure 2 Method 210) notifies the administrator of the security status of the data source system. In some embodiments, the notification may be transmitted to the system log of the data source system. In some embodiments, when the affected data source system is part of a cluster network or computing environment, the notification may be transmitted to all other computing systems within the cluster. In some embodiments, when the backup management system is part of a globally redundant system with a disaster recovery failover site, the notification may be transmitted to all other sites within the system. After transmitting the notification, method 300 returns to box 305, where the backup system continues to monitor the data source and collect security event indicators. In some embodiments, in addition to sending notifications, the backup management system may take other proactive actions in response to detected threats or breaches. For example, the backup management system may generate an immediate backup of the data source system and save the backup for further analysis and recovery operations. The backup management system may initiate an immediate investigation of system logs, network activity, user login activity, and / or other indications of malicious activity. Furthermore, the system may increase the frequency of backups during high-risk periods to ensure data security and that undamaged copies are maintained.

[0055] Figure 4 An example method 400 for dynamic backup management based on changes in damage confidence, according to some embodiments of this disclosure, is described. In some embodiments, Figure 4 Method 400 can be performed by one or more backup management systems, such as Figure 1 The computer 101 shown Figure 2 The Backup Management Server (BMS) 205 shown, and / or Figure 7 The computing device 700 shown herein. As depicted herein, the steps from block 405 to 425 in method 400 largely correspond to the steps from block 305 to 325 in method 300. In some embodiments, method 300 of FIG3 and Figure 4Method 400 can be combined and executed jointly by one or more backup management systems, such as Figure 1 The computer 101 shown Figure 2 The Backup Management Server (BMS) 205 shown, and / or Figure 7 The computing device 700 shown is shown.

[0056] Method 400 begins at box 405, where the backup management system tracks and collects data from the data source system (e.g., Figure 2 Security event indicators (220). As described above, in some embodiments, security event indicators may include system anomalies, intrusion detection data, damage indicators, and / or other parameters / indicators indicating the security status of the system.

[0057] At box 410, the backup management system checks whether a backup action has been triggered based on one or more predefined triggering criteria. If it is determined that a backup action has been triggered, method 400 proceeds to box 415, where the backup management system performs the backup operation and generates a data source system (e.g., Figure 2 Backup of (e.g., backup N) of 220). If it is determined that the backup action has not yet been triggered, method 400 returns to box 405, where the backup management system continues to monitor the data source system and collect security event indicators until the backup action is triggered.

[0058] At box 420, the backup management system generates a damage confidence score (also referred to as a damage level confidence score in some embodiments) based on one or more collected security metrics. In some embodiments, the damage confidence score can be used to quantify the overall security level of the data source system when a current backup (e.g., backup N) is performed. A lower damage confidence score can indicate a lower probability of system damage and thus suggest a higher level of system security. For example, a data backup with a 10% damage confidence score indicates that the system has higher integrity compared to another backup with a 20% damage confidence score. In some embodiments, a significant increase in the damage confidence score between two adjacent backups (e.g., backups N and (N-1)) (such as from 10% to 30%) can indicate a potential breach or intrusion. A significant increase in the score can serve as an alert for the backup management system, indicating an increased risk that requires further analysis and investigation.

[0059] At box 425, the backup management system saves the collected security metrics and / or the generated security confidence scores as metadata associated with the current backup (e.g., backup N).

[0060] At box 430, the backup management system identifies whether there is a significant increase in the damage confidence score between two adjacent backups. In some embodiments, the identification process may begin by comparing the damage confidence score of the current backup (e.g., backup N) with the damage confidence score of the immediately preceding backup (e.g., backup N-1) to calculate the increase between the two backups. After calculating the increase (or change), the system may then compare the increase (or change) with a significance criterion. In some embodiments, the significance criterion may include a defined significance threshold used to distinguish between a “normal” or “tolerable” increase in the confidence score and a “significant” increase indicating potential system damage (e.g., policy violation or intrusion). In some embodiments, the defined significance threshold may be determined based on various factors, including (but not limited to) the risk tolerance of the backup management system and the data source system, the infrastructure of the data source system, the sensitivity of the data being processed, historical data regarding the damage confidence score, and / or regulatory requirements.

[0061] If the increase meets the significance criteria (e.g., exceeds (or equals) a defined significance threshold), indicating a significant increase in the damage confidence score between the current backup (e.g., backup N) and the immediately preceding backup (e.g., backup N-1), then method 400 proceeds to box 435. At box 435, the backup management system flags two adjacent backups (e.g., backup N and (N-1)) and stores the flagged backups for future forensic analysis. If the increase falls below the defined significance threshold, indicating no significant increase in the damage confidence score, then method 400 returns to box 405, where the backup management system continues to monitor the data source system and collect relevant security event metrics.

[0062] At box 440, the backup management system analyzes the tagged backups (e.g., backups N and (N-1)) and their corresponding metadata (e.g., security event metrics, damage confidence scores) to detect potential breaches or intrusions (e.g., and / or their scope and impact). In some embodiments, forensic analysis may involve using advanced algorithms or machine learning (ML) models to detect potential breaches or intrusions.

[0063] At box 445, the backup management system determines whether a breach or intrusion has occurred (or the likelihood of a breach or intrusion occurring) based on the analysis results from box 440. If the system determines that some breach or intrusion may have occurred (e.g., the likelihood of a breach or intrusion occurring exceeds a defined threshold, or the current backup is classified as “abnormal”), method 400 proceeds to box 450, where the backup management system generates a notification and transmits it to the responsible party. Otherwise, method 400 returns to box 405, where the backup system continues to monitor the data source and collect security event indicators. In some embodiments, the process depicted from box 405 to box 450 may be repeated for each of the N+1 backups, and the backup strategy of the computing system may be modified when assessing and comparing the confidence levels of the damage levels.

[0064] In some embodiments, method 400 may skip box 445, where the backup management system generates a notification regardless of any potential breach or intrusion detected. In some embodiments, the notification may include security event metrics for the tagged backup, detection results for any potential breach or intrusion, an increase in the damage confidence score, and / or a determination of the significance of the increase. The notification may be transmitted to parties such as the data source system, administrators (e.g., via client devices), other computing systems in the same cluster network, and / or other sites of the globally redundant system. In some embodiments, in addition to sending notifications, the backup management system may perform other proactive actions in response to a potential threat or breach, such as generating an immediate backup of the data source system, initiating an immediate investigation of malicious activity, and / or changing the current backup policy (e.g., increasing the frequency of backups during high-risk periods).

[0065] Figure 5 A flowchart depicting an example method 500 for adjusting a backup strategy based on one or more security event indicators, according to some embodiments of the present disclosure, is described.

[0066] Method 500 begins at box 505, where the backup management system (e.g., Figure 2 The BMS 205 generates the computing system (e.g., in real time) at the first moment. Figure 2 The first backup of the data source 220 (as depicted in box 315 of Figure 3).

[0067] At box 510, the backup management system generates a computing system (e.g., Figure 2 The data source 220) has the first level of damage confidence at the first moment (as depicted in box 320 of Figure 3).

[0068] At box 515, the backup management system stores the first backup along with metadata, where the metadata includes the computing system (e.g., Figure 2The data source 220) determines the first level of damage confidence at the first moment (as depicted in box 325 of Figure 3). In one embodiment, the first level of damage confidence is determined at least in part based on system anomalies, intrusion detection, or indicators of damage.

[0069] At box 520, the backup management system assesses a first damage level confidence level based on one or more backup criteria (as depicted in box 330 of Figure 3). In response to the assessment results, the backup management system modifies the backup policy of the computing system. In one embodiment, the process of modifying the backup policy includes: when it is determined that the first damage level confidence level meets one or more backup criteria, storing a first backup and a second backup for forensic analysis, wherein the second backup corresponds to the backup immediately preceding the first backup (as depicted in box 335 of Figure 3). In other embodiments, the process of modifying the backup policy includes: when it is determined that the first damage level confidence level is the smallest among the existing backups of the computing system, retaining the first backup of the data (as depicted in box 345 of Figure 3).

[0070] In some embodiments, the backup management system may also generate a second backup of the computing system at a second time, wherein the second backup is the backup immediately preceding the first backup; store the second backup along with metadata, wherein the metadata includes a second damage level confidence level of the computing system at the second time; and compare the increase from the second damage level confidence level to the first damage level confidence level with one or more significance criteria (such as...). Figure 4 (As depicted in box 430). In some embodiments, the backup management system may store a first backup and a second backup for forensic analysis (e.g., when an increase is determined to satisfy one or more significance criteria). Figure 4 (As depicted in frame 435).

[0071] In some embodiments, the backup management system may also analyze the first and second backups to detect potential leaks (as depicted in box 355 of Figure 3), and initiate an immediate backup of the computing system in response to the detection of a potential leak. In some embodiments, the process of initiating an immediate backup of the computing system may include at least one of the following: capturing the current state of the computing system, generating a new backup of the data stored on the computing system, or recording relevant metadata.

[0072] In some embodiments, the backup management system may also notify one or more other computing systems, which are in the same cluster system as the current computing system (as depicted in box 365 of Figure 3), of the modified backup policy and evaluation results. In some embodiments, each of the one or more other computing systems may, upon receiving the notification, tag at least one corresponding backup using metadata indicating the modified backup policy and evaluation results, and adjust the backup frequency in response to the modified backup policy and evaluation results.

[0073] Figure 6 A flowchart is depicted illustrating an example method 600 for adjusting a backup strategy when a significant change in the confidence level of damage level is detected, according to some embodiments of the present disclosure.

[0074] Method 600 begins at box 605, where the backup management system (e.g., Figure 2 The BMS 205 generates the computing system (e.g., in real time) at the first moment. Figure 2 The first backup of data source 220 (such as) Figure 4 (As depicted in frame 415).

[0075] At box 610, the backup management system generates a computing system (e.g., Figure 2 The data source 220) first damage level confidence level at the first moment (e.g. Figure 4 (As depicted in box 420).

[0076] At box 615, the backup management system stores the first backup along with metadata, where the metadata includes the computing system (e.g., Figure 2 The data source 220) first damage level confidence level at the first moment (e.g. Figure 4 (As depicted in box 425).

[0077] At box 620, the backup management system generates a second backup of the computing system at a second time, wherein the second backup is the backup immediately preceding the first backup.

[0078] At box 625, the backup management system stores the second backup along with metadata, wherein the metadata includes a second damage level confidence level calculated for the system at a second time. In one embodiment, the first damage level confidence level and the second damage level confidence level are determined at least in part based on system anomalies, intrusion detection, or indicators of damage.

[0079] At box 630, the backup management system compares the increase in confidence level from the second damage level to the first damage level with one or more significance criteria (such as...). Figure 4 (As depicted in frame 430).

[0080] At box 635, the backup management system modifies the backup policy of the computing system in response to the comparison results. In one embodiment, the process of modifying the backup policy may include: storing a first backup and a second backup for forensic analysis (e.g., when it is determined that more than one or more significance criteria are added). Figure 4 (As depicted in frame 435).

[0081] In some embodiments, the backup management system can also analyze the first and second backups to detect potential leaks (such as...). Figure 4 As depicted in box 440), and in response to detecting a potential leak, initiate an immediate backup of the computing system. In some embodiments, the backup management system may also notify one or more other computing systems, wherein the other computing systems are in the same cluster system as the current computing system (e.g., ...). Figure 4 (As depicted in frame 450).

[0082] Figure 7 Example computing device 700 for security metric analysis and backup management according to some embodiments of this disclosure is depicted. Although depicted as a physical device, in embodiments, computing device 700 may be implemented using (multiple) virtual devices and / or across multiple devices (e.g., in a cloud environment). Computing device 700 can be implemented as any computing device, such as Figure 1 The computer 101 shown, or Figure 2 The backup management server(s) 205 shown.

[0083] As shown in the figure, computing device 700 includes a CPU 705, memory 710, storage device 715, one or more network interfaces 725, and one or more I / O interfaces 720. In the illustrated embodiment, CPU 705 retrieves and executes programming instructions stored in memory 710, and stores and retrieves application data residing in storage device 715. CPU 705 typically represents a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU with multiple processing cores, etc. Memory 710 is typically included to represent random access memory. Storage device 715 can be any combination of disk drives, flash-based storage devices, etc., and can include fixed and / or removable storage devices, such as fixed disk drives, removable memory cards, caches, optical storage devices, network-attached storage devices (NAS), or storage area networks (SANs).

[0084] In some embodiments, I / O devices 735 (such as a keyboard, monitor, etc.) are connected via I / O interfaces 720. Furthermore, computing device 700 can be communicatively coupled to one or more other devices and components (e.g., via a network, which may include the Internet, multiple local networks, etc.) via network interfaces 725. As shown, CPU 705, memory 710, storage device 715, multiple network interfaces 725, and multiple I / O interfaces 720 are communicatively coupled via one or more buses 730.

[0085] In the illustrated embodiment, the memory 710 includes a data collection component 750, a backup generation and management component 755, an analysis component 760, and a notification generation component 765.

[0086] Although depicted as discrete components for clarity of concept, in some embodiments, the operation of the depicted components (and other components not shown) may be combined or distributed across any number of components. Furthermore, although depicted as software residing in memory 710, in some embodiments, the operation of the depicted components (and other components not shown) may be implemented using hardware, software, or a combination of hardware and software.

[0087] In one embodiment, the data collection component 750 can collect data from a data source system (e.g., Figure 2 Within 220), various sources are traced and security-related data (also referred to as security incident indicators in some embodiments) are collected. Security-related data can include various aspects, including (but not limited to) system anomalies, intrusion detection data, and indicators of damage. The collected data can then be used to generate damage confidence scores and determine dynamic backup strategies.

[0088] In one embodiment, the backup generation and management component 755 can continuously monitor and check backup triggers and communicate with the data source system to initiate a backup process when a backup trigger is met. After creating a data backup (e.g., backup N), the backup generation and management component 755 can use security metrics collected by the data collection component 750 to calculate a damage confidence score for the backup. This score can provide a quantitative assessment of the overall security of the data source system at the time of the backup (e.g., backup N). As described above, the damage confidence score can be calculated based on individual metrics (e.g., system anomalies, intrusion detection data, and / or indicators of damage) or combinations of various metrics. Along with the backup, the backup generation and management component 755 can generate metadata. The metadata may include security event metrics collected by the data collection component 750, the generated damage confidence score, and other relevant details. The metadata may be stored along with its associated backup data and provided to the analysis component 760 for further analysis.

[0089] In one embodiment, analysis component 760 may compare the damage confidence score generated by backup generation & management component 755 with one or more backup criteria. In some embodiments, analysis component 760 may compare the damage confidence score with a defined maximum allowable threshold to determine whether the current backup (e.g., backup N) meets the set security criteria. In some embodiments, analysis component 760 may compare the score with scores from all existing data backups to determine whether the current backup has the lowest score and is therefore most likely undamaged, and has high integrity across all other backups. In some embodiments, analysis component 760 may compare the score with scores from a previous backup (e.g., backup N-1) to determine trends in system security. The previous backup (e.g., backup N-1) may have occurred immediately preceding the current backup (e.g., backup N).

[0090] After the comparison is complete, in some embodiments, the analysis component 760 may send the comparison results to the backup generation & management component 755, which adjusts the backup strategy as needed upon receiving the results. This adjustment may include changing the backup interval, saving certain backups regardless of retention policies, and / or marking certain backups for future forensic analysis. For example, in some embodiments, when it is determined that the score of the current backup (e.g., backup N) is higher than (or equal to) the maximum allowable threshold, the backup generation & management component 755 may take snapshots of the current backup (e.g., backup N) and the immediately preceding backup (e.g., backup N-1) and save them for future forensic analysis. In some embodiments, after the analysis component 760 determines that the score of the current backup is the lowest among all existing backups, the backup generation & management component 755 may save the current backup (e.g., backup N) and adjust the strategy to prevent it from being discarded or overwritten by a new backup with a higher damage score, regardless of the backup retention policy. In some embodiments, when calculating the increase between the current backup (e.g., backup N) and the immediately preceding backup (e.g., backup N-1) and determining that it exceeds (or equals) a defined significance threshold (indicating potential system damage), backup generation & management can save and tag these two adjacent backups for future forensic analysis.

[0091] In one embodiment, after backups indicating potential system damage are tagged and saved, the analysis component 760 can perform detailed forensic analysis on the tagged backups (e.g., the current backup N and the backup immediately preceding it (N-1)) and their corresponding metadata (e.g., security incident metrics, damage confidence scores) to detect whether a breach or intrusion has occurred. In some embodiments, the analysis component 760 can use a trained ML model to examine the backup data for patterns, anomalies, and deviations from an established baseline. As described above, in some embodiments, the ML model can generate predictions (e.g., probability scores) of the likelihood of a breach or intrusion occurring. In some embodiments, the output of the ML model can include a binary classification that categorizes backups as “normal” or “abnormal,” where an anomalous output indicates the presence of a breach or intrusion. In some embodiments, the output of the ML model can also include recommended proactive actions that can be taken in response to mitigating the impact of a detected breach or intrusion.

[0092] In some embodiments, the analysis component 760 may transmit the analysis results to the backup generation and management component 755. The backup generation and management component 755 may take proactive action based on the received analysis results, in response to a detected breach or intrusion. In some embodiments, the backup generation and management component 755 may send a command to the notification generation component 765, instructing it to generate a notification and send it to relevant parties, such as data source systems (e.g., ...). Figure 2 The system logs of 220) and client devices (e.g., Figure 2(210). In some embodiments, if the affected data source system is associated with other computing systems in a cluster network or environment, the backup generation & management component 755 may instruct the notification generation component 765 to transmit a notification to all associated computing systems. In some embodiments, the notification may include: forensic analysis details, detection results of any potential breach or intrusion, the security status of the data source system (e.g., security incident indicators, damage confidence scores), and / or a comparison between the damage score and one or more defined thresholds. Upon receiving the notification, the associated computing system may evaluate the reported information and adjust its backup strategy accordingly. For example, if the damage confidence score of the data source system has increased significantly (indicating an increased risk), other systems may decide to increase their backup frequency, perform internal checks, and / or other security measures to prevent breaches or intrusions. In some embodiments, when a globally redundant system with a disaster recovery failover site is involved, the backup generation & management component 755 may instruct the notification generation component 765 to transmit a notification to all other sites within the system. Based on this notification, other sites in the globally redundant system may adjust their synchronization strategies to align with the reported potential risk. For example, if the damage confidence score of the data source system is higher than the score of backups at other sites (indicating a lower security status), those other sites may slow down or pause data replication.

[0093] In some embodiments, in addition to sending notifications, the backup generation & management component 755 may take other proactive actions in response to detected threats or breaches. For example, in some embodiments, the backup generation & management component 755 may generate an immediate backup of the data source system and save the backup for further analysis and recovery operations. In some embodiments, the backup generation & management component 755 may initiate an immediate investigation into system logs, network activity, user login activity, and / or other indications of malicious activity. In some embodiments, the backup generation & management component 755 may increase the frequency of backups during high-risk periods to ensure data security and that undamaged copies are maintained.

[0094] In the example shown, storage device 715 may include backups of data 775 from a data source system, metadata 780 associated with each backup, analysis results 785 (e.g., generated by analysis component 760), comparison results of damage level confidence levels 790 (e.g., generated by backup generation & management component 755), and notification logs 795. In some embodiments, the information mentioned above may be stored in a remote database connected to computing device 700 via a network (e.g., Figure 2 In 215).

[0095] The following reference is made to the embodiments presented in this disclosure. However, the scope of this disclosure is not limited to the specifically described embodiments. Rather, any combination of the following features and elements is contemplated for implementing and practicing the intended embodiments, regardless of whether different embodiments are involved. Furthermore, while the embodiments disclosed herein may achieve advantages over other possible solutions or prior art, whether a given embodiment achieves a particular advantage does not limit the scope of this disclosure. Therefore, the following aspects, features, embodiments, and advantages are merely illustrative and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims. Similarly, references to “the invention” should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered as elements or limitations of the appended claims unless expressly stated in the claims.

[0096] Various aspects of this disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). Regarding any flowchart, depending on the technology involved, operations may be performed in a different order than that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0097] Computer Program Product Embodiment (“CPP Embodiment” or “CPP”) is a term used in this disclosure to describe any collection of one or more storage media (also referred to as “media”) collectively included in a collection of one or more storage devices, wherein the collection of one or more storage devices collectively includes machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A “storage device” is any tangible device capable of holding and storing instructions used by a computer processor. Without limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / platforms formed in the main surface of the disk), or any suitable combination of the foregoing. As used in this disclosure, the term computer-readable storage medium should not be construed as storing transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As those skilled in the art will understand, data is typically moved at certain incidental points in time during normal operation of the storage device, such as during access, defragmentation, or garbage collection; however, this does not make the storage device transient, because the data is not transient when it is stored.

[0098] While the foregoing relates to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope of the invention, the scope of which is defined by the appended claims.

Claims

1. A method comprising: Generate the first backup of the computing system as soon as possible; Generate the confidence level of the first damage level for the first time period of the computing system; The first backup is stored together with metadata including the confidence level of the first damage level of the computing system at the first time. as well as In response to assessing the confidence level of the first damage level based on one or more dynamic backup strategy criteria, the backup strategy of the computing system is modified.

2. The method of claim 1, wherein the first damage level confidence is determined at least in part based on at least one of: (i) system anomaly; (ii) intrusion detection; or (iii) an indicator of damage.

3. The method according to claim 1, wherein modifying the backup strategy of the computing system includes: When the confidence level of the first damage level is determined to meet the criteria of one or more dynamic backup strategies, the first backup and the second backup are stored for forensic analysis, wherein the second backup corresponds to the backup immediately preceding the first backup.

4. The method according to claim 1, wherein modifying the backup strategy of the computing system includes: The first backup of the data is retained when the confidence level of the first damage level is determined to be the lowest among the existing backups of the computing system.

5. The method according to claim 1, further comprising: A second backup of the computing system is generated at a second time, wherein the second backup is the backup that immediately precedes the first backup; Store the second backup along with metadata including the second damage level confidence level of the computing system at the second time. as well as Compare the increase from the confidence level of the second damage level to the confidence level of the first damage level with one or more significance criteria.

6. The method of claim 5, wherein modifying the backup strategy of the computing system comprises: When it is determined that the addition satisfies one or more of the significance criteria, the first backup and the second backup are retained for forensic analysis.

7. The method of claim 3, further comprising: Analyze the damage level confidence of the first backup and the second backup to detect potential leaks; as well as In response to the detection of the potential leak, an immediate backup of the computing system is initiated.

8. The method of claim 7, wherein initiating an immediate backup of the computing system comprises at least one of: capturing the current state of the computing system, generating a new backup of the computing system, or recording relevant metadata.

9. The method according to claim 1, further comprising: The modified backup strategy and evaluation results are notified to one or more other computing systems, wherein the one or more other computing systems are in the same cluster system as the computing system.

10. The method according to claim 1, further comprising: The modified backup policy and evaluation results are notified to one or more other computing systems, wherein the one or more other computing systems share access to the data stored in one or more backup sets with the computing system.

11. A system comprising: One or more computer processors; as well as One or more memories, the one or more memories collectively containing one or more programs, the one or more programs performing operations when executed by the one or more computer processors, the operations including: Generate the first backup of the computing system as soon as possible; Generate the confidence level of the first damage level for the first time period of the computing system; The first backup is stored together with metadata including the confidence level of the first damage level of the computing system at the first time; and In response to assessing the confidence level of the first damage level based on one or more dynamic backup strategy criteria, the backup strategy of the computing system is modified.

12. The system of claim 11, wherein the confidence level of the first damage level is determined at least in part based on at least one of: (i) system anomaly; (ii) intrusion detection; or (iii) an indicator of damage.

13. The system of claim 11, wherein modifying the backup strategy of the computing system comprises: When the confidence level of the first damage level is determined to meet the criteria of one or more dynamic backup strategies, the first backup and the second backup are stored for forensic analysis, wherein the second backup corresponds to the backup immediately preceding the first backup.

14. The system of claim 11, wherein the operation further comprises: A second backup of the computing system is generated at a second time, wherein the second backup is the backup that immediately precedes the first backup; Store the second backup along with metadata including the second damage level confidence level of the computing system at the second time. as well as Compare the increase from the confidence level of the second damage level to the confidence level of the first damage level with one or more significance criteria.

15. The system of claim 14, wherein modifying the backup strategy of the computing system comprises: When it is determined that the addition satisfies one or more of the significance criteria, the first backup and the second backup are retained for forensic analysis.

16. The system of claim 11, wherein the operation further comprises: The modified backup strategy and evaluation results are notified to one or more other computing systems, wherein the one or more other computing systems are in the same cluster system as the computing system.

17. A computer program product comprising one or more computer-readable storage media collectively containing computer-readable program code, the computer-readable program code performing operations when executed by operations of one or more computer processors, the operations including: Generate the first backup of the computing system as soon as possible; Generate the confidence level of the first damage level for the first time period of the computing system; The first backup is stored together with metadata including the confidence level of the first damage level of the computing system at the first time. as well as In response to assessing the confidence level of the first damage level based on one or more dynamic backup strategy criteria, the backup strategy of the computing system is modified.

18. The computer program product of claim 17, wherein the confidence level of the first damage level is determined at least in part based on at least one of: (i) system anomaly; (ii) intrusion detection; or (iii) an indicator of damage.

19. A method comprising: Generate the first backup of the computing system as soon as possible; Generate the confidence level of the first damage level for the first time period of the computing system; The first backup is stored together with metadata including the confidence level of the first damage level of the computing system at the first time. as well as A second backup of the computing system is generated at a second time, wherein the second backup is the backup that immediately precedes the first backup; Store the second backup and metadata including a second confidence level of the damage level of the computing system at the second time; Compare the increase from the confidence level of the second damage level to the confidence level of the first damage level with one or more significance criteria; as well as In response to the comparison results, the backup strategy of the computing system is modified.

20. A system comprising: One or more computer processors; as well as One or more memories, the one or more memories collectively containing one or more programs, the one or more programs performing operations when executed by the one or more computer processors, the operations including: Generate the first backup of the computing system as soon as possible; Generate the confidence level of the first damage level for the first time period of the computing system; The first backup is stored together with metadata including the confidence level of the first damage level of the computing system at the first time; and A second backup of the computing system is generated at a second time, wherein the second backup is the backup that immediately precedes the first backup; Store the second backup along with metadata including the second damage level confidence level of the computing system at the second time. Compare the increase in confidence level from the second damage level to the first damage level with one or more significance criteria; and In response to the comparison results, the backup strategy of the computing system is modified.

Images