Movatterモバイル変換

Network Working Group                                       D. BrezinskiRequest for Comments: 3227                                      In-Q-TelBCP: 55                                                      T. KillaleaCategory: Best Current Practice                                neart.org                                                           February 2002Guidelines for Evidence Collection and ArchivingStatus of this Memo   This document specifies an Internet Best Current Practices for the   Internet Community, and requests discussion and suggestions for   improvements.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   A "security incident" as defined in the "Internet Security Glossary",RFC 2828, is a security-relevant system event in which the system's   security policy is disobeyed or otherwise breached.  The purpose of   this document is to provide System Administrators with guidelines on   the collection and archiving of evidence relevant to such a security   incident.   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.Table of Contents1 Introduction....................................................21.1 Conventions Used in this Document...........................22 Guiding Principles during Evidence Collection...................32.1 Order of Volatility.........................................42.2 Things to avoid.............................................42.3 Privacy Considerations......................................52.4 Legal Considerations........................................53 The Collection Procedure........................................63.1 Transparency................................................63.2 Collection Steps............................................64 The Archiving Procedure.........................................74.1 Chain of Custody............................................74.2 The Archive.................................................75 Tools you'll need...............................................7Brezinski & Killalea     Best Current Practice                  [Page 1]

RFC 3227           Evidence Collection and Archiving       February 20026 References......................................................87 Acknowledgements................................................88 Security Considerations.........................................89 Authors' Addresses..............................................910 Full Copyright Statement.......................................101 Introduction   A "security incident" as defined in [RFC2828] is a security-relevant   system event in which the system's security policy is disobeyed or   otherwise breached.  The purpose of this document is to provide   System Administrators with guidelines on the collection and archiving   of evidence relevant to such a security incident.  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   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].Brezinski & Killalea     Best Current Practice                  [Page 2]

RFC 3227           Evidence Collection and Archiving       February 20022 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., On Unix         systems the 'script' program can be used, however the output         file it generates should not be to media that is part of the         evidence).  Notes and print-outs should be signed and dated.      -  Note the difference between the system clock and UTC.  For each         timestamp provided, indicate whether UTC or local time is used.      -  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.  As with any aspect of an incident response         policy, procedures should be tested to ensure feasibility,         particularly in a crisis.  If possible procedures should be         automated for reasons of speed and accuracy.  Be methodical.      -  For each device, a methodical approach should be adopted which         follows the guidelines laid down in your collection procedure.         Speed will often be critical so where there are a number of         devices requiring examination it may be appropriate to spread         the work among your team to collect the evidence in parallel.         However on a single given system collection should be done step         by step.      -  Proceed from the volatile to the less volatile (see the Order         of Volatility below).Brezinski & Killalea     Best Current Practice                  [Page 3]

RFC 3227           Evidence Collection and Archiving       February 2002      -  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      -  remote logging and monitoring data that is relevant to the         system in question      -  physical configuration, network topology      -  archival media2.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 appropriately protected media (see         below).      -  Don't run programs that modify the access time of all files on         the system (e.g., 'tar' or 'xcopy').Brezinski & Killalea     Best Current Practice                  [Page 4]

RFC 3227           Evidence Collection and Archiving       February 2002      -  When removing external avenues for change note that simply         disconnecting or filtering from the network may trigger         "deadman switches" that detect when they're off the net and         wipe evidence.2.3 Privacy Considerations      -  Respect the privacy rules and guidelines of your company and         your legal jurisdiction.  In particular, make sure no         information collected along with the evidence you are searching         for is available to anyone who would not normally have access         to this information.  This includes access to log files (which         may reveal patterns of user behaviour) as well as personal data         files.      -  Do not intrude on people's privacy without strong         justification.  In particular, do not collect information from         areas you do not normally have reason to access (such as         personal file stores) unless you have sufficient indication         that there is a real incident.      -  Make sure you have the backing of your company's established         procedures in taking the steps you do to collect evidence of an         incident.2.4 Legal Considerations   Computer evidence needs to be      -  Admissible:  It must conform to certain legal rules before it         can be put before a court.      -  Authentic:  It must be possible to positively tie evidentiary         material to the incident.      -  Complete:  It must tell the whole story and not just a         particular perspective.      -  Reliable:  There must be nothing about how the evidence was         collected and subsequently handled that casts doubt about its         authenticity and veracity.      -  Believable:  It must be readily believable and understandable         by a court.Brezinski & Killalea     Best Current Practice                  [Page 5]

RFC 3227           Evidence Collection and Archiving       February 20023 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 inSection 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 20024 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,RFC2828, 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 20029 Authors' Addresses   Dominique Brezinski   In-Q-Tel   1000 Wilson Blvd., Ste. 2900   Arlington, VA 22209   USA   EMail: dbrezinski@In-Q-Tel.org   Tom Killalea   Lisi/n na Bro/n   Be/al A/tha na Muice   Co. Mhaigh Eo   IRELAND   Phone: +1 206 266-2196   EMail: tomk@neart.orgBrezinski & Killalea     Best Current Practice                  [Page 9]

RFC 3227           Evidence Collection and Archiving       February 200210.  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]