1. Digital Forensics Dr. Bhavani Thuraisingham The University of Texas at Dallas Lecture #21 Detection and Analysis of Database Tampering October 15 and 17, 2007

2. Papers to discuss l Auditing and Forensic Analysis l Richard T. Snodgrass, Stanley Yao and Christian Collberg, "Tamper Detection in Audit Logs," In Proceedings of the International Conference on Very Large Databases, Toronto, Canada, August–September 2004, pp. 504–515. l Kyri Pavlou and Richard T. Snodgrass, "Forensic Analysis of Database Tampering," in Proceedings of the ACM SIGMOD International Conference on Management of Data (SIGMOD), pages 109-120, Chicago, June, 2006. l Additional paper for reading: Kyri Pavlou and Richard. T. Snodgrass, "The Pre-images of Bitwise AND Functions in Forensic Analysis,'' TimeCenter TR 87, October, 2006. l http://www.cs.arizona.edu/~rts/publications.html http://www.cs.arizona.edu/~rts/publications.html l Main focus will be on the first two papers

3. Outline l Review of Part 1 of Course CS 4398 l Discuss the papers - Tamper Detection in Audit Logs l Did the problem occur? (e.g. similar to intrusion detection) - Forensic Analysis of Database Tampering l Who caused the problem (e.g., similar to digital forensics analysis)

4. Part I of Course l Parts I, II and III of the book l Additional papers: URLs given in the lectures l Focus mainly on - What is digital forensics - What are the services - What id digital evidence and how it is analyzed? - What is network forensics? - Stegangography, Intrusion detection, Honeypots l Part II of the course will focus on research papers and certain chapters of the book

5. Abstract of Paper 1 l Richard T. Snodgrass, Stanley Yao and Christian Collberg, "Tamper Detection in Audit Logs," In Proceedings of the International Conference on Very Large Databases, Toronto, Canada, August– September 2004, pp. 504–515. l Audit logs are considered good practice for business systems, and are required by federal regulations for secure systems, drug approval data, medical information disclosure, financial records, and electronic voting. Given the central role of audit logs, it is critical that they are correct and inalterable. It is not sufficient to say, our data is correct, because we store all interactions in a separate audit log.“ The integrity of the audit log itself must also be guaranteed. This paper proposes mechanisms within a database management system (DBMS), based on cryptographically strong one-way hash functions, that prevent an intruder, including an auditor or an employee or even an unknown bug within the DBMS itself, from silently corrupting the audit log. We propose that the DBMS store additional information in the database to enable a separate audit log validator to examine the database along with this extra information and state conclusively whether the audit log has been compromised. We show with an implementation on a high-performance storage engine that the overhead for auditing is low and that the validator can efficiently and correctly determine if the audit log has been compromised.

6. Abstract of Paper 2 l Kyri Pavlou and Richard T. Snodgrass, "Forensic Analysis of Database Tampering," in Proceedings of the ACM SIGMOD International Conference on Management of Data (SIGMOD), pages 109-120, Chicago, June, 2006. l Mechanisms now exist that detect tampering of a database, through the use of cryptographically-strong hash functions. This paper addresses the next problem, that of determining who, when, and what, by providing a systematic means of performing forensic analysis after such tampering has been uncovered. We introduce a schematic representation termed a “corruption diagram” that aids in intrusion investigation. We use these diagrams to fully analyze the original proposal, that of a linked sequence of hash values. We examine the various kinds of intrusions that are possible, including retroactive, introactive, backdating, and postdating intrusions. We then introduce successively more sophisticated forensic analysis algorithms: the monochromatic, RGB, and polychromatic algorithms, and characterize the “forensic strength” of these algorithms. We show how forensic analysis can efficiently extract a good deal of information concerning a corruption event.

7. Tamper Detection in Audit Logs l A variety of federal laws (e.g., Code of Federal Regulations for the Food and Drug Administration, Sarbanes-Oxley Act, Health Insurance Portability and Accountability Act, Canada's PIPEDA) and standards (e.g., Orange Book for security) mandate audit logs. l The correctness of the auditing records themselves is critical. l Cannot make the assumption that the audit records are secure and tamperproof l Therefore need a mechanism to validate the audit records – these records are created/modified during transaction execution

8. Current Audit Log Techniques l The traditional way [to protect logging data from tampering is to write it to an append-only device, such as a Write Once Read Multiple (WORM) optical drive or a continuous-feed printer. l The security of such schemes assumes, however, that the computing site will not be compromised. l If this is a possible attack scenario the logging data can be sent to a remote site over the network, so called remote logging. l Log replication can be used to send the data to several hosts to require the attacker to physically compromise several sites. l Schneier and Kelsey describe a secure audit log system using hash functions and encryption but does not work for databases.

9. DBMS Design Issues l Query Processing - Optimization techniques l Transaction Management - Techniques for concurrency control and recovery l Metadata Management - Techniques for querying and updating the metadatabase l Security/Integrity Maintenance - Techniques for processing integrity constraints and enforcing access control rules l Storage management - Access methods and index strategies for efficient access to the database

10. Database Audit Log l Authors show how a database can be protected by having the DBMS maintain the audit log in the background and by using cryptographic techniques to ensure that any alteration of prior entries in this audit log can be detected. l This approach thus applies to any application that uses a DBMS. l As an example, assume that we are a pharmacological research firm that develops new drugs, providing data to the FDA for approval of those drugs. As part of this effort we have a relational table, Administer, that records what drugs were administered to which patients during a drug trial. l 62 FR 13430 requires a computer-generated, time-stamped audit trail.

11. Database Audit Log l Authors define the table as follows in MySQL - CREATE TABLE Administer (...) AS TRANSACTIONTIME TYPE = BDB AUDITABLE = 1 l The first line - which also species the columns and primary and foreign key constraints for the table is supported by the conventional MySQL release, as is the third line, which specifies that the Berkeley DB storage system be used. l The second line specifiies that this Administer table includes transaction-time support (this is an open-source extension that we have implemented). l A transaction-time database records the history of its content. All past states are retained and can be reconstituted from the information in the database. This is ensured through the append only property of a transaction-time database: modifications only add information; no information is ever deleted. It is this basic property that the authors exploit to validate the audit log (in fact, the table is the audit log).

12. Database Audit Log l The last line species that this transaction-time table be auditable, that is, that the system take additional steps so that an audit log in maintained and so that later a separate audit log validator can examine the database and state conclusively whether the audit log has been compromised. l The authors have implemented support for auditable tables and independent validation in MySQL and Berkeley DB. l It is important to emphasize that the applications that update and query this table need not be aware of the last three lines of the CREATE TABLE statement. l Behind the scenes, transparently to the application, the DBMS creates an audit log and ensures auditability.

13. Threat Model l Authors assume that Trusted Computing Base (TCB) consisting of correctly booted and functioning hardware and a correctly installed operating system and DBMS. That is, the TCB is correctly functioning until such a time T when a penetration occurs. l Similarly, until time T the DBMS is created, maintained, and operated in a secure manner, and all network communication is performed through secure channels (such as SSL), ensuring the correctness of the internal state of the DBMS. l Since the DBMS is a transaction-time database, all previous states can be reconstructed. l A penetration by an adversary “Bob” can take many forms. An intruder (or an insider) who gains physical access to the DBMS server will have full freedom to corrupt any database file, including data, timestamps, and audit logs stored in tuples.

14. The Approach l The user application performs transactions on the database, which insert, delete, and update the rows of current state. Behind the scenes, the DBMS retains for each tuple hidden Start and Stop times, recording when each change occurred. The DBMS ensures that only the current state of the table is accessible to the application, with the rest of the table serving as the audit log. l Alternatively, the table itself could be viewed by the application as the audit log. In that case, the application only makes insertions to the audited table; these insertions are associated with a monotonically increasing Start time. l The approach and implementation support both usages. l The basic idea is to store a check field" in each tuple. This check field cannot be computed directly from the data (and timestamps) of the tuple, because then Bob could simply recompute the check field after he has altered the tuple. l Indeed, if needed he could replay all of the transactions, making whatever changes he wanted to the data or the timestamps.

15. The Approach l Authors use a digital notarization service that, when provided with a digital document, provides a notary ID1. l Later, during audit log validation, the notarization service can ascertain, when presented with supposedly unaltered document and the notary ID, whether that document was notarized, and if so, when. l On each modication of a tuple, the DBMS obtains a timestamp, computes a cryptographically strong oneway hash function of the (new) data in the tuple and the timestamp, and sends that hash value, as a digital document, to the notarization service, obtaining a notary ID. The DBMS stores that ID in the tuple. l Later, Bob gets access to the database. If Bob changes the data or a timestamp, the ID will now be inconsistent with the rest of the tuple. l Bob cannot manipulate the data or timestamp so that the ID remains valid, because the hash function is one-way.

16. The Approach l Note that this holds even when Bob has access to the hash function itself. Bob can instead compute a new hash value for the altered tuple, but that hash value won't match the one that was notarized. l If an independent audit log validation service was provided with the database that service could, for each tuple, hash the data and the timestamp, provide it with the ID to the notarization service, which will check the notarization time with the stored timestamp. l There is a timing issue in that the database obtains a timestamp first and later notarizes the tuple. The notarization time will be slightly later than the timestamp. Also, there will be many tuples with identical timestamps, as they were all modfiied within a single transaction. l The validation service would then report whether the database and the audit log are consistent. If not, either or both had been compromised.

17. The Approach l The system is secure until Bob gets access, at which point he has access to everything: the DBMS, the operating system, the hardware, and the data in the database. l It is assumed that the notarization and validation services remain in the trusted computing base. This can be done by making them geographically and perhaps organizationally separate from the DBMS and the database. l The basic mechanism provides correct tamper detection. If Bob modifies even a single byte of the data or its timestamp, the independent validator will detect a mismatch with the notarized document, thereby detecting the tampering. l Bob could simply re-execute the transactions, making whatever changes he wanted, and then replace the original database with his altered one. However, the notarized documents would not match in time. l Avoiding tamper detection comes down to inverting the cryptographically- strong one-way hash function.

18. Performance Improvements l Different types of hash function l Different size storage for tuples l Minimize interactions l Simulation studies l Details discussed in paper

19. Related Work l Schneier and Kelsey address audit logs that are used for later forensic investigations into detected intrusions; they render the log entries impossible for the attacker to read. l Merkle proposed a digital signature system based on a secure conventional encryption function over a tree of document fragments. This work could be utilized within an notarization service l Devanbu et al. applied the Merkle Tree authentication mechanism to both relational and XML data. Here the model is different: queries over static data which has been previous digested are evaluated by an insecure server. The query results are sent to clients, which can independently verify, using the digest, that the result contains all the requested records and no superfluous records. l Another related work not cited is the work of Bertino, Carminati Ferrari and Thuraisingham on Secure Publishing of XML Data

20. Forensic Analysis of Database Tampering l To be concluded October 17, 2007 l The idea is the following: Once it is detected that there is tampering (using audit logs) determine when and where it occurred (i.e. conduct forensics analysis)

21. Forensic Analysis of Database Tampering l To be concluded October 17, 2007 l The idea is the following: Once it is detected that there is tampering (using audit logs) determine when and where it occurred (i.e. conduct forensics analysis)

22. Forensic Analysis of Database Tampering l Audit log tampering technique provides exactly one bit of information: has the audit log been tampered? l Authors introduce a schematic representation termed a “corruption diagram” for analyzing an intrusion. l They then consider how additional validation steps provide a sequence of bits that can dramatically narrow down the “when” and “where.” l They examine the corruption diagram for this initial approach; this diagram is central in all of our further analyses. We characterize the “forensic strength” of this algorithm, defined as the reduction in area of the uncertainty region in the corruption diagram.

23. Forensic Analysis of Database Tampering l Authors look at the more complex case in which the timestamp of the data item is corrupted, along with the data. l Such an action by the intruder turns out to greatly decrease the forensic strength. Along the way, we identify some configurations that turn out not to improve the forensic strength, thus helping to cull the most appropriate alternatives. l They then consider computing and notarizing additional sequence of hash values. For each successively more powerful forensic analysis algorithm, we provide a formal/diagrammatic analysis of its forensic strength. The above-mentioned algorithm is the monochromatic algorithm; they also consider the RGB algorithm and the polychromatic algorithm. This last algorithm can efficiently extract a good deal of information concerning a corruption event.

24. Forensic Analysis of Database Tampering l To explain forensic analysis, authors introduce the Corruption l Diagram, which is a graphical representation of CE(s) in terms of the temporal-spatial dimensions of a database. They have found these diagrams to be very helpful in understanding and communicating the many forensic algorithms Cosndier the simplest case. During validation, they have detected a corruption event. Though they don’t know it (yet), assume that this corruption event is a single-locus CE. Furthermore, assume that the CE just altered the data of a tuple; no timestamps were changed.

25. Definitions l Corruption event (or CE), which is any event that corrupts the data and compromises the database. The corruption event could be due to an intrusion, some kind of human intervention, a bug in the software (be it the DBMS or the file system or somewhere in the operating system), or a hardware failure, either in the processor or on the disk. l There exists a one-to-one correspondence between a CE and its corruption time (tc), which is the actual time instant (in seconds) at which a CE has occurred. l The CE was detected during a validation of the audit log by the Notarization Service (NS), termed a validation event (or VE). A validation can be scheduled (that is, is periodic) or could be an ad hoc VE. The time (instant) at which a VE occurred is termed the time of validation event, and is denoted by tv. l Tampering is indicated by a validation failure, in which the validation service returns false for the particular query of a hash value and a notarization time.

26. Definitions l What is desired is a validation success, in which the NS returns true, stating that everything is OK: the data has not been tampered. l The validator compares the hash value it computes over the data with the hash value that was previously notarized. A notarization event (or NE) is the notarization of a document (specifically, a hash value) by the notarization service. l As with validation, notarization can be scheduled (is periodic) or can be an ad hoc notarization event. Each NE has an associated notarization time (tn), which is a time instant. l Forensic analysis involves temporal detection, the determination of the corruption time, tc. Forensic analysis also involves spatial detection, the determination of “where,” that is, the location in the database of the data altered in a CE. l The finest granularity of the corruption data locus would be an explicit attribute of a tuple, or a particular timestamp attribute. We term this data that has been corrupted the corruption locus data (lc).

27. Definitions l Forensic analysis involves temporal detection, the determination of the corruption time, tc. Forensic analysis also involves spatial detection, the determination of “where,” that is, the location in the database of the data altered in a CE. l The finest granularity of the corruption data locus would be an explicit attribute of a tuple, or a particular timestamp attribute. We term this data that has been corrupted the corruption locus data (lc).

28. The Approach l To explain forensic analysis, authors introduce the Corruption Diagram, which is a graphical representation of CE(s) in terms of the temporal-spatial dimensions of a database. They have found these diagrams to be very helpful in understanding and communicating the many forensic algorithms l Once the corruption has been detected, a forensics analyzer determines the corruption region, the bounds on where and when of the corruption using the corruption diagrams and the locus. l From this validation there is 1 bit information and that is validation failure. l Need to go to other sources of information to learn about the failure l Backup copy of the database is one such source

29. The Approach l One approach is to compare tuple by tuple the backup with the current content of the database to determine the CE, (where is it?), also look at the time. Form where and when then the SSO could determine who. l Paper then describes more sophisticated algorithms, monochromatic, RGB and Polychromatic l Paper shows thorough a formal forensic strength comparison that each successive algorithm adds extra work in the form of main-memory processing, but that the resulting additional precision in the obtained information more than counterbalances this extra work l The polychromatic algorithm in particular is able to determine the “where”, the “when,” and the “to when” of a tampering quite precisely l Essentially the approach is to use corruption diagrams as a way of visualizing corruption events and forensic analysis algorithms. showing through

30. Reading for Monday October 22 l http://dfrws.org/2006/proceedings/7-Alink.pdf http://dfrws.org/2006/proceedings/7-Alink.pdf l XIRAF – XML-based indexing and querying for digital forensics http://dfrws.org/2006/proceedings/8-Turner.pdf l Selective and intelligent imaging using digital evidence bags l http://dfrws.org/2006/proceedings/9-Lee.pdf http://dfrws.org/2006/proceedings/9-Lee.pdf l Detecting false captioning using common-sense reasoning