GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp55

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

  1. Adhere to your site's Security Policy and engage the

appropriate Incident Handling and Law Enforcement personnel.

  1. Capture as accurate a picture of the system as possible.
  1. 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.
  1. Note the difference between the system clock and UTC. For each

timestamp provided, indicate whether UTC or local time is used.

  1. Be prepared to testify (perhaps years later) outlining all

actions you took and at what times. Detailed notes will be

       vital.
  1. 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.
  1. Remove external avenues for change.
  1. When confronted with a choice between collection and analysis

you should do collection first and analysis later.

  1. 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.
  1. 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.
  1. 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

  1. 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.
  1. registers, cache
  1. routing table, arp cache, process table, kernel statistics,

memory

  1. temporary file systems
  1. disk
  1. remote logging and monitoring data that is relevant to the

system in question

  1. physical configuration, network topology
  1. archival media

2.2 Things to avoid

 It's all too easy to destroy evidence, however inadvertently.
  1. 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.
  1. Don't trust the programs on the system. Run your evidence

gathering programs from appropriately protected media (see

       below).
  1. 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

  1. 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

  1. 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.
  1. 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.
  1. 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
  1. Admissible: It must conform to certain legal rules before it

can be put before a court.

  1. Authentic: It must be possible to positively tie evidentiary

material to the incident.

  1. Complete: It must tell the whole story and not just a

particular perspective.

  1. Reliable: There must be nothing about how the evidence was

collected and subsequently handled that casts doubt about its

       authenticity and veracity.
  1. 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

  1. Where is the evidence? List what systems were involved in the

incident and from which evidence will be collected.

  1. Establish what is likely to be relevant and admissible. When

in doubt err on the side of collecting too much rather than not

       enough.
  1. For each system, obtain the relevant order of volatility.
  1. Remove external avenues for change.
  1. Following the order of volatility, collect the evidence with

tools as discussed in Section 5.

  1. Record the extent of the system's clock drift.
  1. Question what else may be evidence as you work through the

collection steps.

  1. Document each step.
  1. 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
  1. Where, when, and by whom was the evidence discovered and

collected.

  1. Where, when and by whom was the evidence handled or examined.
  1. Who had custody of the evidence, during what period. How was

it stored.

  1. 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:
  1. a program for examining processes (e.g., 'ps').
  1. programs for examining system state (e.g., 'showrev',

'ifconfig', 'netstat', 'arp').

  1. 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

  1. programs for generating checksums and signatures (e.g.,

'sha1sum', a checksum-enabled 'dd', 'SafeBack', 'pgp').

  1. programs for generating core images and for examining them

(e.g., 'gcore', 'gdb').

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp55.txt · Last modified: 2002/02/05 00:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki