Database Reference
In-Depth Information
The main legal developments since my previous book are that data-breach laws are becoming more stringent,
more geographically widespread, and technologically specific. For instance, Massachusetts has implemented a data
security law, 201 CMR 17.00, which requires encryption of PI (personal information) on mobile devices and a data
This extension of SB1386 from California is now taking hold in the EU and is already applicable to ISPs in the
U.K., which may have suffered a breach, thus requiring notification in most circumstances—though exceptions are
The intention of the data-breach laws are that organizations suffering a data breach are obligated to notify
the owners of the personally identifying information. This responsibility acts as a driver to take greater care with
customer data in the first instance, in order to avoid reputational damage. On the whole the legal and compliance
drivers do not specify deep technical details for the obvious reason that lawyers do not understand how the various
systems work.
Generic Forensic Response Process
Following is the generic technical computer forensics process:
1.
Initiate a timeline of computer-based events.
2.
Identify and contain the incident.
3.
Back up electronic files as evidence in chain of custody.
4.
Recover service and deleted data.
5.
Collect and sort electronic metadata by time.
6.
Integrate all event information into the timeline, including log aggregation.
7.
Analyze the metadata timeline.
8.
Make a detailed examination of data.
9.
Document the process to make findings repeatable.
10.
Apply the evidence to a criminal or legal context.
Not many legal cases involving IT forensics are brought by victim organizations after a breach. This is partly to
avoid public reputational damage to the victim organization. However, business areas that have called upon forensic
techniques are HR (human resources), DBA team management, and external auditors in the case of governmental
and financial services corruption investigations. The application of computer forensic science applied to internal
management will be increasingly important as organizations prepare themselves for consolidation of DBA resources,
partly encouraged by the technical consolidation features of 12c.
The general aim of database forensics as a field is to be able to deduce if, how, and when a database came to be
breached, and by whom. In the absence of a time machine, how do we piece together the past actions of humans
using the database and supported applications? This is not so easy to do, because the DB is dynamically changing and
the design of a relational database is such that the past value of a tuple is discarded and only one current copy of a row
is kept (to save on disk space and maintain integrity).
So what is needed are methods of piecing together the past in Oracle. Skill in these methods is closely associated
with general troubleshooting skills, but is more focused on human actions within the DB.
