As per Relevance of the word collection, we have this rfc below:
Network Working Group D.
Request for Comments: 3227 In-Q-
BCP: 55 T.
Category: Best Current Practice neart.
February 2002
Guidelines for Evidence Collection and
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
A "security incident" as defined in the "Internet Security Glossary",
RFC 2828, is a security-relevant system event in which the system'
security policy is disobeyed or otherwise breached. The purpose
this document is to provide System Administrators with guidelines
the collection and archiving of evidence relevant to such a
incident
If evidence collection is done correctly, it is much more useful
apprehending the attacker, and stands a much greater chance of
admissible in the event of a prosecution
Table of
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
A "security incident" as defined in [RFC2828] is a security-
system event in which the system's security policy is disobeyed
otherwise breached. The purpose of this document is to
System Administrators with guidelines on the collection and
of evidence relevant to such a security incident. It's not
intention to insist that all System Administrators rigidly
these guidelines every time they have a security incident. Rather
we want to provide guidance on what they should do if they elect
collect and protect information relating to an intrusion
Such collection represents a considerable effort on the part of
System Administrator. Great progress has been made in recent
to speed up the re-installation of the Operating System and
facilitate the reversion of a system to a 'known' state, thus
the 'easy option' even more attractive. Meanwhile little has
done to provide easy ways of archiving evidence (the
option). Further, increasing disk and memory capacities and the
widespread use of stealth and cover-your-tracks tactics by
have exacerbated the problem
If evidence collection is done correctly, it is much more useful
apprehending the attacker, and stands a much greater chance of
admissible in the event of a prosecution
You should use these guidelines as a basis for formulating
site's evidence collection procedures, and should incorporate
site's procedures into your Incident Handling documentation.
guidelines in this document may not be appropriate under
jurisdictions. Once you've formulated your site's
collection procedures, you should have law enforcement for
jurisdiction confirm that they're adequate
1.1 Conventions Used in this
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
and "MAY" in this document are to be interpreted as described in "
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
- Adhere to your site's Security Policy and engage
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.
possible generate an automatic transcript. (e.g., On
systems the 'script' program can be used, however the
file it generates should not be to media that is part of
evidence). Notes and print-outs should be signed and dated
- Note the difference between the system clock and UTC. For
timestamp provided, indicate whether UTC or local time is used
- Be prepared to testify (perhaps years later) outlining
actions you took and at what times. Detailed notes will
vital
- Minimise changes to the data as you are collecting it. This
not limited to content changes; you should avoid updating
or directory access times
- Remove external avenues for change
- When confronted with a choice between collection and
you should do collection first and analysis later
- Though it hardly needs stating, your procedures should
implementable. As with any aspect of an incident
policy, procedures should be tested to ensure feasibility
particularly in a crisis. If possible procedures should
automated for reasons of speed and accuracy. Be methodical
- For each device, a methodical approach should be adopted
follows the guidelines laid down in your collection procedure
Speed will often be critical so where there are a number
devices requiring examination it may be appropriate to
the work among your team to collect the evidence in parallel
However on a single given system collection should be done
by step
- Proceed from the volatile to the less volatile (see the
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
wish to do forensics analysis you should make a bit-level
of your evidence copy for that purpose, as your analysis
almost certainly alter file access times. Avoid
forensics on the evidence copy
2.1 Order of
When collecting evidence you should proceed from the volatile to
less volatile. Here is an example order of volatility for a
system
- registers,
- routing table, arp cache, process table, kernel statistics
- temporary file
-
- remote logging and monitoring data that is relevant to
system in
- physical configuration, network
- archival
2.2 Things to
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
startup/shutdown scripts/services to destroy evidence
- Don't trust the programs on the system. Run your
gathering programs from appropriately protected media (
below).
- Don't run programs that modify the access time of all files
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
disconnecting or filtering from the network may
"deadman switches" that detect when they're off the net
wipe evidence
2.3 Privacy
- Respect the privacy rules and guidelines of your company
your legal jurisdiction. In particular, make sure
information collected along with the evidence you are
for is available to anyone who would not normally have
to this information. This includes access to log files (
may reveal patterns of user behaviour) as well as personal
files
- Do not intrude on people's privacy without
justification. In particular, do not collect information
areas you do not normally have reason to access (such
personal file stores) unless you have sufficient
that there is a real incident
- Make sure you have the backing of your company's
procedures in taking the steps you do to collect evidence of
incident
2.4 Legal
Computer evidence needs to
- Admissible: It must conform to certain legal rules before
can be put before a court
- Authentic: It must be possible to positively tie
material to the incident
- Complete: It must tell the whole story and not just
particular perspective
- Reliable: There must be nothing about how the evidence
collected and subsequently handled that casts doubt about
authenticity and veracity
- Believable: It must be readily believable and
by a court
Brezinski & Killalea Best Current Practice [Page 5]
RFC 3227 Evidence Collection and Archiving February 2002
3 The Collection
Your collection procedures should be as detailed as possible. As
the case with your overall Incident Handling procedures, they
be unambiguous, and should minimise the amount of decision-
needed during the collection process
3.1
The methods used to collect evidence should be transparent
reproducible. You should be prepared to reproduce precisely
methods you used, and have those methods tested by
experts
3.2 Collection
- Where is the evidence? List what systems were involved in
incident and from which evidence will be collected
- Establish what is likely to be relevant and admissible.
in doubt err on the side of collecting too much rather than
enough
- For each system, obtain the relevant order of volatility
- Remove external avenues for change
- Following the order of volatility, collect the evidence
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
collection steps
- Document each step
- Don't forget the people involved. Make notes of who was
and what were they doing, what they observed and how
reacted
Where feasible you should consider generating checksums
cryptographically signing the collected evidence, as this may make
easier to preserve a strong chain of evidence. In doing so you
not alter the evidence
Brezinski & Killalea Best Current Practice [Page 6]
RFC 3227 Evidence Collection and Archiving February 2002
4 The Archiving
Evidence must be strictly secured. In addition, the Chain of
needs to be clearly documented
4.1 Chain of
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
- Where, when, and by whom was the evidence discovered
collected
- Where, when and by whom was the evidence handled or examined
- Who had custody of the evidence, during what period. How
it stored
- When the evidence changed custody, when and how did
transfer occur (include shipping numbers, etc.).
4.2 Where and how to
If possible commonly used media (rather than some obscure
media) should be used for archiving
Access to evidence should be extremely restricted, and should
clearly documented. It should be possible to detect
access
5 Tools you'll
You should have the programs you need to do evidence collection
forensics on read-only media (e.g., a CD). You should have
such a set of tools for each of the Operating Systems that you
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
(e.g., 'gcore', 'gdb').
- scripts to automate evidence collection (e.g., The Coroner'
Toolkit [FAR1999]).
The programs in your set of tools should be statically linked,
should not require the use of any libraries other than those on
read-only media. Even then, since modern rootkits may be
through loadable kernel modules, you should consider that your
might not be giving you a full picture of the system
You should be prepared to testify to the authenticity and
of the tools that you use
6
[FAR1999] Farmer, D., and W Venema, "Computer Forensics
Class Handouts", http://www.fish.com/forensics
[RFC2119] Bradner, S., "Key words for use in RFCs to
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
Security Incident Response", FYI 8, RFC 2350, June 1998.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36,
2828, May 2000.
7
We gratefully acknowledge the constructive comments received
Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox
Andrew Rees, Steve Romig and Floyd Short
8 Security
This entire document discuses security issues
Brezinski & Killalea Best Current Practice [Page 8]
RFC 3227 Evidence Collection and Archiving February 2002
9 Authors'
Dominique
In-Q-
1000 Wilson Blvd., Ste. 2900
Arlington, VA 22209
EMail: dbrezinski@In-Q-Tel.
Tom
Lisi/n na Bro/
Be/al A/tha na
Co. Mhaigh
Phone: +1 206 266-2196
EMail: tomk@neart.
Brezinski & Killalea Best Current Practice [Page 9]
RFC 3227 Evidence Collection and Archiving February 2002
10. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Brezinski & Killalea Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
