Personal Contact InformationReview of Two Papers"Tamper Detection in Audit Logs“ Overview of PaperTransaction Time DatabaseSlide 5Slide 6Slide 7"Tamper Detection in Audit Logs“ Main Steps of Basic Algorithm"Tamper Detection in Audit Logs“ Important observations – Basic Algorithm"Tamper Detection in Audit Logs“ Validation"Tamper Detection in Audit Logs“Hashing Functions Verifying the accuracy of the copyHashing Functions -- MD5Hashing Functions Reduce work load"Tamper Detection in Audit Logs“ Summary of main points“Forensic Analysis of Database Tampering” Overview of PaperSlide 17“Forensic Analysis of Database Tampering” Basic Definitions“Forensic Analysis of Database Tampering”Slide 20“Forensic Analysis of Database Tampering” Monochromatic Forensic Analysis“Forensic Analysis of Database Tampering” Classification of Corruption EventsSlide 23Slide 24“Forensic Analysis of Database Tampering” SummarySlide 26Personal Contact Information•Charles Shields, Jr., Ph.D., J.D. –Research Associate at University of Texas at Dallas (UTD)–[email protected]–www.utdallas.edu/~cshieldsReview of Two Papers•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. •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."Tamper Detection in Audit Logs“Overview of Paper•Emphasize the fact that audit logs be correct and verifiable–Required now by several US Federal laws (e.g. Sarbanes-Oxley, HIPAA, etc.)•Review of existing audit log techniques•Presentation of their basic idea (converting the audit log to a transaction time database with periodic validation and notarization)•Give some performance enhancements (e.g. opportunistic hashing, linked hashing)•Performance graphs and final summaryTransaction Time Database•A subset of “Temporal Databases”–http://en.wikipedia.org/wiki/Temporal_database•A temporal database is a database that tracks, among other things, two different time parameters: valid-time and transaction-time. –Valid time denotes the time period during which a fact is true with respect to the real world (i.e. “real” time) –Transaction time refers to the time period during which a fact is stored in the database. •Bitemporal data combines both Valid and Transaction Time.Transaction Time Database•Records and retains the history of its content. [1]–All past states are retained and can be reconstructed from the information in the DB.•Past state reconstruction enabled by the append only property: [1]–All new information is added only–No information is ever deleted. •In addition, the transaction time component must be auditable. That is,–An audit log is maintained–Can be examined later by a validatorTransaction Time Database•Ultimate goal is to have enough information to both: –detect a bad event–determine exactly when, how, and by whom it occurred.Transaction Time Database•Transaction time table contains all the columns a normal database table might have, with two extra fields: Start and Stop. –START:tracks when the data item was added to the database (transaction time)–STOP: tracks different states of the row (tuple)•Example operations that maintain history:–Deletion: STOP marked deleted, but row is retained–Modification: Deletion of old value; insertion of new•Invisible to user; maintained by DBMS. •Extra fields are carried for each tuple (row)."Tamper Detection in Audit Logs“Main Steps of Basic Algorithm•On each modification of a tuple, the DBMS:–Gets a timestamp for the modification–Computes a cryptographically strong one-way hash of the (new) data and the time stamp together. –Sends that value to a trusted notarization service, which sends back a unique Notary ID based on that value. –The Notary ID is then stored with the tuple."Tamper Detection in Audit Logs“Important observations – Basic Algorithm•If the data or timestamp are modified, the ID will be inconsistent with the new tuple (i.e. detected when rehashed and re-notarized). –Holds even if intruder has access to the hash function. He can calculate a new hash, but it won’t match the ID.•It is very important that the ID cannot be calculated from the data in the database (i.e. must be calculated by an independent and trusted source):–This prevents an intruder from changing the database and then recalculating the ID."Tamper Detection in Audit Logs“Validation•An independent and trusted audit log validation service can then be used to verify the integrity of the DB.•For each tuple (basic algorithm), the validation service will rehash the data and time-stamp, recalculate the ID, and compare. Called a “Validation Event” (VE)•Inconsistencies are reported as an “Corruption Event” (CE)."Tamper Detection in Audit Logs“•Modern systems can update thousands of tuples per second, leading to time efficiency problems. •Optimizations seek to minimize the time spent calculating hashes and interacting with the notarization service:– Opportunistic hashing•Reduce the interactions with the notary to one per transaction, rather than to one per tuple.–Linked hashing•Final commit hash done at midnight each day.•Reduces the interactions with the notary to one per day•creates a “hash chain” that can be used in later analysisHashing FunctionsVerifying the accuracy of the copy •A hashing function can be used to generate a “digest” specific for each file. •The digest is usually a hexadecimal number that is, with a high probability, unique for each file. •A hashing function is secure if, for a given algorithm, it is computationally infeasible–to find a message that corresponds to a given message digest, or –to find two different messages that produce the same message digest (i.e. “collision”)•In general, any change to a message will, with a very high probability, result in a different message digest. –Failure called a “collision”Hashing Functions -- MD5•MD5 Hash Function–Most commonly used (although it has been shown to have flaws (i.e. collisions))–developed by Ronald Rivest, 1991.–produces a 32 character (16 digit) hex number.
View Full Document
Unlocking...