A Bit More About Timelines...
Just a few more thoughts about timelines and data reduction...
One of the comments to my previous post brought up the fact that sometimes, you DO want everything you can get into a timeline. The example given was a murder investigation...in such cases, you may want to "see" what an individual's online or "cyber" life looked like for the last few days or weeks. In such instances, I completely agree that a comprehensive timeline could be very valuable, but in such instances, a comprehensive timeline would be an actual goal of your exam, wouldn't it? Everything goes back to the goals of the examination.
There are other things you can do with respect to data reduction and timelines. One of the tools I use to transition the events file (file containing the listing of all events) into a timeline includes an option to restrict the time window that I want to look at:
C:\tools>parse.pl -f D:\cases\events.txt -r 11/20/2010-11/22/2010 > D:\cases\tln.txt
This command line tells parse.pl to create a timeline using all events from 00:00:00 Z on 11/20 to 23:59:59 Z on 11/22.
Another tool you can use against the events file is grep. The "-v" option is for inverting regex matches, and allows you to remove all lines that meet a specific criteria...such as application updates, Restore Point creation/deletion, etc. This can be very useful and powerful in removing noise from your timeline.
Rob Lee also pointed out that dumping all of the Registry key LastWrite times into a timeline has been valuable, and in at least one instance, revealed a very interesting artifact. With the tools and methodology I use, I've created mini-timelines of the various verbose data sources...Registry hives generally have a LOT of keys, and I may not want to include everything, so I can instead go find the interesting tidbits and add only those items, documenting my decision to include or exclude certain data. I've also done this with web server logs during SQL injection exams, and even used this approach to answer very specific questions that did not require that entire timelines be created; a micro-timeline of just the event ID 528, type 10 events from the Security Event Log provided the answer I needed.
One final point on data reduction in your timelines...as with creating timelines, run your data reduction from an educated, knowledgeable standpoint. If you can't justify the data reduction steps in your own documentation, don't do it. Not only is repeatability something we're striving for, but being able to come back to the exam 6 months or more down the road, and understand what you did...I think everyone sees the value in that.
One of the comments to my previous post brought up the fact that sometimes, you DO want everything you can get into a timeline. The example given was a murder investigation...in such cases, you may want to "see" what an individual's online or "cyber" life looked like for the last few days or weeks. In such instances, I completely agree that a comprehensive timeline could be very valuable, but in such instances, a comprehensive timeline would be an actual goal of your exam, wouldn't it? Everything goes back to the goals of the examination.
There are other things you can do with respect to data reduction and timelines. One of the tools I use to transition the events file (file containing the listing of all events) into a timeline includes an option to restrict the time window that I want to look at:
C:\tools>parse.pl -f D:\cases\events.txt -r 11/20/2010-11/22/2010 > D:\cases\tln.txt
This command line tells parse.pl to create a timeline using all events from 00:00:00 Z on 11/20 to 23:59:59 Z on 11/22.
Another tool you can use against the events file is grep. The "-v" option is for inverting regex matches, and allows you to remove all lines that meet a specific criteria...such as application updates, Restore Point creation/deletion, etc. This can be very useful and powerful in removing noise from your timeline.
Rob Lee also pointed out that dumping all of the Registry key LastWrite times into a timeline has been valuable, and in at least one instance, revealed a very interesting artifact. With the tools and methodology I use, I've created mini-timelines of the various verbose data sources...Registry hives generally have a LOT of keys, and I may not want to include everything, so I can instead go find the interesting tidbits and add only those items, documenting my decision to include or exclude certain data. I've also done this with web server logs during SQL injection exams, and even used this approach to answer very specific questions that did not require that entire timelines be created; a micro-timeline of just the event ID 528, type 10 events from the Security Event Log provided the answer I needed.
One final point on data reduction in your timelines...as with creating timelines, run your data reduction from an educated, knowledgeable standpoint. If you can't justify the data reduction steps in your own documentation, don't do it. Not only is repeatability something we're striving for, but being able to come back to the exam 6 months or more down the road, and understand what you did...I think everyone sees the value in that.