rfc3227.txt

RFC 的详细文档！


RFC 3227           Evidence Collection and Archiving       February 2002


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.

3.1 Transparency

   The methods used to collect evidence should be transparent and
   reproducible.  You should be prepared to reproduce 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 admissible.  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.

      -  Record the extent of the system's clock drift.

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

      -  Document each step.

      -  Don't forget the people involved.  Make notes of who was there
         and what were they doing, what they observed and how they
         reacted.

   Where feasible you should consider generating checksums and
   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.






Brezinski & Killalea     Best Current Practice                  [Page 6]

RFC 3227           Evidence Collection and Archiving       February 2002


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 and
         collected.

      -  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., a CD).  You should have prepared
   such a set of tools for each of the Operating Systems that you manage
   in advance of having to use it.

   Your set of tools 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', 'SafeBack').




Brezinski & Killalea     Best Current Practice                  [Page 7]

RFC 3227           Evidence Collection and Archiving       February 2002


      -  programs for generating checksums and signatures (e.g.,
         'sha1sum', a checksum-enabled 'dd', 'SafeBack', 'pgp').

      -  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 in your set of tools should be statically linked, and
   should not require the use of any libraries other than those on the
   read-only media.  Even then, since modern rootkits may be installed
   through loadable kernel modules, you should consider that your tools
   might not be giving you a full picture of the system.

   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", BCP 14, RFC 2119, March 1997.

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

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

   [RFC2828]   Shirey, R., "Internet Security Glossary", FYI 36, RFC
               2828, May 2000.

7 Acknowledgements

   We gratefully acknowledge the constructive comments received from
   Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,
   Andrew Rees, Steve Romig and Floyd Short.

8 Security Considerations

   This entire document discuses security issues.







Brezinski & Killalea     Best Current Practice                  [Page 8]

RFC 3227           Evidence Collection and Archiving       February 2002


9 Authors' Addresses

   Dominique Brezinski
   In-Q-Tel
   1000 Wilson Blvd., Ste. 2900
   Arlington, VA 22209
   USA

   EMail: [e-mail]


   Tom Killalea
   Lisi/n na Bro/n
   Be/al A/tha na Muice
   Co. Mhaigh Eo
   IRELAND

   Phone: [phone]
   EMail: [e-mail]
































Brezinski & Killalea     Best Current Practice                  [Page 9]

RFC 3227           Evidence Collection and Archiving       February 2002


10.  Full Copyright Statement

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

   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 implementation 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 organizations, 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Brezinski & Killalea     Best Current Practice                 [Page 10]