idnits 2.17.1 draft-ietf-grip-prot-evidence-03.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 2001) is 8320 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 355, but no explicit reference was found in the text == Unused Reference: 'RFC2350' is defined on line 358, 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: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Dominique Brezinski 3 INTERNET-DRAFT [...] 4 Valid for six months Tom Killalea 5 neart.org 6 July 2001 8 Guidelines for Evidence Collection and Archiving 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is inappropriate to use Internet 23 Drafts as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 The purpose of this document is to provide System Administrators with 39 guidelines on the collection and archiving of evidence. 41 Table of Contents 43 1 Introduction 44 1.1 Conventions Used in this Document 46 2 Guiding Principles during Evidence Collection 47 2.1 Order of Volatility 48 2.2 Things to avoid 49 2.3 Privacy Considerations 50 2.4 Legal Considerations 52 3 The Collection Procedure 53 3.1 Transparency 54 3.2 Collection Steps 56 4 The Archiving Procedure 57 4.1 Chain of Custody 58 4.2 The Archive 60 5 Tools you'll need 62 6 References 64 7 Acknowledgements 66 8 Security Considerations 68 9 Authors' Addresses 70 10 Full Copyright Statement 72 1 Introduction 74 The purpose of this document is to provide System Administrators with 75 guidelines on the collection and archiving of evidence. It's not our 76 intention to insist that all System Administrators rigidly follow 77 these guidelines every time they have a security incident. Rather, 78 we want to provide guidance on what they should do if they elect to 79 collect and protect information relating to an intrusion. 81 Such collection represents a considerable effort on the part of the 82 System Administrator. Great progress has been made in recent years 83 to speed up the re-installation of the Operating System and to 84 facilitate the reversion of a system to a 'known' state, thus making 85 the 'easy option' even more attractive. Meanwhile little has been 86 done to provide easy ways of archiving evidence (the difficult 87 option). Further, increasing disk and memory capacities and the more 88 widespread use of stealth and cover-your-tracks tactics by attackers 89 have exacerbated the problem. 91 If evidence collection is done correctly, it is much more useful in 92 apprehending the attacker, and stands a much greater chance of being 93 admissible in the event of a prosecution. 95 You should use these guidelines as a basis for formulating your 96 site's evidence collection procedures, and should incorporate your 97 site's procedures into your Incident Handling documentation. The 98 guidelines in this document may not be appropriate under all 99 jurisdictions. Once you've formulated your site's evidence 100 collection procedures, you should have law enforcement for your 101 jurisdiction confirm that they're adequate. 103 1.1 Conventions Used in this Document 105 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 106 and "MAY" in this document are to be interpreted as described in "Key 107 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 109 2 Guiding Principles during Evidence Collection 111 - Adhere to your site's Security Policy and engage the appropriate 112 Incident Handling and Law Enforcement personnel. 114 - Capture as accurate a picture of the system as possible. 116 - Keep detailed notes. These should include dates and times. 117 If possible generate an automatic transcript. 118 (e.g., On Unix systems the 'script' program can be used, however 119 the output file it generates should not be to media that is part 120 of the evidence). Notes and print-outs should be signed and 121 dated. 123 - Be prepared to testify (perhaps years later) outlining all 124 actions you took and at what times. Detailed notes will be 125 vital. 127 - Minimise changes to the data as you are collecting it. This is 128 not limited to content changes; you should avoid updating file or 129 directory access times. 131 - Remove external avenues for change. 133 - When confronted with a choice between collection and analysis you 134 should do collection first and analysis later. 136 - Though it hardly needs stating, your procedures should be 137 implementable. As with any aspect of an incident response 138 policy, procedures should be tested to ensure feasibility, 139 particularly in a crisis. If possible procedures should be 140 automated for reasons of speed and accuracy. Be methodical. 142 - For each device, a methodical approach should be adopted which 143 follows the guidelines laid down in your collection procedure. 144 Speed will often be critical so where there are a number of 145 devices requiring examination it may be appropriate to spread the 146 work among your team to collect the evidence in parallel. 147 However on a single given system collection should be done step 148 by step. 150 - Proceed from the volatile to the less volatile (see the Order of 151 Volatility below). 153 - You should make a bit-level copy of the system's media. If you 154 wish to do forensics analysis you should make a bit-level copy of 155 your evidence copy for that purpose, as your analysis will almost 156 certainly alter file access times. Avoid doing forensics on the 157 evidence copy. 159 2.1 Order of Volatility 161 When collecting evidence you should proceed from the volatile to the 162 less volatile. Here is an example order of volatility for a typical 163 system. 165 - registers, cache 167 - routing table, arp cache, process table, kernel statistics, 168 memory 170 - temporary file systems 172 - disk 174 - remote logging and monitoring data that is relevant to the system 175 in question 177 - physical configuration, network topology 179 - archival media 181 2.2 Things to avoid 183 It's all too easy to destroy evidence, however inadvertently. 185 - Don't shutdown until you've completed evidence collection. Much 186 evidence may be lost and the attacker may have altered the 187 startup/shutdown scripts/services to destroy evidence. 189 - Don't trust the programs on the system. Run your evidence 190 gathering programs from appropriately protected media(see below). 192 - Don't run programs that modify the access time of all files on 193 the system (e.g., 'tar' or 'xcopy'). 195 - When removing external avenues for change note that simply 196 disconnecting or filtering from the network may trigger "deadman 197 switches" that detect when they're off the net and wipe evidence. 199 2.3 Privacy Considerations 201 - Respect the privacy rules and guidelines of your company and 202 your legal jurisdiction. In particular, make sure no information 203 collected along with the evidence you are searching for is 204 available to anyone who would not normally have access to this 205 information. This includes access to log files (which may reveal 206 patterns of user behaviour) as well as personal data files. 208 - Do not intrude on people's privacy without strong justification. 209 In particular, do not collect information from areas you do not 210 normally have reason to access (such as personal file stores) 211 unless you have sufficient indication that there is a real 212 incident. 214 - Make sure you have the backing of your company's established 215 procedures in taking the steps you do to collect evidence of an 216 incident. 218 2.4 Legal Considerations 220 Computer evidence needs to be 222 - Admissible: It must conform to certain legal rules before it 223 can be put before a jury. 225 - Authentic: It must be possible to positively tie evidentiary 226 material to the incident. 228 - Complete: It must tell the whole story and not just a 229 particular perspective. 231 - Reliable: There must be nothing about how the evidence was 232 collected and subsequently handled which that doubt about its 233 authenticity and veracity. 235 - Believable: It must be readily believable and understandable to 236 members of a jury. 238 3 The Collection Procedure 240 Your collection procedures should be as detailed as possible. As is 241 the case with your overall Incident Handling procedures, they should 242 be unambiguous, and should minimise the amount of decision-making 243 needed during the collection process. 245 3.1 Transparency 247 The methods used to collect evidence should be transparent and 248 reproducible. You should be prepared to reproduce precisely the 249 methods you used, and have those methods tested by independent 250 experts. 252 3.2 Collection Steps 254 - Where is the evidence ? List what systems were involved in the 255 incident and from which evidence will be collected. 257 - Establish what is likely to be relevant and admissible. When in 258 doubt err on the side of collecting too much rather than not 259 enough. 261 - For each system, obtain the relevant order of volatility. 263 - Remove external avenues for change. 265 - Following the order of volatility, collect the evidence with 266 tools as discussed in Section 5. 268 - Record the extent of the system's clock drift. 270 - Question what else may be evidence as you work through the 271 collection steps. 273 - Document each step. 275 - Don't forget the people involved. Make notes of who was there 276 and what were they doing, what they observed and how they 277 reacted. 279 Where feasible you should consider generating checksums and 280 cryptographically signing the collected evidence, as this may make it 281 easier to preserve a strong chain of evidence. In doing so you must 282 not alter the evidence. 284 4 The Archiving Procedure 286 Evidence must be strictly secured. In addition, the Chain of Custody 287 needs to be clearly documented. 289 4.1 Chain of Custody 291 You should be able to clearly describe how the evidence was found, 292 how it was handled and everything that happened to it. 294 The following need to be documented 296 - Where, when and by whom was the evidence discovered and 297 collected. 299 - Where, when and by whom was the evidence handled or examined. 301 - Who had custody of the evidence, during what period. How was it 302 stored. 304 - When the evidence changed custody, when and how did the transfer 305 occur (include shipping numbers, etc.). 307 4.2 Where and how to Archive 309 If possible commonly used media (rather than some obscure storage 310 media) should be used for archiving. 312 Access to evidence should be extremely restricted, and should be 313 clearly documented. It should be possible to detect unauthorised 314 access. 316 5 Tools you'll need 318 You should have the programs you need to do evidence collection and 319 forensics on read-only media (e.g., a CD). You should have prepared 320 such a set of tools for each of the Operating Systems that you manage 321 in advance of having to use it. 323 Your set of tools should include the following 324 - a program for examining processes (e.g., 'ps'). 326 - programs for examining system state (e.g., 'showrev', 'ifconfig', 327 'netstat', 'arp'). 329 - a program for doing bit-to-bit copies (e.g., 'dd'). 331 - programs for generating core images and for examining them (e.g, 332 'gcore', 'gdb'). 334 - scripts to automate evidence collection (e.g., The Coroner's 335 Toolkit [FAR1999]). 337 The programs in your set of tools should be statically linked, and 338 should not require the use of any libraries other than those on the 339 read-only media. Even then, since modern rootkits may be installed 340 through loadable kernel modules, you should consider that your tools 341 might not be giving you a full picture of the system. 343 You should be prepared to testify to the authenticity and reliability 344 of the tools that you use. 346 6 References 348 [FAR1999] 349 Farmer, D., and W Venema, "Computer Forensics Analysis Class 350 Handouts", http://www.fish.com/forensics/ 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", RFC 2119, March 1997. 355 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 356 1997. 358 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 359 Security Incident Response", RFC 2350, June 1998. 361 7 Acknowledgements 363 We gratefully acknowledge the constructive comments received from 364 Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, 365 Andrew Rees, Steve Romig and Floyd Short. 367 8 Security Considerations 368 This entire document discusses security issues. 370 9 Authors' Addresses 372 Dominique Brezinski 373 USA 375 Tom Killalea 376 P.O. Box 81226 377 Seattle, WA 98108-1226 378 USA 380 Phone: +1 206 266-2196 381 E-Mail: tomk@neart.org 383 10 Full Copyright Statement 385 Copyright (C) The Internet Society (2001). All Rights Reserved. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published and 390 distributed, in whole or in part, without restriction of any kind, 391 provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organisations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns. 404 This document and the information contained herein is provided on an 405 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 406 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 407 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 408 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 409 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 411 This document expires January 1, 2002.