译者：孙达（ntbbc@hotmail.com）
发布：networkmanager.blogchina.com
译文发布时间：2004-12-8
版权：本中文翻译文档版权归作者所有。可以用于非商业用途自由转载，但必须保留
本文档的翻译及版权信息。
Network Working Group D. Brezinski
Request for Comments: 3227 In-Q-Tel
BCP: 55 T. Killalea
Category: Best Current Practice neart.org
February 2002
电子证据收集、保管指南
本目录的状态
本文为互联网社区阐述了一个互联网的最佳当前实现，并且为改进而需要讨论和建议。
本文的发布是没有限制的。
版权
Copyright (C) The Internet Society (2002). All Rights Reserved.
摘要
安全事件（在RFC 2828-"Internet Security Glossary"中定义）是指违反或违
背系统安全策略、与安全相关的系统事件。本文的目标就是给系统管理员提供
一种指导，在这种安全事件中如何收集、保存证据。
如果证据收集正确实施，将有助于了解攻击者，并且在起诉过程中将会有更大
的机会被接受。
目录
1 绪论............................................................ 2
1.1 本文约定.................................................... 2
2 证据收集原则.................................................... 3
2.1 以易失程度为序.............................................. 4
2.2 避免发生事项................................................ 4
2.3 隐私考虑.................................................... 5
2.4 合法性考虑.................................................. 5
3 证据收集程序.................................................... 6
3.1 透明度...................................................... 6
3.2 收集步骤.................................................... 6
4 证据保存程序.................................................... 7
4.1 保管链...................................................... 7
4.2 保存........................................................ 7
5 必要的工具...................................................... 7
作者：Brezinski & Killalea 最佳当前实现 [ 页 1]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
6 参考............................................................ 8
7 感谢............................................................ 8
8 安全考虑........................................................ 8
9 作者地址........................................................ 9
10 版权声明....................................................... 10
1 绪论
安全事件（在RFC 2828-"Internet Security Glossary"中定义）是指违反或违
背系统安全策略、与安全相关的系统事件。本文的目标就是给系统管理员提供
一种指导，在这种安全事件中如何收集、保存证据。这并不意味着系统管理员
在每次安全事件中必须严格遵守这些指导。更确切的说，在收集证据和固定入
侵信息中，我们只是提供一些人们应该如何做的指导原则。
这种收集代表了部分系统管理员相当大的努力。近几年来，操作系统重新安装
的速度以及系统版本更新的便利性都得到了大大的提高。因而这种"简单选项"
更加受欢迎。与此同时，便捷的归档证据（高级选项）方法则很少提供。此外，
磁盘和内存容量的不断增长，以及隐蔽的、擦除痕迹的方法广泛的被攻击者使
用，这些都增加取证的困难。
如果证据收集正确实施，将有助于了解攻击者，并且在起诉过程中将会有更大
的机会被接受。
应该使用这些指导作为阐述站点证据收集程序的基础，并且应该将它们融入事
件处理文档。本文给出的指导并不适合所有权限。一旦，阐述了站点证据收集
程序，就应该确认具有足够的法律强制力。
1.1 本文约定
本文中的关键字，如"必需的"、"必须"、"一定不"、"应该"、"不应该"和"可能"
在"Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]
中注释。
作者：Brezinski & Killalea 最佳当前实现 [ 页 2]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
2 证据收集原则
- 遵从站点的安全策略，包括适当的事件处理和法律强制人员。
- 尽可能精确的捕获系统描述。
- 保持详细的纪录，包括日期和时间。如果可能，则产生自动执行的脚本。
（例如，Unix系统中可以使用脚本程序，然而它的输出文件不应该存放在
作为证据一部分的媒体介质上）。记录和打印件都应有标识和日期。
- 注意系统时间与国际标准时间的差别. 每个提供的时间戳可以鉴别是标
准时间还是本地时间。
- 随时准备验证证据，从而勾勒出(可能事隔一年)所有行为以及何时所。
详细的记录至关重要。
- 当你收集证据时，因该尽量避免改变数据。不光是内容的改变，还应避免
改变文件和目录的访问时间。
- 删除外部更改的途径。
- 当遇到是先收集还是分析的情况下，应该先收集后分析。
- 处理程序必须被执行，虽然它很难被表述。作为事件反应策略的各个方面，
处理过程应该被测试确认足够可行，特别是在危机事件中。处于速度和精
确度的考虑，应该尽可能使用处理程序自动化。同时，还应该系统化。
- 对于每个设备，都应该根据事先制定的收集步骤作为指导来调整执行的方
法。速度有时是至关重要的，所以在有大量的设备需要检测时，并行的收
集证据是一种合适的在团队中开展工作的方法。然而，对于单个系统则应
该一步一步执行。
- 实施过程中应该按照从易失部分到非易失部分的顺序执行(具体见下节：以
易失程度为序)。
作者：Brezinski & Killalea 最佳当前实现 [ 页 3]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
- 应该获取系统中的比特级的媒体数据拷贝。如果要做法律鉴定的话，就应
该以收集比特级的媒体数据拷贝为目标，因为当你做分析是将改变文件的
访问时间。不应该在证据拷贝上做鉴定分析。
2.1 以易失程度为序
当收集证据时应该遵循从易失部分到非易失部分的顺序。下面是些典型的按易失
程度排序的系统。
- 寄存器，高速缓存
- 路由表，ARP缓存，进程表，内核状态，内存
- 临时文件系统
- 硬盘
- 与可疑系统相关的远程日志和镜像数据
- 物理配置，网络拓扑
- 归档介质
2.2 避免发生事项
破坏证据是非常容易的，常常可以是在不经意间。
- 在完成证据收集前不应该关机，否则许多证据将丢失。同时，攻击者可能
设置删除证据的开关机脚本和服务。
- 不要轻信系统中程序，从有适当保护的介质中运行自己的证据收集程序（详
细见下）。
- 不要运行能够改变系统中文件访问时间的程序。（如，"tar"或"xcopy"）
作者：Brezinski & Killalea 最佳当前实现 [ 页 4]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
- 当删除外部更改的途径时，应注意如果简单的断网可能会触发"无反应开关"，
从而擦除了证据。
2.3 隐私考虑
- 私人条目、公司战略以及法律权限应该得到重视。特别的，应确信收集的证
据信息不是是属于没有权限访问的信息。这包括访问日志文件（可能会暴露
用户行为的特性），就如个人数据文件。
- 除非有正当理由，不要涉及个人的隐私。特别的，除非足够的理由证明与事
件相关，不要收集你没有权限访问（如保存的个人文件）的信息。
- 当实施收集一个事件证据时，应确信有公司的一个既定程序来支持。
2.4 合法性考虑
计算机证据必须满足：
- 可接受: 在被提交法庭前，必须遵循确定的法律条例。
- 真实性: 必须能够肯定地将证据材料和事件联系起来。
- 完整性: 必须能够描述这个事件而不是特定的片断。
- 可靠性: 必须在如何收集和随后的处理证据方面没有关于其真实性和准确性
的疑问。
- 可信性: 必须是能够被法庭采信和理解的。
作者：Brezinski & Killalea 最佳当前实现 [ 页 5]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
3 证据收集程序
证据收集程序必须尽可能的详细。作为整个事件处理的过程，收集过程中证据收集程
序必须是明确的，并且尽量减少作决策的次数。
3.1 透明度
用于证据收集的方法应该是透明的、可重复的。使用的方法应该是随时可以被准确的
重复，同时这些方法也是被独立专家们测试过的。
3.2 收集步骤
- 证据在什么地方? 列出与事件相关的系统和能够提取证据的系统。
- 确定哪些是可能被涉及的和可接受的。无疑，收集过多的证据总强于没有足够
的证据。
- 对于每个系统，获得他们的易失程度。
- 删除外部更改的途径。
- 按照易失程度为顺序,使用工具(在第5节中讨论)来收集证据。
- 记录系统时间偏移的范围。
- 在执行收集步骤时，注意其他可能成为证据的疑问。
- 记录每一步所作。
- 不要忘记相关的人员。记录他们是谁，以及他们在做什么，在观察什么以及他
们的反应。
如果可行，应该考虑给收集的证据进行校验和加密签名，这样将可以更容易的保存证
据链。如果是这样注意不要改变证据。
作者：Brezinski & Killalea 最佳当前实现 [ 页 6]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
4 证据保存程序
证据必须被严格的保护。另外，保管链必须有明确的日志记录。
4.1 保管链
必须清楚地描述证据如何发现，如何处理以及关于与其相关的一切。
必须记录下面内容：
- 何地，何时，何人发现和收集了证据。
- 何地，何时，何人处理、检验了证据。
- 什么期间，何人保管了证据。证据是如何被保存的。
- 何时证据被改变保管，何时、如何移交（包括航运号等）。
4.2 何地以及如何归档
尽可能使用一般的介质（而不是特别的、少见的介质）来保持归档。
访问证据应该严格控制，并且有明确的记录。同时，还应能够监测非法访问。
5 必要的工具
在只读介质（如，CD）上进行证据收集和鉴定需要一些程序。应该为每种操作系统准
备一系列的、在使用前已经被掌握的工具。
这一系列工具包括：
- 监测进程的程序（如，‘ps'）。
- 检测系统状态的程序（如，'showrev','ifconfig', 'netstat', 'arp'）。
- Bit到Bit拷贝的程序（如， 'dd', 'SafeBack'）。
作者：Brezinski & Killalea 最佳当前实现 [ 页 7]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
- 产生校验和签名的程序（如，'sha1sum', 能够校验的 'dd', 'SafeBack', 'pgp'）。
- 产生、校验内核镜像的程序（如，'gcore', 'gdb'）。
- 证据自动收集脚本（如，The Coroner's Toolkit [FAR1999]）。
这一系列的程序应该是被静态的连接，并且不应该需要使用其他任何库，除非这些库
是在只读介质上。既然现代的Rootkits可以通过可加载的内核模块来安装，那么你使
用的工具也就不可能给出整个系统的全貌。
应该证明所使用的工具是可信和可靠的。
6 参考
[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 感谢
衷心感谢来自Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox,
Andrew Rees, Steve Romig and Floyd Short的建设性建议。
8 安全考虑
本文讨论的是安全问题。
作者：Brezinski & Killalea 最佳当前实现 [ 页 8]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
9 作者地址
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 最佳当前实现 [ 页 9]
翻译：孙达（ntbbc@hotmail.com）
RFC 3227 证据收集和保管 二月 2002
10. 版权声明
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 最佳当前实现 [ 页 10]
翻译：孙达（ntbbc@hotmail.com）
- 作者： sd_cf 2004年12月8日, 星期三 16:32 回复（0） | 引用（0） 加入博采
RFC3227
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.
扫一扫
181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
