draft-ietf-grip-prot-evidence-03.txt   draft-ietf-grip-prot-evidence-04.txt 
Internet Engineering Task Force Dominique Brezinski Internet Engineering Task Force Dominique Brezinski
INTERNET-DRAFT [...] INTERNET-DRAFT In-Q-Tel
Valid for six months Tom Killalea Valid for six months Tom Killalea
neart.org neart.org
November 2001
Guidelines for Evidence Collection and Archiving Guidelines for Evidence Collection and Archiving
<draft-ietf-grip-prot-evidence-03.txt> <draft-ietf-grip-prot-evidence-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 37 skipping to change at page 1, line 39
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The purpose of this document is to provide System Administrators with A "security incident" as defined in [RFC2828] is a security-relevant
guidelines on the collection and archiving of evidence. 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 Table of Contents
1 Introduction 1 Introduction
1.1 Conventions Used in this Document 1.1 Conventions Used in this Document
2 Guiding Principles during Evidence Collection 2 Guiding Principles during Evidence Collection
2.1 Order of Volatility 2.1 Order of Volatility
2.2 Things to avoid 2.2 Things to avoid
2.3 Privacy Considerations 2.3 Privacy Considerations
skipping to change at page 2, line 30 skipping to change at page 2, line 39
7 Acknowledgements 7 Acknowledgements
8 Security Considerations 8 Security Considerations
9 Authors' Addresses 9 Authors' Addresses
10 Full Copyright Statement 10 Full Copyright Statement
1 Introduction 1 Introduction
The purpose of this document is to provide System Administrators with A "security incident" as defined in [RFC2828] is a security-relevant
guidelines on the collection and archiving of evidence. It's not our 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 intention to insist that all System Administrators rigidly follow
these guidelines every time they have a security incident. Rather, these guidelines every time they have a security incident. Rather,
we want to provide guidance on what they should do if they elect to we want to provide guidance on what they should do if they elect to
collect and protect information relating to an intrusion. collect and protect information relating to an intrusion.
Such collection represents a considerable effort on the part of the Such collection represents a considerable effort on the part of the
System Administrator. Great progress has been made in recent years System Administrator. Great progress has been made in recent years
to speed up the re-installation of the Operating System and to to speed up the re-installation of the Operating System and to
facilitate the reversion of a system to a 'known' state, thus making facilitate the reversion of a system to a 'known' state, thus making
the 'easy option' even more attractive. Meanwhile little has been the 'easy option' even more attractive. Meanwhile little has been
skipping to change at page 3, line 33 skipping to change at page 3, line 45
- Capture as accurate a picture of the system as possible. - Capture as accurate a picture of the system as possible.
- Keep detailed notes. These should include dates and times. - Keep detailed notes. These should include dates and times.
If possible generate an automatic transcript. If possible generate an automatic transcript.
(e.g., On Unix systems the 'script' program can be used, however (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 the output file it generates should not be to media that is part
of the evidence). Notes and print-outs should be signed and of the evidence). Notes and print-outs should be signed and
dated. 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 - Be prepared to testify (perhaps years later) outlining all
actions you took and at what times. Detailed notes will be actions you took and at what times. Detailed notes will be
vital. vital.
- Minimise changes to the data as you are collecting it. This is - Minimise changes to the data as you are collecting it. This is
not limited to content changes; you should avoid updating file or not limited to content changes; you should avoid updating file or
directory access times. directory access times.
- Remove external avenues for change. - Remove external avenues for change.
skipping to change at page 5, line 6 skipping to change at page 5, line 22
2.2 Things to avoid 2.2 Things to avoid
It's all too easy to destroy evidence, however inadvertently. It's all too easy to destroy evidence, however inadvertently.
- Don't shutdown until you've completed evidence collection. Much - Don't shutdown until you've completed evidence collection. Much
evidence may be lost and the attacker may have altered the evidence may be lost and the attacker may have altered the
startup/shutdown scripts/services to destroy evidence. startup/shutdown scripts/services to destroy evidence.
- Don't trust the programs on the system. Run your evidence - Don't trust the programs on the system. Run your evidence
gathering programs from appropriately protected media(see below). gathering programs from appropriately protected media (see
below).
- Don't run programs that modify the access time of all files on - Don't run programs that modify the access time of all files on
the system (e.g., 'tar' or 'xcopy'). the system (e.g., 'tar' or 'xcopy').
- When removing external avenues for change note that simply - When removing external avenues for change note that simply
disconnecting or filtering from the network may trigger "deadman disconnecting or filtering from the network may trigger "deadman
switches" that detect when they're off the net and wipe evidence. switches" that detect when they're off the net and wipe evidence.
2.3 Privacy Considerations 2.3 Privacy Considerations
skipping to change at page 5, line 39 skipping to change at page 6, line 10
- Make sure you have the backing of your company's established - Make sure you have the backing of your company's established
procedures in taking the steps you do to collect evidence of an procedures in taking the steps you do to collect evidence of an
incident. incident.
2.4 Legal Considerations 2.4 Legal Considerations
Computer evidence needs to be Computer evidence needs to be
- Admissible: It must conform to certain legal rules before it - Admissible: It must conform to certain legal rules before it
can be put before a jury. can be put before a court.
- Authentic: It must be possible to positively tie evidentiary - Authentic: It must be possible to positively tie evidentiary
material to the incident. material to the incident.
- Complete: It must tell the whole story and not just a - Complete: It must tell the whole story and not just a
particular perspective. particular perspective.
- Reliable: There must be nothing about how the evidence was - Reliable: There must be nothing about how the evidence was
collected and subsequently handled which that doubt about its collected and subsequently handled that casts doubt about its
authenticity and veracity. authenticity and veracity.
- Believable: It must be readily believable and understandable to - Believable: It must be readily believable and understandable by
members of a jury. a court.
3 The Collection Procedure 3 The Collection Procedure
Your collection procedures should be as detailed as possible. As is Your collection procedures should be as detailed as possible. As is
the case with your overall Incident Handling procedures, they should the case with your overall Incident Handling procedures, they should
be unambiguous, and should minimise the amount of decision-making be unambiguous, and should minimise the amount of decision-making
needed during the collection process. needed during the collection process.
3.1 Transparency 3.1 Transparency
skipping to change at page 8, line 41 skipping to change at page 9, line 11
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
1997. 1997.
[RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer
Security Incident Response", RFC 2350, June 1998. Security Incident Response", RFC 2350, June 1998.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
2000.
7 Acknowledgements 7 Acknowledgements
We gratefully acknowledge the constructive comments received from We gratefully acknowledge the constructive comments received from
Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,
Andrew Rees, Steve Romig and Floyd Short. Andrew Rees, Steve Romig and Floyd Short.
8 Security Considerations 8 Security Considerations
This entire document discusses security issues. This entire document discusses security issues.
9 Authors' Addresses 9 Authors' Addresses
Dominique Brezinski Dominique Brezinski
In-Q-Tel
1000 Wilson Blvd., Ste. 2900
Arlington, VA 22209
USA USA
E-Mail: dbrezinski@In-Q-Tel.org
Tom Killalea Tom Killalea
P.O. Box 81226 Lisi/n na Bro/n
Seattle, WA 98108-1226 Be/al A/tha na Muice
USA Co. Mhaigh Eo
IRELAND
Phone: +1 206 266-2196 Phone: +1 206 266-2196
E-Mail: tomk@neart.org E-Mail: tomk@neart.org
10 Full Copyright Statement 10 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
skipping to change at page 9, line 47 skipping to change at page 10, line 26
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
This document expires January 1, 2002. This document expires May 5, 2002.
 End of changes. 16 change blocks. 
14 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/