Patent Description:
Vulnerability scans are performed periodically to discover and resolve security risks on a computer system. For example, the computer system is scanned to identify known weaknesses in applications of the computer system. Weaknesses in applications of the computer system include any defect which leaves the system open to attacks or allows information stored in the system to be exposed to a threat. Vulnerabilities include, for example, bugs, weak passwords, missing data encryption, buffer overflow, missing authorization, use of broken algorithms, path traversal, missing authentication for critical functions of the applications, dependence on untrusted inputs in a security decision, and so forth. Vulnerabilities such as these may be introduced during general operation of the computer system, such as when data is processed and stored in the system. Vulnerabilities may also be introduced when new workloads, including applications, virtual machines, databases, and so forth, are run on the computer system. Workloads can be loaded onto the computer system from external providers. Publicly known information-security vulnerabilities are tracked in the Common Vulnerabilities and Exposures (CVE) system, which is maintained by the National Cybersecurity FFRDC.

A computing system that is scanned for vulnerabilities may be a primary system handling live production data. Performing a vulnerability scan on the primary system may strain system resources and cause the primary system to encounter performance issues. This may cause administrators of the primary system to reduce the frequency of vulnerability scans or worse not perform vulnerability scans to not reduce the performance of the primary system. This increases the chance of the primary system being compromised. Other systems may install on the primary system an agent to perform a vulnerability scan. However, the agent may need to be maintained with one or more update patches, which may result in downtime associated with the primary system.

Where applications and computer hardware are managed on-premises, an operator typically has the capability to manage and patch any vulnerabilities. Where applications and / or computer hardware are cloud-based, as is the case for e.g. Software as a Service (SaaS), an operator of an enterprise that utilizes the applications is likely to have less control over computing infrastructure and configuration of the applications that run on that infrastructure. When SaaS applications are updated, new vulnerabilities may be introduced which were not present in previous versions of the applications.

<CIT> relates to vulnerability assessment of images. <CIT> relates to improving network security threat detection and response in cloud environments hosting containers.

According to a first aspect of the invention, there is provided a method as defined by appended claim <NUM>. According to a second aspect, there is provided a computer program product as defined by appended claim <NUM>. According to a third aspect, there is provided a system as defined by appended claim <NUM>.

A primary system may host one or more workloads. An example of a workload is an application, a virtual machine, a container, a pod, a database, etc. The primary system may be coupled to a storage system. The primary system may be configured to perform a backup snapshot of its data to the storage system. The primary system may perform a backup snapshot of file system data according to a backup policy and send the backup snapshot to a storage system. A backup snapshot may represent the state of a system at a particular point in time (e.g., the state of the file system data or the state of a workload). The backup snapshot policy may require a full backup snapshot or an incremental backup snapshot to be performed. A full backup snapshot may include the entire state of the primary system at a particular point in time. An incremental backup snapshot may include the state of the primary system that has changed since a last backup snapshot of the primary system. In some embodiments, a full backup snapshot includes the entire state of a workload at a particular point in time. In some embodiments, an incremental backup snapshot includes the state of a workload that has changed since a last backup snapshot of the workload.

Backup snapshots can be used to restore one or more workloads of the primary system. Restoring a workload may include initializing the workload at the primary system, initializing a copy of the workload on another computer system, and/or migrating the workload from the primary system to the other computer system. Storing a plurality of backup snapshots allows a selection of a particular state of the one or more workloads to be made when choosing to restore a workload.

A backup snapshot policy may indicate that a backup snapshot is to be performed on a periodic basis (e.g., hourly, daily, weekly, monthly, etc.). In some embodiments, a backup snapshot policy indicates that a backup snapshot is to be backed up when a threshold size of data (e.g., a size of data associated with a primary system, a size of data associated with a workload) has changed. In some embodiments, a backup snapshot policy indicates that a backup snapshot is to be performed upon a command from a user associated with a primary system.

A storage system may receive and ingest the data included in a backup snapshot. The data included in the backup snapshot may be organized using a tree data structure as described in <CIT>. The storage system may generate and store a corresponding tree data structure for each backup snapshot.

The contents included in a backup snapshot may be indexed. For example, an index may indicate which version of an application was backed up in the backup snapshot, which version of a virtual machine was backed up in the backup snapshot, etc. The index may also indicate which portions of the backup snapshot have been scanned for vulnerabilities. For example, the index may indicate that a version of an application was scanned for vulnerabilities, a version of a virtual machine was scanned for vulnerabilities, or the entire backup snapshot was scanned for vulnerabilities.

The storage system scans at least a portion of a backup snapshot for one or more vulnerabilities. The scanned portion may correspond to one or more workloads. The storage system restores to a temporary environment one of the workloads (e.g., sandbox) and performs a vulnerability scan on the restored workload. Restoring the one or more workloads to a temporary environment enables vulnerability scans which are configured to operate on live workloads to be used when scanning the backup snapshots for vulnerabilities.

Performing a vulnerability scan may include scanning the restored backup snapshot for a plurality of vulnerability types, such as bugs, missing data encryption, buffer overflow, or any other appropriate vulnerabilities. The vulnerability scan may be configured to identify vulnerabilities in the backup snapshot which relate to known vulnerabilities such as those which are tracked by the CVE system.

In some embodiments, the scanned portion corresponds to the entire portion of the backup snapshot. The storage system may restore to a temporary environment a version of the primary system corresponding to a backup snapshot and perform a vulnerability scan on the restored version of the primary system. Advantageously, the storage system may determine the one or more vulnerabilities associated with at least a portion of the backup snapshot without having to use primary system resources to determine the one or more vulnerabilities.

The storage system is comprised of a plurality of storage nodes. Each storage node has a corresponding processor. In some embodiments, a plurality of the storage nodes perform the vulnerability scan together. In some embodiments, one of the storage nodes performs the vulnerability scan. Regardless of whether a plurality of the storage nodes or one of the storage nodes performs the vulnerability scan, the one or more storage nodes have a finite amount of resources available to perform the vulnerability scan. The one or more storage nodes may have one or more primary functionalities to perform (e.g., backing up data, replicating data, restoring data, etc.) and/or one or more other tasks (e.g., garbage collection, defragmentation, providing a test/dev environment, etc.). Performing the vulnerability scan reduces the total amount of resources available for the one or more storage nodes to perform the one or more primary functionalities and/or one or more other tasks (e.g., garbage collection, defragmentation, providing a test/dev environment, etc.). In the event a vulnerability scan is performed, the storage system may allocate a certain amount of resources to perform the vulnerability scan during the scan period (e.g., <NUM>-<NUM> minutes) and the certain amount of resources may not be re-allocated.

Depending on the frequency at which the storage system receives backup snapshot data from a primary system, it may not be practical and/or possible for the storage system to scan each of the received backup snapshots. For example, a primary system may perform a backup snapshot every hour. The amount of data that has changed between backup snapshot versions may be minimal (e.g., less than a change threshold amount). Performing a scan on at least a portion of each backup snapshot every hour may not be practical because the storage system may need to allocate the resources needed for the vulnerability scan to one or more other processes. Performing a scan on at least a portion of each backup snapshot may not be possible because the storage system has already allocated the resources needed for the vulnerability scan to one or more other processes.

The storage system assigns a corresponding scanning score to each of the backup snapshots received from a primary system. The storage system selects which of the plurality of backup snapshots to scan based on the corresponding scanning score associated with a backup snapshot. A scanning score associated with a backup snapshot may be based on a plurality of factors. For example, the scanning score may be based on a snapshot distance between a particular backup snapshot and a latest backup snapshot, a snapshot distance between the particular backup snapshot and a previous scan, a snapshot distance between the particular backup snapshot and a previous scan that included one or more critical vulnerabilities, a correlation between the state of a workload in the backup snapshot being evaluated and a state of a backup snapshot which comprises one or more vulnerabilities, and/or the amount of change associated with the particular backup snapshot. A snapshot distance may be the amount of time between backup snapshots, the number of backup snapshots in the chain of snapshot trees between the snapshot tree corresponding to the particular backup snapshot and the latest backup snapshot, etc. The scanning score associated with a backup snapshot may be periodically updated. The one or more backup snapshots with a corresponding scanning score above a threshold value may be scanned. This may ensure that an adequate sample of backup snapshots are scanned for vulnerabilities without unnecessarily taxing the resources of the storage system. In some embodiments, the storage system selects which of the plurality of backup snapshots to scan using a lottery scheduling algorithm.

At least a portion of a selected backup snapshot is restored to a temporary environment of the storage system to create a restored instance of at least a portion of the selected backup snapshot. A vulnerability scan is performed on the restored instance of at least the portion of the selected snapshot. The vulnerability scan may discover one or more vulnerabilities associated with the selected backup snapshot and assign a corresponding vulnerability score to each of the one or more discovered vulnerabilities. The assigned vulnerability score may be based on a vulnerability score assigned to a vulnerability by a government entity. For example, the government entity may use a common vulnerability scoring system (CVSS) to assign a score to a vulnerability.

The one or more vulnerabilities associated with a plurality of scanned portions of backup snapshots are tracked. By tracking vulnerabilities associated with scanned portions of backup snapshots, it becomes possible to restore a workload from a backup snapshot in a manner which identifies and/or corrects vulnerabilities that were present in the workload when the backup snapshot was generated. In this way, historic vulnerabilities which have been corrected in the primary system may not be introduced again when restoring from backup snapshots.

Tracking the one or more vulnerabilities associated with each of the plurality of scanned portions may include storing indications of the one or more vulnerabilities in a data structure, for example, the data structure may include one or more entries for each scanned portion. These stored indications can be associated with respective scanned portions of backup snapshots to which they relate. In this way, the one or more vulnerabilities associated with a given scanned portion of a backup snapshot can be identified by performing a search of the data structure based on the given scanned portion of the backup snapshot. Associating a stored indication with a respective scanned portion of a backup snapshot may include storing data identifying the portion of the backup snapshot, such as a date, time, and/or metadata associated with the backup snapshot.

The data structure for storing one or more vulnerabilities may also include entries relating to unscanned portions of backup snapshots. Tracking the one or more vulnerabilities may include, when one or more vulnerabilities are detected in a scanned portion of a selected backup snapshot, updating entries in the data structure which correspond to portions of backup snapshots which are different to the scanned portion of the selected backup snapshot. In this way, it is possible to generate and maintain information about one or more vulnerabilities which may be present in unscanned portions of backup snapshots.

Some vulnerabilities may be more critical than others. The response to a vulnerability may depend on the vulnerability score associated with the vulnerability. For example, a vulnerability having a vulnerability score less than a first threshold and greater than a minimum vulnerability score (e.g., "<NUM>") may be deemed to be non-critical and one or more remedies associated with the vulnerability may be optional. A vulnerability having a vulnerability score greater than or equal to the first threshold, but less than a second threshold may be deemed to be critical and one or more remedies may be recommended for the vulnerability. A vulnerability having a vulnerability score greater than or equal to the second threshold, but less than the maximum vulnerability score (e.g., "<NUM>") may be deemed to be very critical and one or more remedies may be required for the vulnerability. The storage system may store a data structure that associates a plurality of scanned portions of backup snapshots with their one or more corresponding vulnerabilities and corresponding vulnerability scores.

The storage system may rank the scanned portions of backup snapshots based on the one or more corresponding vulnerabilities associated with the scanned portions of backup snapshots. A scanned portion of a backup snapshot may be ranked based on the vulnerability of the one or more vulnerabilities having the highest vulnerability score. For example, a scanned portion of a backup snapshot may be associated with three vulnerabilities. The storage system may use the vulnerability of the three vulnerabilities having the highest vulnerability score to determine a ranking associated with the scanned portion of the backup snapshot.

The storage system may determine a recovery time associated with each of the scanned portions of backup snapshots. The recovery time associated with a scanned portion of a backup snapshot may be based on a specified security posture associated with a restore environment to which the data associated with a scanned portion of a backup snapshot is to be restored. For example, some restore environments may have higher security requirements than other restore environments. A restore environment with a high security posture may require all of the one or more vulnerabilities associated with a scanned portion of a backup snapshot to be remedied. A restore environment with a medium security posture may require all critical and very critical vulnerabilities to be remedied, but not any non-critical vulnerabilities. A restore environment with a low security posture may not require any of the one or more vulnerabilities to be remedied.

A scanned portion of a backup snapshot may be associated with a plurality of vulnerabilities. The storage system may filter the one or more vulnerabilities required to be remedied for the restore environment to which the data associated with a scanned portion of a backup snapshot is to be restored. For example, a scanned portion of a backup snapshot may be associated with three vulnerabilities: two very critical vulnerabilities and one non-critical vulnerability. A security posture of the restore environment may have a medium security posture and only require the two very critical vulnerabilities to be remedied. The storage system may determine the recovery time associated with the scanned portion of the backup snapshot based on the remedies associated with the two very critical vulnerabilities instead of determining the recovery time associated with the scanned portion of the backup snapshot based on all of the remedies associated with the scanned portion of the backup snapshot. This may reduce the total recovery time associated with restoring a scanned portion of a backup snapshot. In some embodiments, the storage system computes a corresponding recovery time associated with a scanned portion of a backup snapshot based on whether all of the vulnerabilities associated with a scanned portion of backup snapshot are to be remedied, whether some of the vulnerabilities associated with a scanned portion of a backup snapshot are to be remedied, and/or whether none of the vulnerabilities associated with a scanned portion of a backup snapshot are to be remedied.

The storage system may generate an ordering of the one or more remedies to be applied to the scanned portion of a backup snapshot. For example, the storage system may determine a sequence of the one or more remedies that are to be applied to the data associated with a scanned portion of a backup snapshot to restore a restore system (e.g., a primary system).

The recovery time associated with a scanned portion of a backup snapshot may be based on a roll forward time associated with restoring a restore system. The roll forward time may include the amount of time needed to provide data associated with a scanned portion of a backup snapshot from the storage system to the restore system. The roll forward time may also include the amount of time needed by the restore system to restore the system to a state associated with the scanned portion of a backup snapshot. In some embodiments, the data associated with a particular version of a virtual machine may be provided from the storage system to the restore system. In some embodiments, all of the data associated with a scanned backup snapshot is provided from the storage system to the restore system. For example, a restore system is being restored to a particular version of a primary system.

The recovery time associated with a scanned portion of a backup snapshot may be based on a cumulative patch time associated with the one or more remedies. The cumulative patch time is the amount of time needed to apply the one or more remedies to the restored data. The determined recovery time associated with each of the scanned portions of the backup snapshots may be based on the corresponding cumulative patch time associated with the one or more ordered remedies and the corresponding roll forward time associated with the scanned portions of backup snapshots.

The storage system may determine a plurality of recovery times associated with a scanned portion of a backup snapshot based on the different scenarios in which a scanned portion of a backup snapshot may be used to restore a restore system. The storage system may determine a corresponding recovery time based on the different security postures, the different roll forward times (e.g., restore different portions of a backup snapshot versus restore an entire portion of a backup snapshot), the different cumulative patch times (e.g., apply all remedies, some remedies, no remedies), and/or a combination thereof.

The storage system may receive a request associated with identifying a backup snapshot to restore. A restore system, such as a primary system, may be restored using any of the scanned portions of backup snapshots, however, a user associated with the restore system may need guidance in selecting a scanned portion of a backup snapshot. The user associated with the restore system may need guidance in selecting a version of a selected scanned portion of a backup snapshot. The restore system may request the system to be restored to a state associated with a particular day or a particular time period (e.g., range of hours, range of days, etc.).

In response to the request, the storage system may provide an interface that indicates the one or more scanned portions of backup snapshots associated with the request and their one or more corresponding vulnerabilities. The interface may display one or more entries corresponding to one or more scanned portions of backup snapshots. An entry corresponding to a scanned portion of a backup snapshot may indicate whether a vulnerability associated with a scanned portion of a backup snapshot is very critical, critical, and/or non-critical. An entry may indicate one or more recovery times associated with a scanned portion of a backup snapshot. For example, the entry may indicate a recovery time associated with restoring the scanned portion of a backup snapshot to a high security posture restore environment, a recovery time associated with restoring the scanned portion of a backup snapshot to a medium security posture restore environment, and/or a recovery time associated with restoring the scanned portion of a backup snapshot to a low security posture restore environment.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected scanned portion of a backup snapshot based on a security posture. For example, a user associated with a restore system may select a "high security posture. " In response to the selection, the storage system may update the interface to associate the one or more scanned portions of backup snapshots and their corresponding one or more recovery times in the event the selected scanned portion of a backup snapshot is restored to a restore environment having a "high security posture.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected backup snapshot based on a total amount of recovery time. For example, a user associated with the restore system may have a certain amount of time to restore the restore system. Some of the scanned portions of backup snapshots may have a corresponding recovery time that is greater than the certain amount of time. The storage system may update the interface to rank the scanned portions of backup snapshots based on the total amount of recovery time.

The storage system may also display the recovery time associated with different portions of a scanned backup snapshot. For example, the interface may indicate a recovery time associated with restoring a particular workload included in a backup snapshot. The interface may indicate a recovery time associated with restoring two of the workloads included in a backup snapshot. The interface may indicate a recovery time associated with restoring the entire backup snapshot. The interface may allow a user associated with the restore system to select the one or more workloads to restore and in response to the selection, the storage system may update the interface to indicate the corresponding recovery times associated with the selection of the one or more workloads.

A restore system may select one of the scanned portions of backup snapshots. In response to the request, the storage system may provide the data associated with the selected scanned portion of a backup snapshot. In response to receiving the data, the restore system may apply the one or more remedies associated with the selected scanned portion of a backup snapshot to the received data.

<FIG> is a block diagram illustrating a system for performing vulnerability scans in accordance with some embodiments. In the example shown, system <NUM> is comprised of a primary system <NUM> and a storage system <NUM>. Primary system <NUM> is coupled to storage system <NUM> via connection <NUM>. Connection <NUM> may be a wired or wireless connection. Connection <NUM> may be a LAN, WAN, intranet, the Internet, and/or a combination thereof.

Primary system <NUM> is a computing system that stores file system data. The file system data may include a plurality of files (e.g., content files, text files, etc.) and metadata associated with the plurality of files. Primary system <NUM> may be comprised of one or more servers, one or more computing devices, one or more storage devices, and/or a combination thereof. Primary system <NUM> may be configured to send a backup snapshot of file system data to storage system <NUM> according to one or more backup snapshot policies. In some embodiments, a backup snapshot policy indicates that file system data is to be backed up on a periodic basis (e.g., hourly, daily, weekly, monthly, etc.), when a threshold size of data has changed, or in response to a command from a user associated with primary system <NUM>. Additionally, or alternatively, the backup policy may dynamically determine when to perform a backup snapshot based on resource availability, such as memory and processor usage in the primary system <NUM>.

Primary system <NUM> may be configured to run one or more workloads <NUM>. Examples of workloads include, but are not limited to, a virtual machine, a database, an application, a container, a pod, etc. Primary system <NUM> may include one or more storage volumes (not shown) that are configured to store file system data associated with primary system <NUM>. The file system data associated with primary system <NUM> includes the data associated with the one or more workloads <NUM>.

Backup agent <NUM> may be configured to cause primary system <NUM> to perform a backup snapshot (e.g., a full backup snapshot or incremental backup snapshot). A full backup snapshot may include all of the file system data of primary system <NUM> at a particular moment in time. In some embodiments, a full backup snapshot for a particular workload of the one or more workloads <NUM> is performed and the full backup snapshot of the particular workload includes all of the workload data associated with the particular workload at a particular moment in time. In some embodiments, backup agent <NUM> is running on primary system <NUM>. In some embodiments, backup agent <NUM> is running in one of the one or more workloads <NUM>. In some embodiments, a backup agent <NUM> is running on primary system <NUM> and a separate backup agent <NUM> is running in one of the one or more workloads <NUM>. In some embodiments, a workload includes a backup function and is configured to perform a backup snapshot on its own without backup agent <NUM>.

Backup agent <NUM> may be configured to cause backup snapshots to be performed according to the storage policy. The backup agent <NUM> may receive and/or store backup policy data identifying the backup policy in order to determine when to cause the primary system <NUM> to perform a backup snapshot. In this respect, the backup agent <NUM> may instruct the primary system <NUM> to perform a full or incremental backup snapshot at predetermined intervals based on the backup policy. The backup agent <NUM> may monitor the one or more workloads <NUM> to determine when to perform a backup snapshot, for example, based on when an amount of data which has changed in the one or more workloads <NUM> has exceeded a threshold size. The backup agent <NUM> may receive data representing the availability of resources of the primary system <NUM>, for example, current memory capacity, processor usage, storage capacity, and so forth. The data representing the availability of resources may be used by the data agent <NUM> such that the backup snapshot frequency can be determined dynamically according to available resources in the primary system <NUM>.

Storage system <NUM> is comprised of a storage cluster that includes a plurality of storage nodes <NUM>, <NUM>, <NUM>. Although three storage nodes are shown, storage system <NUM> may be comprised of n storage nodes. The plurality of storage nodes may be comprised of one or more solid state drives, one or more hard disk drives, or a combination thereof. Each storage node may have its own corresponding processor. Storage system <NUM> may be configured to ingest a backup snapshot received from primary system <NUM> and configured to store the data associated with the backup snapshot across the storage cluster. Storage system <NUM> may be a cloud version of a secondary storage system as described in <CIT>.

Storage system <NUM> may receive and ingest the data associated with a backup snapshot. Storage system <NUM> may include a file system manager <NUM> that is configured to organize the file system data of the backup snapshot using a tree data structure. An example of the tree data structure is a snapshot tree, which may be based on a B+ tree structure (or other type of tree structure in other embodiments). Storage system <NUM> may generate a snapshot tree and one or more metadata structures for each backup snapshot. The contents included in a backup snapshot may be indexed. For example, an index may indicate which version of an application was backed up in the backup snapshot, which version of a virtual machine was backed up in the backup snapshot, etc. The index may also indicate which portions of the backup snapshot have been scanned for vulnerabilities. For example, the index may indicate that a version of an application was scanned for vulnerabilities, a version of a virtual machine was scanned for vulnerabilities, or the entire backup snapshot was scanned for vulnerabilities.

In the event the backup snapshot corresponds to all of the file system data of primary system <NUM>, the view corresponding to the backup snapshot may be comprised of a snapshot tree and one or more workload metadata structures. The snapshot tree may be configured to store the metadata associated with primary system <NUM>. A workload metadata structure may be configured to store the metadata associated with one of the one or more workloads <NUM>. Each of the one or more workloads <NUM> may have a corresponding metadata structure.

In the event the backup snapshot corresponds to all of the workload data of one of the one or more workloads <NUM>, the view corresponding to the backup snapshot may be comprised of a snapshot tree and one or more workload file metadata structures. The snapshot tree may be configured to store the metadata associated with one of the one or more workloads <NUM>. A workload file metadata structure may be configured to store the metadata associated with a workload file included in the workload.

The tree data structure may be used to capture different restoration points. The tree data structure allows a chain of snapshot trees to be linked together by allowing a node of a later version of a snapshot tree to reference a node of a previous version of a snapshot tree. The previous version of the snapshot tree may correspond to an earlier backup snapshot. For example, a root node or an intermediate node of a snapshot tree corresponding to a second backup snapshot may reference an intermediate node or leaf node of a snapshot tree corresponding to a first backup snapshot.

A snapshot tree is a representation of a fully hydrated restoration point because it provides a complete view of a primary system or a workload at a particular moment in time. A fully hydrated restoration point is a restoration point that is ready for use without having to reconstruct a plurality of backups to use it. Instead of reconstructing a restoration point by starting with a full backup and applying one or more data changes associated with one or more incremental backups to the data associated with the full backup, storage system <NUM> maintains fully hydrated restoration points. Any file associated with primary system <NUM> or a workload at a particular time and the file's contents, for which there is an associated reference restoration point, may be determined from the snapshot tree, regardless if the associated reference restoration was a full reference restoration point or an intermediate reference restoration point.

A snapshot tree may include a root node, one or more levels of one or more intermediate nodes associated with the root node, and one or more leaf nodes associated with an intermediate node of the lowest intermediate level. The root node of a snapshot tree may include one or more pointers to one or more intermediate nodes. Each intermediate node may include one or more pointers to other nodes (e.g., a lower intermediate node or a leaf node). A leaf node may store file system metadata, data associated with a file that is less than a limit size, an identifier of a data brick, a pointer to a metadata structure (e.g., workload metadata structure or a workload file metadata structure), a pointer to a data chunk stored on the storage cluster, node reservation information, file offset information associated with a combined metadata structure, etc..

A metadata structure (e.g., workload file metadata structure or workload metadata structure) may include a root node, one or more levels of one or more intermediate nodes associated with the root node, and one or more leaf nodes associated with an intermediate node of the lowest intermediate level. The tree data structure associated with a metadata structure allows a chain of metadata structures corresponding to different versions of a workload or a workload file to be linked together by allowing a node of a later version of a metadata structure to reference a node of a previous version of a metadata structure.

A metadata structure may be associated with a plurality of chunk files. A chunk file may be comprised of a plurality of data chunks. Metadata store <NUM> may store one or more metadata structures. In some embodiments, a metadata structure corresponds to a workload. In other embodiments, a metadata structure corresponds to a workload file. In other embodiments, a metadata structure corresponds to a portion of a workload. In other embodiments, a metadata structure corresponds to a portion of a workload file.

A leaf node of a metadata structure may store a value, such as an identifier of a data brick associated with one or more data chunks. The location of the one or more data chunks associated with a data brick may be identified using one or more data structures (e.g., list, table, etc.) stored in metadata store <NUM>. A first data structure (e.g., chunk metadata table) may store information that associates a brick identifier with one or more chunk identifiers and one or more chunk file identifiers. A second data structure (e.g., chunk file metadata table) may associate a chunk file identifier with a chunk file storing a plurality of data chunks. In some embodiments, the first data structure and the second data structure are combined as a single data structure. The one or more data chunks associated with a data brick may be located based on the chunk metadata table and the chunk file metadata table. For example, a first data brick having a first brick identifier may be associated with a first chunk identifier (e.g., SHA-<NUM> hash value). The first chunk identifier may be used in conjunction with the chunk metadata table to identify a chunk file identifier. A chunk file having the identified chunk file identifier is comprised of a plurality of data chunks. The chunk file metadata table may be used to identify a location of the plurality of data chunks. The chunk file metadata table may include offset information of the plurality of data chunks within a chunk file.

Depending on the frequency at which storage system <NUM> receives backup snapshot data from primary system <NUM>, it may not be practical and/or possible to scan each of the received backup snapshots. For example, primary system <NUM> may perform a backup snapshot every four hours. The amount of data that has changed between backup snapshot versions may be little. Performing a scan on at least a portion of each backup snapshot every four hours may not be practical because storage system <NUM> may need to allocate the resources needed for the vulnerability scan to one or more other processes. Performing a scan on at least a portion of each backup snapshot may not be possible because storage system <NUM> has already allocated the resources needed for the vulnerability scan to one or more other processes.

Storage system <NUM> stores a plurality of backup snapshots received from primary system <NUM>. It may not be practical and/or possible to scan all of the plurality of backup snapshots for vulnerabilities. Storage system <NUM> assigns a corresponding scanning score to each of the backup snapshots received from primary system <NUM>. The storage system selects which of the plurality of backup snapshots to scan based on the corresponding scanning score associated with a backup snapshot. A scanning score associated with a backup snapshot may be based on a plurality of factors. For example, the scanning score may be based on a snapshot distance between a particular backup snapshot and a latest backup snapshot, a snapshot distance between the particular backup snapshot and a previous scan, a snapshot distance between the particular backup snapshot and a previous scan that included one or more critical vulnerabilities, a correlation between the state of a workload in the backup snapshot being evaluated and a state of a backup snapshot which comprises one or more vulnerabilities, and/or the amount of change associated with the particular backup snapshot. A snapshot distance may be the amount of time between backup snapshots, the number of backup snapshots in the chain of snapshot trees between the snapshot tree corresponding to the particular backup snapshot and the latest backup snapshot, etc..

The amount of change associated with a particular backup snapshot may refer to an amount of change in the production data stored in the primary system <NUM> since a previous backup snapshot, an amount of change in the infrastructure of the primary system <NUM> since the previous backup snapshot and/or an amount of change in the configuration of one or more workloads in the primary system <NUM> since the previous backup snapshot. An amount of change in the production data stored in the primary system <NUM> may relate to a volume of data which has been stored in the primary system <NUM>, such as in one or more databases, since a previous backup snapshot was performed. In some examples, such as where the workload includes one or more databases, the amount of change in production data may be determined based on log files which track and identify transactions in the one or more databases. The amount of change in production data may be evaluated as a proportion of the total production data stored in the primary system.

An amount of change in the infrastructure of the primary system <NUM> may relate to a number of, or types of, devices which have been added to, or removed from, the primary system <NUM> since the previous backup snapshot. In examples where the addition or removal of infrastructure at the primary system <NUM> relates to the addition and/or removal of physical hardware resources such as a processor and/or memory, the amount of change in the infrastructure may be evaluated as a function of memory capacity or compute power which has changed in the primary system <NUM> since the previous backup snapshot. Alternatively, where the change in infrastructure relates to the addition and/or removal of further computing devices, such as external servers in a distributed computing architecture, the amount of change may be related to the type of servers which are added or removed at the primary system <NUM>. For example, where an additional server is added to the primary system <NUM>, and the additional server includes a different system architecture and/or operating system to the computing devices previously included in the primary system <NUM>, the amount of change in the infrastructure may be evaluated as being high.

An amount of change in the configuration of one or more workloads in the primary system <NUM> since the previous backup snapshot may relate to changes in one or more metadata files of the one or more workloads, the addition or subtraction of executable files, libraries, and so forth, in the one or more workloads. An amount of change in the configuration of the one or more workloads may be identified by an index associated with the backup snapshot, where the index includes an identification of the version of each of the one or more workloads associated with the backup snapshot. The scanning score may be calculated based on any one of the factors described above, or a combination of one or more these factors.

The one or more backup snapshots with a scanning score above a threshold value, also referred to as a scanning threshold value, are scanned. There is a trade-off between vulnerability detection and computing resource availability in the storage system <NUM>. By performing vulnerability scans more frequently, it is possible to detect more vulnerabilities and potentially to detect them sooner, however, the available resources of the storage system <NUM> may be reduced, leaving fewer resources for handling on-demand requests from users and/or for performing scheduled tasks.

By comparing the scanning score to a threshold value, it is possible to ensure that an adequate sample of backup snapshots are scanned for vulnerabilities without unnecessarily taxing the resources of the storage system. The threshold value may be a fixed value which is configured such that it allows an adequate number of vulnerability scans to be performed whilst also keeping computing resource usage for performing vulnerability scans sufficiently low to allow the storage system <NUM> to handle on-demand requests from users and/or to perform scheduled tasks. The threshold value may be configured such that computing resources in the storage system <NUM> used to perform vulnerability scans does not exceed a predetermined proportion, e.g. <NUM>%, of the total computing resources provided in the storage system <NUM>.

The threshold value may alternatively be dynamically calculated. For example, the threshold value may be dynamically determined based on current and/or predicted available computing resources in the storage system <NUM>. Where the storage system <NUM> is performing, or is scheduled to soon perform, one or more primary functions, such as a data defragmentation, the threshold value may be increased, to account for reduction in available computing resources. In this way, the storage system <NUM> can be configured such that there are sufficient available computing resources to handle on-demand requests from users whilst also performing vulnerability scans and other scheduled tasks. Similarly, when on-demand requests are received from users, the threshold value may be increased to such that there are sufficient computing resources for the storage system <NUM> to continue to perform scheduled tasks. To this end, the scanning threshold value may be determined as a function of available computing resources in the storage system <NUM>. In some embodiments, the storage system selects which of the plurality of backup snapshots to scan using a lottery scheduling algorithm.

Storage system <NUM> includes a temporary environment <NUM> to restore and scan at least a portion of a selected snapshot to create a restored instance of the portion of the selected snapshot. An example of temporary environment <NUM> is a sandbox testing environment. Restoring the selected backup snapshot to the temporary environment <NUM> allows vulnerability scans, which are configured for scanning live workloads, to be performed on the selected backup snapshot.

In some embodiments, storage system <NUM> restores to temporary environment <NUM> a version of primary system <NUM> corresponding to a backup snapshot and performs a vulnerability scan on the restored version of the primary system. Storage system <NUM> may restore the version of primary system <NUM> corresponding to a backup snapshot in part by cloning a view associated with a version of primary system <NUM> corresponding to a backup snapshot. In some embodiments, the view associated with the version of primary system <NUM> corresponding to a backup snapshot is cloned by copying the root node associated with the version of primary system <NUM>.

In some embodiments, storage system <NUM> may restore to temporary environment <NUM> a version of a workload <NUM> corresponding to a backup snapshot and perform a vulnerability scan on the restored version of the workload. Storage system <NUM> may restore the version of the workload <NUM> corresponding to a backup snapshot in part by cloning a view associated with the version of a workload <NUM> corresponding to a backup snapshot. In some embodiments, the view associated with the version of workload <NUM> corresponding to a backup snapshot is cloned by copying the root node associated with the version of the workload <NUM>. The view associated with the version of primary system <NUM> corresponding to a backup snapshot and/or the view associated with the version of workload <NUM> corresponding to a backup snapshot may be cloned, using the technique described in <CIT>. Storage system <NUM> may further restore the version of primary system <NUM> or a workload <NUM> in part by providing access, in temporary environment <NUM>, to the data associated with the cloned view.

Storage system <NUM> scans the restored portion of the selected backup snapshot for one or more vulnerabilities. Storage system <NUM> may obtain one or more lists of known vulnerabilities associated with one or more applications. The one or more lists of known vulnerabilities associated with one or more applications may include corresponding vulnerability scores for each of the known vulnerabilities. The one or more lists of known vulnerabilities may include lists obtained from the Common Vulnerabilities and Exposures (CVE) system. A government entity may assign the corresponding vulnerability scores using a CVSS. The restored portion of the selected backup snapshot may include at least one of the known vulnerabilities. A vulnerability scan of the restored portion of the selected backup snapshot determines the one or more vulnerabilities associated with the restored portion of the selected backup snapshot. Storage system <NUM> may assign a corresponding vulnerability score to each of the one or more determined vulnerabilities associated with the restored portion of the selected backup snapshot.

Storage system <NUM> may store a data structure (e.g., list, map, etc.) that tracks the one or more vulnerabilities associated with a scanned backup snapshot. The data structure may include a plurality of entries, each entry corresponding to one of the scanned portions of a backup snapshot. The entry may associate a scanned portion of a backup snapshot with the one or more known vulnerabilities and a recovery time associated with the scanned portion of the backup snapshot. The data structure may indicate all of the potential remedies associated with a scanned portion of a backup snapshot as well as all of the required remedies associated with the scanned portion of a backup snapshot.

Tracking one or more vulnerabilities associated with scanned backup snapshots provides useful information to the primary system <NUM> and/or the storage system <NUM> when restoring a state of a workload from one of the scanned backup snapshots. As explained above, workloads may be restored from backup snapshots at the request of the primary system <NUM> and/or a user. Restoration of a workload may be performed when the workload becomes corrupted, stops working, and/or when the workload is being migrated to a different production environment. By tracking the one or more vulnerabilities associated with the scanned backup snapshot, it is possible to identify and correct vulnerabilities which are present in the scanned backup snapshot when restoring the workload. An operator of a primary system <NUM> may patch vulnerabilities on the live production environment, e.g. the primary system <NUM>, as they are detected. By maintaining historic information about vulnerabilities detected at different states of the primary system <NUM>, e.g. vulnerabilities in the scanned portions of backup snapshots, it is possible to prevent previous vulnerabilities from being introduced onto the primary system <NUM> when restoring from a backup snapshot.

The storage system <NUM> may update the stored data structure that tracks the one or more vulnerabilities, based on vulnerability scans performed on subsequent selected backup snapshots. For example, assume that at a first time, a first scanned portion of a first backup snapshot includes a virtual machine, VM_1 which is a particular version, e.g. V. <NUM>, of a virtual machine provided by a third-party, and no vulnerabilities are detected in the first scanned portion of the backup snapshot. At a second time, one or more vulnerabilities are detected in a second scanned portion of a second, subsequent, backup snapshot, including the same virtual machine VM_1 which is version V. The detected vulnerability is then associated with the particular version V. <NUM> of the VM_1. In this example, the first scanned portion of the first backup snapshot may include the same vulnerability as the second scanned portion, but this went undetected due to the differences in the vulnerability scans performed at the first and second times.

Vulnerability scans which are performed may change over time where new vulnerabilities are identified, new types of scans are invented, and/or where updates are made to the list of known vulnerabilities since the first scanned portion of the first backup snapshot was scanned. The storage system <NUM> may update the data structure such that the first scanned portion of the first backup snapshot is associated with the vulnerability detected in the second scanned portion of the second backup snapshot. In this way, it is possible to maintain and update vulnerability information for a plurality of backup snapshots, including those which were not selected and scanned, based on correlations to backup snapshots which comprise vulnerabilities.

Storage system <NUM> may determine a recovery time associated with a scanned portion of a backup snapshot. The recovery time associated with a scanned portion of a backup snapshot may be based on a specified security posture associated with an environment in which the data associated with a scanned portion of a backup snapshot is to be restored. For example, some restore environments may have higher security requirements than other restore environments. A restore environment with a high security posture may require all of the one or more vulnerabilities associated with a scanned portion of a backup snapshot to be remedied. A restore environment with a medium security posture may require all critical and very critical vulnerabilities to be remedied, but not any non-critical vulnerabilities. A restore environment with a low security posture may not require any of the one or more vulnerabilities to be remedied.

A scanned portion of a backup snapshot may be associated with a plurality of vulnerabilities. Storage system <NUM> may filter the one or more vulnerabilities required to be remedied for the restore environment to which the data associated with a scanned portion of a backup snapshot is to be restored. For example, a scanned portion of a backup snapshot may be associated with three vulnerabilities: two very critical vulnerabilities and one non-critical vulnerability. A security posture of the restore environment may have a medium security posture and only require the two very critical vulnerabilities to be remedied. Storage system <NUM> may determine the recovery time associated with the scanned portion of the backup snapshot based on the remedies associated with the two very critical vulnerabilities instead of determining the recovery time associated with the scanned portion of the backup snapshot based on all of the remedies associated with the scanned portion of the backup snapshot. In some embodiments, the storage system computes a corresponding recovery time associated with a scanned portion of a backup snapshot based on whether all of the vulnerabilities associated with a scanned portion of a backup snapshot are to be remedied, whether some of the vulnerabilities associated with a scanned portion of a backup snapshot are to be remedied, and/or whether none of the vulnerabilities associated with a scanned portion of a backup snapshot are to be remedied.

Storage system <NUM> may generate an ordering of one or more remedies to be applied to the scanned portion of a backup snapshot. For example, storage system <NUM> may determine a sequence of the one or more remedies that are to be applied to the data associated with a scanned portion of a backup snapshot portion to restore a restore system (e.g., a primary system).

The recovery time associated with a scanned portion of a backup snapshot may be based a roll forward time associated with restoring a restore system (e.g., primary system <NUM>). The roll forward time may include the amount of time needed to provide data associated with a scanned portion of a backup snapshot from storage system <NUM> to the restore system. The roll forward time may also include the amount of time needed by the restore system to restore the system to a state associated with the scanned portion of the backup snapshot. In some embodiments, the data associated with a particular version of a virtual machine is provided from storage system <NUM> to the restore system. In some embodiments, all of the data associated with a scanned portion of a backup snapshot is provided from storage system <NUM> to the restore system. For example, a restore system is being restored to a particular version of primary system <NUM>.

The recovery time associated with a scanned portion of a backup snapshot may be based on a cumulative patch time associated with the one or more remedies. The cumulative patch time is the amount of time needed to apply the one or more remedies to the restored data. The determined recovery time associated with each of the scanned backup snapshots may be based on the corresponding cumulative patch time associated with the one or more remedies and the corresponding roll forward time associated with at least a portion of the scanned backup snapshot.

Storage system <NUM> may determine a plurality of recovery times associated with a scanned portion of a backup snapshot based on the different scenarios in which a scanned portion of a backup snapshot may be used to restore a restore system. The storage system may determine a corresponding recovery time based on the different security postures, the different roll forward times (e.g., restore different portions of a backup snapshot versus restore an entire portion of a backup snapshot), the different cumulative patch times (e.g., apply all remedies, some remedies, no remedies), and/or a combination thereof.

Storage system <NUM> may receive a request associated with identifying a backup snapshot to restore. For example, primary system <NUM> may send a request to storage system <NUM> to restore the entire system or one of the workloads. Primary system <NUM> may be restored using any of the scanned portions of backup snapshots, however, a user associated with the primary system <NUM> may need guidance in selecting a scanned portion of a backup snapshot. The user associated with the restore system may need guidance in selecting a version of a selected scanned portion of a backup snapshot. The restore system may request the system to be restored to a state associated with a particular day or a particular time period (e.g., range of hours, range of days, etc.).

In response to the request, storage system <NUM> may provide an interface that indicates the one or more scanned portions of backup snapshots associated with the request and their one or more corresponding vulnerabilities. The interface may display one or more entries corresponding to one or more scanned portions of backup snapshots. An entry corresponding to a scanned portion of a backup snapshot may indicate whether a vulnerability associated with a scanned portion of a backup snapshot is very critical, critical, and/or non-critical. An entry may indicate one or more recovery times associated with a scanned portion of a backup snapshot. For example, the entry may indicate a recovery time associated with restoring the scanned portion of a backup snapshot to a high security posture restore environment, a recovery time associated with restoring the scanned portion of a backup snapshot to a medium security posture restore environment, and/or a recovery time associated with restoring the scanned portion of a backup snapshot to a low security posture restore environment.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected backup snapshot based on a security posture. For example, a user associated with a restore system may select a "high security posture. " In response to the selection, storage system <NUM> may update the interface to associate the one or more scanned portions of backup snapshots and their corresponding one or more recovery times in the event the selected backup snapshot is restored to a restore environment having a "high security posture.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected scanned portion of a backup snapshot based on a total amount of recovery time. For example, a user associated with the restore system may have a certain amount of time to restore the restore system. Some of the scanned portions of backup snapshots may have a corresponding recovery time that is greater than the certain amount of time. Storage system <NUM> may update the interface to rank the scanned portions of backup snapshots based on the total amount of recovery time.

Storage system <NUM> may also display the recovery time associated with different portions of a scanned portion of a backup snapshot. For example, the interface may indicate a recovery time associated with restoring a particular workload included in a backup snapshot. The interface may indicate a recovery time associated with restoring the entire backup snapshot. The interface may allow a user associated with the restore system to select the one or more workloads to restore and in response to the selection, storage system <NUM> may update the interface to indicate the corresponding recovery times associated with the selection of the one or more workloads.

A requesting system may select one of the scanned portions of backup snapshots. In response to the request, storage system <NUM> may provide the data associated with the selected scanned portion of a backup snapshot. In some embodiments, storage system <NUM> may traverse a tree data structure corresponding to the selected scanned portion of a backup snapshot to locate the data associated with the selected scanned portion of a backup snapshot and provide the located data to the requesting system. In response to receiving the data, the requesting system may apply the one or more remedies associated with the selected scanned backup snapshot to the received data.

<FIG> is a flow chart illustrating a process for performing a vulnerability scan in accordance with some embodiments. In the example shown, process <NUM> may be performed by a storage system, such as storage system <NUM>. Process <NUM> may be periodically performed by a storage system. In some embodiments, process <NUM> is performed when the storage system has a sufficient amount of resources to perform process <NUM>. Process <NUM> may be separately performed for a plurality of backup snapshots to generate a plurality of scanned backup snapshots.

At <NUM>, data associated with a plurality of backup snapshots is received. A primary system may perform a backup snapshot and send file system data associated with the primary system to a storage system. The backup snapshot may be a full backup snapshot or an incremental backup snapshot. The backup snapshot may be a backup of the entire primary system or a backup of one or more workloads hosted by the primary system. The backup snapshot may be performed according to a backup snapshot policy. A backup snapshot policy may indicate that file system data is to be backed up on a periodic basis (e.g., hourly, daily, weekly, monthly, etc.), when a threshold size of data has changed, and/or upon a command from a user associated with a primary system.

A storage system may receive the data associated with a plurality of backup snapshots, store the data associated with the plurality backup snapshots, and generate corresponding tree data structures for the plurality of backup snapshots. A tree data structure may organize and store the metadata associated with the backup snapshot data. An example of the tree data structure is a snapshot tree. In some embodiments, each snapshot tree corresponds to a version of the primary system to which the primary system may be restored. In some embodiments, each snapshot tree corresponds to a version of a workload hosted on the primary system to which the workload may be restored.

At <NUM>, a backup snapshot among the plurality of backup snapshots is selected to be scanned. The backup snapshot is selected to be scanned based on a corresponding scanning score associated with the backup snapshot. Each of the backup snapshots has a corresponding scanning score. The scanning score may indicate whether a backup snapshot is ripe for a vulnerability scan. The scanning score associated with a backup snapshot is compared to a threshold value. A backup snapshot is selected in the event the scanning score is greater than or equal to the threshold value. This may ensure that an adequate sample of backup snapshots are scanned for vulnerabilities without unnecessarily taxing the resources of the storage system.

At <NUM>, at least a portion of the selected backup snapshot is restored to a temporary environment to create a restored instance of at least a portion of the selected backup snapshot. The portion of the selected snapshot may correspond to a workload hosted by a primary system. For example, a virtual machine hosted by a primary system may be restored to a temporary environment. In some embodiments, the portion of the selected snapshot is the entire portion of the selected snapshot and the entire primary system is restored to the temporary environment.

At <NUM>, a vulnerability scan of the restored instance is performed. One or more vulnerabilities associated with the restored instance may be detected. The storage system may obtain from a third party system, such as a government entity, a corresponding vulnerability score for the one or more detected vulnerabilities.

At <NUM>, a recovery time associated with the scanned portion of a backup snapshot is determined. Each of the one or more detected vulnerabilities may have a corresponding remedy. The corresponding remedy may have an associated roll forward time.

At <NUM>, one or more vulnerabilities of the scanned portion of a backup snapshot identified by the vulnerability scan are tracked. A storage system may store a data structure (e.g., list, map, etc.) that tracks the one or more vulnerabilities associated with a scanned portion of a backup snapshot. The data structure may include a plurality of entries, each entry corresponding to one of the scanned portions of backup snapshots. The entry may associate a scanned portion of a backup snapshot with the one or more known vulnerabilities and a recovery time associated with a scanned portion of a backup snapshot. The data structure may indicate all of the potential remedies associated with a scanned portion of a backup snapshot as well as all of the required remedies associated with the scanned portion of the backup snapshot.

<FIG> is a flow chart illustrating a process for restoring a backup snapshot in accordance with some embodiments. In the example shown, process <NUM> may be implemented by a storage system, such as storage system <NUM>.

At <NUM>, a request associated with identifying a backup snapshot to restore from a plurality of scanned backup snapshots is received. A restore system may be restored using any of the scanned portions of backup snapshots, however, a user associated with the restore system may need guidance in selecting a scanned portion of a backup snapshot. The user associated with the restore system may need guidance in selecting a version of a selected scanned portion of a backup snapshot. The restore system may request the system to be restored to a state associated with a particular day or a particular time period (e.g., range of hours, range of days, etc.). A storage system may receive the request associated with identifying a backup snapshot to restore. The request may be a request to restore the entire system or to restore one or more of the workloads. For example, the storage system may receive a request to restore a primary system to one of the backup snapshots that was performed yesterday.

At <NUM>, in response to the request, at least a predetermined identification of the one or more vulnerabilities of the selected scanned portion of a backup snapshot is provided.

The storage system may provide an interface that indicates the one or more scanned portions of backup snapshots associated with the request and their one or more corresponding vulnerabilities. For example, the interface may display the one or more scanned backup snapshots that were performed yesterday. The interface may display one or more entries corresponding to one or more scanned portions of backup snapshots. An entry may indicate the one or more vulnerabilities associated with a scanned portion of a backup snapshot. An entry corresponding to a scanned portion of a backup snapshot may indicate whether a vulnerability associated with a scanned portion of a backup snapshot is very critical, critical, and/or non-critical. An entry may indicate one or more recovery times associated with a scanned portion of a backup snapshot. For example, the entry may indicate a recovery time associated with restoring the scanned portion of a backup snapshot to a high security posture restore environment, a recovery time associated with restoring the scanned portion of a backup snapshot to a medium security posture restore environment, and/or a recovery time associated with restoring the scanned portion of a backup snapshot to a low security posture restore environment.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected scanned portion of a backup snapshot based on a security posture. For example, a user associated with a restore system may select a "high security posture. " In response to the selection, the storage system may update the interface to associate the one or more scanned portions of backup snapshots and their corresponding one or more recovery times in the event the selected backup snapshot is restored to a restore environment having a "high security posture.

The interface may provide a user associated with a restore system with the ability to filter versions of a selected scanned portion of a backup snapshot based on a total amount of recovery time. For example, a user associated with the restore system may have a certain amount of time to restore the restore system. Some of the scanned portions of backup snapshots may have a corresponding recovery time that is greater than the certain amount of time. The storage system may update the interface to rank the scanned portions of backup snapshots based on the total amount of recovery time.

The storage system may also display the recovery time associated with different portions of a scanned backup snapshot. For example, the interface may indicate a recovery time associated with restoring a particular workload included in a backup snapshot. The interface may indicate a recovery time associated with restoring the entire backup snapshot. The interface may allow a user associated with the restore system to select the one or more workloads to restore and in response to the selection, the storage system may update the interface to indicate the corresponding recovery times associated with the selection of one or more workloads.

The interface may provide a user associated with a restore system with the ability to select which of the one or more vulnerabilities associated with a scanned portion of a backup snapshot to remedy.

At <NUM>, a request to restore one of the scanned portions of backup snapshots is received. At <NUM>, the data associated with the requested scanned portion of a backup snapshot is provided. In some embodiments, the storage system may traverse a tree data structure corresponding to the selected scanned portion of a backup snapshot to locate the data associated with the selected scanned portion of the backup snapshot and provide the located data to the requesting system. In response to receiving the data, the requesting system may apply the one or more remedies associated with the selected scanned portion of a backup snapshot to the received data.

<FIG> is a flow chart illustrating a process for selecting a backup snapshot in accordance with some embodiments. In the example shown, process <NUM> may be implemented by a storage system, such as storage system <NUM>. Process <NUM> includes determining a scanning score for each of the backup snapshots to determine whether to select the backup snapshot. In some embodiments, process <NUM> may be implemented to perform some or all of step <NUM> of process <NUM>.

At <NUM>, a snapshot distance between a particular backup snapshot and a latest backup snapshot is determined. The snapshot distance between the particular backup snapshot and the latest backup snapshot may be the amount of time between the particular backup snapshot and the latest backup snapshot. The snapshot distance between the particular backup snapshot and the latest backup snapshot may be the number of backup snapshots in the chain of snapshot trees between the snapshot tree corresponding to the particular backup snapshot and the snapshot tree corresponding to the latest backup snapshot. A scanning score associated with a particular backup snapshot may be increased (e.g., incremented) in dependence on the snapshot distance between the particular backup snapshot and a latest backup snapshot.

The scanning score may be increased by an amount which is proportional to the size of the snapshot distance such that where a longer time has elapsed between the particular backup snapshot and the latest backup snapshot the scanning score is increased by a greater amount. Where there are larger snapshot distances between backup snapshots, it may be desirable to perform vulnerability scans on a larger number of backup snapshots, for example, as a greater amount of change may have occurred in the primary system <NUM>. Where the snapshot distances are smaller, it may be desirable to reduce the frequency of scanning backup snapshots to preserve computing resources in the storage system <NUM>. In some cases, the scanning score may be increased in the event that the snapshot distance between the particular backup snapshot and the latest backup snapshot is greater than a first threshold distance.

At <NUM>, a snapshot distance between the particular backup snapshot and a previous scan is determined. The snapshot distance between the particular backup snapshot and the previous scan may be the amount of time between the particular backup snapshot and the previous scan. The snapshot distance between the particular backup snapshot and the previous scan may be the number of backup snapshots in the chain of snapshot trees between the snapshot tree corresponding to the particular backup snapshot and the snapshot tree corresponding to the previous scan. The scanning score associated with the particular backup snapshot may be increased (e.g. incremented) in dependence on the snapshot distance between the particular backup snapshot and the previous scan. Similarly, to step <NUM>, the amount by which the scanning score is increased may be proportional to the snapshot distance. By modifying the scanning score based on the snapshot distance between the particular backup snapshot and the previous scan it is possible to control the frequency of scans in a manner which is dependent on a ratio between the frequency of backup snapshots and the desired frequency of scans. In some cases, the scanning score is increased in the event that the snapshot distance between a particular backup snapshot and a previous scan is greater than a second threshold distance.

At <NUM>, a snapshot distance between the particular backup snapshot and a previous scan with one or more vulnerabilities is determined. The snapshot distance between the particular backup snapshot and the latest backup snapshot may be the amount of time between the particular backup snapshot and the previous scan with one or more vulnerabilities. The snapshot distance between the particular backup snapshot and the previous scan with one or more vulnerabilities may be the number of backup snapshots in the chain of snapshot trees between the snapshot tree corresponding to the particular backup snapshot and the snapshot tree corresponding to the previous scan with one or more vulnerabilities. The scanning score associated with the particular backup snapshot may be increased (e.g. incremented) in dependence on the snapshot distance between the particular backup snapshot and a previous scan with one or more vulnerabilities. The amount by which the scanning score is increased may be proportional to the snapshot distance between the particular snapshot and the scan with one or more vulnerabilities. By modifying the scanning score in this way, the frequency of performing vulnerability scans on backup snapshots may be increased in dependence on there being a detection of one or more vulnerabilities. Where a vulnerability has been detected it may be desirable to increase the frequency of performing vulnerability scans on backup snapshots such that vulnerabilities which increase in severity and/or workloads which have a growing number of vulnerabilities are identified. The amount by which the scanning score is increased may additionally, or alternatively, be proportional to the severity of the one or more vulnerabilities. In this way, after the detection of a critical vulnerability the frequency of performing vulnerability scans on backup snapshots may be increased, while the detection of a less critical vulnerability may not result in an increase in the frequency of vulnerability scans, therefore preserving computing resources in the storage system <NUM>.

In some cases, the scanning score is increased in the event that the snapshot distance between a particular backup snapshot and a previous scan with one or more vulnerabilities is greater than a third threshold distance.

At <NUM>, an amount of change associated with a particular backup snapshot is determined. The scanning score associated with the particular backup snapshot may be increased in dependence on the amount of change associated with the particular backup snapshot. The amount of change may relate to the amount of change in production data, or data change, in the primary system associated with the particular backup snapshot. Where the particular backup snapshot is an incremental backup snapshot, then the amount of change in production data associated with the particular backup snapshot may be directly related to the size of the particular backup snapshot. Where the particular backup snapshot is a full backup snapshot, the amount of change in production data may be determined based on file system metadata in the backup snapshot and/or an index associated with the backup snapshot.

The amount of change associated with the particular backup snapshot may alternatively, or additionally, relate to an amount of change in the infrastructure of the primary system which is represented by the particular backup snapshot. A change in the infrastructure of the primary system may include the addition of one or more computing devices in the primary system <NUM>. Where there has been a change in the infrastructure of the primary system <NUM>, this change may be represented in the file system metadata of the primary system <NUM>. For example, the file system metadata may indicate new partitions and/or storage locations for workloads and/or production data in the primary system <NUM>. The file system metadata may be included in the backup snapshot and hence the amount of change in the infrastructure of the primary system <NUM> may be determined from the backup snapshot.

The amount of change associated with the particular backup snapshot may alternatively, or additionally, relate to an amount of change in the configuration of one or more workloads associated with the particular backup snapshot. For example, a specific version of the one or more workloads running on the primary system, such as a version of a virtual machine, a database, an application, and so forth. In an example, where a virtual machine is updated to a new version, it is desirable to perform a vulnerability scan on a backup snapshot representing the updated virtual machine to identify any vulnerabilities that have been introduced with the updated version. The configuration of the one or more workloads may alternatively, or additionally, refer to the organizational structure of one or more file systems in the primary system used to implement the one or more workloads. Where the change associated with the particular backup snapshot relates to a change in the configuration of the one or more workloads of the primary system, an index associated with the backup snapshot may be used to determine the amount of change. For example, the index may indicate the versions of one or more workloads included in the backup snapshot, and hence can be used to identify where a version of one or more of the workloads has changed.

The amount of change in the infrastructure of the primary system may also relate to the addition of new workloads in the primary system. File system metadata associated with the primary system may be used to identify one or more new workloads, e.g. applications, or virtual machines, which have been installed on the primary system since the previous backup snapshot, or the previous scan. In some cases, the scanning score is increased in the event that the amount of change associated with the particular backup snapshot is greater than a threshold amount.

At <NUM>, one or more votes are assigned to the particular backup snapshot based on the plurality of determinations. The number of votes assigned to the particular backup snapshot may be dependent on the size of the snapshot distances and the amount of change between the particular backup snapshot and a previous backup snapshot or a previous scan.

One or more votes may be assigned to the particular backup snapshot based on a correlation between the particular backup snapshot and a previous backup snapshot comprising one or more vulnerabilities. For example, where a previous backup snapshot comprises a first version of a workload, W_1, which includes one or more vulnerabilities, and the particular backup snapshot comprises the workload, W_1, one or more votes may be assigned to the particular backup snapshot. The number of votes assigned to the particular backup snapshot in this case may be dependent on the severity of the one or more vulnerabilities associated with the W_1 version of the workload. In other examples, the particular backup snapshot may be assigned one or more votes if it comprises a workload, W_2, which is an updated version of the first workload, W_1, which was found to include one or more vulnerabilities.

In some cases, the particular backup snapshot may be assigned a vote in the event the snapshot distance is greater than the first threshold distance, the second threshold distance, or the third threshold distance. A particular backup snapshot may be assigned a vote in the event the amount of change is greater than the threshold amount. The scanning score associated with a backup snapshot may be the total number of votes associated with the backup snapshot.

In some embodiments, the determinations performed in <NUM>, <NUM>, <NUM>, and <NUM> have corresponding weights. Some determinations may be given greater weight than other determinations when deciding whether to scan a backup snapshot for one or more vulnerabilities, and the weights may be used in the afore-mentioned assignment of votes.

The weights associated with each of the determinations <NUM>, <NUM>, <NUM>, and <NUM>, may be predetermined. For example, an optimization may be performed to select a set of weights for the determinations <NUM>, <NUM>, <NUM>, and <NUM> which aims to minimize the computing resources of the storage system <NUM> which are used to perform vulnerability scans, while maximizing the likelihood that critical vulnerabilities do not go undetected in the plurality of backup snapshots.

Alternatively, the weights associated with each of the determinations <NUM>, <NUM>, <NUM>, and <NUM> may be determined dynamically. That is, the weights may be modified during operation such that they are responsive to feedback from the storage system <NUM>. The feedback may include feedback regarding the amount of computing resources used to perform vulnerability scans and/or the feedback regarding the number of vulnerabilities which are being detected.

The weights associated with the determinations <NUM>, <NUM>, <NUM>, and <NUM> may additionally be dependent on the content and/or characteristics of the particular backup snapshot under evaluation. For example, some workloads may be prone to vulnerabilities arising from frequent changes in the configuration of these workloads and may also be operated in a manner such that vulnerabilities which are detected are quickly patched. In this case, detecting a vulnerability in a previous backup snapshot may not be closely correlated with detecting a vulnerability in a subsequent backup snapshot. When evaluating a backup snapshot comprising a workload such as this, a weight associated with an amount of change in the backup snapshot may be increased, while a weight associated with the snapshot distance between the particular backup snapshot and a backup snapshot comprising one or more vulnerabilities may be reduced. In this way, it is possible to optimize the selection of a backup snapshot based on factors which are relevant to each of the backup snapshots on a case by case basis. An index associated with the particular backup snapshot may be used to determine whether the weights should be modified for the particular backup snapshot. For example, where the index identifies a workload included in the backup snapshot which is known to have one or more characteristics that affect the manner in which vulnerabilities are introduced, then the weights may be modified accordingly. Alternatively, or additionally, characteristics of the plurality of backup snapshots may be stored and analyzed by the storage system <NUM> to identify trends in the workloads on the primary system <NUM> which are being backed up. These trends may be used to dynamically modify the weights associated with each of the determinations <NUM>, <NUM>, <NUM>, and <NUM>.

At <NUM>, the particular backup snapshot is selected based on the amount of votes associated with the particular backup snapshot. The total number of votes associated with a backup snapshot is compared to a scanning threshold value. In the event the total number of votes is greater than the scanning threshold value, the particular backup snapshot may be scanned for one or more vulnerabilities. In the event the total number of votes is not greater than the scanning threshold value, the particular backup snapshot may not be scanned for one or more vulnerabilities.

The determinations made in <NUM>, <NUM>, <NUM>, and <NUM> may be performed on a periodic basis (e.g., after each backup snapshot, after every four backup snapshots, etc.), after a threshold number of backup snapshots, in response to a user command, etc..

<FIG> is a flow chart illustrating a process for determining a recovery time associated with a backup snapshot in accordance with some embodiments. In the example shown, process <NUM> may be implemented by a storage system, such as storage system <NUM>. In some embodiments, process <NUM> may be implemented to perform some or all of step <NUM> of process <NUM>.

At <NUM>, one or more vulnerabilities are filtered based on a security posture associated with a restore environment. The data associated with at least a scanned portion of a backup snapshot may be restored to a restore system. The restore system may be operating in an environment with a corresponding security posture (e.g., network security zone). The corresponding security posture may be specified by a user associated with the restore system. A scanned portion of a backup snapshot may be associated with one or more vulnerabilities. The security posture associated with an environment may dictate the one or more vulnerabilities, if any, to be filtered.

A scanned portion of a backup snapshot may be associated with a plurality of vulnerabilities. The storage system may filter the one or more vulnerabilities required to be remedied for the restore environment to which the data associated with a scanned portion of a backup snapshot is to be restored. For example, a scanned portion of a backup snapshot may be associated with three vulnerabilities: two very critical vulnerabilities and one non-critical vulnerability. A security posture of the restore environment may have a medium security posture and only require the two very critical vulnerabilities to be remedied. The storage system may determine the recovery time associated with the scanned portion of a backup snapshot based on the remedies associated with the two very critical vulnerabilities instead of determining the recovery time associated with the scanned portion of a backup snapshot based on all of the remedies associated with the scanned snapshot. In some embodiments, the storage system computes a corresponding recovery time associated with a backup snapshot based on whether all of the vulnerabilities associated with a scanned portion of a backup snapshot are remedied, whether some of the vulnerabilities associated with a scanned portion of a backup snapshot are remedied, and/or whether none of the vulnerabilities associated with a scanned portion of a backup snapshot are remedied.

At <NUM>, an ordering of one or more remedies associated with the one or more filtered vulnerabilities is generated. For example, the storage system may determine a sequence of the one or more remedies that are to be applied to the data associated with a scanned portion of a backup snapshot to restore a restore system (e.g., a primary system).

At <NUM>, a roll forward time for the data associated with a selected scanned portion of a backup snapshot is determined. The roll forward time may include the amount of time needed to provide data associated with a scanned portion of a backup snapshot from the storage system to the restore system. The roll forward time may also include the amount of time needed by the restore system to restore the system to a state associated with the scanned portion of a backup snapshot.

In some embodiments, the data associated with a particular version of a virtual machine may be provided from the storage system to the restore system. In some embodiments, all of the data associated with a scanned backup snapshot is provided from the storage system to the restore system. For example, a restore system is being restored to a particular version of a primary system.

At <NUM>, a cumulative patch time associated with the one or more ordered remedies is determined. The cumulative patch time is the amount of time needed to apply the one or more ordered remedies to the restored data. A remedy may include applying a software patch, changing an application configuration, deleting a file, etc. Each of the ordered remedies may have an associated patch time.

At <NUM>, a recovery time based on the determined roll forward time and the determined cumulative patch time is determined. The recovery time may be the sum of the computed cumulative patch time and the computed roll forward time. The recovery time may be the sum of a weighted cumulative patch time and a weighted roll forward time.

A detailed description of one or more embodiments of the invention is provided along with accompanying figures that illustrate the principles of the invention. Numerous specific details are set forth in the description in order to provide a thorough understanding of the invention.

Claim 1:
A method, comprising:
assigning a corresponding scanning score to each of a plurality of backup snapshots stored by a storage system (<NUM>);
determining that a scanning score associated with a particular backup snapshot of the plurality of backup snapshots is greater than or equal to a scanning score threshold;
in response to the determining, scanning the particular backup snapshot by:
restoring (<NUM>), in a temporary environment (<NUM>), at least a portion of the particular backup snapshot to create a restored instance of at least the portion of the particular backup snapshot; and
performing (<NUM>) a vulnerability scan of the restored instance of at least the portion of the particular backup snapshot; and
tracking (<NUM>) one or more corresponding vulnerabilities of the scanned portion of the particular backup snapshot.