April 5th, 2003, 12:29 PM
What should someone do when they think their system has been compromised?
Does anyone have a quick checklist? For example:
[list=1][*]Don't turn off computer[*]Run XYZ tool to gather info[*]Save all logs[*]Etc.[/list=1]
I am curious if anyone has a defined response for a system compromise which has a checklist like this and what sorts of things one might put on such a list.
While this isn't a "checklist", I think many will find the following FAQ helpful in handling an incident or performing forensic investigations:
Incident Handling / Forensics FAQ
April 5th, 2003, 09:48 PM
Have you ever read the book Incident Response Investigating Computer Crime by Kevin Mandia and Chris Prosise?
It is a very good book dealing with what you were asking.
It has several scenarios and how to deal with a compromised host or network.
Here is a link. From there, click on the link to look inside the book. It has a exerpts that you can look through.
April 5th, 2003, 10:06 PM
I have not read that. Thanks for the heads up- I'll have to check it out.
I was really half curious what a standard incident response checklist would look like, and almost equally curious whether companies in general have even thought enough to proactively create such a checklist or if they just wing it when an incident occurs.
I found the FAQ and the information on the link from my original post to be very helpful and informative.
Are there any GCIH-certified members? Is there a sanctioned incident response handling checklist provided by the GIAC?
April 5th, 2003, 10:37 PM
I checked the link that you provided, TonyBradley, and I found some very useful information, thanks. I have heard about how companies should have an incident response checklist but I have not seen any type of standard or recommended one as of yet.
April 6th, 2003, 04:50 PM
It is actually very common for large companies to have incident response policies, most smaller businesses, smaller educational institutes, usually lack the resources to have or develop incident response policies. I can tell you that companies who are security minded usually have policies that breakdown events into categories and give a set of steps to follow:
For example, a broad policy that I have read breaks down incidents into three categories:
1.) Intrusion is currently taking place
2.) A Past Intrusion has been detected
3.) Attempt to gain information or intrude.
Each category is then broken down into smaller scenerios, for example: If scenerio #1 were occurring then the policy says there are two courses of action, (depending on the personnel availabled) either the intruder is disconnected and the computer sanitized or the intruder is allowed to continue while his actions are monitored, the intruder is then disconnected and the box is sanitized.
I have read that in some companies, they actually have like flow chart diagrams that broadly determine the steps needed to handle certain incidents.
As for your other question about the set of steps here are the checklists that I use:
For First Response:
1.) The first responder fills out a "First Responder's Form" - which is usually has some basic questions, the computer name, location, your name, anything that is blatantly obvious on the screen (windows, etc). The First Responder's Form also tells the person what not to do: such as turn off the computer, install software, or add/delete anything from the harddrive.
2.) Run the First Response Disk - Which is a disk that dumps the results of a set of tools (Fport, Handle, Listdlls, Pslist, all the Windows NET Commands, Dumps the Startup Registry keys, etc) to the floppy.
3.) Contact the appropiate network operations personnell listed on the First Responder's Form,
For Incident Response:
1.) Fill out the First Responders Form.
2.) Run the First Response Disk
3.) An image of the First Response Floppy is made, a checksum is taken and the original floppy is catalogued and stored in a secure storage area in the office.
4.) We then use the image to make a new copy of the floppy and analyze the results.
5.) If we noticed suspicous entries in the logs, we perform a more detailed investigation that is completely documented.
6.) After the appropiate actions have been taken, the box is sanitized and a follow up form is filled out (It documents the steps that we did to restore the computer.
Anyways I hope that helped, I also suggest you go to SecurityFocus.com and check out their articles on Incident Response. They have alot of GREAT information.
\"Your work is to discover your world and then with all your heart give yourself to it. \"
April 7th, 2003, 03:48 PM
OMG, Simon Templer, back from the dead
I wish to express my gratitude to the people of Italy. Thank you for inventing pizza.
April 30th, 2003, 01:31 AM
I study computer forensics, if you have any questions you would like to direct to me.
July 12th, 2003, 02:21 PM
i got this from an e-book which you can get by the link below.
1) Figure out how it happened.
(2) Find out how to avoid further exploitation of the same vulnerability.
(3) Avoid escalation and further incidents.
(4) Assess the impact and damage of the incident.
(5) Recover from the incident.
(6) Update policies and procedures as needed.
(7) Find out who did it (if appropriate and possible).
July 12th, 2003, 02:34 PM
Its an old thread, but since you've dragged it back up I'll add something as well.
I just finished reading and reviewing Incident Response: Computer Forensics Toolkit by Douglas Schweitzer (to read my review on About.com click here: Book Review).
It is an excellent book and I highly recommend it. It is very readable and explains every step of incident response in detail. One of my favorite parts is the appendix that breaks down the USA PATRIOT Act and what changes were brought about as a result. It also includes a CD with various freeware and trialware tools and checklists to keep handy for each phase of incident response.
Similar to what you list from the as-yet-to-be-uploaded ebook, the basic phases of incident response are generally accepted to be:
*Prepare to detect and respond to incidents
*Gather clues and evidence
*Clean system and patch vulnerabilities
*Recover lost data or files
*Take lessons from incident and apply them to secure for future