RFC 3227

Title Block 🎀

Okay bestie, here's the deets 💅 RFC 3227, Guidelines for Evidence Collection and Archiving, from the Network Working Group, dated February 2002.

• Authors: D. Brezinski (In-Q-Tel) and T. Killalea (neart.org) 🫶
• Category: Best Current Practice, which is also BCP: 55 🌸
• Obsoletes/Updates: the title block doesn't list any RFCs that this one obsoletes or updates 🦋

Status of This Memo ✨

This is a Best Current Practice for the Internet Community 💜 It asks for discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright Notice 🎀

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌈

So a "security incident" is, per the "Internet Security Glossary" (RFC 2828), a security-relevant system event where the system's security policy gets disobeyed or otherwise breached 😭 This doc is here to give System Administrators guidance on collecting and archiving evidence for that kind of incident 🔥

Here's the tea: if you collect evidence the right way, it's way more helpful for catching the attacker, and it has a much better shot at being admissible if the case goes to 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
6 References...................................................... 8
7 Acknowledgements................................................ 8
8 Security Considerations......................................... 8
9 Authors' Addresses.............................................. 9
10 Full Copyright Statement.......................................10

---

1 Introduction 💖

Same definition as above, bestie: [RFC2828] calls a "security incident" a security-relevant system event where the system's security policy is disobeyed or otherwise breached 🙈 The whole point of this doc is to help System Administrators collect and archive evidence for that kind of incident.

Real talk though 💅 We are NOT saying every sysadmin has to follow these rigidly every single time there's an incident. It's more like: here's what you should do if you decide to collect and protect info about an intrusion 🦋

Collecting evidence is a whole project for the System Administrator 😩 Recently, people have made huge progress on reinstalling the Operating System and putting a system back into a 'known' state, so the 'easy option' is looking extra tempting 💀 Meanwhile, there's been way less work on easy ways to archive evidence (the difficult option). Bigger disks and memory, plus attackers using stealth and cover-your-tracks tactics more, have made it all even messier 🌸

Once again, because it's that important: 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 🫶

Use these guidelines as a basis for writing your site's evidence collection procedures, and fold those procedures into your Incident Handling documentation ✨ These guidelines might not fit every jurisdiction, so once your procedures are written, get law enforcement for your jurisdiction to confirm 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] 🧚

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) ⏳
• 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's 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) 🙈
• 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 🥹

4.1 Chain of Custody ✨

okay bestie, this one is all about receipts 🧾💅 You need to be able to clearly describe how the evidence was found, how it was handled, and everything that happened to it. no gaps, no vibes-only storytelling 😭

You need to document:

• Where, when, and by whom the evidence was discovered and collected.
• Where, when, and by whom the evidence was handled or examined.
• Who had custody of the evidence, and for what period. How it was stored.
• When the evidence changed custody, when and how the transfer happened (include shipping numbers, etc.) 📦

4.2 Where and how to Archive 🗄️

if you can, use commonly used media (rather than some obscure storage media) for archiving. nobody needs a mystery floppy from 1997 in their life 💀

access to the evidence should be extremely restricted, and that access should be clearly documented. it should also be possible to detect unauthorised access 🔒👀 very much a "who touched my stuff" situation.

5 Tools you'll need 🧰

okay this is the glam kit 💄 you should have the programs you need for evidence collection and forensics on read-only media (e.g., a CD). and you should prepare a set like this for each of the Operating Systems you manage before you ever need it. future you will be so grateful 🫶

your toolkit 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, SafeBack).
• 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 toolkit should be statically linked, and should not require any libraries other than the ones on the read-only media ✨ but here's the plot twist 🙈 modern rootkits can be installed through loadable kernel modules, so you should consider that your tools might not be giving you the full picture of the system. not paranoid, just prepared 💜

and you should be ready to testify to the authenticity and reliability of the tools you use. main character courtroom energy 👑⚖️

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 🌸

big thank-you to everyone who sent constructive comments: Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig and Floyd Short 🫶🎀

8 Security Considerations 🔐

okay this is the dramatic one 😭 this entire document discuses security issues. the whole thing. every page. respect the process 💀🔥

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

---

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 🌈