Your SlideShare is downloading. ×
Tamper Detection in Audit Logs by Richard T Snodgrass
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Tamper Detection in Audit Logs by Richard T Snodgrass


Published on

This is a review presentation which I did for research Seminar Lecture based on the paper..

This is a review presentation which I did for research Seminar Lecture based on the paper..

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Order independent hash functions are cryptographically weak
  • Online transactions need high performance
  • Tuple size 250 bytes 3.0 GHz pentium 4 linux fedora default buffer pool 264KBNumber of tuples updated is 4
  • Same configurations10,000 transactions
  • Same configurations10 bytes 10000 transactions1000 bytes 100 transactions* Total hash operations total bytes of data hashed
  • Transcript

    • 1. Tamper Detection in Audit Logs K.P.A.S. Karunarathna University of Colombo School of Computing 2008/CS/056 Supervisor:Dr M.D.J.S. Goonethillake
    • 2. Richard T. Snodgrass Professor at University of Arizona, Computer Science Department Member of the Advisory Board of ACM SIGMOD and of the Editorial Board of ACM Ubiquity Research Interests 1. Science of Computing 2. Temporal databases 3. Query language design 4. Query optimization and evaluation 5. Storage structures and database design Books Published 1. Developing Time-Oriented Database Applications in SQL (1999) 2. Temporal Databases: Theory, Design, and Implementation (1993) Contact-
    • 3. Shilong Stanley Yao Software Engineer at National Optical Astronomy Observatory Research Interests 1. Spatial and temporal databases 2. Spatial partitioning (HTM) 3. Software engineering 4. Distributed databases Professional Activities 1. External viewer of SIGMOD conference 2004 2. Chair of ACM Student Chapter of Nankai Univ 1998/1999. Publications and Research Work 1. Distributed Event Heap, CS Dept., U of Arizona, December 2003 2. Efficient Lazy Time Stamping, PhD Qualifying Presentation, CS Dept., U of Arizona, April 2003 Contact-
    • 4. Christian Collberg Assistant Professor at University of Arizona, Computer Science Department Teaching subjects at university 1. Logic Programming 2. Functional Programming 3. Compiler Design 4. Systems Programming 5. Software Security Research Projects 1. SandMark: A Tool for the Study of Software Protection Algorithms 2. AlgoVista : A web-based search engine 3. Automatic retargeting compiler 4. ART : A language-independent and specification-driven program rendering tool
    • 5. Structure Audit Logs Introduction Existing Audit Log Techniques Temporal Database Concepts Threat model Execution of Queries and validation Minimize Notary Transactions  Opportunistic Hashing  Linked Hashing Performance Analysis Conclusion
    • 6. Audit logs What is an Audit Log? “Audit log is a separate table or a file which records the transaction activities for a given table or a database” Why we need an Audit log? 1. To protect the integrity of the data 2. Some regulations federal laws and standards 3. It’ s good practice Database and Audit Log both can be tampered Necessary to provide security mechanisms to protect the Audit Log
    • 7. Data Integrity? Guarantee that gives the originally stored data hasn’t been altered by unknown or unauthorized manner Threats for the Database 1. Authentication and Access Control 2. Database Extensions 3. OS vulnerabilities 4. Trusted Parties Paper is more focused on the threats caused by the insiders
    • 8. Existing Audit Log Techniques Using a WORM(Write Once Read Multiple) disk 1. Append Only device 2. Optical drive or a continuous-feed printer 3. Risk of remote logging present 4. Can be avoided using Log replication Schneier and Kelsey audit log mechanism 1. Render audit log entries impossible to attacker to read 2. Hash linking is used 3. Does not consider the performance
    • 9. Temporal database concepts No record will ever deleted Modification to a record treated as the deletion of that record and adds a new record. Special two columns in each table start time, end time 1. Start time column is the time which the record has been entered to the database 2. End Time is the time the record has been deleted 3. Modification to a record put the end time and insert a new record Valid or relevant records in a given time : The records which only has a start time Temporal Upward Compatibility : SELECT query will result in the only the records which are valid(records only has a start time)
    • 10. Threat Model Correctly booted and functioning hardware Correctly installed operating system and DBMS All the network communication channels are secured Intruder to the database have full free access to the DBMS server and he can corrupt any 1. database file including data 2. timestamps 3. even the audit log Information stored in the notarization service assumed to be remain secure
    • 11. Execution of QueriesUser Application Hash Value of the tuple Notarization DBMS Network Service Notary IDDatabase + Audit Log
    • 12. Validation Program Validator Notarization Network Service Hash Value of the Tuple Notary ID DBMS Hash Value of the Tuple + Notary IDDatabase + Audit Log
    • 13. Minimizing the Notary Transactions Transaction cost is high 1. The hashed value of the tuples data and timestamp(32 bytes) sent and receiving notary ID(32 bytes) 2. One transaction may change thousands of tuples ; the solution could be impractical 3. Network communication may delay transactions Some considerations 1. Opportunistic Hashing 2. Linked Hashing 3. Transaction Ordering List
    • 14. Opportunistic Hashing Hash all the tuples involve in a single transaction to create single hash value Used a separate table “Notarization History Table” When hashing “Incremental Hashing” is used Tuple T1,T2,T3 : Ti 1 <= i<= 3 Validation process one transaction per basis Order has to be preserved, since different tuple order generate different hash values Tuple sequence number is used to determine the order of the tuples are hashed
    • 15. Opportunistic Hashing cont… Temporal database is used so start time and end time columns are used for validation Reduce notarization overhead : Reduced by one per tuple one per transaction Can validate only transaction wised, not per tuple or a record basis
    • 16. Linked Hashing One Transaction per notary service call still too expensive Database Creation time hash schema + timestamp and notarize this value and store in the notarization history table Then linked hash all the transactions hash values End of the day recompute hash values and generate a new notary ID Greatly reduce notary transactions : one notary transaction per day Reduce information of attacks  Only gives corrupt details per day basis
    • 17. Performance AnalysisNumber of transactions per application
    • 18. Performance AnalysisNumber of tuples modified per transaction
    • 19. Performance AnalysisImpact of the tuple size
    • 20. Conclusion Important to provide security mechanisms to protect the audit log Major Threats are caused by the insiders Temporal database and temporal upward compatibility techniques are used Minimized notary transactions using  Opportunistic hashing  Linked hashing Still there are limitations to detect exactly who the intruder was