This document discusses techniques for tamper detection in audit logs to protect data integrity. It proposes using temporal databases and opportunistic/linked hashing to minimize notary transactions when validating audit log entries. These techniques help reduce overhead by hashing all tuples in a transaction or linking daily hashes while still allowing detection of tampering at the transaction or daily level. Limitations remain in identifying the exact intruder.

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- rts@cs.arizona.edu

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- yao@noao.edu

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
Contact-collberg@cs.arizona.edu

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 Queries
User Application
Hash Value
of the tuple
Notarization
DBMS Network Service
Notary ID
Database + Audit
Log

12. Validation Program
Validator Notarization
Network
Service
Hash Value
of the Tuple Notary ID
DBMS Hash Value of
the Tuple +
Notary ID
Database + Audit
Log

13. Minimizing the Notary Transactions
 Transaction cost is high
1. The hashed value of the tuple's 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 Analysis
Number of transactions per application

18. Performance Analysis
Number of tuples modified per transaction

19. Performance Analysis
Impact 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