To Forensicize or Not To Forensicize!

If you don't listen to the PaulDotCom Security Weekly Podcast, then you may not be familiar with the term "forensicize" as defined by Twitchy. I recommend you start listening and begin developing your kung-fu!

I have had the pleasure of partipating in more cases requiring forensic analysis. This isn't common in most university environments. Why not? Well, I think it is primarily because most known compromises deal with student/staff/faculty desktops and laptops. Some underpaid university employee is tasked to figure out what is wrong so they run antivirus, antispyware, anti-whatever and finally realize the machine is too screwed up to do anything with so they reinstall Windows. OR, some wise administrator has decided that too much time has been wasted with figuring out why the systems are hosed up, so at the first sign of trouble, the OS is wiped and reinstalled via Ghost/RIS/etc.

So, what about the compromises that deal with servers or systems that could have sensitive information on them? Again, another unfortunate truth rears its ugly head--lack of knowledge of proper incident response and forensic procedures. I would guess that 90% of system administrators and support staff run McAfee or Symantec when they are told that a system may be compromised. Not only is that useless, but it could be damaging because the filesystem timeline is now destroyed. Now, ask each one of those administrators how to create a forensically sound copy of the hard drive or how to write-block a drive and all but 4-5% could answer it correctly (I am probably being generous with those numbers).

This really isn't where I was planning on going with this posting but my frustrations slowly creeped to the surface as I was writing. You can expect more and more on the topic of forensics as I get closer to my talk for the GatorLUG this month and start writing detailed forensics procedures for our university.