1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc3227.txt b/doc/rfc/rfc3227.txt
new file mode 100644
index 0000000..1112767
--- /dev/null
+++ b/doc/rfc/rfc3227.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       D. Brezinski
+Request for Comments: 3227                                      In-Q-Tel
+BCP: 55                                                      T. Killalea
+Category: Best Current Practice                                neart.org
+                                                           February 2002
+
+
+            Guidelines for Evidence Collection and Archiving
+
+Status 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 Contents
+
+   1 Introduction.................................................... 2
+     1.1 Conventions Used in this Document........................... 2
+   2 Guiding Principles during Evidence Collection................... 3
+     2.1 Order of Volatility......................................... 4
+     2.2 Things to avoid............................................. 4
+     2.3 Privacy Considerations...................................... 5
+     2.4 Legal Considerations........................................ 5
+   3 The Collection Procedure........................................ 6
+     3.1 Transparency................................................ 6
+     3.2 Collection Steps............................................ 6
+   4 The Archiving Procedure......................................... 7
+     4.1 Chain of Custody............................................ 7
+     4.2 The Archive................................................. 7
+   5 Tools you'll need............................................... 7
+
+
+
+Brezinski & Killalea     Best Current Practice                  [Page 1]
+
+RFC 3227           Evidence Collection and Archiving       February 2002
+
+
+   6 References...................................................... 8
+   7 Acknowledgements................................................ 8
+   8 Security Considerations......................................... 8
+   9 Authors' Addresses.............................................. 9
+   10 Full Copyright Statement.......................................10
+
+1 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 2002
+
+
+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., 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 media
+
+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 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 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: 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.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+