Guidelines for Evidence Collection and Archiving
RFC 3227

Document Type RFC - Best Current Practice (February 2002; No errata)
Also known as BCP 55
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3227 (Best Current Practice)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text