System and method for event-based data acquisition in real-time applications

A system for acquiring time limited data to facilitate integrity verification in real-time applications (RTAs) includes an agent and a collector. The agent is associated with a RTA and is in communication with the collector. The agent defines a plurality of time ordered time frames and during each time frame collects a collection of events from event sources occurring on the RTA. The agent calculates a local integrity check from the collection and a previous integrity check or an initial key, and transmits a global integrity check calculated from local integrity checks to the collector. The collector receives the global integrity check from the agent and stores the received global integrity check in a secure storage. The collector validates the integrity of the global integrity check and the received collections of events.

FIELD OF THE INVENTION

The present invention relates to system forensics analysis (also known as digital forensics or computer forensics), and more particularly, is related to proactively acquiring data in real-time applications.

BACKGROUND OF THE INVENTION

Some proceedings or analyses involve or utilize data collected by or extracted from one or more computer based real-time applications (RTA), for example, web servers, application servers, database servers, operating systems and/or business critical applications (BCAs), among others. Examples of BCAs include, but are not limited to Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supplier Relationship Management (SRM), Supply Chain Management (SCM), Product Life-cycle Management (PLM), Human Capital Management (HCM), Integration Platforms, Business Warehouse (BW)/Business Intelligence (BI) and Integration applications developed by SAP, Oracle, Microsoft, Siebel, J D Edwards and PeopleSoft. While it is noted that such proceedings or analyses are in no way limited to evidence gathering, looking at an example of forensics analysis where the collected/extracted data may be used as evidence, the data collected by previous systems has not shown when and how specific data became available (e.g., was received or derived) by the RTA. This may be important, for example, for proving chain of custody (CoC) of certain information used by and/or stored by the RTA. Examples of other such proceedings include, but are not limited to, compliance testing and/or verification of RTAs, internal/external controls verification, audit processes such as SOX audits, PCI audits, and other standards.

When high use computer based systems are subjected to data collection/extraction such as, for example, in forensics analysis, the traditional way of extracting evidence and checking its integrity is not feasible for RTAs. The traditional chain of custody for data collected from computer systems is not applicable for RTAs. For RTAs, the evidence identification and acquisition (first step of CoC) and the characteristics such evidence must comply with has not been achieved for RTAs in the same manner as for more simple services or computers. For instance, the first step of a forensics process is often related to imaging and data handling. As RTAs such as BCAs are usually huge systems that cannot be shut down, these types of processes may be impracticable.

Currently, extracting data from an RTA is performed without shutting down the system, without a user of the system being aware of altering the behavior of the system, and without modifying the data itself.

While current data acquisition practices are internationally accepted, they only warranty a snapshot of the moment when the data was extracted. However, in certain circumstances it is necessary, or desirable, to have data extraction repeatable and reproducible. For example, according to NIST (National Institute of Standards and Technology), the results of a digital forensics procedure must be repeatable and reproducible to be considered admissible as electronic evidence. Repeatability means that the same results should be obtained when performing the same procedure within short intervals of time; reproducibility means that the same results should be obtained when performing the same procedure in different facilities; and, time limited means that the evidence may be attributable to an identifiable, defined period of time. It should be noted that as per the Detailed Description section, the definitions of these terms as used within this disclosure may be broader than the NIST definitions.

Since an RTA such as a BCA is constantly being heavily used, information within the BCA is modified at every moment, so every elapsed second may represent thousands of changes in the information. As a consequence, the data acquired using current methods from RTAs is neither repeatable nor reproducible. Further, previous systems and methods support the integrity for evidence acquisition in only one events source which, while possibly useful in certain scenarios, may not be scalable to systems with multiple sources of information. A description of this type of evidence acquisition has been described, for example, by Bruce Schneier and John Kelsey (“Secure Audit Logs to Support Computer Forensics,” January 1998), and Emiliano Kargieman and Ariel Futoransky (“VCR and PEO revised”, October 1998). These mechanisms are generally event based, such that an integrity calculation is calculated per event, as shown byFIG.1. Such systems may work in concert with a security audit log file, including static organizational data that must be constantly updated. In addition, both mechanisms depend upon not leaking the integrity check, thereby implementing forward secrecy. In practice, however, the integrity of the events is unenforceable if the integrity check (hash) is compromised.

An integrity check for each subsequent event is calculated using the current event and the previous integrity check k. Integrity checks are stored in integrity storage, for example, a hard drive. An initial random key k0is stored in secure storage, and used for the first integrity calculation. An events source produces multiple events, so n integrity checks k1, k2, kn, k0+1are performed as a result of the occurrence of n events event_0, event_1, . . . , event n. Each integrity check k is calculated per event, independently of when each event occurred. Consecutive integrity checks are chained together to calculate a single check for all of them. If the integrity check is compromised, the integrity of the system cannot be ensured. Further, since there is no time reference, the system check is time dependent, and changes over time as additional events occur, there is no way to reconstruct the integrity check at a specified moment in time. Therefore, there is a need in the industry to address one or more of these shortcomings.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a system and method for events-based acquisition of time limited data to facilitate integrity verification in real-time applications (RTAs). Briefly described, the present invention is directed to a system for data acquisition from real-time applications (RTAs) including an agent and a collector. The agent is associated with an RTA and is in communication with the collector. The agent defines a plurality of time ordered time frames and during each time frame collects a collection of events from event sources occurring on the RTA. The agent calculates a local integrity check from the collection of events and a previous integrity check or an initial key, and transmits a global integrity check calculated from local integrity checks to the collector. The collector receives the global integrity check from the agent and stores the received global integrity check in a secure storage.

Other systems, methods and features of the present invention will be or become apparent to one having ordinary skill in the art upon examining the following drawings and detailed description. It is intended that all such additional systems, methods, and features be included in this description, be within the scope of the present invention and protected by the accompanying claims.

DETAILED DESCRIPTION

The following definitions are useful for interpreting terms applied to features of the embodiments disclosed herein, and are meant only to define elements within the disclosure.

As used within this disclosure, a “time frame” is a period of time having a defined duration (otherwise known as a “time window”) where events may be collected by an agent from an RTA. A time frame may have a duration ranging from, for example, on the order of one or more seconds, to several minutes or more. Different time frames, for example, two different time frames configured by the user in the same agent, may have different durations. For example, time frames may be relatively short during times of high RTA activity, and relatively long during times of low RTA activity (for instance, outside of normal business operating hours).

As used within this disclosure, a “source” is an addressable storage/memory location within an RTA where one or more events may reside. For example, a source may include a database table, a plain-text file, or any other form of data format stored in persistent memory. An event refers to an instance of one or more instances of data within a source being changed: added, deleted, or altered.

As used within this disclosure, “local” refers to data, an event, or an operation occurring at a single collection, for example, a local integrity check refers to an integrity check performed at a collection of on data/events of one time frame. In contrast, “global” refers to data, an event, or an operation involving two or more collections. For example, a global integrity check refers to an integrity check based on collections of data/events of more than one time frame.

As used within this specification, a “business-critical application” (BCA) generally refers to a crucial application to keeping the business running. These types of applications can vary from small tools to company-wide systems. These applications can work on clients' servers, be provided by third parties, or can be developed internally. Generally speaking, these are critical applications that if interrupted, the interruption could result in financial losses, legal losses, negative publicity for the company, unhappy employees or customers, etc. A BCA may be totally different in different companies or different industries; depending on which system(s) could cause significant damage to a company if problems occur. Exemplary BCAs include, for example, an enterprise resource planning (ERP) system of a retail company, a Business Intelligence system of a marketing company, or an HR system of a Human Resources Consultant. Other examples of a business critical application include an airline reservation system or a transaction process system for a bank. Examples of vendors of Business Critical Applications include SAP® and Oracle® with their huge variety of products, as well as others listed in the Background section.

As used within this disclosure, “data integrity verification” refers to the validation of integrity of data/information collected from a real-time computer based system during acquisition of the data/information, as an example, for evidence in legal proceedings.

As used within this disclosure, “evidence” is an example of verifiable results of a data acquisition procedure, for example but not limited to, a digital forensics procedure. The data acquisition procedure results may be verifiable if the results are demonstrably not corrupt, for example, if the results are repeatable, reproducible, and/or admissible as electronic evidence. An example of repeatability is that the same results may be obtained when performing the same procedure at two different times. An example of reproducibility is that the same results may be obtained when performing the same procedure in facilities, for example, in different locations, using the same or different devices or systems hosting the RTA. “Time limited” means attributable to an identifiable, closed, defined period of time. An example of evidence includes reproducible time limited data integrity verification in real-time applications. While “evidence” indicates the collected information may meet a standard for admissibility in a legal procedure, the use of the term “evidence” does not restrict the embodiments described herein to only being used for legal procedures. Indeed, the embodiments may be useful in other scenarios, for example, compliance testing/verification.

As described in the Background section, RTAs such as BCAs may operate in environments where associated servers subject to data integrity analysis, such as, but not limited to, forensic analysis, are highly critical or are a part of a critical process within a business. Due to their criticality, those systems cannot be turned off or removed from their process. Additionally, these systems may constantly modify the sources of information. Therefore, for example, these systems cannot be subject to a traditional forensics procedure with legal proceedings since the evidence would not be admissible, as it is not repeatable and/or reproducible. Exemplary embodiments of the present invention provide, but are not limited to systems and methods enabling Business Critical Applications to be part of a Chain of Custody process used for legal proceedings.

While part of the following description of the present system and method provides for use within an exemplary environment to enable BCAs to be part of a Chain of Custody process used for legal proceedings, it is noted that this example is merely provided for exemplary purposes and the present invention is in no way intended to be limited to use in enabling BCAs to be part of a Chain of Custody process used for legal proceedings. Instead, the present system and method may be used in one or more other environments.

As discussed above in the Background section, previous approaches for acquiring verifiable data such as evidence from RTAs, such as BCAs, extract the information by checking the integrity of complete files or tables (sources). As RTAs may constantly modify these sources of information, a source (file) integrity check only produces evidence relevant to a time snapshot of the constantly shifting information context contained in the system at the instant in time when the extraction occurs, and therefore may not be repeatable and/or reproducible.

In general, embodiments of the present invention calculate integrity checks in real time and without powering down an associated system by collecting event based information based on time, instead of being solely based upon the source of the event. Instead, the embodiments collect verifiable results of a data acquisition consisting of events from a specific period of time and calculate a local integrity check for that period of time based on the previously generated checks, for example, in a chain-based approach. As a result, embodiments of the present invention allow an auditor/consultant to pick a specific arbitrary time and calculate a global integrity check for that time. Therefore, the evidence becomes repeatable and reproducible.

Where the prior art system shown inFIG.1performs integrity calculations for each event without a time reference, under the present embodiments the integrity of the sources is calculated with respect to a time frame. A global integrity may be calculated by chaining the integrity values of different time frames, using a different mechanism, described further below.

For the system ofFIG.1, each time a new event occurs, the integrity check may be calculated. In the embodiments described herein, all the events occurring within a time frame may be collected, and an integrity check may be calculated for all the events occurring during that time frame at the end of the time frame.

FIG.2is a schematic diagram of an exemplary first embodiment of a system for extracting evidence from an RTA210A,210B,210C. Each RTA210A,210B,210C includes a memory220A,220B,220C and an agent230A,230B,230C. One or more of the agents230A,230B,230C may be implemented as a process running within the RTA210A,210B,210C, and/or may be implemented as a process running on a processor (not shown) in a processing device separate from the RTA210A,210B,210C and in communication with the RTA210A,210B,210C.

The agent230A,230B,230C is in communication with a collector250, for example, via a data network such as a wired or wireless local area network (LAN) or a wide area network (WAN). The agents230A,230B,230C may all be within the same LAN, or may be distributed across two or more data networks. The agents230A,230B,230C may be configured to convey information240A,240B,240C via the network to the collector250periodically or non-periodically.

FIG.3is a block diagram of an exemplary first embodiment of an agent230, for example, an agent230A,230B,230C shown inFIG.2. Broadly, the agent230includes processing modules and data, where the data may be further categorized as initial data380and data associated with a time frame390. Under the first embodiment the agent230includes an initialization module310that may define an initialization key382, and a set of source definitions384that define the data for sources to be monitored/collected for the RTA210A,210B,210C (FIG.2). Over time, new sources may be added to the source definitions384or removed from the source definitions384, as an integrity check module320is adapted to calculate a local integrity check392and the source definitions384are adapted to sources that are added to or removed from the RTA210A,210B,210C (FIG.2). The collector250(FIG.2) may be informed contemporaneously as the sources definitions384are changed.

A time frame module330defines the duration(s) of time frames during which information is collected from the RTA210A,210B,210C (FIG.2). A collection processing module340manages changes of information in the RTA210A,210B,210C (FIG.2) during the present time frame, for example, data that was added, removed, and/or changed during the present time frame. A record of the changes is stored as collection data394. During the time frame, for example, at the end of each time frame, the integrity check module320calculates the local integrity check392for the presently ending time frame based on the changed information identified by the collection processing module340.

FIG.4is a flow diagram of the actions performed by the agent230over the span of three time frames t0, t1, and t2. The agent230collects a first set of collection data394(FIG.3) collected, for example, by the collection processing module340, during the first time frame t0, as shown by block410. The integrity check module320(FIG.3) uses the first set of collection data394(FIG.3) and the initialization key382to calculate (block420) the local integrity check392for the first time frame t0. The set of collection data394(FIG.3) may be, for example, a list of all the events from all the configured sources belonging to the same time frame. The initialization key382(FIG.3) may be implemented like a master password or a secure passphrase that is used to initialize the system for both the agent230and the collector250, and then may be discarded after its initial use.

The agent230forwards the local integrity check392for the first time frame t0to the collector250(FIG.2). The communication channel preferably enforces the integrity of the information sent between the agent230and the collector250(FIG.2), for example, using some known secure protocol, such as transport layer security (TLS) or internet protocol security (IPSEC). As shown by block411, for the second time frame t1the integrity check module320(FIG.3) uses a second set of collection data394(FIG.3) and the local integrity check392of the previous time frame, t0in this case, to calculate (block421) the local integrity check392for the second-time frame t1.

It should be noted that the local integrity check392for the previous time frame may be used to calculate the local integrity check392for the current time frame, except for the first time frame t0, where the initialization key382is used to calculate the local integrity check392for the first time frame t0in lieu of a previous integrity check392. So, as shown by block412, for the third-time frame t2, a third set of collection data394(FIG.3) and the local integrity check392of the previous time frame, t1in this case, are used to calculate (block422) the local integrity check392for the third-time frame t2. This continues for a fourth-time frame (not shown), and all subsequent time frames (not shown).

Returning toFIG.2, the collector250may be configured to be a secure protector of received information stored therein, for example, within an internal memory260. Information240A,240B,240C may be transmitted from the agent230to the collector250via secure means, for example, using encrypted data, and/or transmitted via a secure channel, for example, a virtual private network (VPN), or by other secure means. The collector250may be a logical entity that may be hosted on a single physical entity, or may be distributed across two or more physical entities in communication with one another. WhileFIG.2shows three RTAs210A,210B, and210C for purposes of clarity, alternative embodiments may have one, two, four, or more RTAs in communication with the collector250.

FIG.6is a flowchart of an exemplary method600for acquiring evidence from a business-critical application. It should be noted that any process descriptions or blocks in flowcharts should be understood as representing modules, segments, portions of code, or steps that include one or more instructions for implementing specific logical functions in the process, and alternative implementations are included within the scope of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present invention. The method600is described in reference toFIG.2.

Sources of extractable events are defined, as shown by block610. For example, sources may include security audit logs, requests logs, change logs, access logs, and system events, among others. A secret initialization key or keys382(FIG.2) may be provided to act as a dummy initial integrity set in lieu of a previous time frame, and demark a first time frame, as shown by block620. The secret initialization key or keys382(FIG.2), may be, for example, a character string, such as a combination of letters, numerals, and symbols used in a strong text password. The agent230A,230B,230C collects events of the RTA210A,210B,210C occurring during the time frame in a collection394(FIG.3), as shown by block630. The collection394(FIG.3) may include an ordered list of entries containing, for example, a source identifier, the even data, a time stamp, arranged in order by time stamp indicating the time of occurrence of the event.

The agent230A,230B,230C calculates one or more local integrity checks392(FIG.2) based on the collection394(FIG.3) and the local integrity check392(FIG.2) of previous time frames, as shown by block640. The local integrity check392(FIG.2) may be, for example, a hash or sumcheck calculated by using an algorithm capable of chaining the different events of the collection394(FIG.3) into one single hash in order to avoid data corruption within the collection394(FIG.3), for instance, the algorithm may be based on, for example, but not limited to PEO or VCR, as these algorithms ensure consecutive events in the collection will be identified by a unique integrity check.

The agent230A,230B,230C calculates a global integrity check992(FIG.9) based on the local integrity checks392(FIG.2) of previous time frames, as shown by block645. The global integrity check992(FIG.9) (and optionally, the entire collection) is sent by the agent to the collector250, as shown by block650. The collector250receives and stores the global integrity check992(FIG.9) (and optionally, the collection394(FIG.3)), as shown by block660. The next time frame is defined and begun, as shown by block670, and the process loops back to block630to process the newly defined time frame.

As described further below, all the extracted events from all the different sources at a specific time have a unique global integrity check992(FIG.9) associated. At any other time or place, the same events from the same sources (regardless if the RTA modified the sources after the time frame) may be obtained again and a new global integrity check992(FIG.9) may be obtained using the secret initialization key. Following the same technique and procedure, both the initially calculated global integrity check R and the validating global integrity check R′ are equal (seeFIG.10). The global integrity check992(FIG.9) may be compromised or leaked and the integrity system is not affected as the global integrity check sent to the collector250is not the one used to perform the calculations, only the local integrity checks392are used for further calculations.

During each time frame, the agent230accumulates all events from a defined set of sources defined in the source definitions384into a collection394. The collection394is then unified into a unique local integrity check392(hash value) using a specific initialization key IV382. Collections394may be taken in pairs, meaning two consecutive hashes may have the same initialization key IV382. The following steps describe this process.

For the first two collections of events, the agent230accumulates all the events from all sources within the last existing time frame (i−1) and generates a corresponding hash (local integrity check392) using the first initialization key IV382. The same process is performed for the initial time frame (i). Both hashes are unified, for example, using an exclusive or (XOR) operation, into one hash (H0,1). For the second two collections of events, the agent230accumulates all the events from all sources within the following time frame (i+1) and generates the corresponding hash or local integrity check (using the second initialization key IV382). The same process is performed for the next time frame (i+2). Both hashes are unified (for example, using an XOR operation) into one hash (H2,3).

For all succeeding pairs, signified as the Nth two collections, the agent230accumulates all the events from all sources within the Nth time frame and generates the corresponding local integrity check using the initialization key IV382as the last generated hash (Hn−1,n−2). The same process may be performed for the next time frame. The last two hashes are unified (for example, XOR operation) into one hash (Hn,n+1).

The collector250receives data regarding all the events within each time frame from the agents230. Each agent230collects all the logs within each time frame, where each agent230unifies all the generated local integrity checks (XOR operation), for example, using a binary-tree, into a unique resulting global integrity check992(R) and sends it to the collector250. The collector250performs the same calculations and operations on all the received events and generates a new resulting global integrity check1092(R′). If R992and R′1092are equal, then all the events within that specific period of time are determined to be integral (not corrupted) and can be trusted.

As shown inFIG.7, an agent230collects logs for events410corresponding to the last existing time frame from all the sources defined in the source definitions384. The set of all the logs is the Collection CT0, which then is unified into a unique local integrity check HT0(392) using the first initialization key392IV0. As shown inFIG.8, the agent230collects the logs corresponding to the first time frame411from all the sources. The set of all the logs is the Collection CT1, which then is unified into a unique local integrity check HT1(392) using the first initialization key392IV0.

As shown byFIG.9, all local integrity checks392from all events belonging to a time frame are unified into a unique global integrity check992in a binary-tree way which is sent from the agent230to the collector250. For example, this global integrity check992may be generated using a Merkle tree, although a person having ordinary skill in the art will recognize that the global hash may be generated with a different algorithm. As shown inFIG.10, U is an untrusted node/server, for example, a RTA, where the logs reside. U has an agent230which actually implements the first side of the integrity check system (seeFIGS.7,8). T is the trusted server (the collector250) which receives all the log events and the global integrity check R (992) from the agent230. T implements a second side of the integrity check system, re-calculating the integrity check R′ (1092) and verifying the integrity of the events in a given period of time by confirming that the recalculated integrity check R′ (1092) check matches the received global integrity check R (992), thereby providing evidence of chain of custody.

As previously mentioned, the present system for executing the functionality described in detail above may be a computer, an example of which is shown in the schematic diagram ofFIG.5. The system500contains a processor502, a storage device504, a memory506having software508stored therein that defines the abovementioned functionality, input and output (I/O) devices510(or peripherals), and a local bus, or local interface512allowing for communication within the system500. The local interface512can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface512may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface512may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor502is a hardware device for executing software, particularly that stored in the memory506. The processor502can be any custom made or commercially available single core or multi-core processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the present system500, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing software instructions.

The memory506can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory506may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory506can have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processor502.

The software508defines functionality performed by the system500, in accordance with the present invention. The software508in the memory506may include one or more separate programs, each of which contains an ordered listing of executable instructions for implementing logical functions of the system500, as described below. The memory506may contain an operating system (O/S)520. The operating system essentially controls the execution of programs within the system500and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

The I/O devices510may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, etc. Furthermore, the I/O devices510may also include output devices, for example but not limited to, a printer, display, etc. Finally, the I/O devices510may further include devices that communicate via both inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, or other device.

When the system500is in operation, the processor502is configured to execute the software508stored within the memory506, to communicate data to and from the memory506, and to generally control operations of the system500pursuant to the software508, as explained above.

When the functionality of the system500is in operation, the processor502is configured to execute the software508stored within the memory506, to communicate data to and from the memory506, and to generally control operations of the system500pursuant to the software508. The operating system520is read by the processor502, perhaps buffered within the processor502, and then executed.

When the system500is implemented in software508, it should be noted that instructions for implementing the system500can be stored on any computer-readable medium for use by or in connection with any computer-related device, system, or method. Such a computer-readable medium may, in some embodiments, correspond to either or both the memory506or the storage device504. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer-related device, system, or method. Instructions for implementing the system can be embodied in any computer-readable medium for use by or in connection with the processor or other such instruction execution system, apparatus, or device. Although the processor502has been mentioned by way of example, such instruction execution system, apparatus, or device may, in some embodiments, be any computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the processor or other such instruction execution system, apparatus, or device.

In an alternative embodiment, where the system500is implemented in hardware, the system500can be implemented with any or a combination of the following technologies, which are each well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

The above described embodiments provide for real-time extraction of data from RTAs so that the data acquisition accuracy may be verified, for example, so as to be admissible as electronic evidence Systems employing RTAs typically have 24×7×365 availability requirements and their sources of information need to be extracted in a way that ensures the feasibility of a proper Chain of Custody. The embodiments work with those systems, and an agent may be deployed in every single system, sending the events to the collector. In particular, the embodiments provide for extraction of evidence that is repeatable and reproducible. The above described embodiments provide for recovery of valid evidence in near real time due to the proactive approach. The embodiments allow access to the information previously available before an incident occurs, which may significantly assist first responders.

In many applications, the ability to produce verifiable data is essential to the functionality of an RTA. Therefore, the claims represent an improvement in the functionality of the systems and devices executing the RTAs themselves by providing data verification over multiple time periods, and also represent an improvement to fields such as, but not limited to system forensics analysis.