Live vs. post mortem . . . it depends on many variables, some of; -> your knowledge of the system and the compromise/investigation -> toolset you have in hand to use -> legal issues That being said, I think you as the on the scene examiner have to make an educated decision as to whether to grab live or not. If you do then it's known changes to the system will be made. *However*, if you document those changes and move in a methodically and sound manner, than I see no reason why you cannot proceed. Of course you'll have to be prepared to state what you did, why you did it that way, and what changes were made, etc. One of the best things about a live system is the volatile info, whether in full or in remnants (passwords, pass phrases, active network connections, etc.). I say be well versed and prepared to do each and defend each. hope this helps farmerdude > I would like some more information if possible before weighing in on this. > What is the event that triggered the investigation? Is the system in > question actively attacking/damaging other systems, in which case you may > want to stop the attack/damage before thinking about imaging the system. > > What are your incident response measures in this case? > > I agree that a 'live' system will be tricky due to changes in files as they > are opened/closed/changed and this in itself may change your course of > action. > > Lee. > > -----Original Message----- > From: H C > To: forensicsat_private > Sent: 6/10/02 2:43 PM > Subject: RE: Imaging a "live" system > > > 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 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 : Mon Jun 17 2002 - 06:18:28 PDT