Digital Forensics

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

• Auditing and Forensic Analysis
• 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,
  AugustSeptember 2004, pp. 504515.
• 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.
• 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.
• http//www.cs.arizona.edu/rts/publications.html
• Main focus will be on the first two papers

3
Outline

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

4
Part I of Course

• Parts I, II and III of the book
• Additional papers URLs given in the lectures
• 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
• Part II of the course will focus on research
  papers and certain chapters of the book

5
Abstract of Paper 1

• 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,
  AugustSeptember 2004, pp. 504515.
• 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

• 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.
• Mechanisms now exist that detect tampering of a
  database, through the use of cryptographically-str
  ong 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

• 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.
• The correctness of the auditing records
  themselves is critical.
• Cannot make the assumption that the audit records
  are secure and tamperproof
• Therefore need a mechanism to validate the audit
  records these records are created/modified
  during transaction execution

8
Current Audit Log Techniques

• 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.
• The security of such schemes assumes, however,
  that the computing site will not be compromised.
• If this is a possible attack scenario the logging
  data can be sent to a remote site over the
  network, so called remote logging.
• Log replication can be used to send the data to
  several hosts to require the attacker to
  physically compromise several sites.
• Schneier and Kelsey describe a secure audit log
  system using hash functions and encryption but
  does not work for databases.

9
DBMS Design Issues

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

10
Database Audit Log

• 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.
• This approach thus applies to any application
  that uses a DBMS.
• 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.
• 62 FR 13430 requires a computer-generated,
  time-stamped audit trail.

11
Database Audit Log

• Authors define the table as follows in MySQL
• CREATE TABLE Administer (...)
• AS TRANSACTIONTIME
• TYPE BDB
• AUDITABLE 1
• 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.
• The second line specifiies that this Administer
  table includes transaction-time support (this is
  an open-source extension that we have
  implemented).
• 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

• 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.
• The authors have implemented support for
  auditable tables and independent validation in
  MySQL and Berkeley DB.
• 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.
• Behind the scenes, transparently to the
  application, the DBMS creates an audit log and
  ensures auditability.

13
Threat Model

• 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.
• 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.
• Since the DBMS is a transaction-time database,
  all previous states can be reconstructed.
• 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

• 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.
• 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.
• The approach and implementation support both
  usages.
• 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.
• Indeed, if needed he could replay all of the
  transactions, making whatever changes he wanted
  to the data or the timestamps.

15
The Approach

• Authors use a digital notarization service that,
  when provided with a digital document, provides a
  notary ID1.
• 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.
• 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.
• 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.
• Bob cannot manipulate the data or timestamp so
  that the ID remains valid, because the hash
  function is one-way.

16
The Approach

• 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.
• 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.
• 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.
• 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

• 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.
• 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.
• 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.
• 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.
• Avoiding tamper detection comes down to inverting
  the cryptographically-strong one-way hash
  function.

18
Performance Improvements

• Different types of hash function
• Different size storage for tuples
• Minimize interactions
• Simulation studies
• Details discussed in paper

19
Related Work

• 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.
• 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
• 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.
• 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

• To be concluded October 17, 2007
• 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

• To be concluded October 17, 2007
• 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

• Audit log tampering technique provides exactly
  one bit of information has the audit log been
  tampered?
• Authors introduce a schematic representation
  termed a corruption diagram for analyzing an
  intrusion.
• They then consider how additional validation
  steps provide a sequence of bits that can
  dramatically narrow down the when and where.
• 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

• Authors look at the more complex case in which
  the timestamp of the data item is corrupted,
  along with the data.
• 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.
• 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

• 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
• Cosndier the simplest case. During validation,
  they
• have detected a corruption event. Though they
  dont 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

• 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.
• 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.
• 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.
• 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

• What is desired is a validation success, in which
  the NS returns true, stating that everything is
  OK the data has not been tampered.
• 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.
• 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.
• 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.
• 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

• 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.
• 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

• 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
• 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.
• From this validation there is 1 bit information
  and that is validation failure.
• Need to go to other sources of information to
  learn about the failure
• Backup copy of the database is one such source

29
The Approach

• 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.
• Paper then describes more sophisticated
  algorithms, monochromatic, RGB and Polychromatic
• 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
• The polychromatic algorithm in particular is able
  to determine the where, the when, and the to
  when of a tampering quite precisely
• 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

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