Systems and methods for performing security scans

A computer-implemented method for performing security scans may include 1) generating a first hash of a first file, 2) performing a first security scan on the first file, 3) storing the first hash to indicate a result of the first security scan of the first file, 4) identifying a second file and generating a second hash of the second file, 5) determining that the second hash of the second file is equivalent to the first hash of the first file and, in response, determining that the result of the first security scan of the first file applies to the second file, 6) identifying a third file and determining that the third file is volatile, and 7) performing a second security scan on the third file instead of generating a third hash of the third file. Various other methods, systems, and computer-readable media are also disclosed.

BACKGROUND

Related computing systems, such as virtual machines running on a common host machine or physical computing devices connected to a common network, may often encounter instances of the same file or files. For example, a high percentage of files within virtual machines that run the same operating system and/or originate from the same base image may be identical. Because of this, related computing systems may redundantly perform identical or similar resource-consuming computing operations (such as security scans) on instances of the same file.

In order to avoid wasting time and/or computing resources on potentially redundant security scans, some traditional security systems may generate and store hashes of scanned files. These traditional security systems may later generate hashes of files that are yet to be scanned and compare the newly generated hashes of the unscanned files to the stored hashes of the previously scanned files. These traditional security systems may scan unscanned files whose hashes do not match any hashes of previously scanned files while skipping scans of unscanned files whose hashes do match hashes of previously scanned files, thus preventing duplicative scans. Unfortunately, hashing operations may also be time- and resource-intensive operations. In some cases, generating a file hash for a file may be more resource-intensive than performing a security scan for the same file. Accordingly, the instant disclosure identifies and addresses a need for additional and improved systems and methods for performing security scans.

SUMMARY

As will be described in greater detail below, the instant disclosure generally relates to systems and methods for performing security scans by generating hashes of non-volatile files and scanning only files whose hashes do not match hashes of previously scanned files, but scanning volatile files without generating hashes for the volatile files.

In one example, a computer-implemented method for performing security scans may include 1) generating a first hash of a first file within a set of files that are subject to security scanning, 2) performing a first security scan on the first file, 3) storing the first hash to indicate a result of the first security scan of the first file, 4) identifying a second file within the set of files and generating a second hash of the second file, 5) determining that the second hash of the second file is equivalent to the first hash of the first file and, in response, determining that the result of the first security scan of the first file applies to the second file, 6) identifying a third file within the set of files and determining that the third file is volatile and therefore less likely to match another file within the set of files, and 7) performing a second security scan on the third file instead of generating a third hash of the third file in response to determining that the third file is volatile.

In some examples, generating the first hash of the first file may include generating the first hash of the first file in response to identifying a hash cache and determining that no hash for the first file is available within the hash cache. Additionally or alternatively, generating the first hash of the first file may include generating the first hash of the first file in response to determining that the first file is non-volatile.

In some embodiments, the computer-implemented method may also include identifying the set of files stored across a plurality of virtual machines. In one embodiment, the computer-implemented method may also include 1) determining that the third file has not changed over a predetermined period of time, 2) marking the third file as non-volatile, and 3) generating the third hash for the third file based on the third file being marked as non-volatile.

In one example, determining that the third file is volatile may include 1) identifying a prior hash indicator that a prior hash for the third file has previously been generated and 2) identifying a current hash indicator that no valid current hash for the third file is available. In some examples, determining that the third file is volatile may include determining that the third file has changed since a previous security assessment of the third file.

In some examples, the computer-implemented method may also include 1) identifying a digitally-signed file within the set of files and 2) performing a security assessment on the digitally-signed file by verifying a digital signature of the digitally-signed file instead of generating an additional hash for the digitally-signed file or performing an additional security scan on the digitally-signed file.

In one embodiment, a system for implementing the above-described method may include 1) a generation module programmed to generate a first hash of a first file within a set of files that are subject to security scanning, 2) a storing module programmed to (i) perform a first security scan on the first file and (ii) store the first hash to indicate a result of the first security scan of the first file, 3) a determination module programmed to (i) identify a second file within the set of files and generating a second hash of the second file and (ii) determine that the second hash of the second file is equivalent to the first hash of the first file and, in response, determining that the result of the first security scan of the first file applies to the second file, 4) an identification module programmed to identify a third file within the set of files and determining that the third file is volatile and therefore less likely to match another file within the set of files, and 5) a scanning module programmed to perform a second security scan on the third file instead of generating a third hash of the third file in response to determining that the third file is volatile. The system may also include at least one processor configured to execute the generation module, the storing module, the determination module, the identification module, and the scanning module.

In some examples, the above-described method may be encoded as computer-readable instructions on a computer-readable-storage medium. For example, a computer-readable-storage medium may include one or more computer-executable instructions that, when executed by at least one processor of a computing device, may cause the computing device to 1) generate a first hash of a first file within a set of files that are subject to security scanning, 2) perform a first security scan on the first file, 3) store the first hash to indicate a result of the first security scan of the first file, 4) identify a second file within the set of files and generating a second hash of the second file, 5) determine that the second hash of the second file is equivalent to the first hash of the first file and, in response, determine that the result of the first security scan of the first file applies to the second file, 6) identify a third file within the set of files and determine that the third file is volatile and therefore less likely to match another file within the set of files, and 7) perform a second security scan on the third file instead of generating a third hash of the third file in response to determining that the third file is volatile.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present disclosure is generally directed to systems and methods for performing security scans. As will be explained in greater detail below, by generating hashes of non-volatile files and scanning only files whose hashes do not match hashes of previously scanned files, but scanning volatile files without generating hashes for the volatile files, the systems and methods described herein may avoid redundant scanning operations using hashes while also avoiding generating hashes in resource-inefficient circumstances. For example, by directly scanning volatile files instead of generating hashes for the volatile files, these systems and methods may consume fewer computing resources in the short term (e.g., because generating hashes may consume significant computing resources) without sacrificing resource efficiency in the long term (e.g., because volatile files may change before their hashes could be reused in future scanning operations and/or because volatile files may be significantly less likely to match other files in the first place).

The following will provide, with reference toFIGS. 1,2, and4, detailed descriptions of exemplary systems for performing security scans. Detailed descriptions of corresponding computer-implemented methods will also be provided in connection withFIG. 3. Detailed descriptions of an exemplary timeline will be provided in connection withFIG. 4. In addition, detailed descriptions of an exemplary computing system and network architecture capable of implementing one or more of the embodiments described herein will be provided in connection withFIGS. 6 and 7, respectively.

FIG. 1is a block diagram of an exemplary system100for performing security scans. As illustrated in this figure, exemplary system100may include one or more modules102for performing one or more tasks. For example, and as will be explained in greater detail below, exemplary system100may include a generation module104programmed to generate a first hash of a first file within a set of files that are subject to security scanning. Exemplary system100may also include a storing module106programmed to (i) perform a first security scan on the first file and (ii) store the first hash to indicate a result of the first security scan of the first file.

In addition, and as will be described in greater detail below, exemplary system100may include a determination module108programmed to (i) identify a second file within the set of files and generating a second hash of the second file and (ii) determine that the second hash of the second file is equivalent to the first hash of the first file and, in response, determining that the result of the first security scan of the first file applies to the second file. Exemplary system100may also include an identification module110programmed to identify a third file within the set of files and determining that the third file is volatile and therefore less likely to match another file within the set of files. Exemplary system100may further include a scanning module112programmed to perform a second security scan on the third file instead of generating a third hash of the third file in response to determining that the third file is volatile. Although illustrated as separate elements, one or more of modules102inFIG. 1may represent portions of a single module or application.

As illustrated inFIG. 1, exemplary system100may also include one or more databases, such as database120. In one example, database120may be configured to store hashes of files that have been scanned (and, in some examples, information indicating that the files have been scanned and/or results of such scans).

Database120may represent portions of a single database or computing device or a plurality of databases or computing devices. For example, database120may represent a portion of computing device202inFIG. 2, computing devices206(1)-(n) inFIG. 2, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7. Alternatively, database120inFIG. 1may represent one or more physically separate devices capable of being accessed by a computing device, such as computing device202inFIG. 2, computing devices206(1)-(n) inFIG. 2, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7.

Exemplary system100inFIG. 1may be implemented in a variety of ways. For example, all or a portion of exemplary system100may represent portions of exemplary system200inFIG. 2. As shown inFIG. 2, system200may include a computing device202in communication with a computing devices206(1)-(n) via a network204. Computing device202may be programmed with one or more of modules102and/or may store all or a portion of the data in database120. Additionally or alternatively, computing devices206(1)-(n) may be programmed with one or more of modules102and/or may store all or a portion of the data in database120.

In one embodiment, one or more of modules102fromFIG. 1may, when executed by at least one processor of computing device202and/or computing devices206(1)-(n), facilitate computing device202and/or computing devices206(1)-(n) in performing security scans. For example, and as will be described in greater detail below, one or more of modules102may cause computing device202and/or computing devices206(1)-(n) to 1) generate a hash220(1) of a file210(1) within a set of files210(1)-(k) that are subject to security scanning, 2) perform a security scan on file210(1), 3) store hash220(1) to indicate a scan result222of the first security scan of file210(1), 4) identify a file210(j) within the set of files210(1)-(k) and generating a hash220(j) of file210(j), 5) determine that hash220(j) of file210(j) is equivalent to hash220(1) of file210(1) and, in response, determine that scan result222of the security scan of file210(1) applies to file210(j), 6) identify a file210(k) within the set of files210(1)-(k) and determine that file210(k) is volatile and therefore less likely to match another file within the set of files210(1)-(k), and 7) perform a security scan on file210(k) instead of generating a hash of file210(k) in response to determining that file210(k) is volatile.

Computing device202generally represents any type or form of computing device capable of reading computer-executable instructions. Examples of computing device202include, without limitation, laptops, tablets, desktops, servers, cellular phones, Personal Digital Assistants (PDAs), multimedia players, embedded systems, combinations of one or more of the same, exemplary computing system610inFIG. 6, or any other suitable computing device.

Computing devices206(1)-(n) generally represent any type or form of computing device that is capable of hosting, storing, and/or accessing files. Examples of computing devices206(1)-(n) include, without limitation, application servers and database servers configured to provide various database services and/or run certain software applications. In some examples, computing devices206(1)-(n) may include virtual machines and/or virtual machine hosts.

FIG. 3is a flow diagram of an exemplary computer-implemented method300for performing security scans. The steps shown inFIG. 3may be performed by any suitable computer-executable code and/or computing system. In some embodiments, the steps shown inFIG. 3may be performed by one or more of the components of system100inFIG. 1, system200inFIG. 2, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7.

As illustrated inFIG. 3, at step302one or more of the systems described herein may generate a first hash of a first file within a set of files that are subject to security scanning. For example, at step302generation module104may, as part of computing device202inFIG. 2, generate a hash220(1) of a file210(1) within a set of files210(1)-(k) that are subject to security scanning.

As used herein, the term “hash” may refer to any abbreviated representation of the contents of a file, including the outputs of hash functions, fingerprints, checksums, and/or any other type of file identifiers that uniquely identify file content (barring a collision).

As used herein, the term “file” may refer to any unit of data, including, without limitation, files, data objects, images, packages, databases, and documents. In some examples, the file may include an executable file and/or one or more computer-executable instructions. As used herein, the phrase “security scan” may refer to any suitable security assessment, analysis, and/or scan (e.g., to determine the safety, maliciousness, and/or legitimacy of a file). For example, the security scan may include a malware scan, an intrusion prevention analysis, a scan for potential security exploits, etc. As used herein, the term “malware” may refer to any virus, worm, Trojan horse, spyware, and/or any other malicious, illegitimate, and/or unauthorized software. Additionally or alternatively, a security scan may include a privacy and/or data loss prevention assessment for determining the sensitivity of a file.

In some examples, generation module104may also identify the set of files. Generation module104may identify the set of files in any suitable context. For example, the set of files may be stored across a group of virtual machines. In some examples, the group of virtual machines may store many instances of identical files. For example, the group of virtual machines may run the same operating system and/or originate from the same base image. Accordingly, in some examples, generation module104may identify the set of files stored across a plurality of virtual machines by identifying a plurality of virtual machines that run the same operating system. Additionally or alternatively, generation module104may identify the set of files stored across the plurality of virtual machines by identifying a plurality of virtual machines that originate from the same base image. In some examples, generation module104may identify the set of files stored across the plurality of virtual machines by reading a configuration file identifying the plurality of virtual machines.

As used herein, the phrase “virtual machine” generally refers to a computing system platform that may not have direct correspondence to hardware of an underlying host system. For example, hardware of a host system may be abstracted to a virtual machine using a hypervisor or other virtualization software. A virtual machine may run a guest operating system and/or various other software applications.

Generation module104may generate the first hash of the first file in any suitable context. In some examples, generation module104may generate the first hash of the first file in response to identifying a hash cache and determining that no hash for the first file is available within the hash cache. The hash cache may include any suitable database, data store, and/or data structure for storing file hashes.

FIG. 4illustrates an exemplary timeline400for performing security scans. UsingFIG. 4as an example, exemplary timeline400may include a file “A” hash check402. For example, generation module104may identify a hash cache and determine that no hash for file “A” is available within the hash cache. A file “A” hash creation404may follow file “A” hash check402. For example, generation module104may, having determined that no hash for file “A” is available, generate a hash for file “A.”

In some examples, generation module104may generate the first hash of the first file in response to determining that the first file is non-volatile. As used herein, the term “non-volatile” may refer to any file that is unlikely to change in the future and/or that has not changed in the past and/or the recent past. Generation module104may determine that the first file is non-volatile according to any of a number of criteria. For example, generation module104may determine that the first file is non-volatile based on the file type of the file (e.g., generation module104may determine that an executable file and/or a static data file is non-volatile). In some examples, generation module104may determine that the first file is non-volatile based on determining that the file has not been modified (e.g., since the creation of the file, for a predetermined period of time, etc.). In some examples, generation module104may determine that the first file is non-volatile by identifying a configuration file designating the first file as non-volatile. UsingFIG. 4as an example, generation module104may determine that file “A” is non-volatile before (e.g., and as a prerequisite to) file “A” hash creation404. As will be explained in greater detail below, by only generating hashes for non-volatile files, the systems and methods described herein may conserve computing resources.

FIG. 5illustrates an exemplary system500for performing security scans. As shown inFIG. 5, exemplary system500may include modules102. UsingFIG. 5as an example, generation module104may, as a part of modules102, identify a set of files510,512, and514. Generation module104may also generate a hash520for file510. In generating hash520, generation module104may also set a hash flag530, indicating that a hash for file510has been created.

Returning toFIG. 3, at step304one or more of the systems described herein may perform a first security scan on the first file. For example, at step304storing module106may, as part of computing device202inFIG. 2, perform a security scan on file210(1).

Storing module106may perform the first security scan on the first file in any suitable manner. For example, storing module106may parse and/or analyze the first file for one or more fingerprints and/or patterns identifying malware, security vulnerabilities, and/or sensitive data. Additionally or alternatively, storing module106may communicate with a security system to initiate and/or retrieve the results of a security scan of the first file.

In some examples, storing module106may perform the first security scan on the first file in response to determining that the first hash generated for first file did not match any hash of previously scanned files in the set of files.

UsingFIG. 4as an example, a file “A” scan406may follow file “A” hash creation404. For example, storing module106may scan file “A” for malware (e.g., because the hash for file “A” in file “A” hash creation404does not match any existing hash of a previously scanned file).

UsingFIG. 5as an example, at step304storing module106may, as a part of modules102, perform a security scan on file510.

Returning toFIG. 3, at step306one or more of the systems described herein may store the first hash to indicate a result of the first security scan of the first file. For example, at step306storing module106may, as part of computing device202inFIG. 2, store hash220(1) to indicate a scan result222of the first security scan of file210(1).

Storing module106may store the first hash to indicate the result of the security scan of the first file in any suitable manner. For example, storing module106may simply store the first hash in a data structure for clean scanned files, thereby indicating that the first file has been scanned and verified as safe and/or legitimate. Additionally or alternatively, storing module106may store the first hash and the result of the first security scan in a data pair, thereby enabling a lookup of the result of the first security scan (e.g., safe, suspicious, malicious, sensitive, etc.) using the first hash.

UsingFIG. 4as an example, a file “A” hash storage408may follow file “A” scan406. For example, storing module106may store the hash created in file “A” hash creation404to indicate the result of file “A” scan406.

UsingFIG. 5as an example, storing module106may, as a part of modules102, store hash520to indicate the result of scanning file510.

Returning toFIG. 3, at step308one or more of the systems described herein may identify a second file within the set of files and generating a second hash of the second file. For example, at step308determination module108may, as part of computing device202inFIG. 2, identify a file210(j) within the set of files210(1)-(k) and generating a hash220(j) of file210(j).

Determination module108may identify the second file within any suitable context. For example, determination module108may determine that the second file is subject to a security assessment. Accordingly, determination module108may determine that no hash for the second file has been generated, and then generate the hash for the second file (e.g., having determined that the second file is non-volatile).

UsingFIG. 4as an example, timeline400may include a file “B” hash check410followed by a file “B” hash creation412and a file “B” hash storage. For example, determination module108may identify file “B” for a security assessment and check for the existence of a hash for file “B”. Determination module108may then create a hash for file “B” (e.g., having determined that no hash existed and that file “B” is non-volatile). Determination module108may then store the hash for file “B” (e.g., to be available for future security assessments).

Returning toFIG. 3, at step310one or more of the systems described herein may determine that the second hash of the second file is equivalent to the first hash of the first file and, in response, determine that the result of the first security scan of the first file applies to the second file. For example, at step310determination module108may, as part of computing device202inFIG. 2, determine that hash220(j) of file210(j) is equivalent to hash220(1) of file210(1) and, in response, determine that scan result222of the security scan of file210(1) applies to file210(j).

Determination module108may determine that the second hash of the second file is equivalent to the first hash of the first file in any suitable manner. For example, determination module108may query a database storing the first hash of the first file (e.g., previously stored by storing module106) with the second hash, and receive a hit of the second hash in response. In some examples, simply by identifying the hit, determination module108may determine that an identical file has previously been scanned and determined to be clean, safe, and/or non-sensitive. Additionally or alternatively, determination module108may receive a representation of the result of the first security scan on the first file in response to the query.

UsingFIG. 4as an example, following file “B” hash storage414, determination module108may determine that the hash of file “A” matches the hash of file “B”, and that the results of file “A” scan406therefore apply to file “B”. Accordingly, timeline400may not include a separate scan of file “B”.

UsingFIG. 5as an example, determination module108may, as a part of modules102, determine that hash520and hash522match. Determination module108may therefore skip a scan of file512, instead relying on a result of a past scan of file510based on the matching hashes520and522.

Returning toFIG. 3, at step312one or more of the systems described herein may identify a third file within the set of files and determine that the third file is volatile and therefore less likely to match another file within the set of files. For example, at step312identification module110may, as part of computing device202inFIG. 2, identify a file210(k) within the set of files210(1)-(k) and determine that file210(k) is volatile and therefore less likely to match another file within the set of files210(1)-(k).

As used herein, the term “volatile” may refer to any file may and/or is likely to change in the future and/or that has changed in the past and/or recent past. As will be described in greater detail below, the systems and methods described herein may use any of a variety of criteria to judge the volatility of a file.

Identification module110may identify the third file in any suitable context. For example, identification module110may identify the third file by determining that the third file is subject to a security assessment. In some examples, identification module110may identify the third file in response to identifying the creation and/or modification of the third file.

Identification module110may determine that the third file is volatile in any of a variety of ways. For example, identification module110may identify a prior hash indicator that a prior hash for the third file has previously been generated. Identification module110may also identify a current hash indicator that no valid current hash for the third file is available. The prior hash indicator may include any value capable of indicating that a hash has previously been generated for a file (e.g., whether or not the hash is currently available). For example, the prior hash indicator may include a flag that is set when a hash is generated for the file. The current hash indicator may include any value capable of indicating that a valid current hash for a file is available. For example, the current hash indicator may include a placeholder for the current hash for the file (e.g., by setting the hash value for a file to a null value and/or otherwise deleting the hash value for a file, the systems and methods described herein may cause the current hash indicator to indicate that no valid current hash for the file is available). By determining that a hash had previously been generated for the third file but that the hash is no longer valid, identification module110may determine that the third file has changed, and is therefore volatile.

UsingFIG. 5as an example, one or more of modules102may generate a hash524for file514and, therefore, set a hash flag534. One or more of modules102may then determine that file514has been modified, and may therefore invalidate hash524(e.g., by overwriting hash524with a null value). Identification module110may later identify file514as subject to a security assessment. However, identification module110may not generate and/or may cause no hash to be generated for file514based on determining that a hash was previously created for file514(e.g., due to hash flag534being set). Instead, as will be described in greater detail below, one or more of the systems described herein may scan file514without hashing file514again.

In some examples, identification module110may determine that the third file is volatile simply by determining that the third file has changed since a previous security assessment of the third file. For example, identification module110may identify a modification time of the third file as described within a file system managing the third file. In some examples, identification module110may determine that the third file is volatile based at least in part of a file type of the third file (e.g., a log file, a configuration file, a user-facing document such as a word processing document, etc.).

UsingFIG. 4as an example, timeline400may include a file “C” modification416and a file “C” hash check418. For example, some time after file “C” is modified, identification module110may determine that file “C” is subject to a security assessment and check for a valid hash for file “C”. Upon determining that no valid hash exists for file “C”, identification module110may nevertheless skip a hash creation for file “C” based on determining that file “C” is volatile.

Returning toFIG. 3, at step314one or more of the systems described herein may perform a second security scan on the third file instead of generating a third hash of the third file in response to determining that the third file is volatile. For example, at step314scanning module112may, as part of computing device202inFIG. 2, perform a security scan on file210(k) instead of generating a hash of file210(k) in response to determining that file210(k) is volatile.

Scanning module112may perform the second security scan instead of generating the third hash in any suitable manner. For example, scanning module112may block the generation of the third hash. In some examples, scanning module112may skip an instruction that would otherwise generate the third hash.

UsingFIG. 4as an example, timeline400may include a file “C” scan. For example, scanning module112may scan file “C” without generating a hash for file “C” in response to determining that file “C” is volatile. As shown inFIG. 4, timeline400may include no creation of a hash for file “C” (e.g., following file “C” hash check418and before file “C” scan420).

UsingFIG. 5as an example, scanning module112may scan file514without generating a new hash524for file514based on determining that file514is volatile (e.g., because no current hash524exists but hash flag534has been set, indicating that hash524existed before but was later invalidated by a change to file514).

In some examples, one or more of the systems described herein may also 1) identify a digitally-signed file within the set of files and 2) perform a security assessment on the digitally-signed file by verifying a digital signature of the digitally-signed file instead of generating an additional hash for the digitally-signed file or performing an additional security scan on the digitally-signed file. By neither generating hashes for nor scanning digitally-signed files, the systems and methods described herein may avoid resource-intensive operations for files that have already been validated as safe.

In some examples, one or more of the systems described herein may determine that a file previously designated as volatile is not volatile. For example, generation module104may 1) determine that the third file has not changed over a predetermined period of time, 2) mark the third file as non-volatile (e.g., in response to the determination that the third file has not changed over the predetermined period of time), and 3) generate the third hash for the third file based on the third file being marked as non-volatile. For example, the third file may have been subject to a non-signed update that modified the file but which does not signify that the file is subject to frequent changes and/or that the file is unlikely to match parallel files on other computing systems. Accordingly, by marking the third file as non-volatile, generation module104may capture potential resource savings from generating a hash for the third file.

As explained above, by generating hashes of non-volatile files and scanning only files whose hashes do not match hashes of previously scanned files, but scanning volatile files without generating hashes for the volatile files, the systems and methods described herein may avoid redundant scanning operations using hashes while also avoiding generating hashes in resource-inefficient circumstances. For example, by directly scanning volatile files instead of generating hashes for the volatile files, these systems and methods may consume fewer computing resources in the short term (e.g., because generating hashes may consume significant computing resources) without sacrificing resource efficiency in the long term (e.g., because volatile files may change before their hashes could be reused in future scanning operations and/or because volatile files may be significantly less likely to match other files in the first place).

As detailed above, computing system610and/or one or more components of network architecture700may perform and/or be a means for performing, either alone or in combination with other elements, one or more steps of an exemplary method for performing security scans.

In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another. For example, one or more of the modules recited herein may receive a file to be transformed, transform the file, output a result of the transformation, use the result of the transformation to reuse prior security scan results (e.g., for duplicative files across disparate systems, such as virtual machines), and store the result of the transformation to a hash database on a storage device. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and/or any other portion of a physical computing device from one form to another by executing on the computing device, storing data on the computing device, and/or otherwise interacting with the computing device.