I just had a presentation from the EnCase folks. They have a system that will acquire images from running computers (windows only for now). However, if you want an exact image in time, you will need to go elsewhere. Various backup products (Budtool and Netbackup come to mind) can create file system images during backup, queuing pending writes to a cache to the until the backup is finished. This queuing is normally transparent to the applications running on the system, however it is not system transparent, meaning that the I/O is redirected, and the kernel modified. You will be able to preserve the system data, however, I am not sure these products allow for the backup of raw devices in such a way that they allow for forensic analysis of slack space, etc. Additionally, dumping a live system typically creates a noticeable hit to system performance, possibly alerting users of the system to your activity. The tradeoff is between time and accuracy; The more time you take to dump a live system the less noticeable it is from a system load perspective, and the less accurate a picture of the system you will get. Forensically sound on the other hand is debatable. If you mean can it withstand the scrutiny of cross examination, then I would say probably not. I am not a lawyer and if you intend to use evidence ,gathered live, in a court, I would consult with your DA's office or corporate legal department. I don't think data gathered from a live system is unsound, and it can be used to help in determining whether a violation (of the law or policy) occurred, however as always your mileage may vary. At 11:43 AM 6/10/2002 -0700, H C wrote: > > I would be interested in knowing what criteria >others > > are using for deciding to acquire an image from a >"live" > > system (*nix or Windows) and what you think the > > appropriate standards should be for acquiring the > > evidence in a forensically sound manner within the > > incident response context. > >I'm not clear on why you'd want to image a "live" >system...given the size of some of these drives, the >system will change between when you start and finish >the imaging process. > >For NT/2K systems specifically, I would recommend >collecting "volatile" data prior to imaging the >system. I'll elaborate by way of example...assume a >system is found to have Sub7, and something about the >incident requires that an image be made of the drive. >If you simply shut down the system and image it, how >do you know that the Sub7 server was a running process >at the time that the system was shut down? How do you >know who was connected? > >That being said, I'm working on a project to retrieve >and *document* the collection of volatile information >from a "victim" system. > >Carv > > >__________________________________________________ >Do You Yahoo!? >Yahoo! - Official partner of 2002 FIFA World Cup >http://fifaworldcup.yahoo.com > >----------------------------------------------------------------- >This list is provided by the SecurityFocus ARIS analyzer service. >For more information on this free incident handling, management >and tracking system please see: http://aris.securityfocus.com ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Jun 14 2002 - 17:19:25 PDT