GB2478554A

GB2478554A - A digital forensic evidence data capture tool for a cloud computing system

Info

Publication number: GB2478554A
Application number: GB1003888A
Authority: GB
Inventors: Mark Alan West; Eleanor Hepworth
Original assignee: Roke Manor Research Ltd
Current assignee: Roke Manor Research Ltd
Priority date: 2010-03-09
Filing date: 2010-03-09
Publication date: 2011-09-14
Also published as: EP2545488A1; WO2011110847A1; GB201003888D0

Abstract

An evidence data capture tool comprises a record device (1), which comprises a control processor (2), a transaction data store (10), a target data store (9), and an output (7). In use, the control processor (1) communicates with a target device via a network (11). The target device may comprise one or more elements of a distributed system (e.g. cloud computing system). Target data is downloaded from the target device to the record device (1). Associated transaction data is stored in the transaction data store (10) of the record device (1). A security marker such as a hash is applied to the target data and its associated transaction data. The record device (1) outputs a copy of the marked target and transaction data. The transaction data may comprise audio, video, or still image recordings of user activity on the record device during target data downloading.

Description

DATA CAPTURE TOOL AND METHOD

This invention relates to an evidence data capture tool and a method of capturing evidence in digital form, for example, for evidence gathering, or for the purpose of applying scientific techniques to the investigation or detection of crime.

As the usage of digital forms of evidence in trials has increased, the process of capturing data from seized computer equipment has become common and has adopted a standardised approach. When a physical computer data storage device is seized with potential use as evidence, a bit-by-bit copy is created, without booting from the device or connecting it to a running computer system. The copy is frequently hashed. This must be done in accordance with processes regarded as acceptable to prove that the original contents have not been modified by human or computer-generated activity.

When files are held on a remote server, such as in a cloud or on a web server, seizing media is typically not possible. In most cases access to the servers, which make up the remote server platform, would not be possible even if their location were known.

Prior art systems for collection of computer forensic evidence include US2009/150998, which is concerned with allowing a user to remotely interrogate a target computing device to collect and analyse computer evidence stored there, such as log files, account information and network information; and WO/0207 1192 in which a computer in a company network which has been hacked into, which is not on the same site as the party collecting the evidence, can be remotely accessed to save time, rather than the third party evidence collecting company having to actually visit the site, making monitoring and dealing with such intrusions more efficient. Neither of these considers the issues specific to remote servers e.g. cloud computing. In the paper by S. D. Wolthusen (IMF 2009), "Overcast: Forensic Discovery in Cloud Environments", Fifth International Conference on IT Security Incident Management and IT forensics, Stuttgart, Germany 15-17 September 2009. IEEE Computer Society, there is a description of problems arising from cloud computing in the field of forensics, but no solutions are proposed.

In accordance with a first aspect of the present invention an evidence data capture tool comprises a record device; wherein the record device comprises a control processor, a transaction data store, a target data store, and an output; wherein, in use, the control processor communicates with a target device via a network; wherein target data is downloaded from the target device to the record device; wherein associated transaction data is stored in the transaction data store of the record device; wherein a security marker is applied to the target data and its associated transaction data; and wherein the record device outputs a copy of the marked target and transaction data.

The present invention addresses the need to obtain digital evidence from a remote server in such a way that it provides an evidential trail by collecting target data downloaded from the remote server, whilst also capturing transaction data associated with the download to verify the download by. It is particularly applicable to distributed systems, particularly systems such as those in use for public, community or private cloud computing implementations, as well as data accessed over the internet.

Preferably, the target device comprises one or more elements of a distributed system, Preferably, at least one of the elements includes a file store, the target data being stored in the file store.

Preferably, the distributed system comprises one of a public network, a community network; or a private network.

Preferably, the distributed system comprises a cloud computing system.

Preferably, each element of the distributed system comprises shared computing resources.

Although the main application is in distributed systems such as cloud computing, the tool is also useful for downloading from a single file store over the internet.

Preferably, the security marker comprises a hash.

Preferably, the output comprises one or both of a display and removable media.

Preferably, the transaction data store receives transaction data from the control processor, or from an external source.

In one embodiment, the transaction data comprises protocol interactions on the network, associated with downloading of the target data.

Alternatively, or in addition, the transaction data comprises record device operating information.

Preferably, the record device operating information includes at least one of a local file access log and a device state.

Preferably, the transaction data comprises audio, video, or still image recordings of user activity on the record device during target data downloading.

Preferably, the transaction data further comprises data received from a notary device.

Preferably, the notary device is connected to the record device via an alternative network.

The notary device may be connected via the same network as the target device, or else it can be connected via a separate network, such as one which is not accessible to the public.

Target data comprises any data in digital form available for downloading from the target device, but preferably the target data comprises at least one of a web page; or remotely authored document, program or data comprising image, text, video, audio or other digital content.

In accordance with a second aspect of the present invention, a method of evidence data capture comprises the steps of: (a) issuing a request from a record device to a target device via a network; (b) downloading target data from the target device to the record device; (c) recording transaction data associated with step (b); (d) storing the associated transaction data in the record device; and (e) applying a security marker to the downloaded target data and its associated transaction data.

Preferably, step (c) further comprises generating a video or audio recording of steps (a) and (b); converting the recording to digital data and inputting the digital recording to the transaction data store of the record device.

Preferably, step (c) further comprises recording protocol exchanges with the network during step (b).

Preferably, step (e) comprises applying a hash function.

Preferably, the target device comprises one or more elements of a distributed system.

Preferably, the method further comprises authenticating the security marked, downloaded data and storing a copy in the record device.

Preferably, the method further comprises outputting a copy of the data, after step (e).

Preferably, the data is output to a removable storage medium.

Preferably, the method further comprises reviewing and validating the target data.

This step may be carried out before outputting to the removable storage medium, to ensure that there has not been any corruption of the data in the process, or to check that the desired data has been recorded.

Preferably, the validation further comprises acquiring data from an ISP or CSP and comparing recorded information exchanges with ISP or CSP records.

Preferably, the method further comprises downloading record logs from the target device.

Preferably, the method further comprises time-stamping the target and transaction data during downloading and recording.

An improvement to the time-stamping is to synchronise the record device with a network time protocol server.

An example of an evidence data capture tool and a method of evidence data capture according to the present invention will now be described with reference to the accompanying drawings in which: Figure 1 illustrates a first example of a record device according to the present invention; Figure 2 illustrates example implementations in which the device of Fig. 1 may be used; Figure 3 is a block diagram showing in more detail the transaction data store of the device of Fig.1; Figure 4 illustrates an alternative implementation in which the record device of Fig. 1 may be used; Figure 5 is a flow diagram of one method of using the record device of the present invention in any of the implementations; Figure 6 illustrates an example of a general case of browser/server encryption; Figure 7 illustrates one option for decrypting the packet log in the example of Fig.6; and, Figure 8 illustrates an alternative method of decrypting the packet log in the

example of Fig.6.

In the field of digital forensics, it has been recognised that the Courts require a similar standard of evidence for data collected from cloud environments, where the storage device is not within the custody of the authorities, as to that which is collected from stand alone devices, which have been seized. However, beyond recognising that this objective needs to be met, there has been little discussion of how to achieve the evidential chain. Although, US2009/0 150998 describes downloading data which provides evidence, such as the log files, with or without applying a hash to the downloaded data before storing it, this document does not make any suggestion of the feature of the present invention which makes it possible to prove that the evidence downloaded has neither been interfered with in any way, nor falsely generated. By associating the downloaded data with transaction data related to the act of downloading, or the act involved in causing the download to take place, concerns relating to fraudulent generation of data and attribution are addressed.

Outside the legal field, there may be occasions when a user wishes to be able to prove the existence of certain data at a certain time and that they accessed that data at the appropriate time, for example the terms and conditions for an offer on a website, which is time limited. In this case, the data may be accessed directly, on the basis that it is publicly available, whereas for forensic data, this is less often data which has been made public, although it may be possible to access the data using a user's login credentials. However, in order to be useful, whether to a consumer for storing website information they may want to use as proof later, or in legal proceedings, the data that has been accessed and the protocol interactions used to access it need to be captured in such a way as to meet appropriate standards of proof in each case.

The present invention provides a record device and a method of using this. An example of a record device according to the invention is illustrated in Fig. 1, although other implementations are equally possible. The record device 1 of this example comprises a control processor 2, a display 3, a user input 4, one or more data inputs, or Input/Output ports 5, 6 and an output 7. Optionally, the data input 6 may receive data from external sources 34 and the output 7 may be connected to a store 35, typically a removable recording Write Once Read Many (WORM) medium, such as a DVD, CD or Blu-ray. Alternatively the store may be a hard-drive or other mass storage device, in which case standard evidential practises such as hashing may be used to maintain integrity. In addition, the record device is provided with a security unit 8, which is typically integrated into the control processor functionality, but may also be implemented as a separate device and one or more stores 9, 10 for storing received data.

As further illustrated in Figs. 2a and 2b, the record device 1 is connected via a network 11 to a distributed system 12. The distributed system 12 is made up of a plurality of elements, typically servers 14a. .. 14n, within which are respective file stores 13a. .. 13n. For the examples described above, the elements of the distributed system may amount to a specific server on the internet, operated by or on behalf of the company, or servers associated with a cloud computing system, which store data from many sources and allow companies, or individuals to adapt their usage of storage and according to changes in their requirements, without the fixed costs of investing in personal IT systems. Tn this latter case, the company or individual does not have control of the server on which their data is stored and the operator of the cloud computing system frequently stores data belonging to one company or individual on many different servers, according to when the user extended their requirement for storage space. Thus, even if a distributed system was physically accessible, in the sense of being in the same country as the user, or within the jurisdiction of the Courts, it is not practical to isolate a particular server and seize it to extract data required for a specific investigation from the file store because the distributed systems are designed to be used by hundreds or thousands of users and may contain data belonging to a great many other users.

The example shown in Fig.2a is for a user wishing to cany out evidence data capture from one of the elements 14b in a server within the distributed system 12. The system is accessed from the record device 1 via the network 11 and a download made of target data 16 from the associated file store 13b. Tn conjunction with this download, a separate record is made of transaction data. The transaction data 17 may be protocol information to and/ or from the network which is associated with the act of downloading the target data, or alternatively the transaction data may be a record of certain steps or actions taken at the record device 1 by the party doing the downloading, such record being internal 21, 22, 23, 24, 25, 26 or external 34. In some circumstances, where the transaction data is all packets exchanged between the record device 1 and the server 14, then the transaction data may include the target data as a subset, as well as the target data being recorded separately. Examples of these steps or actions are given in more detail below. More rarely, the transaction data, 17, is a record of actions taken by a third party, such as an internet service provider (TSP), or communication service provider (CSP), in addition to the transaction data recorded and then stored within the record device 1.

For the example in which the transaction data is protocol information, the present invention uses the record device 1 to download target data 16 from a file store 13b on a remote server platform 14b, e.g. a cloud server, whilst also capturing the protocol interactions 17 made and received by the device 1. These protocol interactions encompass all of the packets sent and received from the record device during evidence collection. The transaction data may include corroborating information such as all protocol interactions supporting the download and any other steps taken to identify the environment, such as the results of traceroute, ping, reverse DNS lookups, or WHOTS database queries The transaction data, 17, may also include corroborating meta-data for the information which has been downloaded, such as time of access to files; file ownership; access control lists and privileges associated with the file; the location of the file; file version information and other such information. The downloaded target data 16 is stored along with the packet capture transaction data 17 in respective target data store 9 and transaction data store 10. A means of cross checking the downloaded data to the transaction data may be provided, for example the downloaded data may be reconstructed from a packet trace and compared.

Fig.2b illustrates how there may be multiple data flows of encrypted data 1 6b, 1 7b and unencrypted data 1 6a, 1 7a, which by means of a proxy 20, can be downloaded and stored both in encrypted form 9b, lOb and in unencrypted form 9a, lOa. A key requirement for the downloaded data is that decrypted packet data must be available in order to allow the packet transaction data to be cross-checked with the downloaded target data. If no encryption is used then there is no issue. If encryption is used, then some means must be provided to gain access to the decrypted packets. In the examples described below, one option is to instrument the browser' -i.e. get the browser to log the session keys used so that the recorded packets can be subsequently decrypted; and the other is to introduce a man-in-the-middle' proxy to split the connection and get both encrypted and decrypted contents.

Fig.6 shows a general case of proxy/browser encryption. A file 54 is delivered from a server 14 to a browser 50 via an encrypted session. There is a flow endpoint' 51 in the server and a flow endpoint' 52 within the browser: between these two points the data is encrypted; the endpoints agree and use a session key' (K = 123 in this example) to encrypt and decrypt the data. When monitoring the packets going to the browser, it is only possible to see the encrypted packets 53. The encrypted packets from the server 14 to the browser 50 pass through network interface and packet capture 57, from which an encrypted packet log 56 is obtained. The browser can decrypt the data 54 and save the file 55, but this cannot be compared to the packet log 56.

It is necessary to access the content of the encrypted flow, to do a comparison of what is in the packets with the downloaded (target) data. In Fig. 6, the decrypted packet data is available in exactly two places, which are the flow endpoints 51, 52 at the point of encryption, or decryption.

Fig.7 shows one possible solution which is that by modifying the browser 14, the browser can then write the session keys to a separate file 58. The initial steps are as described above for Fig.6, with encrypted packets 53 received at the flow endpoint 52.

The session keys are then used in additional steps of taking the encrypted packet data 56, applying, in a decryption stage 59, the session key from the log-file 58 and producing a decrypted packet log 60. The advantage of this is that the packet capture process is still completely separate from the browser 50 and the original' encrypted packets 53 as exchanged between the server and browser are obtained. The disadvantage is the need to modify the browser to make the flow endpoint' 52 log this data. That resfricts the browser 50 that can be used and means that if there is a change (or update) of the browser, the modification may need to be repeated.

Therefore, an alternative is illustrated in Fig.8, in which a proxy 20 (which typically runs on the same machine as the browser 50), is used. The proxy looks to the server 14 as if it is the browser 50; and the proxy looks to the browser as if it is the server. Encrypted packets 53 flow between the server and proxy (using key 123), the proxy 20 decrypts the data and can, at that point, log 60 the decrypted version of the packet data. The proxy 20 then encrypts the data again, because the browser 50 is expecting encrypted data, but this time using key 456 because the keys are negotiated separately for each leg. The re-encrypted data 53a is then sent to the browser 50. The proxy approach has the disadvantage that it leaves open the possibility of performing arbitrary modifications to the data coming from the server, so to address this, the proxy code can be included in the evidential data, so that the behaviour of the proxy can be verified. However, this method has the advantage that it requires no modification to the browser.

An alternative source of data providing corroborating evidence is from information capture, internal to, or external to, the record device 1 during the target data download. This captured information is then stored in the transaction data store 10 as illustrated in Fig.3. In some cases, it may be desirable to use this type of transaction data in addition to that which can be collected from the network. For example, a web camera 21 connected to the apparatus may record video images, or periodic still images whilst the evidence is being gathered; a keyboard logger 25 may record any keys on the keyboard being used during the evidence gathering period; a log 23 of (local) disk! file accesses made during evidence may be gathered; a record 22 of device state (hardware components, MAC addresses, CPU serial numbers, etc) for the evidence gathering device may be made; screen shots 24 may be taken during the evidence gathering stage, either as individual screen shots, or sufficiently rapid series of screen shots to act as a screen recorder; and an audio recorder 25 may be provided to record audio signals generated by the record device. Externally 34, audio recordings 28 of audio outputs from the record device and from the surroundings during evidence data capture may be made, or a video recording 29 of the on screen view, or surroundings may be produced, whilst the evidence is being gathered. These can then be digitised and input 6 to the transaction data store 10.

In another embodiment of the invention, as shown in Fig.4, a notary or registry server 31, connected to the record device 1, via an internet 11 or intranet 30 provides further traceability of the session. There are a number of possible applications for the notary server. The notary server may provide authorisation' of access for the evidence gathering session whereby keys / passwords are exchanged in a secure way with the record device 1 over the internet 11 or intranet 30 to allow the user to access the evidence (user passwords), or evidence gathering program (passwords for the evidence collection tool) which will be used in downloading the target data. The notary server may also provide keying material to the record device to make every download session uniquely identified and logged in the notary server 31.

Another possible option, not shown, is that information relating to the download such as the start of the download and the size of the download could be passed to this notary server. This provides a time stamp for the downloads relating to this evidence gathering period and a second piece of information to check against the hashed data.

Another possible option, not shown, is that the notary server may provide an evidence pack identifier and at the end of the evidence gathering session, having downloaded and stored target data in the target data store 9 and transaction data in the transaction data store 10, then some metadata (for example, the amount of data sent and/or received) may be transmitted to the notary server 31, as a further cross-checking mechanism. The computer evidence collected can be output to the store 35, for example, a Write Once Read Many storage device, such as a DVD with a cryptographic hash to detect any errors, or deliberate tampering. In this storage medium 35 the appropriate parts of the transaction data and target data may be stored as separate encrypted 32 and unencrypted 33 files, so that both the data as it was received, as well as the data in a directly viewable form is kept in the store 35.

The record device may synchronise with a network time protocol (NTP) server 36 connected to the network 11, such as the internet, in order to ensure timestamps are accurately recorded throughout the evidence gathering period. In some cases, a service provider 37, e.g. ISP or CSP, may acquire data on the service provider's networks and this can then be used to corroborate the data exchanged between the record device and the cloud platform 14.

An example of a method of using the record device 1 of the present invention is given in Fig.5. A user initiates 40 a data capture routine and labels the session. The labelling may be done directly, or via the notary server 31, as described above.

Optional steps are then applied according to the specific requirements of that session, of activation 41 of a proxy 20 in the network or the recording device, or activation 42 of the notary server. The notary server communicates with the record device 1 via the network 11, or via an intranet 30. If neither step is required, or after these optional steps are taken, the authentication information, or user credentials are sent 43 to the target device 14.

As mentioned, along with the transaction data, record logs pertaining to the data transferred over the internet may be captured to strengthen the evidence. These record logs may be one or more of various types, including: URLs used, IP addresses, results of traceroute, fingerprint of the host/server; round trip times, such as from ping. In addition, any files created by the browser during the download session, such as cookies, or temporary files, may be identified and preserved as part of the evidence suite. Other information which can be used as transaction data is GPS information, digitally collected at the time of evidence capture and stored, or information exchanges between the record device 1 and the cloud platform 14 or the notary server 31, which may then be compared with any available CSP records, depending upon jurisdiction and local legislation.

The target data 16 is downloaded 44 from the target device 14, with metadata if required and transaction data is collected. Further optional steps are to check for availability of ISP or CSP log files and to check 45 whether any of the data 16, 17 being downloaded is encrypted and, if it is, to separate that out. If necessary, the notary server 31 is activated 46 at this stage before applying 47 a security marker to the downloaded data. This may be a hash, or digital signature, applied under control of the processor 2, or if provided from an optional, separate security unit 8, within the record device. Alternatively, the notary server 31 notarises the collected data, so that once the data has been collected, the notary is sent a hash of the data, which it then timestamps, signs, logs and sends back to be stored with the evidence bundle. It is desirable that wherever the notary provides any method for authenticating data, suitable audit logs are available, with an option to view and authenticate these logs from an evidence review platform e.g. via the display 3. Having applied the security marker, the marked, stored data is output 48 to the removable storage medium 35 and the session is ended 49.

Arranging for the captured target and transaction data to be digitally signed before being stored on a Write Once Read Many storage device is another means to prove, to a level suitable for use as evidence, that the data is an unmodified version of what was collected from the cloud platform.

Clearly, the method described above is one example, which can be modified, by the omission or addition of various steps according to the specific circumstances of the data collection being undertaken and the degree of proof required.

Having downloaded target data and obtained corroborating transaction data, the user may review and/or validate the downloaded data and may also playback and review any of the corroborating data stored with the evidence before outputting the stored data to the storage medium 35. The reviewing may be done using session reconstruction tools and a web-page viewer, or a tool such as Wireshark for packet data and any suitable viewer for other non-packet data.

The invention may be implemented as an open source virtual machine, providing an effective, yet low cost, solution to the problems faced with internet based, or cloud computing related evidence data capture. Data downloads may be carried out in both fixed and mobile networks. The invention provides greater assurance that the downloaded data has actually come from the distributed system, rather than being generated elsewhere, simply for the download. Capturing transaction data along with the packet capture data allow traceability of the evidence gathering. This information is harder to fake during the evidence collecting period and the details in the information can all be checked to ensure that the reviewer is happy that these files have been collected from the cloud server and not modified subsequently. Whether the transaction data amounts to protocol interactions from the network due to the communications between the record device and the target device, or external or record device generated corroborating evidence taken during the data capture, the invention provides a mechanism of proving the data capture has not been modified by the downloading user and that the data capture is an accurate capture from the remote server files in question.

Although the examples have been described with respect to downloading data files from a file store in one of a plurality of elements of a distributed system, the method may equally be applied to downloading data which is shared across several elements, possibly in different locations and under different service providers.

Claims

CLAIMS1. An evidence data capture tool comprising a record device; wherein the record device comprises a control processor, a transaction data store, a target data store, and an output; wherein, in use, the control processor communicates with a target device via a network; wherein target data is downloaded from the target device to the record device; wherein associated transaction data is stored in the transaction data store of the record device; wherein a security marker is applied to the target data and its associated transaction data; and wherein the record device outputs a copy of the marked target and transaction data.
2. A tool according to claim 1, wherein the target device comprises one or more elements of a distributed system,
3. A tool according to claim 2, wherein at least one of the elements includes a file store, the target data being stored in the file store.
4. A tool according to claim 2 or claim 3, wherein the distributed system comprises one of a public network, a community network; or a private network.
5. A tool according to any of claims 2 to 4, wherein the distributed system comprises a cloud computing system.
6. A tool according to any of claims 2 to 5, wherein each element of the distributed system comprises shared computing resources.
7. A tool according to any preceding claim, wherein the security marker comprises a hash.
8. A tool according to any preceding claim, wherein the output comprises a display.
9. A tool according to any preceding claim, wherein the output comprises removable media.
10. A tool according to any preceding claim, wherein the transaction data store receives transaction data from the control processor or from an external source.
11. A tool according to any preceding claim, wherein the transaction data comprises protocol interactions on the network, associated with downloading of the target data.
12. A tool according to any preceding claim, wherein the transaction data comprises record device operating information.
13. A tool according to claim 12, wherein the record device operating information includes at least one of a local file access log and a device state.
14. A tool according to any preceding claim, wherein the transaction data comprises audio, video, or still image recordings of user activity on the record device during target data downloading.
15. A tool according to any preceding claim, wherein the transaction data further comprises data received from a notary device.
16. A tool according to claim 15, wherein the notary device is connected to the record device via an alternative network.
17. A tool according to any preceding claim, wherein the target data comprises at least one of a web page; or remotely authored document, program or data comprising image, text, video, audio or other digital content.
18. A method of evidence data capture, the method comprising the steps of: (a) issuing a request from a record device to a target device via a network; (b) downloading target data from the target device to the record device; (c) recording transaction data associated with step (b); (d) storing the associated transaction data in the record device; and (e) applying a security marker to the downloaded target data and its associated transaction data.
19. A method according to claim 18, wherein step (c) further comprises generating a video or audio recording of steps (a) and (b); converting the recording to digital data and inputting the digital recording to the transaction data store of the record device.
20. A method according to claim 18, wherein step (c) further comprises recording protocol exchanges with the network during step (b).
21. A method according to any of claims 18 to 20, wherein step (e) comprises applying a hash function.
22. A method according to any of claims 18 to 21, wherein the target device comprises one or more elements of a distributed system.
23. A method according to any of claims 18 to 22, further comprising authenticating the security marked, downloaded data and storing a copy in the record device.
24. A method according to any of claims 18 to 23, further comprising outputting a copy of the data, after step (e).
25. A method according to claim 24, wherein the data is output to a removable storage medium.
26. A method according to any of claims 18 to 25, wherein the method further comprises reviewing and validating the target data.
27. A method according to claim 26, wherein the validation further comprises acquiring data from an ISP or CSP and comparing recorded information exchanges with ISP or CSP records.
28. A method according to any of claims 18 to 27, wherein the method further comprises downloading record logs from the target device.
29. A method according to any of claims 18 to 28, wherein the method further comprises time-stamping the target and transaction data during downloading and recording.