Shawn,
I appreciate the (re)focus of what it is we’re talking about. In my opinion, you are naming two exclusive but technologically and procedurally overlapping disciplines (incident response and forensics), but discussing it in the framework of yet a third discipline (application security architecture). In my opinion each exists for its own purpose, approaches evaluating the problem and formulating a process differently, and is conducted by groups of people with different base skill sets.
First, it appears as though we were talking about information technology/systems security planning and architecture. You discuss the configuration and review of audit logs from database management applications. This is more the typical preventative and detective control discussions that are had in traditional application security design circles. The ability to recover relevant information during incident response, and for later forensic examination should be inputs into this discussion – but this is not forensics itself.
Now on to forensics. Let me paraphrase my definition of forensics: The process of identifying, evaluating, and presenting facts to or on behalf of a court of law. So, to clarify, the purpose of forensics as it relates to a database is not to ensure that the log files are unaltered or even exist at all. The purpose of forensic investigations is to first identify the possible areas where information about an activity may reside (including the apparent lack of information), and then collect, examine, and make conclusions about that information in a verifiable and repeatable way.
There is an unfortunate fact in the perspective of forensics, for the purposes of your discussion, that the database application, the database management application, the database store, the log files, and other relevant data is just that - data. Forgive me if my understanding of what you are talking about is off, but the hard and fast procedures that you're talking about in relation to recovering "forensic images" of hard disks and file systems applies to databases as well, because these are the contents of those higher level systems. Getting into looking at the content, regardless of if that is the structure of FAT, NTFS, HFS, Windows configuration files, log files, applications, data, etc. is the Examination phase of forensics. It's the collection phase, ensuring that the material is collected in a way that that minimizes or documents any potential alteration that has the most procedurally stringent controls. Examination is left up to the examiner to plan and develop.
The method to formulate a plan is based on –current best practice—about how to collect that information from the contents of data storage. Document the process including any deviations from the plan, errors encountered, failures and successes, to establish as fact that the information collected is a true and accurate representation of the information from the source – not that the content of that information is true or unaltered by an adverse party. And finally, to collect information from all available sources to recreate an accurate narrative of the activity at the time. That means looking beyond the database itself to determine what happened, such as network logs, operating system logs on servers and workstations, application logs, the state of the files themselves, etc.
I can tell you from experience, that imaging a system or data storage area is extraordinarily easy – but this is _not_ forensics. It’s a part of forensics. There are several automated tools that will practically do this for us by clicking “next” a bunch of times. The rest of forensics is fetching or developing a best practice for a newly encountered application, or a revision of an application that’s 20 years old, or so new a best practice hasn’t been developed yet. What is hard, is explaining to lay persons (a jury for example) the condition that exists in the system without speculating how the system arrived in that condition. Finally, I spend more time refuting a speculation from the opposite party by running tests to recreate the speculative condition: Running a copy of the database in a virtual machine while attempting different scenarios like adding, removing, modifying records, compacting/garbage collection processes, creating enough events to partially rollover/overwrite logs, and explaining why the proposed process does not create the condition that the adverse party speculates it might. I even once had an entire case built around a bug in a feature of a database application that I was able to diffuse by going back through the change log history to determine that the actual version of the database being used hadn’t implemented the feature yet. Forensics is way more than setting up the database “the right way”.
Sincerely,
Eric B.
