idnits 2.17.1 draft-ietf-grip-prot-evidence-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2196' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'RFC2350' is defined on line 293, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FAR1999' ** Downref: Normative reference to an Informational RFC: RFC 2196 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Dominique Brezinski 2 INTERNET-DRAFT [...] 3 Valid for six months Tom Killalea 4 neart.org 5 July 2000 7 Guidelines for Evidence Collection and Archiving 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use Internet 22 Drafts as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 Abstract 37 The purpose of this document is to provide System Administrators with 38 guidelines on the collection and archiving of evidence. 40 Table of Contents 42 1 Introduction 43 1.1 Conventions Used in this Document 45 2 Guiding Principles during Evidence Collection 46 2.1 Order of Volatility 47 2.2 Things to avoid 49 3 The Collection Procedure 50 3.1 Transparency 51 3.2 Collection Steps 53 4 The Archiving Procedure 54 4.1 Chain of Custody 55 4.2 The Archive 57 5 Tools you'll need 59 6 Security Considerations 61 7 Author's Address 63 8 Full Copyright Statement 65 1 Introduction 67 The purpose of this document is to provide System Administrators with 68 guidelines on the collection and archiving of evidence. It's not our 69 intention to insist that all System Administrators rigidly follow 70 these guidelines every time they have a security incident. Rather, 71 we want to provide guidance on what they should do if they elect to 72 collect and protect information relating to an intrusion. 74 Such collection represents a considerable effort on the part of the 75 System Administrator. Great progress has been made in recent years 76 to speed up the re-installation of the Operating System and to 77 facilitate the reversion of a system to a 'known' state, thus making 78 the 'easy option' even more attractive. Meanwhile little has been 79 done to provide easy ways of archiving evidence (the difficult 80 option). Further, increasing disk and memory capacities and the more 81 widespread use of stealth and cover-your-tracks tactics by attackers 82 have exacerbated the problem. 84 If evidence collection is done correctly, it is much more useful in 85 apprehending the attacker, and stands a much greater chance of being 86 admissible in the event of a prosecution. 88 You should use these guidelines as a basis for formulating your 89 site's evidence collection procedures, and should incorporate your 90 site's procedures into your Incident Handling documentation. The 91 guidelines in this document may not be appropriate under all 92 jurisdictions. Once you've formulated your site's evidence 93 collection procedures, you should have law enforcement for your 94 jurisdiction confirm that they're adequate. 96 1.1 Conventions Used in this Document 98 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 99 and "MAY" in this document are to be interpreted as described in "Key 100 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 102 2 Guiding Principles during Evidence Collection 104 - Adhere to your site's Security Policy and engage the appropriate 105 Incident Handling and Law Enforcement personnel. 107 - Capture as accurate a picture of the system as possible. 109 - Keep detailed notes. These should include dates and times. 110 If possible generate an automatic transcript. 111 (e.g., The 'script' program can be used, however the output file 112 it generates should not be to media that is part of the 113 evidence). 115 - Be prepared to testify (perhaps years later) outlining all 116 actions you took and at what times. Detailed notes will be 117 vital. 119 - Minimise changes to the data as you are collecting it. This is 120 not limited to content changes; you should avoid updating file or 121 directory access times. 123 - Remove external avenues for change. 125 - When confronted with a choice between collection and analysis you 126 should do collection first and analysis later. 128 - Though it hardly needs stating, your procedures should be 129 implementable. If possible procedures should be automated for 130 reasons of speed and accuracy. Be methodical. 132 - Speed will often be critical so your team should break up and 133 collect evidence from multiple systems (including network 134 devices) in parallel. However on a single given system 135 collection should be done step by step, strictly according to 136 your collection procedure. 138 - Proceed from the volatile to the less volatile (see the Order of 139 Volatility below). 141 - You should make a bit-level copy of the system's media. If you 142 wish to do forensics analysis you should make a bit-level copy of 143 your evidence copy for that purpose, as your analysis will almost 144 certainly alter file access times. Avoid doing forensics on the 145 evidence copy. 147 2.1 Order of Volatility 149 When collecting evidence you should proceed from the volatile to the 150 less volatile. Here is an example order of volatility for a typical 151 system. 153 - Registers, cache 155 - routing table, arp cache, process table, kernel statistics 157 - Memory 159 - temporary file systems 161 - Disk 163 - physical configuration, network topology 165 2.2 Things to avoid 167 It's all too easy to destroy evidence, however inadvertently. 169 - Don't shutdown until you've completed evidence collection. Much 170 evidence may be lost and the attacker may have altered the 171 startup/shutdown scripts/services to destroy evidence. 173 - Don't trust the programs on the system. Run your evidence 174 gathering programs from your Forensics CD (see below) or similar 175 read-only media. 177 - Don't run programs that modify the access time of all files on 178 the system (e.g., 'tar' or 'xcopy'). 180 3 The Collection Procedure 182 Your collection procedures should be as detailed as possible. As is 183 the case with your overall Incident Handling procedures, they should 184 be unambiguous, and should minimise the amount of decision-making 185 needed during the collection process. 187 3.1 Transparency 189 The methods used to collect evidence should be transparent. You 190 should be prepared to disclose precisely the methods you used, and 191 have those methods tested by independent experts. 193 3.2 Collection Steps 195 - Where is the evidence ? List what systems were involved in the 196 incident and from which evidence will be collected. 198 - Establish what is likely to be relevant and admissable. When in 199 doubt err on the side of collecting too much rather than not 200 enough. 202 - For each system, obtain the relevant order of volatility. 204 - Remove external avenues for change. 206 - Following the order of volatility, collect the evidence with 207 tools as discussed in Section 5. 209 - Question what else may be evidence as you work through the 210 collection steps. 212 - Document each step. 214 Where feasible you should consider cryptographically signing the 215 collected evidence, as this may make it easier to preserve a strong 216 chain of evidence. In doing so you must not alter the evidence. 218 4 The Archiving Procedure 220 Evidence must be strictly secured. In addition, the Chain of Custody 221 needs to be clearly documented. 223 4.1 Chain of Custody 225 You should be able to clearly describe how the evidence was found, 226 how it was handled and everything that happened to it. 228 The following need to be documented 230 - Where, when and by whom was the evidence discovered. 232 - Where, when and by whom was the evidence handled or examined. 234 - Who had custody of the evidence, during what period. How was it 235 stored. 237 - When the evidence changed custody, when and how did the transfer 238 occur (include shipping numbers, etc.). 240 4.2 Where and how to Archive 242 If possible commonly used media (rather than some obscure storage 243 media) should be used for archiving. 245 Access to evidence should be extremely restricted, and should be 246 clearly documented. It should be possible to detect unauthorised 247 access. 249 5 Tools you'll need 251 You should have the programs you need to do evidence collection and 252 forensics on read-only media (e.g., CD). You should have prepared 253 such a CD for each of the Operating Systems that you manage in 254 advance of having to use it. When your systems are in production you 255 might consider leaving a Forensics CD in the CD drive of each system, 256 especially if your systems rarely need to use the CD drive after the 257 installation process. 259 Your forensics CD should include the following 261 - a program for examining processes (e.g., 'ps'). 263 - programs for examining system state (e.g., 'showrev', 'ifconfig', 264 'netstat', 'arp'). 266 - a program for doing bit-to-bit copies (e.g., 'dd'). 268 - programs for generating core images and for examining them (e.g, 269 'gcore', 'gdb'). 271 - scripts to automate evidence collection (e.g., The Coroner's 272 Toolkit [FAR1999]). 274 The programs on the forensics CD should be statically linked, and 275 should not require the use of any libraries other than those on the 276 CD. 278 You should be prepared to testify to the authenticity and reliability 279 of the tools that you use. 281 6 References 283 [FAR1999] 284 Farmer, D., and W Venema, "Computer Forensics Analysis Class 285 Handouts", http://www.fish.com/forensics/ 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", RFC 2119, March 1997. 290 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 291 1997. 293 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 294 Security Incident Response", RFC 2350, June 1998. 296 7 Acknowledgements 298 We gratefully acknowledge the constructive comments received from 299 Barbara Y. Fraser and Floyd Short. 301 6 Security Considerations 303 This entire document discusses security issues. 305 7 Authors' Addresses 307 Dominique Brezinski 308 USA 310 Tom Killalea 311 P.O. Box 81226 312 Seattle, WA 98108-1226 313 USA 315 Phone: +1 206 266-2196 316 E-Mail: tomk@neart.org 318 8 Full Copyright Statement 320 Copyright (C) The Internet Society (2000). All Rights Reserved. 322 This document and translations of it may be copied and furnished to 323 others, and derivative works that comment on or otherwise explain it 324 or assist in its implmentation may be prepared, copied, published and 325 distributed, in whole or in part, without restriction of any kind, 326 provided that the above copyright notice and this paragraph are 327 included on all such copies and derivative works. However, this 328 document itself may not be modified in any way, such as by removing 329 the copyright notice or references to the Internet Society or other 330 Internet organisations, except as needed for the purpose of 331 developing Internet standards in which case the procedures for 332 copyrights defined in the Internet Standards process must be 333 followed, or as required to translate it into languages other than 334 English. 336 The limited permissions granted above are perpetual and will not be 337 revoked by the Internet Society or its successors or assigns. 339 This document and the information contained herein is provided on an 340 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 341 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 342 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 343 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 344 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 346 This document expires January 9, 2001.