Patent Description:
Data on a computing device may need to be restored for various reasons. For example, an operating system on a computing device may experience corruption and the system may need to retrieve an uncorrupted set of backup files as a replacement. Traditionally, backup copies are made only for the data that is needed to restore a user's system. This data may include installed applications, settings, documents, files, databases, etc..

As the reliance on digital computing has increased, the amount of cybercrimes such as hacking, data theft, and malware attacks, has followed suit. As a result, it has become necessary to save additional information about the data on a system when creating backup copies, which can be used to investigate these cybercrimes. Forensics engineers can utilize this additional information to determine the origins of an attack and detect remaining artifacts and traces of the attack on a system.

However, digital forensics investigations require urgency, time and manpower. A brute force approach to analyzing data item by item is ineffective because this approach involves multiple assumptions such as the untrusted objects not being deleted by an attacker and the authenticity of the data being analyzed. The time to complete an investigation using this approach is further dependent on the amount of data to analyze. For example, the time to review a significantly large hard drive may be exponentially greater than the time required for a smaller hard drive because investigators have far more files to review and may not necessarily know where to start the analysis. This approach can be even more discouraging when an investigation is inconclusive because the relevant data on a system has already been removed by the time an investigator begins the analysis because, for example, the computing device in question has been restarted, formatted, or damaged.

Therefore, there is a need for a method of generating and storing forensics-specific metadata that addresses the shortcomings described above.

Documents <CIT> and <CIT> the creation of backups and the use of the backup and metadata to identify suspicious activities.

Aspects of the disclosure relate to the field of data security. In particular, aspects of the disclosure describe methods and systems for generating and storing forensics-specific metadata.

In one example, method for generating and storing forensics-specific metadata comprises a digital forensics module configured to generate a backup of user data stored on a computing device in accordance with a backup schedule. The digital forensics module identifies, from a plurality of system metadata of the backup of the user data, forensics-specific metadata of the computing device based on predetermined rules, wherein the forensics-specific metadata is utilized for detecting suspicious digital activity. The digital forensics module generates a backup of the forensics-specific metadata in accordance with the backup schedule, wherein the backup of the forensics-specific metadata is stored separately from the backup of the user data. The digital forensics module analyzes the forensics-specific metadata of the backup of the user data for an indication of the suspicious digital activity on the computing device and in response to detecting the suspicious digital activity based on the analysis, generates a security event indicating that the suspicious digital activity has occurred.

In one example, the digital forensics module further marks subsequent user data backups of the backup schedule as potentially affected by the suspicious digital activity.

In one example, the digital forensics module further requests that a digital investigation be performed.

In one example, the digital forensics module further restores the computing device with a previous backup of the user data generated prior to the suspicious digital activity.

In one example, the digital forensics module further increases a frequency of generating backups in the backup schedule of the forensics-specific metadata.

In one example, the forensics-specific metadata comprises at least one of: an identifier of a running process, memory allocation information, an identifier of a running thread, security privilege information, registry information, an identifier of a hidden process, and an auto-run path on the computing device.

In one example, the digital forensics module generates a notarization identifier of the backup of the forensics-specific metadata, wherein the notarization identifier is one of: a blockchain transaction identifier, a hash value, a digital signature, or a checksum. The digital forensics module then stores the notarization identifier with the backup of the forensics-specific metadata.

In one example, the digital forensics module analyzes the forensics-specific metadata for the indication of the suspicious digital activity by first identifying a first backup of the forensics-specific metadata generated at a first time and a second backup of the forensics-specific metadata generated at a second time after the first time. The digital forensics module then detects, from the forensics-specific metadata, a process in the second backup that is not present in the first backup and determines whether the process is trusted. In response to determining that the process is not trusted, the digital forensics module detects the indication of the suspicious digital activity on the computing device.

In one example, the digital forensics module determines whether the process is trusted by comparing the process to a plurality of known trusted processes listed in a data structure and determining that no match between the process and a known trusted process in the plurality of known trusted processes exists.

In one example, the digital forensics module further identifies characteristics of the suspicious digital activity and identifies enhanced forensics-specific metadata based on those characteristics, wherein the enhanced forensics-specific metadata comprises characteristic-specific details of the suspicious digital activity. The digital forensics module then generates subsequent backups of the enhanced forensics-specific metadata (either additionally or alternatively to the original forensics-specific metadata).

The above simplified summary of example aspects serves to provide a basic understanding of the present disclosure. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects of the present disclosure. Its sole purpose is to present one or more aspects in a simplified form as a prelude to the more detailed description of the disclosure that follows. To the accomplishment of the foregoing, the one or more aspects of the present disclosure include the features described and exemplarily pointed out in the claims.

Exemplary aspects are described herein in the context of a system, method, and computer program product for generating and storing forensics-specific metadata. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other aspects will readily suggest themselves to those skilled in the art having the benefit of this disclosure. Reference will now be made in detail to implementations of the example aspects as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.

<FIG> is a block diagram illustrating system <NUM> for generating and storing forensics-specific metadata. The system <NUM> includes computing device <NUM>, which may comprise a personal computer, server, etc., that includes a computer processing unit ("CPU"), and a memory that includes software for performing various tasks (e.g., Operating System (OS) software, application software, etc.). Data for computing device <NUM> may be stored in the memory of the device itself as well as on other external devices such as backup server <NUM>, a compact disk, flash drive, optical disk, and the like.

In the present disclosure, backup data <NUM> originating from the memory of computing device <NUM> is transmitted to backup server <NUM> over network <NUM>. Network <NUM> may be the Internet, a mobile phone network, a data network (e.g., a <NUM> or LTE network), Bluetooth, or any combination thereof. For example, backup server <NUM> may be part of a cloud computing environment accessed via the Internet, or may be part of a local area network (LAN) with computing device <NUM>. The lines connecting backup server <NUM> and computing device <NUM> to network <NUM> represent communication paths, which may include any combination of free-space connections (e.g., for wireless signals) and physical connections (e.g., fiber-optic cables).

In should be noted that there may be more than one backup server <NUM>, but only one is shown in <FIG> to avoid overcomplicating the drawing. For example, backup server <NUM> may represent a plurality of servers in a distributed cloud cluster. Backup server <NUM> may comprise any number of physical components (e.g., as shown in <FIG>). For example, backup server <NUM> may comprise a number of physical components, e.g., processors, physical block storage devices (e.g., Hard Disk Drives (HDDs), Solid State Drives (SSDs), flash drives, SMR disks, etc.) or memory (e.g., Random Access Memory (RAM)), I/O interface components, etc..

Backup data <NUM> may be any type of data including user data, applications, system files, preferences, documents, media, etc. Computing device <NUM> may send backup data <NUM> for storage in backup server <NUM> in accordance with a backup schedule that indicates the specific data to include in backup data <NUM> and the frequency at which the data should be backed up. For example, computing device <NUM> may generate a copy of a data file existing in the memory of computing device <NUM> and transmit the copy as backup data <NUM> to backup server <NUM> every other hour. Backup data <NUM> may be selected by a user of computing device <NUM> and the frequency of the backup schedule may also be selected by a user.

As described above, although backing up data allows for the preservation of information on a system (e.g., computing device <NUM>), defending against potential suspicious digital activities makes saving additional information about the data on computing device <NUM> necessary. Forensics engineers can utilize this additional information to determine the origins of a suspicious digital activity and detect remaining artifacts and traces of the suspicious digital activity on computing device <NUM>. Because a forensics analysis may be time consuming as engineers must manually extract data and review all information item-by-item, there is a need for a method that reduces the time for evidence triage, provides access to evidence content without data unarchiving, and authenticates the data to ensure that the data is not corrupted.

Accordingly, the present disclosure provides a method for generating and storing forensics-specific metadata. Digital forensics module <NUM> comprises three components, namely: forensics-specific (FS) metadata generator <NUM>, activity analyzer <NUM>, and notary <NUM>. Digital forensics module <NUM> may reside on computing device <NUM> and may be executed by the processor of computing device <NUM>. Digital forensics module <NUM> may be a backup software divided as a thin client on computing device <NUM> and a thick client on backup server <NUM> (or vice versa). In some embodiments, digital forensics module <NUM> may reside on an external device, such as a server connected to computing device <NUM> over network <NUM> or a direct communication path (e.g., a USB cable).

In order to provide to a forensics engineer with the information needed to conduct a forensics analysis in an efficient manner, FS metadata generator <NUM> identifies the relevant data and metadata on computing device <NUM> that should be separately stored in an accessible archive. In some embodiments, FS metadata generator <NUM> may extract the metadata of backup data <NUM> and store it in backup server <NUM> as FS metadata <NUM>. FS metadata <NUM> may include various predetermined attributes of backup data <NUM> that are prone to change during a suspicious digital activity. Such attributes include the identification of backup data <NUM>, a path to backup data <NUM>, identification of processes utilizing backup data <NUM>, and memory utilization associated with backup data <NUM>.

FS metadata generator <NUM> may collect system information using various internal system functions and calls. Although collecting system information can be performed on any operating system, for the sake of brevity, the metadata collection functions and calls discussed in the present disclosure are specific to Windows™ operating systems. It should be noted that FS metadata generator <NUM> may employ comparable functions and calls to extract comparable metadata in any other operating system running on computing device <NUM>.

FS metadata generator <NUM> may enumerate processes using any of the following functions: EnumProcesses, WTSEnumerateProcesses, CreateToolhelp32Snapshot, Process32First, Process32Next, NtQuerySystemInformation (SystemProcessAndThreadInformation).

FS metadata generator <NUM> may extract metadata such as name, description and company name of a specified file by Path via resource APIs: GetFileVersionInfoSize, GetFileVersionInfo, and VerQueryValue.

FS metadata generator <NUM> may extract metadata such as base address, size, and load count of a specified file via the function NtQuerySystemInformation (SystemProcessAndThreadInformation).

FS metadata generator <NUM> may extract metadata about memory usage of a specified process using the function GetProcessMemoryInfo.

FS metadata generator <NUM> may extract metadata such as command line and current directory information using the function NtQueryInformationProcess, where the function ReadProcessMemory is used to read from the Process Environment Block (PEB).

FS metadata generator <NUM> may extract metadata regarding a dynamic link library (DLL) file such as DLL base address, DLL size, and DLL loadcount using the function EnumProcessModules. Furthermore, FS metadata generator <NUM> may extract metadata regarding a DLL file such as name, description, and company name by Path via resource APIs: GetFileVersionInfoSize, GetFileVersionInfo, VerQueryValue.

FS metadata generator <NUM> may extract metadata regarding a process such as timing information using the function GetProcessTimes.

FS metadata generator <NUM> may extract metadata such as a list of all open handles for each process using the function NtQuerySystemInformation(SystemHandleInformation).

FS metadata generator <NUM> may extract metadata such as mitigation policy settings for a process (e.g., Address Space Layout Randomization (ASLR) policy or Control Flow Guard (CFG) policy) using the functions GetProcessMitigationPolicy(ProcessASLRPolicy) and GetProcessMitigationPolicy(ProcessControlFlowGuardPolicy), respectively.

FS metadata generator <NUM> may extract metadata such as a copy of the security descriptor for an object specified by a handle using the function GetSecurityInfo.

FS metadata generator <NUM> may extract metadata such as information about an access token using the function GetTokenInformation(TokenUser). An access token is created by a system such as computing device <NUM> when a user logs on. Every process executed on behalf of the user has a copy of the access token. The access token identifies the user, the user's groups, and privileges. FS metadata generator <NUM> may use the function PrivilegeCheck to determine whether an access token holds a specified set of privileges.

FS metadata generator <NUM> may extract metadata such as the priority class for a specified process along with the priority value of each thread of the process using the functions GetPriorityClass and GetThreadPriority, respectively.

FS metadata generator <NUM> may extract metadata of the services registered in a process such as service name, description, path and state. Likewise, FS generator <NUM> may extract metadata of threads such as TID, start time, kernel time, user time, stacktrace, and stackwalk using the functions CreateToolhelp32Snapshot, Thread32First and Thread32Next.

FS metadata generator <NUM> may extract metadata such as names of the programs that are initiated at startup by reading the values in the following registry keys:.

FS metadata generator <NUM> may extract metadata using a forensics tool such as the Volatility Framework™. For example, FS metadata generator <NUM> may extract information on hidden processes using the command "psxview," may scan memory for loaded, unloaded, and unlinked drivers using the command 'modscan" or "moddump," may find API/DLL function hooks using the command "apihooks," may find hooks in a system service descriptor table using the command "ssdt," may identify I/O request packet (IRP) hooks using the command "driverirp," and may extract the interrupt descriptor table using the command "idt," may extract the command history buffer using the command "cmdscan," may extract console information using the command "consoles," may identify services registered in a system using the command "svcscan.

FS metadata generator <NUM> may extract metadata such as network socket information (e.g., a list of TCP/UDP endpoints available to an application) using the functions GetExtendedTcpTable and GetExtendedUdpTable.

FS metadata generator <NUM> may extract metadata such as the master file table (MFT) records detailing information about a file on an NTFS file system volume, including its size, time and date stamps, permissions, and data content.

FS metadata generator <NUM> may extract metadata detailing the set of existing logon session identifiers (LUIDs), the number of sessions and information about a specified logon session using the functions LsaEnumerateLogonSessions and LsaGetLogonSessionData.

FS metadata generator <NUM> may extract metadata such as windows event logs using the function ReadEventLog.

FS metadata generator <NUM> may extract metadata such as a file list of recycle bin contents using the functions SHGetDesktopFolder and SHGetSpecialFolderLocation(CSIDL_BITBUCKET).

FS metadata generator <NUM> may extract metadata such as the IPv4 to physical address mapping table using the function GetIpNetTable.

FS metadata generator <NUM> may extract metadata such as DNS cache information using the function DnsQuery(DNS_QUERY_NO_WIRE_QUERY).

FS metadata generator <NUM> may generate a screenshot using the functions CreateCompatibleDC, CreateCompatibleBitmap, StretchBlt, BitBlt, and GetDIBits.

Additional metadata that FS metadata generator <NUM> may extract is computer name, domain name, time zone, environment variables, signatures and certificates. To determine metadata such as hashes, entropy profile, and strings, FS metadata generator <NUM> may employ special calculation and search methods.

FS metadata generator <NUM> may generate FS metadata <NUM>. FS metadata <NUM> may be a data structure (e.g., an array) that aggregates any combination of the metadata previously described. For example, a first field of the data structure may indicate the name of the data file, a second field of the data structure may indicate the path of the data file, and so on.

FS metadata generator <NUM> may generate FS metadata <NUM> based on predetermined rules for selecting a combination of the metadata described above and periodically collecting this information for backup. These predetermined rules may be stored in memory of computing device <NUM> or backup server <NUM>. In one example, a rule may indicate that depending on the state of computing device <NUM> (e.g., suspicious activity detected or no suspicious activity detected), to retrieve a certain set of the metadata described above. For example, a rule may specify that when suspicious activity is not detected, to collect at least one of: identifiers of running processes, memory allocation information, identifiers of running threads, security privilege information, registry information, identifiers of hidden processes, and auto-run paths on the computing device. If suspicious activity is detected, an additional set of metadata may be included in the list of forensics-specific metadata such as identifiers of idle processes, identifies of idle threads, etc., according to the predetermined rule. Another rule may indicate to reduce the number of types of forensics-specific metadata to retrieve for backup depending on whether computing device <NUM> is inactive (e.g., in sleep mode). Yet another rule may indicate to reduce the number of types of forensics-specific metadata to retrieve for backup if the amount of free space in backup server <NUM> reaches below a threshold amount of space. And yet another rule may indicate to reduce the number of types of forensics-specific metadata to retrieve for backup if the frequency of the backup schedule is higher than a threshold frequency (e.g., to ensure that the backup of forensics is not too processing or memory intensive). In terms of reduction, the rule may specify the exact number of metadata types to retrieve. For example, if by default <NUM> metadata types are being retrieved for backup, the rule may indicate to reduce the number to <NUM> metadata types.

Activity analyzer <NUM> analyzes the attributes of FS metadata <NUM> stored on computing device <NUM> and may serve as the first line of defense for detecting suspicious digital activity. For example, FS metadata <NUM> may comprise the enumerated processes executing on computing device <NUM> (e.g., retrieved by FS metadata generator <NUM> using the function EnumProcesses). Activity analyzer <NUM> may thus identify foreign processes that have not been executed by an authorized user of computing device <NUM>. Activity analyzer <NUM> may also scan FS metadata <NUM> for foreign applications and data files that have not been installed by an authorized user of computing device <NUM>. In response to detecting a foreign process, application or data file, activity analyzer <NUM> may generate a security event indicating suspicious digital activity on computing device <NUM>. The security event represents a signal requesting that a digital investigation be performed. As mentioned before, any delays in reporting suspicious digital activity may be costly. By the time a forensics engineer may get to examine computing device <NUM>, damage from a cyberattack may already have been performed. Accordingly, in response to finding an indication of suspicious digital activity, a security event is immediately generated. The security event may, for example, be an alert to the user of computing device <NUM> that suspicious activity is detect.

In one example, activity analyzer <NUM> may mark subsequent user data backups (e.g., backup data <NUM>) of the backup schedule as potentially affected by the suspicious digital activity. In one example, activity analyzer <NUM> may restore computing device <NUM> with a previous backup of backup data <NUM> generated prior to the suspicious digital activity. Specifically, activity analyzer <NUM> may transmit backup data <NUM> and FS metadata <NUM> to backup server <NUM>, both with a marker indicating that suspicious digital activity has been detected, and may retrieve, from backup server <NUM>, a prior copy of backup data <NUM> that does not feature the suspicious digital activity to replace at computing device <NUM>. In one example, the digital forensics module further increases a frequency of generating backups in the backup schedule of the forensics-specific metadata.

Another aspect of the present disclosure is to verify the authenticity of the data being analyzed in a forensics analysis. Typically a forensics engineer extracts data from computing device <NUM>, but it is possible that the data being extracted has been corrupted by the suspicious digital activity. It is also possible that computing device <NUM> underwent a change such as a shutdown or being formatted to an extent that a forensics engineer cannot generate accurate reports of the data. Therefore, there is a need to verify whether the data being analyzed is authentic and has not been altered in any way.

Notary <NUM> may generate a notarization identifier of the backup of the forensics-specific metadata, wherein the notarization identifier is one of: a blockchain transaction identifier, a hash value, a digital signature, or a checksum. Notary <NUM> may then store the notarization identifier with the backup of the forensics-specific metadata. For example, notary <NUM> may generate hash values of FS metadata <NUM> in computing device <NUM> to enable this verification process. When FS metadata <NUM> is being transmitted to backup server <NUM>, notary <NUM> may utilize a cryptographic hash function to generate a hash value of FS metadata <NUM> and subsequently add the hash value to the backup. In some embodiments, computing device <NUM> may transmit backup data <NUM> and FS metadata <NUM> simultaneously to backup server <NUM>. Thus, for any given backup data <NUM> on backup server <NUM>, there exists FS metadata <NUM> with relevant metadata information about computing device <NUM> (including a corresponding hash value). By storing a notarization proof such as a blockchain transaction ID, the authenticity of the metadata is ensured.

<FIG> illustrates a flow diagram of method <NUM> for generating and storing forensics-specific metadata. At <NUM>, FS metadata generator <NUM> generates a backup of user data stored on a computing device in accordance with a backup schedule. The backup data may include data files (e.g., photos, videos, documents, applications, etc.) and settings associated with the user. The backup schedule may require backing up the identified user data periodically (e.g., once per hour). At <NUM>, FS metadata generator <NUM> identifies system metadata. In one example, suppose that the system metadata is idle threads information. This metadata may be a part of a list of system metadata that can be retrieved by FS metadata generator <NUM>. Of course, retrieving all available system metadata can be processor and memory intensive, and can be a burden on a forensics engineer to review. Therefore, reducing the amount of metadata to backup is necessary and allows for improved visibility of suspicious digital activity when only forensics-specific metadata is considered.

At <NUM>, FS metadata generator <NUM> determines whether the system metadata is classified as forensics-specific metadata. Referring to the previous example, FS metadata generator <NUM> may retrieve a list of predetermined rules, of which one may indicate that during normal activity (e.g., when no suspicious digital activity is detected), information about idle threads does not need to be stored as a part of forensics-specific metadata. In response to determining that the system metadata is not classified as forensics-specific metadata, method <NUM> advances to <NUM>, where FS metadata generator <NUM> determines whether all system metadata has been considered (e.g., whether there is other unconsidered system metadata in the list of system metadata).

At <NUM>, FS metadata generator <NUM> may determine that there is other system metadata to consider. As a result, method <NUM> returns to <NUM>, where different system metadata is identified. For example, FS metadata generator <NUM> may consider identifiers of running processes on the computing device as system metadata. At <NUM>, FS metadata generator <NUM> may determine that the identifiers of running processes are classified as forensics-specific metadata. Thus, at <NUM>, FS metadata generator <NUM> retrieves the system metadata (e.g., the identifiers of running processes) for backup as a part of forensics-specific metadata. For example, FS metadata generator <NUM> may use the functions described above to enumerate running processes and collect their respective PIDs. From <NUM>, method <NUM> returns to <NUM> so that other forensics-specific metadata may be retrieved.

If no other system metadata is to be considered at <NUM>, method <NUM> advances to <NUM>, where FS metadata generator <NUM> generates a backup for the forensics-specific metadata in accordance with the backup schedule. For example, FS metadata generator <NUM> may aggregate the retrieved forensics-specific metadata and upload it to backup server <NUM> via network <NUM>.

At <NUM>, activity analyzer <NUM> may determine whether suspicious digital activity has been detected based on the forensics-specific metadata. This is further discussed in the description of <FIG>. In response to detecting the suspicious digital activity, at <NUM>, activity analyzer <NUM> generates a security event. For example, activity analyzer <NUM> may signal a request for a digital investigation by a forensics engineer. If suspicious digital activity is not detected, method <NUM> returns to <NUM>, where another cycle of backup begins.

<FIG> illustrates a flow diagram of method <NUM> for detecting suspicious digital activity. At <NUM>, activity analyzer <NUM> may identify a first backup of the forensics-specific metadata generated at a first time (e.g., in the previous cycle of the backup schedule). At <NUM>, activity analyzer <NUM> identifies a second backup of the forensics-specific metadata generated at a second time after the first time (e.g., the current backup).

At <NUM>, activity analyzer <NUM> compares the respective backups to identify a process that exists in the second backup and not in the first backup. If no such process is found, method <NUM> ends. In response to identifying such a process, activity analyzer <NUM> may determine whether the process is trusted. For example, activity analyzer <NUM> may determine whether the process is trusted by comparing the process to a plurality of known trusted processes listed in a data structure. In response to determining that no match between the process and a known trusted process in the plurality of known trusted processes exists, activity analyzer <NUM> may determine that the process is not trusted. Based on this, method <NUM> advances to <NUM>, where activity analyzer <NUM> detects an indication of suspicious digital activity on the computing device.

If the process is in fact trusted (e.g., found in the list of trusted processes), method <NUM> instead advances to <NUM>, where activity analyzer <NUM> detects no suspicious digital activity on the computing device.

<FIG> illustrates a flow diagram of method <NUM> for updating the backup schedule based on the detection of suspicious digital activity. Method <NUM> may be executed by digital forensics module <NUM> after activity analyzer <NUM> generates a security event at <NUM> of method <NUM>. At <NUM>, FS metadata generator <NUM> may increase a frequency of the backup schedule. Suppose that the frequency of the backup schedule is once every minute. It is possible that a full-fledged cyberattack has yet to occur and any detected suspicious digital activity is a component of a potential cyberattack. In order to improve the granularity of information for a forensics engineer performing a digital investigation, the frequency of backups and the amount of targeted details about the suspicious activities should increase. Accordingly, at <NUM>, FS metadata generator <NUM> may increase the frequency of the backup schedule - specifically for forensics-specific metadata - to every <NUM> seconds (rather than every minute).

At <NUM>, activity analyzer <NUM> may identify a characteristic of the suspicious digital activity. For example, the suspicious digital activity may be the running of a process that is untrusted. The characteristic of the suspicious digital activity may thus be the PID of the process. At <NUM>, FS metadata generator <NUM> may identify system metadata for enhanced details on the suspicious digital activity based on the characteristic. For example, FS metadata generator <NUM> may initially retrieve the PIDs of running processes exclusively. In response to identifying the characteristic, FS metadata generator <NUM> may begin monitoring additional details about the untrusted process such as memory usage, security privileges and thread information.

At <NUM>, FS metadata generator <NUM> retrieves the identified system metadata as part of an enhanced forensics-specific metadata. Method <NUM> then proceeds to <NUM> of method <NUM>. Accordingly, during the second iteration of method <NUM> (e.g., after suspicious activity has been detected), subsequent backups of forensics-specific metadata will occur more frequently and with additional details about the suspicious digital activity (as a part of enhanced forensics-specific metadata).

<FIG> is a block diagram illustrating a computer system <NUM> on which aspects of systems and methods for storing and generating forensics-specific metadata may be implemented. The computer system <NUM> may represent computing device <NUM> and/or backup server <NUM> and can be in the form of multiple computing devices, or in the form of a single computing device, for example, a desktop computer, a notebook computer, a laptop computer, a mobile computing device, a smart phone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

As shown, the computer system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, and a system bus <NUM> connecting the various system components, including the memory associated with the central processing unit <NUM>. The system bus <NUM> may comprise a bus memory or bus memory controller, a peripheral bus, and a local bus that is able to interact with any other bus architecture. Examples of the buses may include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<NUM>C, and other suitable interconnects. The central processing unit <NUM> (also referred to as a processor) can include a single or multiple sets of processors having single or multiple cores. The processor <NUM> may execute one or more computer-executable code implementing the techniques of the present disclosure. For example, any of methods <NUM>-<NUM> performed by digital forensics module <NUM> (e.g., via its components such as FS metadata generator <NUM>) may be executed by processor <NUM>. The system memory <NUM> may be any memory for storing data used herein and/or computer programs that are executable by the processor <NUM>. The system memory <NUM> may include volatile memory such as a random access memory (RAM) <NUM> and non-volatile memory such as a read only memory (ROM) <NUM>, flash memory, etc., or any combination thereof. The basic input/output system (BIOS) <NUM> may store the basic procedures for transfer of information between elements of the computer system <NUM>, such as those at the time of loading the operating system with the use of the ROM <NUM>.

Computer readable program instructions for carrying out operations of the present disclosure may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, through the Internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

In various aspects, the systems and methods described in the present disclosure can be addressed in terms of modules. The term "module" as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or FPGA, for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a computer system. Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

Furthermore, it is to be understood that the phraseology or terminology used herein is for the purpose of description and not of restriction, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combination with the knowledge of those skilled in the relevant art(s). Moreover, it is not intended for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.

Claim 1:
A method for storing forensics-specific metadata, the method comprising:
generating a backup of user data stored on a computing device in accordance with a backup schedule;
identifying, from a plurality of system metadata of the computing device, forensics-specific metadata of the backup of the user data based on predetermined rules, wherein the forensics-specific metadata is utilized for detecting suspicious digital activity;
generating a backup of the forensics-specific metadata in accordance with the backup schedule, wherein the backup of the forensics-specific metadata is stored separately from the backup of the user data;
analyzing the forensics-specific metadata of the backup of the user data for an indication of the suspicious digital activity on the computing device; and
in response to detecting the suspicious digital activity based on the analysis, generating a security event indicating that the suspicious digital activity has occurred.