EXAMPLE
FORENSICS SOP/PROCEDURE
Tiger Shark
from Antionline has kindly given his permission for his tutorial to be
hosted at The Taz.
You can find the original post here:
http://www.antionline.com/showthread.php?s=&threadid=255811
Enjoy
I just finished the initial draft of the "Incident Response" SOP that
is required to comply with federal law. Since it is an exhaustive
document that took a while to compile I thought I should post it here
to assist others in both the process and the documentation.
If anyone can see any glaring omissions or errors I would appreciate a
*heads up* before I publish this to the SOP file here at work. All the
tools should be "Googleable" by just their name. If you have a problem
finding them send a response and I'll point you to them.
I have attached an .rtf of the file for those of you that like
"pretty"....
Begin Text
========================
Company X
Agency-Wide
STANDARD OPERATING PROCEDURE
NAME OF SOP: INITIAL PRODECURES IN THE EVENT OF A SUSPECTED NETWORK
INTRUSION.
PURPOSE: While it is the intent of the COMPANY X’s IT Department to
ensure that the potential for intrusion into the COMPANY X’s Wide Area
Network, (WAN), and it’s associated networks from the outside are
minimized and that the unavailability of the data of the participating
Agencies be maintained from unauthorized viewing from the inside of the
WAN it is recognized that there will always be the potential for
compromise. This document outlines the procedures to be carried out in
the event that there is suspicion and/or evidence of such activities.
It is important to understand that compromise can come from both
without and within the network. It is further important to understand
that the perpetrators second task, after the initial penetration, is to
hide their activity by deleting logs, preventing other access to the
compromised machine, installing “back doors” to give them unfettered
access to it, “sniffing” the network to catch login/password data sent
in clear to help them elevate their privileges within the domain,
installing “kits” that allow them to carry out other actions and even
to install “rootkits” at the user or even the kernel level so that
while the machine appears to be cooperating with you it is very subtly
hiding the presence of the perpetrator.. In short, depending upon the
skill level of the attacker, everything will be done to make the
investigator(s) job more difficult or even impossible. The process
documented below follows the steps it does because the more
sophisticated attack systems may have self protection built into them.
An example would be a backdoor listening on port 1234. It will reply to
a simple SYN with a SYN/ACK, (which it is supposed to), but, if the
returning ACK packet does not contain certain data in the payload,
(there should be no payload on a standard ACK packet), then
communication will cease, or, worse yet a clean-up routine begins where
the compromised machine protects itself, (drops all packets from the
network and ignores console input), while it removes all evidence of
itself and then reboots to a “clean” system. While I know of no working
systems such as this currently “in the wild” the potential is certainly
there and as the level of sophistication rises the probability of such
systems is quite high.
APPLICATION: This policy applies to all IT staff of COMPANY X and it’s
associated agencies.
PROCEDURES: There are occasions where a machine may give the impression
that it might be compromised and there will be occasions where it is
quite clear that compromise has taken place. The first act in the case
of suspicion of compromise is to consult with the MIS/designated
security person in the IT department to determine whether the steps
this policy outlines should proceed. Prior to consultation make sure
you note down exactly why your suspicions were aroused, any error
messages that appeared, (the entire text), activity that was apparent
etc. so that the lengthy process that follows is not gone through in
vain. In short, think it through - is this really a potential
compromise or is there a viable explanation for the activity, (but
don’t be too quick to pass it off as a “glitch”, often the only
indication of a compromise is a very subtle sign or signs). At this
point great care must be taken to not alter the machine or carry out
actions that might begin what are known as “kill processes” that clean
the machine. Do the absolute minimum you can to confirm your
suspicions. If you are at all unsure how to proceed at this point do
nothing. Make the appropriate notes regarding how you were alerted,
what you have done and call COMPANY X’ MIS for advice on how to proceed.
Every step taken is to be logged. The log sheet is available from here.
Logs will be created for each asset and it’s components that are being
investigated. Logs entries are to contain investigators initials,
(legibly), date, time, action, tool, tool purpose, result, evidence
location, (file name, printed document etc.). If floppy disks are used
the log should indicate which floppy the evidence is located on and
it’s file name. Floppy Disks are to be clearly labeled EVDISKX where X
is the disk number, dated and the machine name being investigated, (eg.
EVDISK1 12/21/03 RM123P). CD-ROM’s are to be similarly labeled. Make
sure that there is no confusion caused by disk naming, (if there are 8
floppies and one CD-ROM, label them in the order of creation, Thus if
the CD-ROM was the fourth disk created it should be labeled number 4).
If components are removed from the computer such as the hard drive this
action must be logged and a manifest created detailing date, time,
action performed, signature. The drive is to be clearly labeled with
the name of the machine it was removed from, the date and time of
removal and the name of the person that removed it. When it is placed
in or removed from storage, passed on to another person, or forensic
tests are done on it the manifest must detail everything. In this way
we create a chain of evidence that may be used if legal action is
deemed necessary. All floppy disks should have their data backed up to
a trusted and secure computer, (standalone), as soon as possible to
prevent the possibility of data loss through bad floppies. When
sufficient data is collected it should be written to CD-ROM to preserve
it. Data written to CD-ROM for preservation purposes should be checked
to ensure the write was good and labeled as “FINAL EVDISK 12/21/03
Rm123P). The original evidence disks are to be secured along with the
original copy of the Incident Response Log. The Incident Response Logs
should also be photocopied at the completion of each sheet. At the
completion of the investigation and after the “of” sequence numbers
have been assigned to the original logs the entire log for each asset
is to be photocopied and secured in a location separate from the
originals. The importance of these logs cannot be over-emphasized - log
it, log it, log it………
The following are the steps to be taken on each computer or server that
is considered to be compromised. This document is to be printed and
followed by each member of the IT response team in the order it is
written unless the team leader determines that an alternative route is
justified. The printed document should be shredded upon completion of
the investigation.
Original Tutorial
Submitted by nokia for TheTAZZone-TAZForum
Originally posted on March 4th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.