How to modify backup policies based on the confidence level of a breach, system

Abstract

A system is provided that allows for the modification of backup policies based on the confidence level of the compromise. At a first point in time, a first backup of the computing system is generated. A confidence level for the first compromise of the computing system is generated for that first point in time. The first backup is stored along with metadata, which includes the confidence level for the first compromise of the computing system at that first point in time. The computing system's backup policy is modified in response to the evaluation of the confidence level for the first compromise based on one or more backup criteria.

Description

BACKGROUND ART

[0001] The present disclosure relates to data backup for computing systems, and more specifically, to dynamically adjusting data backup policies of a computing system based on threat reliability.

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

[0003] Despite each having its own unique strengths, both types of systems operate within a rigid framework. In other words, conventional backup systems do not adapt their behavior in response to changes in the system's security environment or potential threats. They proceed without considering the security state of the system or potential threats, which can lead to scenarios where compromised data is included in backups, or where uncompromised data is overwritten by compromised data. Given the dynamic and constantly evolving nature of cybersecurity threats, it has become increasingly important to develop more responsive and adaptive backup strategies that are capable of dynamically adjusting their backup policies in response to detected potential security threats and vulnerabilities. SUMMARY OF THE INVENTION

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

[0005] In another embodiment, one or more of the following features may be included: The method further comprises a step of storing a first backup and a second backup for forensic analysis when it is determined that the confidence level of a first breach meets one or more dynamic backup policy criteria, the second backup corresponding to the backup immediately preceding the first backup. The provided embodiment facilitates more efficient identification of potential security risks and further enables detailed forensic analysis using the stored backups.

[0006] In another embodiment, one or more of the following features may be included: The method may further have a step of retaining a first backup of data if it is determined that the confidence level of the first breach is minimal across multiple existing backups of the computing system. The provided embodiment optimizes backup storage space and reduces the risk of data loss by retaining backups with a relatively low confidence level of breach. In another embodiment, one or more of the following features may be included: The method further comprises a step of notifying one or more other computing systems of a modified backup policy and evaluation results, wherein one or more other computing systems reside in a clustered system together with the computing system, and each of the one or more other computing systems, upon receiving the notification, tags at least one of each backups with metadata indicating the modified backup policy and evaluation results, and can adjust the backup frequency in response to the modified backup policy and evaluation results. By sharing evaluation results or changes in backup policy with other computing systems in the network, the provided embodiment enables other systems to respond quickly to potential security risks and thus improves overall network security. Furthermore, in another embodiment, the method further comprises a step of notifying one or more other computing systems of a modified backup policy and evaluation results, wherein one or more other computing systems share access with the computing system to the data stored in one or more backup sets.

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

[0008] Other embodiments of this disclosure provide a non-temporary computer-readable medium having computer program code that, when executed by the operation of one or more computer processors, operates in accordance with one or more of the above methods, and a system comprising one or more computer processors and one or more memories having one or more programs that, when executed by said one or more computer processors, operate in accordance with one or more of the above methods. [Brief explanation of the drawing]

[0009] To allow the above-mentioned features of this disclosure to be understood in detail, a more specific description of this disclosure, which has been briefly summarized above, is given with reference to embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings illustrate typical embodiments and should therefore not be considered limiting; other equally valid embodiments are contemplated.

[0010] [Figure 1] This document describes an exemplary computing environment for executing at least a portion of the computer code involved in carrying out the method of the present invention.

[0011] [Figure 2] This document illustrates an exemplary environment in which embodiments of the embodiments of this disclosure may be implemented.

[0012] [Figure 3A] This disclosure illustrates exemplary methods for dynamic backup management according to several embodiments. [Figure 3B] This disclosure illustrates exemplary methods for dynamic backup management according to several embodiments.

[0013] [Figure 4] This disclosure illustrates exemplary methods for dynamic backup management based on changes in security confidence, according to several embodiments of this disclosure.

[0014] [Figure 5] The flowcharts illustrate exemplary methods for adjusting backup policies based on one or more security incident metrics, according to several embodiments of this disclosure.

[0015] [Figure 6] The flowcharts illustrate exemplary methods for adjusting backup policies when a significant change in the confidence level of a breach is detected, according to several embodiments of this disclosure.

[0016] [Figure 7] This disclosure illustrates exemplary computing devices for security metrics analysis and backup management according to several embodiments of this disclosure.

[0017] For ease of understanding, the same elements common to each figure are shown using the same reference numerals whenever possible. Elements disclosed in one embodiment are intended to be usefully used in other embodiments without specific description. [Modes for carrying out the invention]

[0018] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be comprehensive or limitless to the embodiments disclosed. Many modifications and variations will become apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market, or to enable other those skilled in the art to understand the embodiments disclosed herein.

[0019] Embodiments of this specification describe methods or systems for dynamically adjusting data backup policies. In one embodiment, dynamic adjustment is performed based on both collected security incident metrics and aggregated breach confidence levels, both of which are stored in the metadata of each backup. For example, the system may continuously monitor and collect metrics that reflect the security and integrity of the data source system. By aggregating these metrics, the system may generate a breach confidence score (also referred to as a breach confidence level in some embodiments) that represents the overall level of compromise or insecurity of the data source system at the time a particular backup was created.

[0020] In one embodiment, the score may be compared to one or more backup criteria (e.g., a predefined maximum allowable threshold) to determine whether the backup meets the established security criteria. If the compromise confidence score meets the backup criteria (e.g., exceeds (or is equal to) the predefined maximum allowable threshold), it may indicate that a significant security concern has arisen and / or that a potential breach occurred in the data source system at the time the backup was created. In response, the system may flag and save the current backup and the backup immediately preceding the current backup for further forensic analysis. In some embodiments, the system may compare the current compromise confidence score to the scores from all existing data backups. If the compromise confidence score does not meet the backup criteria (e.g., falls below the predefined maximum allowable threshold), and the current score is the lowest among all existing backups, it may suggest that the current backup is most likely to be uncompromised (or least likely to be compromised) and therefore has relatively higher integrity. The system may then retain the current backup regardless of other backup retention policies (which may otherwise result in the deletion of backups). In some embodiments, the system may determine trends in system security by comparing the current breach confidence score with the score from the most recent backup. If a significant increase is observed from the most recent backup to the current backup, it may indicate that a potential breach has occurred and / or that a significant security concern has arisen in the data source system. In response, the system may flag and store two adjacent backups (e.g., the current backup and the most recent backup) for further analysis. Continuous monitoring and dynamic adjustment in the disclosed system or method provide a responsive and comprehensive data backup strategy that significantly improves overall data security and system reliability.

[0021] FIG. 1 shows an exemplary computing environment 100 for executing at least part of the computer code involved in performing the method of the present invention.

[0022] The computing environment 100 includes an example of an environment for executing at least part of the computer code involved in performing the method of the present invention, such as backup management code 180. In addition to the 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 the present embodiment, the computer 101 has a processor set 110 (including a processing circuit 120 and a cache 121), a communication fabric 111, a volatile memory 112, persistent storage 113 (including the 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 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0023] The computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch, or other wearable computer, mainframe computer, quantum computer, or any other currently known or future-developed form of computer or mobile device capable of executing programs, accessing a network, or querying a database such as the remote database 130. As is well understood in the field of computer technology, and depending on the technology, the execution of computer-implemented methods may be distributed across multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 100, to keep the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically the computer 101. Although the computer 101 is not shown in the cloud in FIG. 1, it may be located in the cloud. On the other hand, the computer 101 is not required to reside in the cloud, except to the extent that it may be affirmatively indicated.

[0024] The processor set 110 includes one or more computer processors of any type, currently known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, for example multiple coordinated integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. The cache 121 is a memory located within the processor chip package, typically used for data or code that should be available for high-speed access by threads or cores executing on the processor set 110. Cache memory is typically organized into multiple levels according to its relative proximity to the processing circuitry. Alternatively, some or all of the caches for the processor set may be located "off-chip". In some computing environments, the processor set 110 may be designed to operate using qubits and perform quantum computing.

[0025] Computer-readable program instructions are typically loaded onto computer 101, causing the processor set 110 of computer 101 to execute a series of operational steps, thereby enabling the computer implementation method. As a result, the instructions thus executed instantiate the method specified in the flowcharts and / or descriptions of the computer implementation method contained herein (collectively referred to as 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 executing the Method of the Invention may be stored in backup management code 180 in persistent storage 113.

[0026] The communication fabric 111 is a signal conduction path that enables various components of the computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths, such as optical fiber communication paths and / or wireless communication paths, may be used.

[0027] The volatile memory 112 is any type of volatile memory currently 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 mandatory unless explicitly stated. In computer 101, the volatile memory 112 is located in a single package and resides inside computer 101, but alternatively or additionally, the volatile memory may be distributed across multiple packages and / or located externally to computer 101.

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

[0029] The peripheral device set 114 includes a set of peripheral devices for the computer 101. Data communication connections between the computer 101's peripheral devices and other components can be implemented in various ways, including Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insertable 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, the UI device set 123 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic devices. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, when computer 101 locally stores and manages a large database), this storage may 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 may be used in an Internet of Things application. For example, one sensor may be a thermometer and another may be a motion detector.

[0030] The network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the 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 the network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for performing the methods of the present invention can typically be downloaded from an external computer or external storage device to computer 101 via a network adapter card or network interface included in the network module 115.

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

[0032] An end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., an enterprise customer operating computer 101) and can take any of the forms described above in relation to computer 101. EUD 103 typically receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to an end-user, these recommendations would typically be transmitted from computer 101's network module 115 to EUD 103 via WAN 102. In this way, EUD 103 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, and desktop computer or similar.

[0033] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0034] The public cloud 105 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 142, which is the universe of physical computers available in and / or to the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. These VCEs may be stored as images and are understood to be transferable either as images or after instantiation of the VCE, among and between various physical machine hosts. The cloud orchestration module 141 manages the transfer and storage of images, deploys new VCE instances, and manages active instances of the VCE deployment. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate over the WAN 102.

[0035] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known 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 for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave as actual computers from the perspective of the programs running in them. Computer programs running on a normal operating system can utilize all the resources of that computer, including connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0036] The private cloud 106 is similar to the public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown as communicating with the WAN 102, in other embodiments, the private cloud may be completely isolated from the internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains an independent entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configured clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0037] Figure 2 shows an exemplary environment 200 in which embodiments of the present disclosure may be implemented. In the illustrated example, the 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 servers 225, individual computers 230, virtual machines 235, or mobile devices 240), and one or more storage devices 215 (e.g., network storage or cloud storage).

[0038] In the illustrated example, the backup management server (BMS) 205 is directly or indirectly connected to the client device 210, the data source system 220, and the storage device 215 via the network 245. That is, the BMS 205, the client device 210, the data source system 220, and the storage device 215 may each be implemented using separate hardware systems. The network 245 may include or correspond to a wide area network (WAN), a local area network (LAN), the internet, an intranet, or any combination of suitable available communication media, and may include wired, wireless, or a combination of wired and wireless links. The network 245 provides connectivity for various systems, components, or resources within the environment 200 and may be implemented using protocols such as the Transmission Control Protocol (TCP) and / or the Internet Protocol (IP). In some embodiments, the BMS205, client device 210, data source system 220, and storage device 215 may be local to each other (e.g., they may reside on the same local network and / or within the same hardware system) and may communicate with each other using any suitable local communication medium, such as a local area network (LAN) (including a wireless local area network (WLAN)), wired connection, wireless link, or intranet. In some embodiments, environment 200 represents a cloud computing environment, and the BMS205, client device 210, data source system 220, and storage device 215 may operate through a centralized cloud computing platform.

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

[0040] In some embodiments, the BMS205 may allow an administrator to define and adjust backup policies through a client device 210. The administrator may use the client device 210 to send inputs / commands to the BMS205. Within these inputs / commands, the administrator may set a schedule for when backups should be performed (e.g., at regular intervals or based on specific events), adjust the backup frequency, specify the storage devices to be used, and / or define the period for which backups should be retained before being deleted or overwritten.

[0041] In some embodiments, the BMS205 may generate outputs / notifications regarding security incident metrics, detected potential breaches or intrusions, and / or one or more predefined thresholds and / or comparison results with previous backups. In some embodiments, the BMS205 may send outputs / notifications to client devices 210 to inform administrators (e.g., other users responsible for security or system administration) about the backup status of each data source, potential security threats or breaches, and / or proactive actions that may be taken in response to potential breaches. In some embodiments, the BMS205 may send outputs / notifications to the system logs of each data source system 220. In some embodiments, if the affected data source system is part of a clustered network or environment and shares associations with other computing systems, the BMS205 may send outputs / notifications to all associated computing systems within that cluster. Upon receiving the outputs / notifications, the associated computing systems may learn about potential breaches (e.g., potential security threats or breaches) in the affected data source system. Based on the output / notification, the associated computing system (or BMS205) may appropriately tag its backups and / or adjust their backup frequency accordingly to mitigate the risk of a potential breach spreading through the network or clustering. In some embodiments, if exemplary environment 200 is part of a global redundant system with disaster recovery failover sites, BMS205 may send output / notifications to all other sites within that system, continuously informing all other sites in the global redundant system about the backup status and / or potential threats or breaches in exemplary environment 200. Relying on the output / notifications, the other sites in the global redundant system may adjust their synchronization or backup policies to match the potential risks.For example, if the compromise confidence score of a backup in storage device 215 is higher than the score of a backup at another site, indicating a lower security status, the other site may delay or refrain from replicating data with the potentially compromised site.

[0042] In some embodiments, the BMS205 may send alerts to the client device 210, the data source's system log, or other associated devices if a backup fails or other critical event occurs, such as an uncompromised backup being overwritten.

[0043] Figures 3A and 3B illustrate exemplary methods 300 for dynamic backup management according to several embodiments of the present disclosure. In some embodiments, methods 300A in Figure 3A and 300B in Figure 3B (collectively forming method 300) may be performed by one or more backup management systems, such as the computer 101 shown in Figure 1, the backup management server (BMS) 205 shown in Figure 2, and / or the computing device 700 shown in Figure 7.

[0044] Method 300 begins in block 305, where a backup management system (e.g., 205 in Figure 2) tracks and collects security incident metrics relating to a computing system (also referred to in some embodiments as a data source system) (e.g., 220 in Figure 2) whose data is being backed up. In some embodiments, these security incident metrics may be collected continuously or at predefined intervals from various sources within the computing system. In some embodiments, security incident metrics may include system anomalies, intrusion detection data, indicators of breach, and / or other parameters / metrics indicating the security status of the system. As used herein, “system anomaly” may refer to an unusual or unexpected operation or pattern within the system that deviates from the normal or expected operation of the system, such as a sudden surge in network traffic, an unusual delay, an unexpected reboot, an unusual level of data access or usage, and the like. 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 breaches. Intrusion Detection Data may include network traffic, system logs, and application activity. As used herein, “Indicators of a Breach” may refer to data indicating that a security incident has occurred or may be occurring in a system. Indicators of a breach may include, among other things, unusual outbound network traffic, anomalies in privileged user account activity, geographical irregularities, login warning flags, and / or increased database read volumes.

[0045] In block 310, the backup management system checks the backup configuration to determine whether a backup action has been triggered (for example, based on predefined trigger criteria). If the system determines that the predefined trigger criteria have been met, method 300 proceeds to block 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 collects security incident metrics until the criteria are met. In some embodiments, the predefined trigger criteria are time-based and may occur at regular time intervals (e.g., hourly, daily, weekly, or monthly). The backup management system may check a 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 trigger criteria are event-based, where the backup process is triggered when one or more specific events occur. A variety of events, such as system shutdown, user logout, or completion of a specific task, may be set as backup triggers within an event-based system. In some embodiments, backups may be triggered based on the security metrics described above (for example, if a metric is equal to or exceeds a predefined threshold, it may indicate a potential security incident). For instance, if a sudden spike in the network exceeds a certain limit within a specified period, it may indicate a potential attack or intrusion, and the backup management system may trigger an immediate backup to prevent potential data loss in the event of a successful attack.

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

[0047] In block 320, the backup management system evaluates the collected security metrics to generate a compromise confidence score (also referred to in some embodiments as the compromise confidence level). The compromise confidence score serves as a practical indicator for quantifying the overall security state of the data source system at the time the current backup (e.g., backup N) was created. In some embodiments, the confidence score may quantify the overall security state of the data source system over the period between the previous backup (e.g., backup N-1) and the current backup (e.g., backup N). In some embodiments, the compromise confidence score (= compromise confidence level) operates on a scale where a lower score indicates a lower probability of system compromise. In other words, a lower compromise confidence score indicates a higher level of confidence that the backup data has not been compromised and is therefore secure. In some embodiments, the compromise confidence score may be calculated based on a single metric (e.g., system anomalies, intrusion detection data, and / or indicators of compromise). For example, the compromise confidence score may be calculated by considering the presence (or absence) and / or severity of detected system anomalies. In some embodiments, a breach confidence score may be generated based on a combination of various metrics. The algorithms and weightings used to calculate this score will be designed according to the infrastructure of the data source system, its risk tolerance, the confidentiality of the data it handles, and / or the specific threat model it employs. For example, for a system with numerous publicly accessible interfaces, the score may place more emphasis (or weight) on network intrusion detection data. In contrast, for a system protected behind a firewall, greater weight may be given to internal anomalies or normal system behavior when calculating the final breach confidence score.

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

[0049] In block 330, the backup management system compares the compromise confidence score of the current backup (e.g., backup N) to an evaluation criterion (also referred to in some embodiments as a dynamic backup policy criterion). In some embodiments, the backup criterion includes a predefined maximum tolerance threshold, which represents the highest acceptable level of compromise risk that a particular data source system (or administrator of the source system) would dare to tolerate. If the compromise confidence score of the current backup (e.g., backup N) exceeds (or is equal to) the threshold, it indicates a high probability of a system compromise at the time the backup was created, which may trigger a significant security concern. In response, method 300 proceeds to block 335, where the backup management system flags the current backup (e.g., backup N) and the backup immediately preceding the current backup (e.g., backup N-1) for future forensic analysis and stores the flagged backups. That is, the backup management system may refrain from deleting or removing the current backup (backup N) and the preceding backup (backup N-1) even if an existing policy would result in their deletion (e.g., after a certain period of time or after additional backups have been created). In some embodiments, the system may store associated security metrics, breach confidence scores, and any other relevant metadata along with the data backups for future forensic analysis. In some embodiments, the maximum permissible threshold may be adjusted according to the specific risk tolerance of the backup management system and data source system, the confidentiality of the data being handled, and / or regulatory requirements. For conceptual clarification, we have discussed flagging and retraining two backups (e.g., backup N and backup N-1), but in some embodiments, the backup management system may also flag and retain additional backups, e.g., the three most recent backups (e.g., backup N-1, backup N-2, and backup N-3).

[0050] If the breach confidence score does not meet the backup criteria (e.g., below a predefined maximum acceptable threshold), it indicates that the data source system was within an acceptable risk level when the current backup was created, suggesting a lower probability of system breach. In response, the method proceeds to block 340, where the backup management system compares the breach confidence score of the current backup (e.g., backup N) to 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 breach 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 breach), the method proceeds to block 345, where the backup management system flags and retains the current backup (e.g., backup N). In some embodiments, the backup management system may flag backups as “high confidence” or “most secure.” In some embodiments, the backup management system may store flagged backups in storage with policies configured to prevent them from being discarded or overwritten by backups with higher compromise scores, regardless of backup retention policies (which may otherwise result in the oldest backup being deleted each time a new backup is created). In some embodiments, the backup management system may store associated security metrics, compromise confidence scores, and any other relevant metadata along with the flagged backup data for future analysis or recovery operations. If the compromise confidence score of the current backup (e.g., backup N) is not the lowest among all existing backups (to 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 stored in storage (e.g., backup N) may be replaced with a newer backup when a newer backup becomes available, or when other policy-based conditions are met, such as insufficient storage space or when a cleanup trigger is initiated.

[0051] Returning to block 335, method 300 then proceeds to block 355 (Figure 3B), where the backup management system performs a detailed forensic analysis on flagged backups (e.g., the current backup N and its immediately preceding backup (N-1)) and their respective metadata (e.g., security incident metrics, breach confidence score). The forensic analysis is configured to detect or determine whether a security breach or intrusion has occurred and / or whether a particular security concern has arisen and its corresponding impact. In some embodiments, the forensic analysis may involve comparing the states of two adjacent backups to identify significant changes and / or analyzing these changes to identify signals that potentially indicate a security incident. In some embodiments, the forensic analysis may involve using sophisticated algorithms or machine learning (ML) models to detect breaches or intrusions. For example, an ML model may be trained on relatively large amounts of data to learn patterns of normal behavior within a data source system. At runtime, the trained ML model may take flagged backups (e.g., backups N and (N-1)) and their associated metadata (e.g., security incident metrics, breach confidence score) as input. The ML model processes this data to identify patterns that deviate from normal, expected behavior, which may indicate that a breach has occurred or a security issue has arisen. In some embodiments, the output of the ML model may be a prediction of the likelihood of a breach or intrusion, e.g., a probability score, where a higher value indicates a higher likelihood of a breach or intrusion. In some embodiments, the output of the ML model may be binary classification. For example, the output may classify the state of the current backup as "normal" or "abnormal," where an abnormal output indicates the presence of a breach or intrusion. In some embodiments, the output of the ML model may further include recommended proactive actions to be taken in response to a detected breach or intrusion.For example, if a high probability of infringement is determined, the model may suggest generating an immediate backup of the data source system, initiating an immediate investigation, and / or sending an alert to the relevant responsible party.

[0052] In block 360, the backup management system determines whether a breach or intrusion has occurred (or is likely to occur) based on an analysis of the backups and their associated metadata. If the system determines that a particular breach or intrusion is likely to occur (for example, the likelihood of a breach or intrusion exceeds a predefined threshold or the current backup is classified as “abnormal”), method 300 proceeds to block 365, where the backup management system generates a notification. Otherwise, method 300 returns to block 305, where the backup management system continues to monitor the data source and collect security incident metrics. In some embodiments, the process shown from block 305 to block 365 is repeated for each of the N+1 backups, and after evaluating and comparing the confidence levels of the breach, the backup policy of the computing system may be modified.

[0053] In some embodiments, method 300 skips block 360, where the backup management system generates a notification regardless of the detection of any potential breach or intrusion. In some embodiments, the notification may include security incident metrics for the flagged backup, the detection of any potential breach or intrusion, and / or the result of a comparison between the breach score and one or more predefined thresholds (e.g., the result of a comparison between the breach score of backup N and a predefined maximum acceptable threshold, or the result of a comparison between the breach score of backup N and the breach scores from all existing backups). In some embodiments, the notification may also include recommended proactive actions that may be taken in response to the potential threat or breach.

[0054] The generated notification may be sent to various recipient parties. For example, in some embodiments, the notification may be sent to a client device (e.g., 210 in Figure 2) to inform an administrator of the security status of the data source system. In some embodiments, the notification may be sent to the system log of the data source system. In some embodiments, if the affected data source system is part of a clustered network or computing environment, the notification may be sent to all other computing systems in the cluster. In some embodiments, if the backup management system is part of a global redundant system with disaster recovery failover sites, the notification may be sent to all other sites in the system. After sending the notification, method 300 returns to block 305, where the backup system continues to monitor the data source and collect security incident metrics. In some embodiments, in addition to sending the notification, the backup management system may implement other proactive actions in response to the detected threat or breach. For example, the backup management system may generate an immediate backup of the data source system and retain this 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 signs of malicious activity. In addition, the system can increase the frequency of backups during high-risk periods to ensure that a secure and uncompromised copy of the data is maintained.

[0055] Figure 4 shows an exemplary method 400 for dynamic backup management based on changes in breach confidence, according to several embodiments of the present disclosure. In some embodiments, the method 400 of Figure 4 may be performed by one or more backup management systems, such as the computer 101 shown in Figure 1, the backup management server (BMS) 245 shown in Figure 2, and / or the computing device 700 shown in Figure 6. As shown herein, steps 405-425 of blocks in method 400 are substantially identical to steps 305-325 of blocks in method 300. In some embodiments, the method 300 of Figure 3 and the method 400 of Figure 4 may be combined and performed jointly by one or more backup management systems, such as the computer 101 shown in Figure 1, the backup management server (BMS) 245 shown in Figure 2, and / or the computing device 700 shown in Figure 6.

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

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

[0058] In block 420, the backup management system generates a breach confidence score (also referred to as the breach confidence level in some embodiments) based on one or more collected security metrics. In some embodiments, the breach confidence score (= breach confidence level) may be used to quantify the overall security level of the data source system at the time the current backup (e.g., backup N) was created. A lower breach confidence score may indicate a lower probability of system breach and therefore suggest a higher level of system security. For example, a data backup with a breach confidence score of 10% suggests that the system has higher integrity compared to another backup with a breach confidence score of 20%. In some embodiments, a significant increase in the breach confidence score between two adjacent backups (e.g., backup N and (N-1)), for example from 10% to 30%, may suggest the occurrence of a potential breach or intrusion. A significant increase in the score serves as an alert to the backup management system, indicating an increased risk requiring further analysis and investigation.

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

[0060] In block 430, the backup management system identifies whether there has been a significant increase in the compromise confidence score between two adjacent backups. In some embodiments, the identification process may begin by comparing the compromise confidence score of the current backup (e.g., backup N) with the compromise confidence score of the previous backup (e.g., backup N-1) to calculate the increase between the two backups. After the increase (or change) is calculated, the system may then compare the increase (or change) to a significance criterion. In some embodiments, the significance criterion may include a predefined significance threshold that serves to distinguish between a “normal” or “acceptable” increase in the confidence score and a “significant” increase that suggests a potential system breach (e.g., a policy breach or intrusion). In some embodiments, the predefined significance threshold may be determined based on a variety of 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 confidentiality of the data being handled, historical data on compromise confidence scores, and / or regulatory requirements.

[0061] If the increase meets a significance criterion (e.g., exceeds (or is equal to) a predefined significance threshold) and indicates a significant increase in the compromise confidence score between the current backup (e.g., backup N) and the previous backup (e.g., backup N-1), method 400 proceeds to block 435. In block 435, the backup management system flags two adjacent backups (e.g., backups N and (N-1)) for future forensic analysis and stores the flagged backups. If the increase falls below a predefined significance threshold and indicates no significant increase in the compromise confidence score, method 400 returns to block 405, where the backup management system continues to monitor the data source system and collect relevant security incident metrics.

[0062] In block 440, the backup management system analyzes flagged backups (e.g., backups N and (N-1)) and their respective metadata (e.g., security incident metrics, breach confidence score) to detect the occurrence of a potential breach or intrusion (e.g., and / or their scope and impact). In some embodiments, the forensic analysis may involve the use of sophisticated algorithms or machine learning (ML) models to detect a potential breach or intrusion.

[0063] In block 445, the backup management system determines, based on the analysis results from block 440, whether a breach or intrusion has occurred (or is likely to occur). If the system determines that a particular breach or intrusion is likely to occur (for example, the likelihood of a breach or intrusion exceeds a defined threshold or the current backup is classified as “abnormal”), method 400 proceeds to block 450, where the backup management system generates and sends a notification to the responsible party. Otherwise, method 400 returns to block 405, where the backup system continues to monitor the data source and collect security incident metrics. In some embodiments, the process shown from block 405 to block 450 is repeated for each of N+1 backups, and after evaluating and comparing the confidence levels of the breach, the backup policy of the computing system may be modified.

[0064] In some embodiments, Method 400 skips block 445, where the backup management system generates a notification regardless of the detection of any potential breach or intrusion. In some embodiments, the notification may include security incident metrics for flagged backups, detection of any potential breach or intrusion, an increase in the breach confidence score, and / or a determination of the significance of such increase. The notification may be sent to various parties, such as the data source system, administrators (e.g., through client devices), other computing systems in the same clustered network, and / or other sites of the global redundant system. In some embodiments, in addition to sending a notification, the backup management system may take 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 into malicious activity, and / or modifying the current backup policy (e.g., increasing the frequency of backups during high-risk periods).

[0065] Figure 5 shows a flowchart illustrating an exemplary method 500 for adjusting a backup policy based on one or more security incident metrics, according to some embodiments of the present disclosure.

[0066] Method 500 begins in block 505, where a backup management system (e.g., BMS205 in Figure 2) generates a first backup of a computing system (e.g., data source220 in Figure 2) at a first point in time (as shown in block 315 in Figure 3).

[0067] In block 510, the backup management system generates a first confidence level of compromise for the computing system (e.g., data source 220 in Figure 2) at a first point in time (as shown in block 320 in Figure 3).

[0068] In block 515, the backup management system stores a first backup along with metadata (as shown in block 325 of Figure 3), where the metadata includes a first confidence level of breach of the computing system (e.g., data source 220 in Figure 2) at a first point in time. In one embodiment, the first confidence level of breach is determined at least in part on an indicator of system anomaly, intrusion detection, or breach.

[0069] In block 520, the backup management system evaluates the confidence level of a first breach (as shown in block 330 of Figure 3) based on one or more backup criteria. In response to the evaluation result, the backup management system modifies the backup policy of the computing system. In one embodiment, the process of modifying the backup policy includes storing a first backup and a second backup (as shown in block 335 of Figure 3) for forensic analysis if it is determined that the confidence level of a first breach satisfies one or more backup criteria, where the second backup corresponds to the backup immediately preceding the first backup. In another embodiment, the process of modifying the backup policy includes retaining a backup of the first data (as shown in block 345 of Figure 3) if it is determined that the confidence level of a first breach is minimal across multiple existing backups of the computing system.

[0070] In some embodiments, the backup management system further generates a second backup of the computing system at a second point in time, where the second backup is the backup immediately preceding the first backup; stores the second backup along with metadata, where the metadata includes the confidence level of a second breach of the computing system at the second point in time; and can compare the increase from the confidence level of a second breach to the confidence level of a first breach to one or more importance criteria (as shown in block 430 of Figure 4). In some embodiments, the backup management system can store the first and second backups for forensic analysis (as shown in block 435 of Figure 4) if it determines that the increase satisfies one or more importance criteria.

[0071] In some embodiments, the backup management system may further analyze the first and second backups (as shown in block 355 of Figure 3) to detect potential breaches and, in response to the detection of a potential breach, initiate an immediate backup of the computing system. In some embodiments, the process of initiating an immediate backup of the computing system may include at least one of obtaining 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 further notifies one or more other computing systems (as shown in block 365 of Figure 3), where one or more other computing systems reside together in a clustered system. In some embodiments, upon receiving the notification, each of the one or more other computing systems may tag at least one of its backups with metadata indicating the modified backup policy and evaluation results, and may adjust the backup frequency in response to the modified backup policy and evaluation results.

[0073] Figure 6 shows a flowchart illustrating an exemplary method 600 for adjusting a backup policy when a significant change in the confidence level of a breach is detected, according to several embodiments of the present disclosure.

[0074] Method 600 begins in block 605, where a backup management system (e.g., BMS205 in Figure 2) generates a first backup of a computing system (e.g., data source220 in Figure 2) at a first point in time (as shown in block 415 in Figure 4).

[0075] In block 610, the backup management system generates a first confidence level of breach for the computing system (e.g., data source 220 in Figure 2) for a first point in time (as shown in block 420 in Figure 4).

[0076] In block 615, the backup management system stores a first backup along with metadata (as shown in block 425 of Figure 4), where the metadata includes a confidence level of a first breach of the computing system (e.g., data source 220 in Figure 2) at a first point in time.

[0077] In block 620, the backup management system generates a second backup of the computing system at a second point in time, where the second backup is the backup immediately preceding the first backup.

[0078] In block 625, the backup management system stores a second backup along with metadata, the metadata including a confidence level of a second breach of the computing system at a second point in time. In one embodiment, the confidence levels of the first and second breaches are determined at least in part on an indicator of system anomaly, intrusion detection, or breach.

[0079] In block 630, the backup management system compares the increase from the confidence level of the second breach to the confidence level of the first breach to one or more importance criteria (as shown in block 430 of Figure 4).

[0080] In block 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 the first and second backups for forensic analysis (as shown in block 435 of Figure 4) if it is determined that the increase exceeds one or more importance criteria.

[0081] In some embodiments, the backup management system may further analyze the first and second backups (as shown in block 440 of Figure 4) to detect potential breaches and, in response to the detection of a potential breach, initiate an immediate backup of the computing system. In some embodiments, the backup management system may further notify one or more other computing systems (as shown in block 450 of Figure 4), where the other computing systems reside together in a clustered system.

[0082] Figure 7 shows exemplary computing devices 700 for security metrics analysis and backup management according to several embodiments of the present disclosure. Although shown as a physical device, in embodiments the computing device 700 may be implemented using virtual devices and / or across multiple devices (e.g., in a cloud environment). The computing device 700 may be embodied as any computing device, such as the computer 101 shown in Figure 1, or the backup management server 205 shown in Figure 2.

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

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

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

[0086] Although shown as separate components for conceptual clarification, in some embodiments, the operation of the shown components (and other components not shown) may be combined or distributed across any number of components. Furthermore, although shown as software residing in memory 710, in some embodiments, the operation of the shown 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 acquisition component 750 may track and collect security-related data (also referred to in some embodiments as security incident metrics) from various sources within the data source system (e.g., 220 in Figure 2). The security-related data may take various forms, including (but not limited to) system anomalies, intrusion detection data, and breach indicators. The collected data may then be used to generate a breach confidence score and to determine a dynamic backup policy.

[0088] In one embodiment, the backup generation and management component 755 may continuously monitor and check for backup triggers and, when a backup trigger is met, communicate with the data source system to initiate the backup process. After a backup of the data (e.g., backup N) is created, the backup generation and management component 755 may calculate a breach confidence score for the backup using security metrics collected by the data collection component 750. This score may provide a quantified assessment of the overall security of the data source system at the time the backup (e.g., backup N) was created. As described above, the breach confidence score may be calculated based on a single metric (e.g., system anomaly, intrusion detection data, and / or an indicator of breach), a combination of various metrics. Along with the backup, the backup generation and management component 755 may generate metadata. The metadata may include security incident metrics collected by the data collection component 750, the generated breach confidence score, and other relevant details. The metadata may be stored together with its associated backup data and provided to the analysis component 760 for further analysis.

[0089] In one embodiment, the analysis component 760 may compare the compromise confidence score generated by the backup generation and management component 755 to one or more backup criteria. In some embodiments, the analysis component 760 may compare the compromise confidence score to a predefined maximum acceptable threshold to determine whether the current backup (e.g., backup N) meets the established security criteria. In some embodiments, the analysis component 760 may compare the score to the scores from all existing data backups to determine whether the current backup has the lowest score and is therefore likely to be the least compromised and have higher integrity across all other backups. In some embodiments, the analysis component 760 may compare the score to the score from the previous backup (e.g., backup N-1) to determine trends in system security. The previous backup (e.g., backup N-1) may have been performed immediately before the current backup (e.g., backup N).

[0090] After the comparison is complete, in some embodiments, the analysis component 760 transmits the comparison results to the backup generation and management component 755, which, upon receiving the results, adjusts the backup policy as necessary. Such adjustments may include changing the backup interval, retaining certain backups regardless of the retention policy, and / or marking certain backups for future forensic analysis. For example, in some embodiments, if the analysis component 760 determines that the score of the current backup (e.g., backup N) is higher than (or equal to) the maximum acceptable threshold, the backup generation and management component 755 may take snapshots of the current backup (e.g., backup N) and the previous 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 and management component 755 may retain the current backup (e.g., backup N) and adjust the policy to prevent it from being discarded or overwritten by new backups with higher compromise scores, regardless of the backup retention policy. In some embodiments, if the increase between the current backup (e.g., backup N) and the previous backup (e.g., backup N-1) is calculated and determined to exceed (or be equal to) a predefined importance threshold, suggesting a potential system breach, backup generation and management may save and flag the two adjacent backups for future forensic analysis.

[0091] In one embodiment, after backups suggesting a potential system breach are flagged and stored, the analysis component 760 may perform a detailed forensic analysis on the flagged backups (e.g., the current backup N and its immediately preceding backup (N-1)) and their respective metadata (e.g., security incident metrics, breach confidence score) to detect whether a breach or intrusion has occurred. In some embodiments, the analysis component 760 may use a trained ML model to investigate patterns, anomalies, and deviations from an established baseline in the backup data. As described above, in some embodiments, the ML model may generate predictions (e.g., probability scores) of the likelihood of a breach or intrusion occurring. In some embodiments, the output of the ML model includes a binary classification that categorizes backups as "normal" or "abnormal," where an abnormal output indicates the presence of a breach or intrusion. In some embodiments, the output of the ML model may further include, in response, recommended proactive actions that may be taken to mitigate the impact of the 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. Based on the received analysis results, the backup generation and management component 755 may take proactive action in response to the 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 and send notifications to relevant parties such as the system logs of the data source system (e.g., 220 in Figure 2) and client devices (e.g., 210 in Figure 2). In some embodiments, if the affected data source system is associated with a clustered network or other computing systems in the environment, the backup generation and management component 755 may instruct the notification generation component 765 to send notifications to all associated computing systems. In some embodiments, the notification may include details of the forensic analysis, detection of any potential breach or intrusion, the security status of the data source system (e.g., security incident metrics, breach confidence score), and / or the results of a comparison between the breach score and one or more predefined thresholds. Upon receiving a notification, the associated computing systems can evaluate the reported information and adjust their backup policies accordingly. For example, if a data source system's breach confidence score shows a significant increase, indicating a heightened risk, other systems may decide to increase their backup frequency, perform internal checks, and / or take other security measures to prevent breaches or intrusions. In some embodiments, if a global redundant system with disaster recovery failover sites is involved, the backup generation and management component 755 may instruct the notification generation component 765 to send notifications to all other sites in the system. Based on the notifications, the other sites in the global redundant system may adjust their synchronization policies to match the reported potential risks.For example, if a data source system's breach confidence score is higher than the score in backups of other sites, indicating a lower level of security, the other sites may delay or refrain from replicating their data.

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

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

[0095] The following refers to embodiments presented in this disclosure. However, the scope of this disclosure is not limited to any specific described embodiment. Instead, any combination of the following features and elements, whether related to a different embodiment or not, is intended to implement and practice the intended embodiment. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether a particular advantage is achieved by a given embodiment does not limit the scope of this disclosure. Accordingly, the following aspects, features, embodiments and advantages are merely illustrative and shall not be considered elements or limitations of the appended claims unless expressly stated in the claims. Similarly, references to “the present invention” shall not be construed as a generalization of the subject matter of any invention disclosed herein and shall not be considered elements or limitations of the appended claims unless expressly stated in the claims.

[0096] Various aspects of this disclosure are described by explanatory text, flowcharts, data block diagrams of computer systems, and / or data block diagrams of machine logic included in embodiments of computer program products (CPPs). With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, again depending on the technology involved, two operations shown in data blocks of a consecutive flowchart may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial time overlap.

[0097] Embodiments of a computer program product ("CPP Embodiment" or "CPP") are terms used in this disclosure to describe any set of one or more storage media (also called "mediums") that collectively comprise a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. "Storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include diskettes, 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 disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be interpreted as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media.As will be understood by those skilled in the art, data is normally moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, since data is not transient while it is stored, this does not mean that the storage device is transient.

[0098] While the foregoing describes embodiments of the present invention, other and further embodiments of the present invention can be devised without departing from the basic scope of the present invention, and the scope of the present invention is defined by the following claims.

Claims

1. At the first point in time, the stage of generating a first backup of the computing system; With respect to the first time point, the step of generating a first confidence level of breach of the computing system; A step of storing the first backup along with metadata including the confidence level of the first breach of the computing system at the first time point; and Steps to modify the backup policy of the computing system in response to an assessment of the confidence level of the first breach based on one or more dynamic backup policy criteria: A method for providing this.

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

3. The step of modifying the backup policy of the computing system includes, when it is determined that the confidence level of the first breach satisfies the one or more dynamic backup policy criteria, storing the first backup and the second backup for forensic analysis, wherein the second backup corresponds to the backup immediately preceding the first backup. The method according to claim 1.

4. The method according to claim 1, wherein the step of modifying the backup policy of the computing system comprises the step of retaining the first backup of data if it is determined that the confidence level of the first breach is minimal across a plurality of existing backups of the computing system.

5. At a second point in time, a second backup of the computing system is generated, wherein the second backup is the backup immediately preceding the first backup; A step of storing the second backup along with metadata including the confidence level of the second breach of the computing system at the second point in time; and The step of comparing the increase from the second confidence level of infringement to the first confidence level of infringement with one or more materiality criteria. The method according to claim 1, further comprising:

6. The method according to claim 5, wherein the step of modifying the backup policy of the computing system comprises the step of retaining the first backup and the second backup for forensic analysis if it is determined that the increase meets the one or more importance criteria.

7. The step of detecting a potential breach by analyzing the confidence levels of the breaches of the first and second backups; and Step 1: In response to the detection of the potential breach, initiate an immediate backup of the computing system. The method according to claim 3, further comprising:

8. The method according to claim 7, wherein the step of initiating an immediate backup of the computing system comprises at least one of the following steps: obtaining 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 step of notifying one or more other computing systems of the modified backup policy and evaluation results, wherein the one or more other computing systems are located in a clustered system together with the computing system.

10. The method according to claim 1, further comprising the step of 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 with the computing system to the data stored in one or more backup sets.

11. One or more computer processors; and One or more memory Equipped with, The one or more memory units collectively contain one or more programs that perform an operation when executed by the one or more computer processors, and the operation is: A procedure for generating a first backup of the computing system at a first point in time; A procedure for generating a first confidence level of breach of the computing system for the first time point; A procedure for storing the first backup along with metadata including the confidence level of the first breach of the computing system at the first point in time; and A procedure for modifying the backup policy of the computing system in response to an assessment of the confidence level of the first breach based on one or more dynamic backup policy criteria. A system that includes this.

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

13. The system according to claim 11, wherein the procedure for modifying the backup policy of the computing system includes, when it is determined that the confidence level of the first breach satisfies the one or more dynamic backup policy criteria, the procedure for storing the first backup and the second backup for forensic analysis, wherein the second backup corresponds to the backup immediately preceding the first backup.

14. The aforementioned operation is: A procedure for generating a second backup of the computing system at a second point in time, wherein the second backup is the backup immediately preceding the first backup; A procedure for storing the second backup along with metadata including the confidence level of the second breach of the computing system at the second point in time; and A procedure for comparing the increase from the second confidence level of infringement to the first confidence level of infringement with one or more materiality criteria. The system according to claim 11, further comprising:

15. The system according to claim 14, wherein the procedure for modifying the backup policy of the computing system includes the procedure for retaining the first backup and the second backup for forensic analysis if it is determined that the increase meets one or more importance criteria.

16. The system according to claim 11, wherein the operation further includes a step of notifying one or more other computing systems of the modified backup policy and evaluation results, the one or more other computing systems being located in a clustered system together with the computing system.

17. A computer program product comprising one or more computer-readable storage media, wherein the one or more computer-readable storage media collectively contain computer-readable program code, and the computer-readable program code, when executed by the operation of one or more computer processors, A procedure for generating a first backup of the computing system at a first point in time; A procedure for generating a first confidence level of breach of the computing system for the first time point; A procedure for storing the first backup along with metadata including the confidence level of the first breach of the computing system at the first point in time; and A procedure for modifying the backup policy of the computing system in response to an assessment of the confidence level of the first breach based on one or more dynamic backup policy criteria. A computer program product that performs actions including those mentioned above.

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

19. At the first point in time, the stage of generating a first backup of the computing system; With respect to the first time point, the step of generating a first confidence level of breach of the computing system; A step of storing the first backup along with metadata including the confidence level of the first breach of the computing system at the first time point; and At a second point in time, a second backup of the computing system is generated, wherein the second backup is the backup immediately preceding the first backup; A step of storing the second backup along with metadata including the confidence level of the second breach of the computing system at the second point in time; A step of comparing the increase from the second confidence level of infringement to the first confidence level of infringement with one or more materiality criteria; and Steps to modify the backup policy of the computing system in response to the comparison results. A method for providing this.

20. One or more computer processors; and One or more memory Equipped with, The one or more memory units collectively contain one or more programs that perform an operation when executed by the one or more computer processors, and the operation is: A procedure for generating a first backup of the computing system at a first point in time; A procedure for generating a first confidence level of breach of the computing system for the first time point; A procedure for storing the first backup along with metadata including the confidence level of the first breach of the computing system at the first point in time; and A procedure for generating a second backup of the computing system at a second point in time, wherein the second backup is the backup immediately preceding the first backup; A procedure for storing the second backup along with metadata including the confidence level of the second breach of the computing system at the second point in time; A procedure for comparing the increase from the second confidence level of infringement to the first confidence level of infringement with one or more materiality criteria; and Procedure for modifying the backup policy of the computing system in response to the comparison results. A system that includes this.

Images