idnits 2.17.1 draft-ietf-grip-prot-evidence-04.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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2828]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 2001) is 8196 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 368, but no explicit reference was found in the text == Unused Reference: 'RFC2350' is defined on line 371, 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 ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 10 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 In-Q-Tel 3 Valid for six months Tom Killalea 4 neart.org 5 November 2001 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/1id-abstracts.html 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 (2001). All Rights Reserved. 35 Abstract 37 A "security incident" as defined in [RFC2828] is a security-relevant 38 system event in which the system's security policy is disobeyed or 39 otherwise breached. The purpose of this document is to provide 40 System Administrators with guidelines on the collection and archiving 41 of evidence relevant to such a security incident. 43 If evidence collection is done correctly, it is much more useful in 44 apprehending the attacker, and stands a much greater chance of being 45 admissible in the event of a prosecution. 47 Table of Contents 49 1 Introduction 50 1.1 Conventions Used in this Document 52 2 Guiding Principles during Evidence Collection 53 2.1 Order of Volatility 54 2.2 Things to avoid 55 2.3 Privacy Considerations 56 2.4 Legal Considerations 58 3 The Collection Procedure 59 3.1 Transparency 60 3.2 Collection Steps 62 4 The Archiving Procedure 63 4.1 Chain of Custody 64 4.2 The Archive 66 5 Tools you'll need 68 6 References 70 7 Acknowledgements 72 8 Security Considerations 74 9 Authors' Addresses 76 10 Full Copyright Statement 78 1 Introduction 80 A "security incident" as defined in [RFC2828] is a security-relevant 81 system event in which the system's security policy is disobeyed or 82 otherwise breached. The purpose of this document is to provide 83 System Administrators with guidelines on the collection and archiving 84 of evidence relevant to such a security incident. It's not our 85 intention to insist that all System Administrators rigidly follow 86 these guidelines every time they have a security incident. Rather, 87 we want to provide guidance on what they should do if they elect to 88 collect and protect information relating to an intrusion. 90 Such collection represents a considerable effort on the part of the 91 System Administrator. Great progress has been made in recent years 92 to speed up the re-installation of the Operating System and to 93 facilitate the reversion of a system to a 'known' state, thus making 94 the 'easy option' even more attractive. Meanwhile little has been 95 done to provide easy ways of archiving evidence (the difficult 96 option). Further, increasing disk and memory capacities and the more 97 widespread use of stealth and cover-your-tracks tactics by attackers 98 have exacerbated the problem. 100 If evidence collection is done correctly, it is much more useful in 101 apprehending the attacker, and stands a much greater chance of being 102 admissible in the event of a prosecution. 104 You should use these guidelines as a basis for formulating your 105 site's evidence collection procedures, and should incorporate your 106 site's procedures into your Incident Handling documentation. The 107 guidelines in this document may not be appropriate under all 108 jurisdictions. Once you've formulated your site's evidence 109 collection procedures, you should have law enforcement for your 110 jurisdiction confirm that they're adequate. 112 1.1 Conventions Used in this Document 114 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 115 and "MAY" in this document are to be interpreted as described in "Key 116 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 118 2 Guiding Principles during Evidence Collection 120 - Adhere to your site's Security Policy and engage the appropriate 121 Incident Handling and Law Enforcement personnel. 123 - Capture as accurate a picture of the system as possible. 125 - Keep detailed notes. These should include dates and times. 126 If possible generate an automatic transcript. 127 (e.g., On Unix systems the 'script' program can be used, however 128 the output file it generates should not be to media that is part 129 of the evidence). Notes and print-outs should be signed and 130 dated. 132 - Note the difference between the system clock and UTC. For 133 each timestamp provided, indicate whether UTC or local time is 134 used. 136 - Be prepared to testify (perhaps years later) outlining all 137 actions you took and at what times. Detailed notes will be 138 vital. 140 - Minimise changes to the data as you are collecting it. This is 141 not limited to content changes; you should avoid updating file or 142 directory access times. 144 - Remove external avenues for change. 146 - When confronted with a choice between collection and analysis you 147 should do collection first and analysis later. 149 - Though it hardly needs stating, your procedures should be 150 implementable. As with any aspect of an incident response 151 policy, procedures should be tested to ensure feasibility, 152 particularly in a crisis. If possible procedures should be 153 automated for reasons of speed and accuracy. Be methodical. 155 - For each device, a methodical approach should be adopted which 156 follows the guidelines laid down in your collection procedure. 157 Speed will often be critical so where there are a number of 158 devices requiring examination it may be appropriate to spread the 159 work among your team to collect the evidence in parallel. 160 However on a single given system collection should be done step 161 by step. 163 - Proceed from the volatile to the less volatile (see the Order of 164 Volatility below). 166 - You should make a bit-level copy of the system's media. If you 167 wish to do forensics analysis you should make a bit-level copy of 168 your evidence copy for that purpose, as your analysis will almost 169 certainly alter file access times. Avoid doing forensics on the 170 evidence copy. 172 2.1 Order of Volatility 174 When collecting evidence you should proceed from the volatile to the 175 less volatile. Here is an example order of volatility for a typical 176 system. 178 - registers, cache 180 - routing table, arp cache, process table, kernel statistics, 181 memory 183 - temporary file systems 184 - disk 186 - remote logging and monitoring data that is relevant to the system 187 in question 189 - physical configuration, network topology 191 - archival media 193 2.2 Things to avoid 195 It's all too easy to destroy evidence, however inadvertently. 197 - Don't shutdown until you've completed evidence collection. Much 198 evidence may be lost and the attacker may have altered the 199 startup/shutdown scripts/services to destroy evidence. 201 - Don't trust the programs on the system. Run your evidence 202 gathering programs from appropriately protected media (see 203 below). 205 - Don't run programs that modify the access time of all files on 206 the system (e.g., 'tar' or 'xcopy'). 208 - When removing external avenues for change note that simply 209 disconnecting or filtering from the network may trigger "deadman 210 switches" that detect when they're off the net and wipe evidence. 212 2.3 Privacy Considerations 214 - Respect the privacy rules and guidelines of your company and 215 your legal jurisdiction. In particular, make sure no information 216 collected along with the evidence you are searching for is 217 available to anyone who would not normally have access to this 218 information. This includes access to log files (which may reveal 219 patterns of user behaviour) as well as personal data files. 221 - Do not intrude on people's privacy without strong justification. 222 In particular, do not collect information from areas you do not 223 normally have reason to access (such as personal file stores) 224 unless you have sufficient indication that there is a real 225 incident. 227 - Make sure you have the backing of your company's established 228 procedures in taking the steps you do to collect evidence of an 229 incident. 231 2.4 Legal Considerations 233 Computer evidence needs to be 235 - Admissible: It must conform to certain legal rules before it 236 can be put before a court. 238 - Authentic: It must be possible to positively tie evidentiary 239 material to the incident. 241 - Complete: It must tell the whole story and not just a 242 particular perspective. 244 - Reliable: There must be nothing about how the evidence was 245 collected and subsequently handled that casts doubt about its 246 authenticity and veracity. 248 - Believable: It must be readily believable and understandable by 249 a court. 251 3 The Collection Procedure 253 Your collection procedures should be as detailed as possible. As is 254 the case with your overall Incident Handling procedures, they should 255 be unambiguous, and should minimise the amount of decision-making 256 needed during the collection process. 258 3.1 Transparency 260 The methods used to collect evidence should be transparent and 261 reproducible. You should be prepared to reproduce precisely the 262 methods you used, and have those methods tested by independent 263 experts. 265 3.2 Collection Steps 267 - Where is the evidence ? List what systems were involved in the 268 incident and from which evidence will be collected. 270 - Establish what is likely to be relevant and admissible. When in 271 doubt err on the side of collecting too much rather than not 272 enough. 274 - For each system, obtain the relevant order of volatility. 276 - Remove external avenues for change. 278 - Following the order of volatility, collect the evidence with 279 tools as discussed in Section 5. 281 - Record the extent of the system's clock drift. 283 - Question what else may be evidence as you work through the 284 collection steps. 286 - Document each step. 288 - Don't forget the people involved. Make notes of who was there 289 and what were they doing, what they observed and how they 290 reacted. 292 Where feasible you should consider generating checksums and 293 cryptographically signing the collected evidence, as this may make it 294 easier to preserve a strong chain of evidence. In doing so you must 295 not alter the evidence. 297 4 The Archiving Procedure 299 Evidence must be strictly secured. In addition, the Chain of Custody 300 needs to be clearly documented. 302 4.1 Chain of Custody 304 You should be able to clearly describe how the evidence was found, 305 how it was handled and everything that happened to it. 307 The following need to be documented 309 - Where, when and by whom was the evidence discovered and 310 collected. 312 - Where, when and by whom was the evidence handled or examined. 314 - Who had custody of the evidence, during what period. How was it 315 stored. 317 - When the evidence changed custody, when and how did the transfer 318 occur (include shipping numbers, etc.). 320 4.2 Where and how to Archive 321 If possible commonly used media (rather than some obscure storage 322 media) should be used for archiving. 324 Access to evidence should be extremely restricted, and should be 325 clearly documented. It should be possible to detect unauthorised 326 access. 328 5 Tools you'll need 330 You should have the programs you need to do evidence collection and 331 forensics on read-only media (e.g., a CD). You should have prepared 332 such a set of tools for each of the Operating Systems that you manage 333 in advance of having to use it. 335 Your set of tools should include the following 337 - a program for examining processes (e.g., 'ps'). 339 - programs for examining system state (e.g., 'showrev', 'ifconfig', 340 'netstat', 'arp'). 342 - a program for doing bit-to-bit copies (e.g., 'dd'). 344 - programs for generating core images and for examining them (e.g, 345 'gcore', 'gdb'). 347 - scripts to automate evidence collection (e.g., The Coroner's 348 Toolkit [FAR1999]). 350 The programs in your set of tools should be statically linked, and 351 should not require the use of any libraries other than those on the 352 read-only media. Even then, since modern rootkits may be installed 353 through loadable kernel modules, you should consider that your tools 354 might not be giving you a full picture of the system. 356 You should be prepared to testify to the authenticity and reliability 357 of the tools that you use. 359 6 References 361 [FAR1999] 362 Farmer, D., and W Venema, "Computer Forensics Analysis Class 363 Handouts", http://www.fish.com/forensics/ 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", RFC 2119, March 1997. 368 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 369 1997. 371 [RFC2350] Brownlee, N., and E. Guttman, "Expectations for Computer 372 Security Incident Response", RFC 2350, June 1998. 374 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 375 2000. 377 7 Acknowledgements 379 We gratefully acknowledge the constructive comments received from 380 Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, 381 Andrew Rees, Steve Romig and Floyd Short. 383 8 Security Considerations 385 This entire document discusses security issues. 387 9 Authors' Addresses 389 Dominique Brezinski 390 In-Q-Tel 391 1000 Wilson Blvd., Ste. 2900 392 Arlington, VA 22209 393 USA 395 E-Mail: dbrezinski@In-Q-Tel.org 397 Tom Killalea 398 Lisi/n na Bro/n 399 Be/al A/tha na Muice 400 Co. Mhaigh Eo 401 IRELAND 403 Phone: +1 206 266-2196 404 E-Mail: tomk@neart.org 406 10 Full Copyright Statement 408 Copyright (C) The Internet Society (2001). All Rights Reserved. 410 This document and translations of it may be copied and furnished to 411 others, and derivative works that comment on or otherwise explain it 412 or assist in its implementation may be prepared, copied, published and 413 distributed, in whole or in part, without restriction of any kind, 414 provided that the above copyright notice and this paragraph are 415 included on all such copies and derivative works. However, this 416 document itself may not be modified in any way, such as by removing 417 the copyright notice or references to the Internet Society or other 418 Internet organisations, except as needed for the purpose of 419 developing Internet standards in which case the procedures for 420 copyrights defined in the Internet Standards process must be 421 followed, or as required to translate it into languages other than 422 English. 424 The limited permissions granted above are perpetual and will not be 425 revoked by the Internet Society or its successors or assigns. 427 This document and the information contained herein is provided on an 428 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 429 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 430 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 431 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 432 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 434 This document expires May 5, 2002.