[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 03 04 05 rfc3227                                        
Internet Engineering Task Force                     Dominique Brezinski
INTERNET-DRAFT                                                    [...]
Valid for six months                                       Tom Killalea
                                                              neart.org
                                                              July 2000



            Guidelines for Evidence Collection and Archiving

                 <draft-ietf-grip-prot-evidence-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is inappropriate to use Internet
   Drafts as reference material or to cite them other than as "work in
   progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.



Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


Abstract

   The purpose of this document is to provide System Administrators with
   guidelines on the collection and archiving of evidence.


Table of Contents

   1 Introduction
     1.1 Conventions Used in this Document

   2 Guiding Principles during Evidence Collection
     2.1 Order of Volatility



Brezinski & Killalea                                            [Page 1]


Internet Draft      Evidence Collection and Archiving        9 July 2000


     2.2 Things to avoid

   3 The Collection Procedure
     3.1 Transparency
     3.2 Collection Steps

   4 The Archiving Procedure
     4.1 Chain of Custody
     4.2 The Archive

   5 Tools you'll need

   6 Security Considerations

   7 Author's Address

   8 Full Copyright Statement


1 Introduction

   The purpose of this document is to provide System Administrators with
   guidelines on the collection and archiving of evidence.  It's not our
   intention to insist that all System Administrators rigidly follow
   these guidelines every time they have a security incident.  Rather,
   we want to provide guidance on what they should do if they elect to
   collect and protect information relating to an intrusion.

   Such collection represents a considerable effort on the part of the
   System Administrator.  Great progress has been made in recent years
   to speed up the re-installation of the Operating System and to
   facilitate the reversion of a system to a 'known' state, thus making
   the 'easy option' even more attractive.  Meanwhile little has been
   done to provide easy ways of archiving evidence (the difficult
   option).  Further, increasing disk and memory capacities and the more
   widespread use of stealth and cover-your-tracks tactics by attackers
   have exacerbated the problem.

   If evidence collection is done correctly, it is much more useful in
   apprehending the attacker, and stands a much greater chance of being
   admissible in the event of a prosecution.

   You should use these guidelines as a basis for formulating your
   site's evidence collection procedures, and should incorporate your
   site's procedures into your Incident Handling documentation.  The
   guidelines in this document may not be appropriate under all
   jurisdictions.  Once you've formulated your site's evidence
   collection procedures, you should have law enforcement for your



Brezinski & Killalea                                            [Page 2]


Internet Draft      Evidence Collection and Archiving        9 July 2000


   jurisdiction confirm that they're adequate.


1.1 Conventions Used in this Document

   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
   and "MAY" in this document are to be interpreted as described in "Key
   words for use in RFCs to Indicate Requirement Levels" [RFC2119].


2 Guiding Principles during Evidence Collection

     - Adhere to your site's Security Policy and engage the appropriate
       Incident Handling and Law Enforcement personnel.

     - Capture as accurate a picture of the system as possible.

     - Keep detailed notes.  These should include dates and times.
       If possible generate an automatic transcript.
       (e.g., The 'script' program can be used, however the output file
       it generates should not be to media that is part of the
       evidence).

     - Be prepared to testify (perhaps years later) outlining all
       actions you took and at what times.  Detailed notes will be
       vital.

     - Minimise changes to the data as you are collecting it.  This is
       not limited to content changes; you should avoid updating file or
       directory access times.

     - Remove external avenues for change.

     - When confronted with a choice between collection and analysis you
       should do collection first and analysis later.

     - Though it hardly needs stating, your procedures should be
       implementable.  If possible procedures should be automated for
       reasons of speed and accuracy.  Be methodical.

     - Speed will often be critical so your team should break up and
       collect evidence from multiple systems (including network
       devices) in parallel.  However on a single given system
       collection should be done step by step, strictly according to
       your collection procedure.

     - Proceed from the volatile to the less volatile (see the Order of
       Volatility below).



Brezinski & Killalea                                            [Page 3]


Internet Draft      Evidence Collection and Archiving        9 July 2000


     - You should make a bit-level copy of the system's media.  If you
       wish to do forensics analysis you should make a bit-level copy of
       your evidence copy for that purpose, as your analysis will almost
       certainly alter file access times.  Avoid doing forensics on the
       evidence copy.


2.1 Order of Volatility

   When collecting evidence you should proceed from the volatile to the
   less volatile.  Here is an example order of volatility for a typical
   system.

     - Registers, cache

     - routing table, arp cache, process table, kernel statistics

     - Memory

     - temporary file systems

     - Disk

     - physical configuration, network topology


2.2 Things to avoid

   It's all too easy to destroy evidence, however inadvertently.

     - Don't shutdown until you've completed evidence collection.  Much
       evidence may be lost and the attacker may have altered the
       startup/shutdown scripts/services to destroy evidence.

     - Don't trust the programs on the system.  Run your evidence
       gathering programs from your Forensics CD (see below) or similar
       read-only media.

     - Don't run programs that modify the access time of all files on
       the system (e.g., 'tar' or 'xcopy').


3 The Collection Procedure

   Your collection procedures should be as detailed as possible.  As is
   the case with your overall Incident Handling procedures, they should
   be unambiguous, and should minimise the amount of decision-making
   needed during the collection process.



Brezinski & Killalea                                            [Page 4]


Internet Draft      Evidence Collection and Archiving        9 July 2000


3.1 Transparency

   The methods used to collect evidence should be transparent.  You
   should be prepared to disclose precisely the methods you used, and
   have those methods tested by independent experts.


3.2 Collection Steps

     - Where is the evidence ?  List what systems were involved in the
       incident and from which evidence will be collected.

     - Establish what is likely to be relevant and admissable.  When in
       doubt err on the side of collecting too much rather than not
       enough.

     - For each system, obtain the relevant order of volatility.

     - Remove external avenues for change.

     - Following the order of volatility, collect the evidence with
       tools as discussed in Section 5.

     - Question what else may be evidence as you work through the
       collection steps.

     - Document each step.

   Where feasible you should consider cryptographically signing the
   collected evidence, as this may make it easier to preserve a strong
   chain of evidence.  In doing so you must not alter the evidence.


4 The Archiving Procedure

   Evidence must be strictly secured.  In addition, the Chain of Custody
   needs to be clearly documented.


4.1 Chain of Custody

   You should be able to clearly describe how the evidence was found,
   how it was handled and everything that happened to it.

   The following need to be documented

     - Where, when and by whom was the evidence discovered.




Brezinski & Killalea                                            [Page 5]


Internet Draft      Evidence Collection and Archiving        9 July 2000


     - Where, when and by whom was the evidence handled or examined.

     - Who had custody of the evidence, during what period.  How was it
       stored.

     - When the evidence changed custody, when and how did the transfer
       occur (include shipping numbers, etc.).


4.2 Where and how to Archive

   If possible commonly used media (rather than some obscure storage
   media) should be used for archiving.

   Access to evidence should be extremely restricted, and should be
   clearly documented.  It should be possible to detect unauthorised
   access.


5 Tools you'll need

   You should have the programs you need to do evidence collection and
   forensics on read-only media (e.g., CD).  You should have prepared
   such a CD for each of the Operating Systems that you manage in
   advance of having to use it.  When your systems are in production you
   might consider leaving a Forensics CD in the CD drive of each system,
   especially if your systems rarely need to use the CD drive after the
   installation process.

   Your forensics CD should include the following

     - a program for examining processes (e.g., 'ps').

     - programs for examining system state (e.g., 'showrev', 'ifconfig',
       'netstat', 'arp').

     - a program for doing bit-to-bit copies (e.g., 'dd').

     - programs for generating core images and for examining them (e.g,
       'gcore', 'gdb').

     - scripts to automate evidence collection (e.g., The Coroner's
       Toolkit [FAR1999]).


   The programs on the forensics CD should be statically linked, and
   should not require the use of any libraries other than those on the
   CD.



Brezinski & Killalea                                            [Page 6]


Internet Draft      Evidence Collection and Archiving        9 July 2000


   You should be prepared to testify to the authenticity and reliability
   of the tools that you use.

6 References

   [FAR1999]
     Farmer, D., and W Venema, "Computer Forensics Analysis Class
     Handouts", http://www.fish.com/forensics/

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, March 1997.

   [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
     1997.

   [RFC2350] Brownlee, N., and  E. Guttman, "Expectations for Computer
     Security Incident Response", RFC 2350, June 1998.


7 Acknowledgements

   We gratefully acknowledge the constructive comments received from
   Barbara Y. Fraser and Floyd Short.


6 Security Considerations

   This entire document discusses security issues.


7 Authors' Addresses

   Dominique Brezinski
   USA

   Tom Killalea
   P.O. Box 81226
   Seattle, WA 98108-1226
   USA

   Phone: +1 206 266-2196
   E-Mail: tomk@neart.org


8 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.




Brezinski & Killalea                                            [Page 7]


Internet Draft      Evidence Collection and Archiving        9 July 2000


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organisations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


This document expires January 9, 2001.

























Brezinski & Killalea                                            [Page 8]