idnits 2.17.1 draft-oreirdan-mody-bot-remediation-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2011) is 4703 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Livingood 3 Internet-Draft N. Mody 4 Intended status: Informational M. O'Reirdan 5 Expires: December 12, 2011 Comcast 6 June 10, 2011 8 Recommendations for the Remediation of Bots in ISP Networks 9 draft-oreirdan-mody-bot-remediation-12 11 Abstract 13 This document contains recommendations on how Internet Service 14 Providers can manage the effects of computers used by their 15 subscribers, which have been infected with malicious bots, via 16 various remediation techniques. Internet users with infected 17 computers are exposed to risks such as loss of personal data, as well 18 as increased susceptibility to online fraud and/or phishing. Such 19 computers can also become an inadvertent participant in or component 20 of an online crime network, spam network, and/or phishing network, as 21 well as be used as a part of a distributed denial of service attack. 22 Mitigating the effects of and remediating the installations of 23 malicious bots will make it more difficult for botnets to operate and 24 could reduce the level of online crime on the Internet in general 25 and/or on a particular Internet Service Provider's network. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 12, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction and Problem Statement . . . . . . . . . . . . . . 6 75 3. Important Notice of Limitations and Scope . . . . . . . . . . 7 76 4. Detection of Bots . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Notification to Internet Users . . . . . . . . . . . . . . . . 12 78 6. Remediation of Hosts Infected with a Bot . . . . . . . . . . . 18 79 6.1. Guided Remediation Process . . . . . . . . . . . . . . . . 20 80 6.2. Professionally-Assisted Remediation Process . . . . . . . 21 81 7. Failure or Refusal to Remediate . . . . . . . . . . . . . . . 22 82 8. Sharing of Data from the User to the ISP . . . . . . . . . . . 22 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 23 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 87 13. Informative references . . . . . . . . . . . . . . . . . . . . 24 88 Appendix A. Examples of Third Party Malware Lists . . . . . . . . 26 89 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 26 90 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Key Terminology 95 This section defines the key terms used in this document. 97 1.1. Malicious Bots, or Bots 99 A malicious or potentially malicious "bot" (derived from the word 100 "robot", hereafter simply referred to as a "bot") refers to a program 101 that is installed on a system in order to enable that system to 102 automatically (or semi-automatically) perform a task or set of tasks 103 typically under the command and control of a remote administrator, or 104 "bot master". Bots are also known as "zombies". Such bots may have 105 been installed surreptitiously, without the user's full understanding 106 of what the bot will do once installed, unknowingly as part of 107 another software installation, under false pretenses, and/or in a 108 variety of other possible ways. 110 It is important to note that there are 'good', or benign bots. Such 111 benign bots are often found in such environments such as gaming and 112 Internet Relay Chat (IRC) [RFC1459], where a continual, interactive 113 presence can be a requirement for participating in the games, 114 interacting with a computing resource. Since such benign bots are 115 performing useful, lawful, and non-disruptive functions, there is no 116 reason for a provider to monitor for their presence and/or alert 117 users to their presence. 119 Thus, while there may be benign, or harmless bots, for the purposes 120 of this document all mention of bots shall assume that the bots 121 involved are malicious or potentially malicious in nature. Such 122 malicious bots shall generally be assumed to have been deployed 123 without the permission or conscious understanding of a particular 124 Internet user. Thus, without a user's knowledge, bots may transform 125 the user's computing device into a platform from which malicious 126 activities can be conducted. In addition, included explicitly in 127 this category are potentially malicious bots, which may initially 128 appear neutral but may simply be waiting for remote instructions to 129 transform and/or otherwise begin engaging in malicious behavior. In 130 general, installation of a malicious bot without user knowledge and 131 consent is considered in most regions to be unlawful, and the 132 activities of malicious bots typically involve unlawful or other 133 maliciously disruptive activities. 135 1.2. Bot Networks, or Botnets 137 These are defined as concerted networks of bots capable of acting on 138 instructions generated remotely. The malicious activities are either 139 focused on the information on the local machine or acting to provide 140 services for remote machines. Bots are highly customizable so they 141 can be programmed to do many things. The major malicious activities 142 include but are not limited to: identity theft, spam, spim (spam over 143 instant messaging), spit (spam over Internet telephony), email 144 address harvesting, distributed denial of service (DDoS) attacks, 145 key-logging, fraudulent DNS pharming (redirection), hosting proxy 146 services, fast flux hosting, hosting of illegal content, use in man- 147 in-the-middle attacks, and click fraud. 149 Infection vectors include un-patched operating systems, software 150 vulnerabilities (which include so-called zero-day vulnerabilities 151 where no patch yet exists), weak/non-existent passwords, malicious 152 websites, un-patched browsers, malware, vulnerable helper 153 applications and social engineering techniques to gain access to the 154 user's computer. The detection and destruction of bots is an ongoing 155 issue and also a constant battle between the internet security 156 community, network security engineers and bot developers. 158 Initially, some bots used IRC to communicate but were easy to 159 shutdown if the command and control server was identified and 160 deactivated. Newer command and control methods have evolved, such 161 that those currently employed by bot masters make them much more 162 resistant to deactivation. With the introduction of P2P, HTTP and 163 other resilient communication protocols along with the widespread 164 adoption of encryption, bots are considerably more difficult to 165 identify and isolate from typical network usage. As a result 166 increased reliance is being placed on anomaly detection and 167 behavioral analysis, both locally and remotely, to identify bots. 169 1.3. Host 171 An end user's host, or computer, as used in the context of this 172 document, is intended to refer to a computing device that connects to 173 the Internet. This encompasses devices used by Internet users such 174 as personal computers, including laptops, desktops, and netbooks, as 175 well as mobile phones, smart phones, home gateway devices, and other 176 end user computing devices which are connected or can connect to the 177 public Internet and/or private IP networks. 179 Increasingly, other household systems and devices contain embedded 180 hosts which are connected to or can connect to the public Internet 181 and/or private IP networks. However, these devices may not be under 182 interactive control of the Internet user, such as may be the case 183 with various smart home and smart grid devices. 185 1.4. Malware 187 This is short for malicious software. In this case, malicious bots 188 are considered a subset of malware. Other forms of malware could 189 include viruses and other similar types of software. Internet users 190 can sometimes cause their host to be infected with malware, which may 191 include a bot or cause a bot to install itself, via inadvertently 192 accessing a specific website, downloading a file, or other 193 activities. 195 In other cases, Internet-connected hosts may become infected with 196 malware through externally initiated malicious activities such as the 197 exploitation of vulnerabilities or the brute force guessing of access 198 credentials. 200 1.5. Fast Flux 202 DNS Fast Fluxing occurs when a domain is bound in DNS using A records 203 to multiple IP addresses, each of which has a very short Time To Live 204 (TTL) value associated with it. This means that the domain resolves 205 to varying IP addresses over a short period of time. 207 DNS Fast Flux is typically used in conjunction with proxies which 208 then route the web requests to the real host which serves the data 209 being sought. The proxies are normally run on compromised user 210 hosts. The effect of this is to make the detection of the real host 211 much more difficult and to ensure that the backend or hidden site 212 remains up for as long as possible. 214 2. Introduction and Problem Statement 216 Hosts used by Internet users, which in this case are customers of an 217 Internet Service Provider (ISP), can be infected with malware which 218 may contain and/or install one or more bots on a host. They can 219 present a major problem for an ISP for a number of reasons (not to 220 mention of course the problems created for users). First, these bots 221 can be used to send spam, in some cases very large volumes of spam 222 [Spamalytics]. This spam can result in extra cost for the ISPs in 223 terms of wasted network, server, and/or personnel resources, among 224 many other potential costs and side effects. Such spam can also 225 negatively affect the reputation of the ISP, their customers, and the 226 email reputation of the IP address space used by the ISP (often 227 referred to simply as 'IP reputation'). 229 In addition, these bots can act as platforms for directing, 230 participating in, or otherwise conducting attacks on critical 231 Internet infrastructure [Threat-Report]. Bots are frequently used as 232 part of coordinated Distributed Denial of Service (DDoS) attacks for 233 criminal, political or other motivations [Gh0st] [Dragon] [DDoS]. 234 For example, bots have been used to attack Internet resources and 235 infrastructure ranging from web sites, to email servers and DNS 236 servers, as well as the critical Internet infrastructure of entire 237 countries [Estonia] [Combat-Zone]. Motivations for such coordinated 238 DDoS attacks can range from criminal extortion attempts through to 239 online protesting and nationalistic fervor [Whiz-Kid]. 241 While any computing device can be infected with bots, the majority of 242 bot infections affect the personal computers used by Internet end 243 users. As a result of the role of ISPs in providing IP connectivity, 244 among many other services, to Internet users, these ISPs are in a 245 unique position to be able to attempt to detect and observe bot nets 246 operating in their networks. Furthermore, ISPs may also be in a 247 unique position to be able to notify their customers of actual, 248 potential, or likely infection by bots or other infection. 250 From end users perspective, being notified that they may have an 251 infected computer on their network is important information. Once 252 they know this, they can take steps to remove the bots, resolve any 253 problems which may stem from the bot infection, and protect 254 themselves againts future threats. Given that bots can consume vast 255 amounts of local computing and network resources, enable theft of 256 personal information (including personal financial information), 257 enable the host to be used for criminal activities (that may result 258 in the Internet user being legally culpable), destroy or leave the 259 host in an unrecoverable state via 'kill switch' bot technologies, it 260 is important to notify the user that they may be infected with a bot. 262 As a result, the intent of this document is to provide guidance to 263 ISPs and other organizations for the remediation of hosts infected 264 with bots, so as to reduce the size of bot nets and minimize the 265 potential harm that bots can inflict upon Internet infrastructure 266 generally, as well as on individual Internet users. Efforts by ISPs 267 and other organizations can, over time, reduce the pool of hosts 268 infected with bots on the Internet, which in turn could result in 269 smaller bot nets with less capability for disruption. 271 The potential mitigation of bots is accomplished through a process of 272 detection, notification to Internet users, and remediation of bot 273 infections with a variety of tools, as described later in this 274 document. 276 3. Important Notice of Limitations and Scope 278 The techniques described in this document in no way guarantee the 279 remediation of all bots. Bot removal is potentially a task requiring 280 specialized knowledge, skills and tools, and may be beyond the 281 ability of average users. Attempts at bot removal may frequently be 282 unsuccessful, or only partially successful, leaving the user's system 283 in an unstable and unsatisfactory state or even in a state where it 284 is still infected. Attempts at bot removal can result in side 285 effects ranging from a loss of data to partial or complete loss of 286 system usability. 288 In general, the only way a user can be sure they have removed some of 289 today's increasingly sophisticated malware is by 'nuking-and-paving' 290 the system: reformatting the drive, reinstalling the operating system 291 and applications (including all patches) from scratch, and then 292 restoring user files from a known clean backup. However the 293 introduction of persistent memory based malware may mean that, in 294 some cases, this may not be enough and may prove to be more than any 295 end user can be reasonably expected to resolve [BIOS]. Experienced 296 users would have to re-flash or re-image persistent memory sections 297 or components of their hosts in order to remove persistent memory 298 based malware. However, in some cases, not even 'nuking-and-paving' 299 the system will solve the problem, which calls for hard drive 300 replacement and/or complete replacement of the host. 302 Devices with embedded operating systems, such as video gaming 303 consoles and smart home appliances, will most likely be beyond a 304 user's capability to remediate by themselves, and could therefore 305 require the aid of vendor-specific advice, updates and tools. 306 However, in some cases, such devices will have a function or switch 307 to enable the user to reset that device to a factory default 308 configuration, which may in some cases enable the user to remediate 309 the infection. Care should be taken when imparting remediation 310 advice to Internet users given the increasingly wide array of 311 computing devices that can be, or could be, infected by bots in the 312 future. 314 4. Detection of Bots 316 An ISP must first identify that an Internet user, in this case a user 317 that is assumed to be their customer or otherwise connected to the 318 ISP's network, is determined to be infected, or likely to have been 319 infected with a bot. The ISP should attempt to detect the presence 320 of bots using methods, processes, and tools which maintain the 321 privacy of the personally identifiable information (PII) of their 322 customers. The ISP should not block legitimate traffic in the course 323 of bot detection, and should instead employ detection methods, tools, 324 and processes which seek to be non-disruptive, and transparent to 325 Internet users and end-user applications. 327 Detection methods, tools, and processes may include analysis of 328 specific network and/or application traffic flows (such as traffic to 329 an email server), analysis of aggregate network and/or application 330 traffic data, data feeds received from other ISPs and organizations 331 (such as lists of the ISP's IP addresses which have been reported to 332 have sent spam), feedback from the ISP's customers or other Internet 333 users, as well as a wide variety of other possibilities. In 334 practice, it has proven effective to validate a bot infect through 335 the use of a combination of multiple bot detection data points. This 336 can help to corroborate information of varying dependability or 337 consistency, as well as to avoid or minimize the possibility of false 338 positive identification of hosts. Detection should also, where 339 possible and feasible, attempt to classify the specific bot infection 340 type in order to confirm that it is malicious in nature, estimate the 341 variety and severity of threats it may pose (such as spam bot, key- 342 logging bot, file distribution bot, etc.), and to determine potential 343 methods for eventual remediation. However, given the dynamic nature 344 of botnet management and the criminal incentives to seek quick 345 financial rewards, botnets frequently update or change their core 346 capabilities. As a consequence, botnets that are initially detected 347 and classified by the ISP as one particular type of bot need to be 348 continuously monitored and tracked in order to correctly identify the 349 threat the botnet poses at any particular point in time. 351 Detection is also time-sensitive. If complex analysis is required 352 and multiple confirmations are needed to verify a bot is indeed 353 present, then it is possible that the bot may cause some damage (to 354 either the infected host or a remotely targeted system) before it can 355 be stopped. This means that an ISP needs to balance the desire or 356 need to definitively classify and/or confirm the presence of a bot, 357 which may take an extended period of time, with the ability to 358 predict the likelihood of a bot in a very short period of time. Such 359 determinations have a relatively low false positive rate in order to 360 maintain the trust of users. This 'definitive-vs-likely' challenge 361 is difficult and, when in doubt, ISPs should err on the side of 362 caution by communicating that a bot infection has taken place. This 363 also means that Internet users may benefit from the installation of 364 client-based software on their host. This can enable rapid 365 performance of heuristically-based detection of bot activity, such as 366 the detection of a bot as it starts to communicate with other botnets 367 and execute commands. Any bot detection system should also be 368 capable of adapting, either via manual intervention or automatically, 369 in order to cope with a rapidly evolving threat. 371 As noted above, detection methods, tools, and processes should ensure 372 that privacy of customers' PII is maintained. While bot detection 373 methods, tools, and processes are similar to spam and virus defenses 374 deployed by the ISP for the benefit of their customers (and may be 375 directly related to those defenses), attempts to detect bots should 376 take into account the need of an ISP to take care to ensure any PII 377 collected or incidentally detected is properly protected. This is 378 important, as just as spam defenses may involve scanning the content 379 of email messages, which may contain PII, then so to may bot defenses 380 similarly come into incidental contact with PII. The definition of 381 PII varies from one jurisdiction to the next so proper care should be 382 taken to ensure that any actions taken comply with legislation and 383 good practice in the jurisdiction in which the PII is gathered. 384 Finally, depending upon the geographic region within which an ISP 385 operates, certain methods relating to bot detection may need to be 386 included in relevant terms of service documents or other documents 387 which are available to the customers of a particular ISP. 389 There are several bot detection methods, tools, and processes that an 390 ISP may choose to utilize, as noted in the list below. It is 391 important to note that the technical solutions available are 392 relatively immature, and are likely to change over time, evolving 393 rapidly in the coming years. While these items are described in 394 relation to ISPs, they may also be applicable to organizations 395 operating other networks, such as campus networks and enterprise 396 networks. 398 a. Where legally permissible or otherwise an industry accepted 399 practice in a particular market region, an ISP may in some manner 400 "scan" their IP space in order to detect un-patched or otherwise 401 vulnerable hosts, or to detect the signs of infection. This may 402 provide the ISP with the opportunity to easily identify Internet 403 users who appear to already be infected or are at great risk of 404 being infected with a bot. ISPs should note that some types of 405 port scanning may leave network services in a hung state or 406 render them unusable due to common frailties, and that many 407 modern firewall and host-based intrusion detection 408 implementations may alert the Internet user to the scan. As a 409 result the scan may be interpreted as a malicious attack against 410 the host. Vulnerability scanning has a higher probability of 411 leaving accessible network services and applications in a damaged 412 state and will often result in a higher probability of detection 413 by the Internet user and subsequent interpretation as a targeted 414 attack. Depending upon the vulnerability for which an ISP may be 415 scanning, some automated methods of vulnerability checking may 416 result in data being altered or created afresh on the Internet 417 user's host which can be a problem in many legal environments. 418 It should also be noted that due to the prevalence of Network 419 Address Translation devices, Port Address Translation devices, 420 and/or firewall devices in user networks, network-based 421 vulnerability scanning may be of limited value. Thus, while we 422 note that this is one technique which may be utilized, it is 423 unlikely to be particularly effective and it has problematic side 424 effects, which leads the authors to recommend against the use of 425 this particular method. 427 b. An ISP may also communicate and share selected data, via feedback 428 loops or other mechanisms, with various third parties. Feedback 429 loops are consistently formatted feeds of real-time (or nearly 430 real-time) abuse reports offered by threat data clearinghouses, 431 security alert organizations, other ISPs, and other 432 organizations. The data may include, but is not limited to, IP 433 addresses of hosts which have or are likely infected, IP 434 addresses, domain names or fully qualified domain names (FQDNs) 435 known to host malware and/or be involved in the command and 436 control of botnets, recently tested or discovered techniques for 437 detecting or remediating bot infections, new threat vectors, and 438 other relevant information. A few good examples of data sharing 439 are noted in Appendix A. 441 c. An ISP may use Netflow [RFC3954] or other similar passive network 442 monitoring to identify network anomalies that may be indicative 443 of botnet attacks or bot communications. For example, an ISP may 444 be able to identify compromised hosts by identifying traffic 445 destined to IP addresses associated with the command and control 446 of botnets, or destined to the combination of an IP address and 447 control port associated with a command and control network 448 (sometimes command and control traffic comes from a host which 449 has legitimate traffic). In addition, bots may be identified 450 when a remote host is under a DDoS attack, because hosts 451 participating in the attack will likely be infected by a bot, 452 frequently as observed at network borders (though ISPs should 453 beware of source IP address spoofing techniques to avoid or 454 confuse detection). 456 d. An ISP may use DNS-based techniques to perform detection. For 457 example, a given classified bot may be known to query a specific 458 list of domain names at specific times or on specific dates (in 459 the example of the so-called "Conficker" bot), often by matching 460 DNS queries to a well known list of domains associated with 461 malware. In many cases such lists are distributed by or shared 462 using third parties, such as threat data clearinghouses. 464 e. User complaints: Because hosts infected by bots are frequently 465 used to send spam or participate in DDoS attacks, the ISP 466 servicing those hosts will normally receive complaints about the 467 malicious network traffic. Those complaints may be sent to 468 RFC2142-specified [RFC2142] role accounts, such as abuse@, or to 469 other relevant addresses such as to abuse or security addresses 470 specified by the site as part of its WHOIS (or other) contact 471 data. 473 f. ISPs may also discover likely bot infected hosts located on other 474 networks. Thus, when legally permissible in a particular market 475 region, it may be worthwhile for ISPs to share information 476 relating to those compromised hosts with the relevant remote 477 network operator, with security researchers, and with blocklist 478 operators. 480 g. ISPs may operate or subscribe to services that provide 481 'sinkholing' or 'honeynet' capabilities. This may enable the ISP 482 to obtain near-real-time lists of bot infected hosts as they 483 attempt to join a larger botnet or propagate to other hosts on a 484 network. 486 h. ISP industry associations should examine the possibility of 487 collating statistics from ISP members in order to provide good 488 statistics about bot infections based on real ISP data. 490 i. An Intrusion Detection System(IDS) can be a useful tool to 491 actually help identify the malware. An IDS tool such as SNORT 492 (open source IDS platform) can be placed in a Walled Garden and 493 used to analyze end user traffic to confirm malware type. This 494 will help with remediation of the infected device. 496 5. Notification to Internet Users 498 Once an ISP has detected a bot, or the strong likelihood of a bot, 499 steps should be undertaken to inform the Internet user that they may 500 have a bot-related problem. Depending upon a range of factors, from 501 the technical capabilities of the ISP, to the technical attributes of 502 their network, financial considerations, available server resources, 503 available organizational resources, the number of likely infected 504 hosts detected at any given time, and the severity of any possible 505 threats, among other things, an ISP should decide the most 506 appropriate method or methods for providing notification to one or 507 more of their customers or Internet users. Such notification methods 508 may include one or more of the following, as well as other possible 509 methods not described below. 511 It is important to note that none of these methods are guaranteed to 512 be one-hundred percent successful, and that each has its own set of 513 limitations. In addition, in some cases, an ISP may determine that a 514 combination of two or more methods is most appropriate and effective, 515 and reduces the chance that malware may block a notification. As 516 such, the authors recommend the use of multiple notification methods. 517 Finally, notification is also considered time sensitive; if the user 518 does not receive or view the notification or a timely basis, then a 519 particular bot could launch an attack, exploit the user, or cause 520 other harm. If possible, an ISP should establish a preferred means 521 of communication when the subscriber first signs up for service. As 522 a part of the notification process, ISPs should maintain a record of 523 the allocation of IP addresses to subscribers for such a period as 524 allows any commonly used bot detection technology to be able to 525 accurately link an infected IP address to a subscriber. This record 526 should only be maintained for a period of time which is necessary, in 527 order to maintain the protection of the privacy of an individual 528 subscriber. 530 One important factor to bear in mind is that notification to end 531 users needs to be resistant to potential spoofing. This should be 532 done to protect, as reasonably as possible, against the potential of 533 legitimate notifications being spoofed and/or used by parties with 534 intent to perform additional malicious attacks against victims of 535 malware, or even to deliver additional malware. 537 5.1. Email Notification 539 This is a common form of notification used by ISPs. One drawback of 540 using email is that it is not guaranteed to be viewed within a 541 reasonable time frame, if at all. The user may be using a different 542 primary email address than that which they have provided to the ISP. 543 In addition, some ISPs do not provide an email account at all, as 544 part of a bundle of Internet services, and/or do not have a need for 545 or method in which to request or retain the primary email addresses 546 of Internet users of their networks. Another possibility is that the 547 user, their email client, and/or their email servers could determine 548 or classify such a notification as spam, which could delete the 549 message or otherwise file it in an email folder that the user may not 550 check on a regular and/or timely basis. Bot masters have also been 551 known to impersonate the ISP or trusted sender and send fraudulent 552 emails to the users. This technique of social engineering often 553 leads to new bot infestations. Finally if the user's email 554 credentials are compromised, then a hacker and/or a bot could simply 555 access the user's email account and delete the email before it is 556 read by the user. 558 5.2. Telephone Call Notification 560 A telephone call may be an effective means of communication in 561 particularly high-risk situations. However, telephone calls may not 562 be feasible due to the cost of making a large number of calls, as 563 measured in either time, money, organizational resources, server 564 resources, or some other means. In addition, there is no guarantee 565 that the user will answer their phone. To the extent that the 566 telephone number called by the ISP can be answered by the infected 567 computing device, the bot on that host may be able to disconnect, 568 divert, or otherwise interfere with an incoming call. Users may also 569 interpret such a telephone notification as a telemarketing call and 570 as such not welcome it, or not accept the call at all. Finally, even 571 if a representative of the ISP is able to connect with and speak to a 572 user, that user is very likely to lack the necessary technical 573 expertise to understand or be able to effectively deal with the 574 threat. 576 5.3. Postal Mail Notification 578 This form of notification is probably the least popular and effective 579 means of communication, due to both preparation time, delivery time, 580 the cost of printing and paper, and the cost of postage. 582 5.4. Walled Garden Notification 584 Placing a user in a walled garden is another approach that ISPs may 585 take to notify users. A walled garden refers to an environment that 586 controls the information and services that a subscriber is allowed to 587 utilize and what network access permissions are granted. A walled 588 garden implementation can range from strict to leaky. In a strict 589 walled garden environment access to most Internet resources are 590 typically limited by the ISP. In contrast a leaky walled garden 591 environment permits access to all Internet resources except those 592 deemed malicious or service and resources that can be used to notify 593 the users. 595 Walled gardens are effective because it is possible to notify the 596 user and simultaneously block all communication between the bot and 597 the command and control channel. While in many cases the user is 598 almost guaranteed to view the notification message and take any 599 appropriate remediation actions, this approach can pose other 600 challenges. For example, it is not always the case that a user is 601 actively using a host that uses a web browser or which has a web 602 browser actively running on it, or that uses another application 603 which uses ports which are redirected to the walled garden. In one 604 example, a user could be playing a game online, via the use of a 605 dedicated, Internet-connected game console. In another example, the 606 user may not be using a host with a web browser when they are placed 607 in the walled garden and may instead be in the course of a telephone 608 conversation, or may be expecting to receive a call, using a Voice 609 Over IP (VoIP) device of some type. As a result, the ISP may feel 610 the need to maintain a potentially lengthy white list of domains 611 which are not subject to the typical restrictions of a walled garden, 612 which could well prove to be an onerous task, from an operational 613 perspective. 615 For these reasons the implementation of a leaky walled garden makes 616 more sense but a leaky walled garden has different set of drawbacks. 617 The ISP has to assume that the user will eventually use a web browser 618 to acknowledge the notification other wise the user will remain in 619 the walled garden and not know it. If the intent of the leaky walled 620 garden is to solely notify the user about the bot infection then the 621 leaky walled garden is not ideal because notification is time 622 sensitive and the user may not receive the notification until the 623 user invokes a request for the targeted service and/or resource. 624 This means the bot can potentially do more damage. Additionally, the 625 ISP has to identify which services and/or resources to restrict for 626 the purposes of notification. This does not have to be resource 627 specific and can be time based and or policy based. For example show 628 notification for all HTTP requests every 10 minutes or show the 629 notification for one in five HTTP requests. 631 The ISP has several options to determine when to let the user out of 632 the walled garden. One approach may be to let the user determine 633 when to exit. This option is suggested when the primary purpose of 634 the walled garden is to notify users and provide information on 635 remediation only, particularly since notification is not a guarantee 636 of successful remediation. It could also be the case that, for 637 whatever reason, the user makes the judgment that they cannot then 638 take the time to remediate their host and that other online 639 activities which they would like to resume are more important. Exit 640 from the walled garden may also involve a process to verify that it 641 is indeed the user who is requesting exit from the walled garden and 642 not the bot. 644 Once the user acknowledges the notification, they may decide to 645 either remediate and exit the walled garden or to exit the walled 646 garden without remediating the issue. Another approach may be to 647 enforce a stricter policy and require the user to clean the host 648 prior to permitting the user to exit the walled garden, though this 649 may not be technically feasible depending upon the type of bot, 650 obfuscation techniques employed by a bot, and/or a range of other 651 factors. Thus, the ISP may also need to support tools to scan the 652 infected host (in the style of a virus scan, rather than a port scan) 653 and determine whether it is still infected or rely on user judgment 654 that the bot has been disabled or removed. One challenge with this 655 approach is that if the user has multiple hosts sharing a single IP 656 address, such as via a common home gateway device which performs 657 Network Address Translation (NAT). In such a case, the ISP may need 658 to determine from user feedback, or other means, that all affected 659 hosts have been remediated, which may or may not be technically 660 feasible. 662 Finally, when a walled garden is used, a list of well-known addresses 663 for both operating system vendors and security vendors should be 664 created and maintained in a white list which permits access to these 665 sites. This can be important for allowing access from the walled 666 garden by end users in search of operating system and application 667 patches. 669 5.5. Instant Message Notification 671 Instant messaging provides the ISP with a simple means to communicate 672 with the user. There are several advantages to using Instant 673 Messaging (IM) which makes it an attractive option. If the ISP 674 provides IM service and the user subscribes to it, then the user can 675 be notified easily. IM-based notification can be a cost effective 676 means to communicate with users automatically from an IM alert system 677 or via a manual process, by the ISP's support staff. Ideally, the 678 ISP should allow the user to register their IM identity in an ISP 679 account management system and grant permission to be contacted via 680 this means. If the IM service provider supports off-line messaging, 681 then the user can be notified regardless of whether they are 682 currently logged into the IM system. 684 There are several drawbacks with this communications method. There 685 is a high probability that subscriber may interpret the communication 686 to be spim, and as such ignore it. Also, not every user uses IM 687 and/or the user may not provide their IM identity to the ISP so some 688 alternative means have to be used. Even in those cases where a user 689 does have an IM address, they may not be signed onto that IM system 690 when the notification is attempted. There may be a privacy concern 691 on the part of users, when such an IM notification must be 692 transmitted over a third-party network and/or IM service. As such, 693 should this method be used, the notification should be discreet and 694 not include any PII in the notification itself. 696 5.6. Short Message Service (SMS) Notification 698 SMS allows the ISP send a brief description of the problem to notify 699 the user of the issue, typically to a mobile device such as a mobile 700 phone or smart phone. Ideally, the ISP should allow the user to 701 register their mobile number and/or SMS address in an ISP account 702 management system and grant permission to be contacted via this 703 means. The primary advantage of SMS is that users are familiar with 704 receiving text messages and are likely to read them. However, users 705 may not act on the notification immediately if they are not in front 706 of their host at the time of the SMS notification. 708 One disadvantage is that ISPs may have to follow up with an alternate 709 means of notification if not all of the necessary information maybe 710 conveyed in one message, given constraints on the number of 711 characters in an individual message (typically 140 characters). 712 Another disadvantage with SMS is the cost associated with it. The 713 ISP has to either build its own SMS gateway to interface with the 714 various wireless network service providers or use a third-party SMS 715 clearinghouse (relay) to notify users. In both cases an ISP may 716 incur fees related to SMS notifications, depending upon the method 717 used to send the notifications. An additional downside is that SMS 718 messages sent to a user may result in a charge to the user by their 719 wireless provider, depending upon the plan to which they subscribe. 720 Another minor disadvantage is that it is possible to notify the wrong 721 user if the intended user changes their mobile number but forgets to 722 update it with the ISP. 724 There are several other drawbacks with this communications method. 725 There is a high probability that subscriber may interpret the 726 communication to be spam, and as such ignore it. Also, not every 727 user uses SMS and/or the user may not provide their SMS address or 728 mobile number to the ISP. Even in those cases where a user does have 729 an SMS address or mobile number, their device may not be powered on 730 or otherwise available on a wireless network when the notification is 731 attempted. There maybe also be a privacy concern on the part of 732 users, when such an SMS notification must be transmitted over a 733 third-party network and/or SMS clearinghouse. As such, should this 734 method be used, the notification should be discreet and not include 735 any PII in the notification itself. 737 5.7. Web Browser Notification 739 Near real-time notification to the user's web browser is another 740 technique that may be utilized for notifying the user [RFC6108], 741 though how such a system might operate is outside the scope of this 742 document. Such a notification could have a comparative advantage 743 over a walled garden notification, in that it does not restrict 744 traffic to a specified list of destinations in the same way that a 745 walled garden by definition would. However, as with a walled garden 746 notification, there is no guarantee that a user is at any given time 747 making use of a web browser, though such a system could certainly 748 provide a notification when such a browser is eventually used. 749 Compared to a walled garden, a web browser notification is probably 750 preferred from the perspective of Internet users, as it does not have 751 the risk of disrupting non-web sessions, such as online games, VoIP 752 calls, etc. (as noted in Section 5.4). 754 5.8. Considerations for Notification to Public Network Locations 756 Delivering a notification to a location that provides a shared public 757 network, such as a train station, public square, coffee shop, or 758 similar location may be of low value since the users connecting to 759 such networks are typically highly transient and generally not know 760 to site or network administrators. For example, a system may detect 761 that a host on such a network has a bot, but by the time a 762 notification is generated that user has departed from the network and 763 moved elsewhere. 765 5.9. Considerations for Notification to Network Locations Using a 766 Shared IP Address 768 Delivering a notification to a location that Internet access routed 769 through one or more shared public IP addresses may be of low value 770 since it may be quite difficult to differentiate between users when 771 providing a notification. For example, on a business network of 500 772 users, all sharing one public IP address, it may be sub-optimal to 773 provide a notification to all 500 users if you only need one specific 774 user to be notified and take action. As a result, such networks may 775 find value in establishing a localized bot detection and notification 776 system, just as they are likely to also establish other localized 777 systems for security, file sharing, email, and so on. 779 However, should an ISP implement some form of notification to such 780 networks, it may be better to simply send notifications to a 781 designated network administrator at the site. In such a case the 782 local network administrator may like to receive additional 783 information in such a notification, such as a date and timestamp, the 784 source port of the infected system, and malicious sites and ports 785 that may have been visited. 787 5.10. Notification and End User Expertise 789 The ultimate effectiveness of any of the aforementioned forms of 790 notification is heavily dependent upon both the expertise of the end 791 user and the wording of any such notification. For example, while a 792 user may receive and acknowledge a notification, that user may lack 793 the necessary technical expertise to understand or be able to 794 effectively deal with the threat. As a result, it is important that 795 such notifications use clear and easily understood language, so that 796 the majority of users (who are non-technical) may understand the 797 notification. In addition, a notification should provide easily 798 understood guidance on how to remediate a threat Section 6, 799 potentially with one path for technical users to take and another for 800 non-technical users. 802 6. Remediation of Hosts Infected with a Bot 804 This section covers the different options available to remediate a 805 host, which means to remove, disable, or otherwise render a bot 806 harmless. Prior to this step, an ISP has detected the bot, notified 807 the user that one of their hosts is infected with a bot, and now may 808 provide some recommended means to clean the host. The generally 809 recommended approach is to provide the necessary tools and education 810 to the user so that they may perform bot remediation themselves, 811 particularly given the risks and difficulties inherent in attempting 812 to remove a bot. 814 For example, this may include the creation of a special web site with 815 security-oriented content that is dedicated for this purpose. This 816 should be a well-publicized security web site to which a user with a 817 bot infection can be directed to for remediation. This security web 818 site should clearly explain why the user was notified and may include 819 an explanation of what bots are, and the threats that they pose. 820 There should be a clear explanation of the steps that the user should 821 take in order to attempt to clean their host and provide information 822 on how users can keep the host free of future infections. The 823 security web site should also have a guided process that takes non- 824 technical users through the remediation process, on an easily 825 understood, step-by-step basis. 827 In terms of the text used to explain what bots are and the threats 828 that they pose, something simple such as this may suffice: 830 "What is a bot? A bot is a piece of software, generally 831 installed on your machine without your knowledge, which either 832 sends spam or tries to steal your personal information. They 833 can be very difficult to spot, though you may have noticed that 834 your computer is running much more slowly than usual or you 835 notice regular disk activity even when you are not doing 836 anything. Ignoring this problem is risky to you and your 837 personal information. Thus, bots need to be removed to protect 838 your data and your personal information." 840 It is also important to note that it may not be immediately apparent 841 to the Internet user precisely which devices have been infected with 842 a particular bot. This may be due to the user's home network 843 configuration, which may encompass several hosts, where a home 844 gateway which performs Network Address Translation (NAT) to share a 845 single public IP address has been used. Therefore, any of these 846 devices can be infected with a bot. The consequence of this for an 847 ISP is that remediation advice may not ultimately be immediately 848 actionable by the Internet user, as that user may need to perform 849 additional investigation within their own home network. 851 An added complication is that the user may have a bot infection on a 852 device such as a video console, multimedia system, appliance, or 853 other end-user computing device which does not have a typical Windows 854 or Macintosh user interface. As a result, diligence needs to be 855 taken by the ISP where possible such that they can identify and 856 communicate the specific nature of the device that has been infected 857 with a bot, and further providing appropriate remediation advice. 859 There are a number of forums that exist online to provide security 860 related support to end users. These forums are staffed by volunteers 861 and often are focussed around the use of a common tool set to help 862 end users to remediate hosts infected with malware. It may be 863 advantageous to ISPs to foster a relationship with one or more 864 forums, perhaps by offering free hosting or other forms of 865 sponsorship. 867 It is also important to keep in mind that not all users will be 868 technically adept Section 5.10. As a result, it may be more 869 effective to provide a range of suggestion options for remediation. 870 This may include for example a very detailed "do it yourself" 871 approach for experts, a simpler guided process for the average user, 872 and even assisted remediation Section 6.2. 874 6.1. Guided Remediation Process 876 Minimally the Guided Remediation Process should include options 877 and/or recommendations on how a user should: 879 1. Backup personal files. For example: "Before you start, make sure 880 to back up all of your important data. (You should do this on a 881 regular basis anyway.) You can back up your files manually or 882 using a system back-up software utility, which may be part of 883 your Operating System (OS). You can back your files up to a USB 884 Thumb Drive (aka USB Key), a writeable CD/DVD-ROM, an external 885 hard drive, a network file server, or an Internet-based backup 886 service." 888 2. Download OS patches and Anti-Virus (A/V) software updates. For 889 example, links could be provided to Microsoft Windows updates as 890 well as to Apple MacOS updates, or to other major operating 891 systems which are relevant to users and their devices. 893 3. Explain how to configure the host to automatically install 894 updates for the OS, A/V and other common Web Browsers such as 895 Microsoft Internet Explorer, Mozilla Firefox, Apple Safari, 896 Opera, and Google Chrome. 898 4. The flow should also have the option for users to get 899 professional assistance if they are unable to remove the bots 900 themselves. If purchasing professional assistance, then the user 901 should be encouraged to pre-determine how much they are willing 902 to pay for that help. If the host that is being remediated is 903 old and can easily be replaced with a new, faster, larger and 904 more reliable system for a certain cost, the it makes no sense to 905 spend more than that cost to fix the old host, for example. On 906 the other hand, if the customer has a brand new host, it might 907 make perfect sense to spend the money to attempt to remediate it. 909 5. To continue, regardless of whether the user or a knowledgeable 910 technical assistant is working on remediating the host, their 911 first task should be to determine which of multiple potentially- 912 infected machines may be the one that needs attention (in the 913 common case of multiple hosts in a home network). Sometimes, as 914 in cases where there is only a single directly-attached host, or 915 the user has been noticing problems with one of their hosts, this 916 can be easy. Other times, it may be more difficult especially if 917 there are no clues as to which host is infected. If the user is 918 behind a home gateway/router, then the first task may be to 919 ascertain which of the machines is infected. In some cases the 920 user may have to check all machines to identify the infected one. 922 6. User surveys to solicit feedback on whether the notification and 923 remediation process is effective and what recommended changes 924 could be made in order to improve the ease, understandability, 925 and effectiveness the remediation process. 927 7. If the user is interested in reporting his or her host's bot 928 infection to an applicable law enforcement authority, then the 929 host effectively becomes a cyber "crime scene" and should not be 930 mitigated unless or until law enforcement has collected the 931 necessary evidence. For individuals in this situation, the ISP 932 may wish to provide links to local, state, federal, or other 933 relevant computer crime offices. (Note: Some "minor" incidents, 934 even if highly traumatic to the user, may not be sufficiently 935 serious for law enforcement to commit some of their limited 936 resources to an investigation.) In addition, individual regions 937 may have other, specialized computer crime organizations to which 938 these incidents can be reported. For example, in the United 939 States, that organization is the Internet Crime Complaint Center, 940 at http://www.ic3.gov. 942 8. Users may also be interested in links to security expert forums, 943 where other users can assist them. 945 6.2. Professionally-Assisted Remediation Process 947 It should be acknowledged that, based on the current state of 948 remediation tools and the technical abilities of end users, that many 949 users may be unable to remediate on their own. As a result, it is 950 recommended that users have the option for professional assistance. 951 This may entail online or telephone assistance for remediation, as 952 well as working face to face with a professional who has training and 953 expertise in the removal of malware. 955 7. Failure or Refusal to Remediate 957 ISP systems should track the bot infection history of hosts in order 958 to detect when users consistently fail to remediate or refuse to take 959 any steps to remediate. In such cases, ISPs may need to consider 960 taking additional steps to protect their network, other users and 961 hosts on that network, and other networks. Such steps may include a 962 progression of actions up to and including account termination. 964 8. Sharing of Data from the User to the ISP 966 As an additional consideration, it may be useful to create a process 967 by which users could choose, at their option and with their express 968 consent, to share data regarding their bot infection with their ISP 969 and/or another authorized third party. Such third parties may 970 include governmental entities that aggregate threat data, such as the 971 Internet Crime Complaint Center referred to earlier in this document, 972 to academic institutions, and/or security researchers. While in many 973 cases the information shared with the user's ISP or designated third 974 parties will only be used for aggregated statistical analysis, it is 975 also possible that certain research needs may be best met with more 976 detailed data. Thus, any such data sharing from a user to the ISP or 977 authorized third party may contain some type of personally 978 identifiable information, either by design or inadvertently. As a 979 result, any such data sharing should be enabled on an opt-in based, 980 where users review and approve of the data being shared and the 981 parties with which it is to be shared, unless the ISP is already 982 required to share such data in order to comply with local laws and in 983 accordance with those laws and applicable regulations. 985 9. Security Considerations 987 This document describes in detail the numerous security risks and 988 concerns relating to bot nets. As such, it has been appropriate to 989 include specific information about security in each section above. 990 This document describes the security risks related to malicious bot 991 infections themselves, such as enabling identity theft, theft of 992 authentication credentials, and the use of a host to unwittingly 993 participate in a DDoS attack, among many other risks. Finally, the 994 document also describes security risks which may relate to the 995 particular methods of communicating a notification to Internet users. 996 Bot networks and bot infections pose extremely serious security risks 997 and any reader should review this document carefully. 999 In addition, regarding notifications, as described in Section 5, care 1000 should be taken to assure users that notifications have been provided 1001 by a trustworthy site and/or party, so that the notification is more 1002 difficult for phishers and/or malicious parties using social 1003 engineering tactics to mimic, or that the user has some level of 1004 trust that the notification is valid, and/or that the user has some 1005 way to verify via some other mechanism or step that the notification 1006 is valid. 1008 10. Privacy Considerations 1010 This document describes at a high level the activities that ISPs 1011 should be sensitive to, where the collection or communication of PII 1012 may be possible. In addition, when performing notifications to end 1013 users Section 5, those notifications should not include PII. 1015 As noted in Section 8, any sharing of data from the user to the ISP 1016 and/or authorized third parties should be done on an opt-in basis. 1017 Additionally the ISP and or authorized third parties should clearly 1018 state what data will be shared and with whom the data will be shared 1019 with. 1021 Lastly, as noted in some other sections, there my be legal 1022 requirements in particular legal jurisdictions concerning how long 1023 any subscriber-related or other data is retained, of which an ISP 1024 operating in such a jurisdiction should be aware and with which an 1025 ISP should comply. 1027 11. IANA Considerations 1029 There are no IANA considerations in this document. 1031 12. Acknowledgements 1033 The authors wish to acknowledge the following individuals and groups 1034 for performing a detailed review of this document and/or providing 1035 comments and feedback that helped to improve and evolve this 1036 document: 1038 Mark Baugher 1040 Richard Bennett 1042 James Butler 1043 Vint Cerf 1045 Alissa Cooper 1047 Jonathan Curtis 1049 Jeff Chan 1051 Roland Dobbins 1053 Dave Farber 1055 Eliot Gillum 1057 Joel Halpern 1059 Joel Jaeggli 1061 Scott Keoseyan 1063 The Messaging Anti-Abuse Working Group (MAAWG) 1065 Jose Nazario 1067 Gunter Ollmann 1069 David Reed 1071 Roger Safian 1073 Donald Smith 1075 Joe Stewart 1077 Forrest Swick 1079 Sean Turner 1081 Robb Topolski 1083 Eric Ziegast 1085 13. Informative references 1087 [BIOS] Sacco, A. and A. Ortega, "Persistent BIOS Infection", 1088 March 2009, . 1091 [Combat-Zone] 1092 Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon 1093 of Electronic Jihad", February 2007, . 1096 [DDoS] Saafan, A., "Distributed Denial of Service Attacks: 1097 Explanation, Classification and Suggested Solutions", 1098 March 2009, . 1100 [Dragon] Nagaraja, S. and R. Anderson, "The snooping dragon: 1101 social-malware surveillance of the Tibetan movement", 1102 March 2009, 1103 . 1105 [Estonia] Evron, G., "Battling Botnets and Online Mobs: Estonia's 1106 Defense Efforts during the Internet War", May 2005, . 1112 [Gh0st] Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st 1113 in the Shell: Network Security in the Himalayas", 1114 February 2010, . 1117 [RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", 1118 RFC 1459, May 1993. 1120 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 1121 FUNCTIONS", RFC 2142, May 1997. 1123 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 1124 9", RFC 3954, October 2004. 1126 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 1127 Van Lieu, "Comcast's Web Notification System Design", 1128 RFC 6108, February 2011. 1130 [Spamalytics] 1131 Kanich, C., Kreibich, C., Levchenko, K., Enright, B., 1132 Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An 1133 Empirical Analysis of Spam Marketing Conversion", 1134 October 2008, . 1137 [Threat-Report] 1138 Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G., 1139 Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G., 1140 Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber 1141 Threats Report for 2009: Data, Mobility and Questions of 1142 Responsibility will Drive Cyber Threats in 2009 and 1143 Beyond", October 2008, . 1146 [Whiz-Kid] 1147 Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid 1148 Took On a DDOS-based Online Extortion Attack", May 2005, < 1149 http://www.csoonline.com/article/220336/ 1150 How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online 1151 _Extortion_Attack>. 1153 Appendix A. Examples of Third Party Malware Lists 1155 As noted in Section 4, there are many potential third parties which 1156 may be willing to share lists of infected hosts. This list is for 1157 example purposes only, is not intended to be either exclusive or 1158 exhaustive, and is subject to change over time. 1160 o Arbor - Atlas, see http://atlas.arbor.net/ 1162 o Internet Systems Consortium - Secure Information Exchange (SIE), 1163 see https://sie.isc.org/ 1165 o Microsoft - Smart Network Data Services (SNDS), see 1166 https://postmaster.live.com/snds/ 1168 o SANS Institute / Internet Storm Center - DShield Distributed 1169 Intrusion Detection System, see http://www.dshield.org/about.html 1171 o ShadowServer Foundation, see http://www.shadowserver.org/ 1173 o Spamhaus - Policy Block List (PBL), see 1174 http://www.spamhaus.org/pbl/ 1176 o Spamhaus - Exploits Block List (XBL), see 1177 http://www.spamhaus.org/xbl/ 1179 o Team Cymru - Community Services, see http://www.team-cymru.org/ 1181 Appendix B. Document Change Log 1183 [RFC Editor: This section is to be removed before publication] 1184 -12 version: 1186 o Shortened reference names (non-RFC references) 1188 o Closed Open Issue #1 and #4, as leaky walled gardens are covered 1189 in Section 5.4 1191 o Closed Open Issue #2 and #6, by adding a section on users that 1192 fail to mitigate, including account termination 1194 o Closed Open Issue #3, by adding a Privacy Considerations section 1195 to address PII 1197 o Closed Open Issue #5, with no action taken 1199 o Closed Open Issue #7, by leaving as Informational (the IETF can 1200 assess this later) 1202 o Closed Open Issue #8, by generalizing the guided remediation 1203 section via the removal of specific links, etc. 1205 o Closed Open Issue #9, by reviewing and updating remediation steps 1207 o Changed some 'must' statements to 'should' statements (even though 1208 there is not RFC 2119 language in the document) 1210 o ALL open issues are now closed! 1212 -11 version: 1214 o Added reference to RFC 6108 1216 o Per Sean Turner, removed RFC 2119 reference and section 1218 o Per Donald Smith, externalized the reference to 3rd party data 1219 sources, now Appendix A 1221 o Per Donald Smith, moved basic notification challenges into a new 1222 section at the end of the Notifications section. 1224 -10 version: 1226 o Minor refresh to keep doc from expiring. Several large updates 1227 planned in a Dec/Jan revision 1229 -09 version: 1231 o Corrected nits pointed out by Sean 1233 o Removed occurrences of double spacing 1235 o Grammar and spelling corrections in many sections 1237 o Added text for leaky walled garden 1239 -08 version: 1241 o Corrected a reference error in Section 10. 1243 o Added a new informative reference 1245 o Change to Section 5.a., to note additional port scanning 1246 limitations 1248 o Per Joel Jaeggli, change computer to host, to conform to IETF 1249 document norms 1251 o Several other changes suggested by Joel Jaeggli and Donald Smith 1252 on the OPSEC mailing list 1254 o Incorp. other feedback received privately 1256 o Because Jason is so very dedicated, he worked on this revision 1257 while on vacation ;-) 1259 -07 version: 1261 o Corrected various spelling and grammatical errors, pointed out by 1262 additional reviewers. Also added a section on information flowing 1263 from the user. Lastly, updated the reviewer list to include all 1264 those who either were kind enough to review for us or who provided 1265 interesting, insightful, and/or helpful feedback. 1267 -06 version: 1269 o Corrected an error in the version change log, and added some extra 1270 information on user remediation. Also added an informational 1271 reference to BIOS infection. 1273 -05 version: 1275 o Minor tweaks made by Jason - ready for wider review and next 1276 steps. Also cleared open issues. Lastly, added 2nd paragraph to 1277 security section and added sections on limitations relating to 1278 public and other shared network sites. Added a new section on 1279 professional remediation. 1281 -04 version: 1283 o Updated reference to BIOS based malware, added wording on PII and 1284 local jurisdictions, added suggestion that industry body produce 1285 bot stats, added suggestion that ISPs use volunteer forums 1287 -03 version: 1289 o all updates from Jason - now ready for wider external review 1291 -02 version: 1293 o all updates from Jason - still some open issues but we're now at a 1294 place where we can solicit more external feedback 1296 -01 version: 1298 o -01 version published 1300 Appendix C. Open Issues 1302 [RFC Editor: This section is to be removed before publication] 1304 per Donald, inclusion of PII is a good general stmt to consider for 1305 an opening section in the notification part of the doc: As such, 1306 should this method be used, the notification should be discreet and 1307 not include any PII in the notification itself. 1309 per Donald, do we want to consider adding a 'leaky' WG? 'Or design a 1310 leaky walled garden that allows most traffic without interference 1311 only redirecting the traffic needed to mitigate or notify.' 1313 Address suggestion from Donald Smith: The risks to users of infected 1314 systems and others are included/defined in many places within this 1315 document. It should probably be defined clearly in one place and 1316 referenced in all other places. 1318 per Roger - ponder acct termination 1320 A question has been raised about whether this should change from 1321 Informational to BCP. 1323 Guided remediation -- these urls while provided for the purpose of 1324 examples are unlikely to be stable on any kind of long timescale. 1325 fundamentally updating os software addresses vulnerability not 1326 remediation (windows malicious software removal tool notwithstanding) 1328 Guided remediation, bullets 4 - 7 -- It's unclear how these steps are 1329 even feasible to undertake for organizations nominally characterized 1330 as ISPs. there's a several thousand fold cost differential between 1331 automated help and remediation by sending a train professional to lay 1332 hands on one computer. 1334 Authors' Addresses 1336 Jason Livingood 1337 Comcast Cable Communications 1338 One Comcast Center 1339 1701 John F. Kennedy Boulevard 1340 Philadelphia, PA 19103 1341 US 1343 Email: jason_livingood@cable.comcast.com 1344 URI: http://www.comcast.com 1346 Nirmal Mody 1347 Comcast Cable Communications 1348 One Comcast Center 1349 1701 John F. Kennedy Boulevard 1350 Philadelphia, PA 19103 1351 US 1353 Email: nirmal_mody@cable.comcast.com 1354 URI: http://www.comcast.com 1356 Mike O'Reirdan 1357 Comcast Cable Communications 1358 One Comcast Center 1359 1701 John F. Kennedy Boulevard 1360 Philadelphia, PA 19103 1361 US 1363 Email: michael_oreirdan@cable.comcast.com 1364 URI: http://www.comcast.com