Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Full-Disclosure] Things that make you go "Hmmm" |
|---|---|
| Date: | Fri, 4 Mar 2005 10:08:41 -0500 |
Actually the point of policy is not to determine HOW the person who is investigating the response will do their job, but how the machine that is held suspect will be treated. Some sample policy guidelines will include whether the machine is to remain on until a forensics expert can look at the machine and make an active backup of it while it is running... Or if it is to remain on, but not connected to the internet thatway no damage can be done to other machines through the suspect machine... Or if the machine is to be immediately turned off. Forensics investigation is not something that can be controlled by policy. It can be very different on each machine you study. There should only be a 3 part policy restricting IR professionals. 1. Document everything. From the time you get the call that something is wrong, to when you arrive at the machine (including the presence of physical security around the machine), until you are completed with your investigation and are ready to give your report. 2. Do not let other people influence your work... Because someone always has an agenda, whether it's to find A problem or put the blame on A person, don't let that direct the way you go about your investigation. You might find out they're trying to pin it on someone who was someplace they weren't supposed to be, but really the machine was hacked by someone else long before that which allowed that person to get to where they shouldn't have been. And if you let them influence your work you might not have found the original breach. 3. Make backups of EVERYTHING before you even start. If you can avoid changing something, don't make the change. Think of it in the way your parents taught you how to behave... "Look, don't touch." -- On Thu, 3 Mar 2005 23:15:15 +0000 GMT, Jason Coombs <jasonc@science.org> wrote:
Matt wrote:In a good company Incidence Response isn't dictated by any of what you said above. It's dictated by policy.Good point. Even in a good company, though, incident response often occurs outside of policy. An incident response professional who works for clients during emergencies is presented with variables and circumstances with which to contend, not a policy playbook to follow. I agree that it would be nice if we could schedule and plan all of our emergencies according to policy. :-) Cheers, Jason Coombs jasonc@science.org
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Full-Disclosure] re: Bios Programming..., Matt Marooney |
|---|---|
| Next by Date: | [Full-Disclosure] [ GLSA 200503-09 ] xv: Filename handling vulnerability, Thierry Carrez |
| Previous by Thread: | Re: [Full-Disclosure] Things that make you go "Hmmm", Michael Simpson |
| Next by Thread: | [Full-Disclosure] [FLSA-2005:2314] Updated XFree86 packages fix security flaws, Dominic Hargreaves |
| Indexes: | [Date] [Thread] [Top] [All Lists] |