[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft on evidence protection
Dominique and I have been working on a draft that fits very neatly
within the scope of the GRIP working group, and I believe it's
of value. It presents "Guidelines for Evidence Collection and
Archiving". The intent is that it should present system/network
administrators with do's and don'ts that will allow them to gather
as much evidence as possible and in a manner that makes it actually
admissible.
It doesn't delve into forensics (though I know there's some good work
that's going on in that area also (finally !).
It didn't make the Internet-drafts cut-off, so I'm circulating it
to the list for now (and will re-submit it when IDs opens up again)
as people here (in Adelaide) have expressed interest in reading it.
Comments welcome.
This is early, and there are a number of "[more text needed here]"
blocks sprinkled throughout it. Text welcome.
Finally, once we've filled out the gaps in this I'd like to get
GRIP participants who live in various jurisdictions to present this
to their local law enforcement agencies for review. While it
won't be possible to come up with guidelines that work
ubiquitously, the more input we get the better.
Thanks,
Tom.
--
Tom Killalea (206) 266-2196 neart.org
tomk@neart.org
Internet Engineering Task Force Dominique Brezinski
INTERNET-DRAFT [...]
Valid for six months Tom Killalea
neart.org
March 2000
Guidelines for Evidence Collection and Archiving
<draft-ietf-grip-prot-evidence-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use Internet
Drafts as reference material or to cite them other than as "work in
progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The purpose of this document is to provide System Administrators with
guidelines on the collection and archiving of evidence.
Table of Contents
1 Introduction
1.1 Conventions Used in this Document
2 Guiding Principles during Evidence Collection
2.1 Order of Volatility
Brezinski & Killalea [Page 1]
Internet Draft Evidence Collection and Archiving 9 March 2000
2.2 Things to avoid
3 The Collection Procedure
4 The Archiving Procedure
4.1 Chain of Custody
4.2 The Archive
5 Tools you'll need
6 Security Considerations
7 Author's Address
8 Full Copyright Statement
1 Introduction
The purpose of this document is to provide System Administrators with
guidelines on the collection and archiving of evidence. 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. In addition, great progress has been made in
recent years to speed up the re-installation of the Operating System
and the reversion of a system to a 'trusted state', thus making the
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.
Brezinski & Killalea [Page 2]
Internet Draft Evidence Collection and Archiving 9 March 2000
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].
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., The 'script' program can be used, however the output file
it generates should not be to media that is part of the
evidence).
- 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. If possible procedures should be automated for
reasons of speed and accuracy. Be methodical.
- Speed will often be critical so your team should break up and
collect evidence from multiple systems (including network
devices)
in parallel. However on a single given system collection should
be done step by step, strictly according to your collection
procedure.
- Proceed from the volatile to the less volatile (see the Order of
Volatility below).
- You should make a bit-level copy of the system's media. If you
Brezinski & Killalea [Page 3]
Internet Draft Evidence Collection and Archiving 9 March 2000
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
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 scripts/services to destroy evidence.
- Don't trust the programs on the system. Run your evidence
gathering
programs from your Forensics CD (see below) or similar read-only
media.
- Don't run programs that modify the access time of all files on
the system (e.g., 'tar' or 'xcopy').
3 The Collection Procedure
[more text needed here]
4 The Archiving Procedure
Evidence must be strictly secured. In addition, the Chain of Custody
Brezinski & Killalea [Page 4]
Internet Draft Evidence Collection and Archiving 9 March 2000
needs to be clearly documented.
4.1 Chain of Custody
The following need to be documented
- Where, when and by whom discovered.
- 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.
[more text needed here]
5 Tools you'll need
You should have the programs you need to do evidence collection and
forensics on read-only media (e.g., CD). You should have prepared
such a CD for each of the Operating Systems that you manage in
advance of having to use it. When your systems are in production you
might consider leaving a Forensics CD in the CD drive of each system,
especially if your systems rarely need to use the CD drive after the
installation process.
Your forensics CD should include
- 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').
- programs for generating core images and for examining them (e.g,
'gcore', 'gdb').
Brezinski & Killalea [Page 5]
Internet Draft Evidence Collection and Archiving 9 March 2000
- scripts to automate evidence collection (e.g., The Coroner's
Toolkit [FAR1999]).
You should be prepared to testify to the authenticity and reliability
of the tools that you use.
6 References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
1997.
[RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer
Security Incident Response", RFC 2350, June 1998.
[FAR1999]
Farmer, D., and W Venema, "Computer Forensics Analysis Class
Handouts", http://www.fish.com/forensics/
7 Acknowledgements
We gratefully acknowledge the constructive comments received from
Barbara Y. Fraser and Floyd Short.
6 Security Considerations
This entire document discusses security issues.
7 Authors' Addresses
Dominique Brezinski
P.O. Box 81226
Seattle, WA 98108-1226
USA
Phone: +1 206 266-6900
E-Mail: dbrez@reflexnet.net
Tom Killalea
P.O. Box 81226
Seattle, WA 98108-1226
USA
Brezinski & Killalea [Page 6]
Internet Draft Evidence Collection and Archiving 9 March 2000
Phone: +1 206 266-2196
E-Mail: tomk@neart.org
8 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 implmentation 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 organisations, 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."
This document expires September 10, 2000.
Brezinski & Killalea [Page 7]