Time and the Relational Schema Oracle Forensics tips by Paul Wright

Dr. Codds relational model is good at organizing sets of objects in a moment in time. One problem is that as these objects change over time, they are overwritten. So for instance in the employees table the historical salaries are not recorded. Relational schemas tend towards keeping a single row for each instance of a thing e.g. a single row for an employee in an employees table. This is good for organizing sets of data but not as useful for organizing information about each tuple over time. For instance if the employee left the company and then returned it might cause problems. One way of dealing with this is to duplicate each entry with an additional column called timestamp to differentiate them so that past states of a tuple can be recorded in the relation. This is not perfect.

Temporal databases become very interesting especially when applied to using SQL based RDBMSs as log hosts and thinking about the forensic investigation of a potential database attack.

The University of Arizona in Phoenix has played a lead role in temporal database research and contributes to the proposed Temporal extensions to SQL3. http://www.cs.arizona.edu/~rts/timecenter/timecenter.html  

Oracle has already added features to combat the temporal shortcoming of the relational model largely based around the proposed temporal extensions to SQL3. Of particular interest is the ability to select all versions of a tuple/row between two times.

Select * from EMPLOYEE versions between '2:00 PM' and '3:00 PM';

This is dependant on the redo available as previously discussed.

The ability to query historic data using temporal SQL is useful but in order to go back weeks, months and years very large storage is required which will prompt organizations to invest in Data Warehouse and Storage Area Network technology to house the large amount of archived data required.

Oracle should be commended for their adoption of greater time functionality in some of its products. http://www.cs.arizona.edu/people/rts/sql3.html

“The Oracle 10g Workspace Manager includes the period data type, valid-time support, transaction-time support, support for bitemporal tables, and support for sequenced primary keys, sequenced uniqueness, sequenced referential integrity, and sequenced selection and projection, in a manner quite similar to that proposed in SQL/Temporal.”

When all the tables in an RDBMS have this type of time support then tracing actions on data will be much improved. One major reason for this is that Oracle basic auditing currently has the ability to record the SQL issued by a user but not the ability to show what data was returned as a result of the query. This may be very important in an investigation. Workspace Manager gives the ability to run audited

SQL on previous versions of the data and so regenerate the result of the audited query. If Extended auditing was being used then by also using LogMiner to query the historical state of the information using regenerated SQL from the Audit then the reporting data should be the same as the original user who issued the SQL.

http://www.oracle.com/technology/products/database/workspace_manager/index.html

http://www.oracle.com/technology/products/database/workspace_manager/pdf/
twp_AppDev_Workspace_Manager_10gR2.pdf

Being able to prove the state of an electronic file at a certain time is a problem which is at the centre of many legal issues concerning Oracle DBA’s. Firstly there is the ability to prove that an external person hacked their database, secondly is the need to show an internal employee misrepresented/modified/abused data in the database, thirdly to prove compliance with external policies such as SOX/PCI and fourthly to show internal due diligence with company policy. Just being able to make the database work and work fast is not enough. Legal controls are also required.

 

This is an excerpt from the book "Oracle Forensics: Oracle Security Best Practices", by Paul M. Wright, the father of Oracle Forensics.