563 lines
18 KiB
Text
563 lines
18 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|