rfc sec
This commit is contained in:
parent
fd4a8123c0
commit
be72f5e7ad
2 changed files with 2694 additions and 0 deletions
2131
anno2/mie/Sicurezza/forensics/other/rfc2350.txt
Normal file
2131
anno2/mie/Sicurezza/forensics/other/rfc2350.txt
Normal file
File diff suppressed because it is too large
Load diff
563
anno2/mie/Sicurezza/forensics/other/rfc3227.txt
Normal file
563
anno2/mie/Sicurezza/forensics/other/rfc3227.txt
Normal file
|
@ -0,0 +1,563 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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]
|
||||
|
Loading…
Reference in a new issue