Re: [OPSEC] Fwd: Last Call for Comments: draft-oreirdan-mody-bot-remediation-06

["Smith, Donald" <[e-mail]>]

First I agree with most of Joel's comments.
2nd original text of this draft are marked with >
My comments are not.

I have numerous comments and corrections below.
Some attempt to fix grammar or make some of the statements more concise or stronger.

Others are comments or questions about the text itself.

Fixes I put directly under the line they are intended to address.

Comments have at least one line from a fix or last section I am attempting to address.

I believe most of your aware that qwest has been doing several types of automated infected customer notifications for a long time now so I have a bit of experience in this area.

>
>
> Internet Engineering Task Force                             J. Livingood
> Internet-Draft                                                   N. Mody
> Intended status: Informational                              M. O'Reirdan
> Expires: August 16, 2010                                         Comcast
>                                                        February 12, 2010
>
>
>       Recommendations for the Remediation of Bots in ISP Networks
>                  draft-oreirdan-mody-bot-remediation-07
>
> Abstract
>
>    This document contains recommendations on how Internet Service
>    Providers can manage the effects of computers used by their
* subscribers, which have been infected with malicious bots, via
A bot is a tool. It can't really be malicious nor benign any more that a gun, or screwdriver is malicious however I understand as this is widely used, incorrectly, within the industry. But malicious implies intent to do harm.
As long as that is addressed in the malicious bot/bot definition it's probably acceptable to use it in this way.
>    various remediation techniques.  Internet users with infected
>    computers are exposed to risks such as loss of personal data, as well
>    as increased susceptibility to online fraud and/or phishing.  Such
>    computers can also become an inadvertent participant in or component
>    of an online crime network, spam network, and/or phishing network, as
>    well as be used as a part of a distributed denial of service attack.
The risks to users of infected systems and others are included/defined in many places within this document.
It should probably be defined clearly in one place and referenced in all other places.
>    Mitigating the effects of and remediating the installations of
>    malicious bots will make it more difficult for botnets to operate and
>    could reduce the level of online crime on the Internet in general
>    and/or on a particular Internet Service Provider's network.
>
> Status of this Memo
>
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on August 16, 2010.
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 1]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
> Copyright Notice
>
>    Copyright (c) 2010 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the BSD License.
>
>    This document may contain material from IETF Documents or IETF
>    Contributions published or made publicly available before November
>    10, 2008.  The person(s) controlling the copyright in some of this
>    material may not have granted the IETF Trust the right to allow
>    modifications of such material outside the IETF Standards Process.
>    Without obtaining an adequate license from the person(s) controlling
>    the copyright in such materials, this document may not be modified
>    outside the IETF Standards Process, and derivative works of it may
>    not be created outside the IETF Standards Process, except to format
>    it for publication as an RFC or to translate it into languages other
>    than English.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 2]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
> Table of Contents
>
>    1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
>    2.  Key Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
>    3.  Introduction and Problem Statement . . . . . . . . . . . . . .  6
>    4.  Important Notice of Limitations and Scope  . . . . . . . . . .  7
>    5.  Detection of Bots  . . . . . . . . . . . . . . . . . . . . . .  8
>    6.  Notification to Internet Users . . . . . . . . . . . . . . . . 12
>    7.  Remediation of Computers Infected with a Bot . . . . . . . . . 17
>    8.  Guided Remediation Process . . . . . . . . . . . . . . . . . . 18
>    9.  Professionally-Assisted Remediation Process  . . . . . . . . . 20
>    10. Sharing of Data from the User to the ISP . . . . . . . . . . . 20
>    11. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
>    12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
>    13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
>    14. Informative references . . . . . . . . . . . . . . . . . . . . 22
>    Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 24
>    Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 25
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 3]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
> 1.  Requirements Language
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>
> 2.  Key Terminology
>
>    This section defines the key terms used in this document.
>
> 2.1.  Malicious Bots, or Bots
>
>    A malicious "bot" (derived from the word "robot", hereafter simply
Malicious bot implies intent to do harm, while these are really bots that can be used to perform potentially harmful tasks for the bot master. Perhaps potentially harmful bot?
>    referred to as a "bot") refers to a program that is surreptitiously
Some times they are installed on purpose but the user doesn't understand the full functionality of the software installed or the amount of remote control the application provides to the remote controller (bot master)

>    installed on a system in order to enable that system to automatically
>    (or semi-automatically) perform a task or set of tasks typically
Isn't always automatically? I am not sure you need the semi-automatically part.
>    under the command and control of a remote administrator, or "bot
>    master."  Bots are also known as "zombies".
>
>    It is important to note that there are 'good', or benign bots.  Such
>    benign bots are often found in such environments such as gaming and
>    Internet Relay Chat (IRC) [RFC1459], where a continual, interactive
>    presence can be a requirement for participating in the games,
>    interacting with a computing resource, or other purposes.  Since such
>    benign bots are performing useful, lawful, and non-disruptive
>    functions, there is no reason for a provider to monitor for their
>    presence and/or alert users to their presence.
Again Benign implies intent. Perhaps harmless instead?
>
>    Thus, while there may be benign bots, for the purposes of this
>    document all mention of bots shall assume that the bots involved are
>    malicious in nature.  Such malicious bots shall generally be assumed
>    to have been deployed without the permission or conscious
>    understanding of a particular Internet user.  Thus, without a user's
>    knowledge, bots may transform the user's computing device into a
>    platform from which malicious activities can be conducted.  In
>    general, installation of a malicious bot without user knowledge and
>    consent is considered in most regions to be unlawful, and the
>    activities of malicious bots typically involve unlawful or other
>    maliciously disruptive activities.
>
> 2.2.  Bot Networks, or Botnets
>
>    These are defined as concerted networks of bots capable of acting on
>    instructions generated remotely.  The malicious activities are either
>    focused on the information on the local machine or acting to provide
>    services for remote machines.  Bots are highly customizable so they
>        can be programmed to do many things.
Binary based bots aren't usually highly customizable. The source code for bot programs is frequently publicly available therefore customizing or adding a new feature isn't difficult for someone with programming abilities.
>The major malicious activities
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 4]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    include: identity theft, spam, distributed denial of service (DDoS)
>    attacks, key-logging, fraudulent DNS (pharming), proxy services, fast
* flux hosting and click fraud.
This is a pretty good risk identification. You might want to add spim, spit, email address harvesting, hosting of highly questionable or illegal content (BulletProof hosting), various MITM attacks (banking ssl ala Zeus) and web site scraping.
>
>    Infection vectors include un-patched operating systems, software
>    vulnerabilities, weak/non-existent passwords, malicious websites, un-
>    patched browsers, malware, vulnerable helper applications and social
>        engineering techniques to gain access to the user's computer.
The use of vulnerable and un-patched seems slightly redundant.
An un-patched piece of software is likely to be vulnerable.
I think your trying to cover the concept of un-patched vs zero day (no patch publicly available) exploitation.
>        The detection and destruction of bots is an ongoing issue and also a
>    constant battle between the internet security community, network
>    security engineers and bot developers.
>
>         Initially, bots used IRC to communicate but were easy to shutdown if
Initally SOME bots used IRC, Q, TFN, Trinoo, etc... all had non-IRC based control.
>    the command and control server was identified and deactivated.  Newer
>    command and control methods have evolved, such that those currently
>    employed by bot masters make them much more resistant to
>    deactivation.  With the introduction of P2P, HTTP and other resilient
>    communication protocols along with the widespread adoption of
>    encryption, bots are considerably more difficult to identify and
>    isolate from typical network usage.  As a result increased reliance
>    is being placed on anomaly detection and behavioral analysis, both
>    locally and remotely, to identify bots.
>
> 2.3.  Computer
>
>    A computer, as used in the context of this document, is intended to
>    refer to a computing device that connects to the Internet.  This
>    encompasses devices used by Internet users such as personal
>    computers, including laptops, desktops, and netbooks, as well as
>    mobile phones, smart phones, home gateway devices, and other end user
>    computing devices which are connected or can connect to the public
>    Internet and/or private IP networks.
>
>    Increasingly, other household systems and devices contain embedded
>    computers which are connected to or can connect to the public
>    Internet and/or private IP networks.  However, these devices may not
>    be under interactive control of the Internet user, such as may be the
>    case with various smart home and smart grid devices.
So do you intend for your computer definition to include smart ip enabled  devices or not. It's hard to tell from this definitation.
I would limit the definition to computers that humans use as general purpose computers.
>
> 2.4.  Malware
>
>    This is short for malicious software.  In this case, malicious bots
>    are considered a subset of malware.  Other forms of malware could
>    include viruses and other similar types of software.  Internet users
>    can sometimes cause their computer to be infected with malware, which
>    may include a bot or cause a bot to install itself, via inadvertently
>    accessing a specific website, downloading a specific file, or other
a website, downloading a file ...
>    activities.
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 5]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    Alternatively, Internet-connected computers may become infected with
Not really alternatively, since you mention vulnerabilities above but I think your trying to say without user interaction (scan and spolit) right?
>    malware through externally initiated malicious activities such as the
>    exploitation of vulnerabilities or the brute force guessing of access
>    credentials.
Again risk defined.
This one is pretty good and maybe the right place to define the risk but it should probably only be defined in detail in one spot.
>
> 2.5.  Fast Flux
>
>    DNS Fast Fluxing occurs when a domain is bound in DNS using A records
>    to multiple IP addresses, each of which has a very short Time To Live
>    (TTL) value associated with it.  This means that the domain resolves
>    to varying IP addresses over a short period of time.
>
>    DNS Fast Flux is typically used in conjunction with proxies which
>    then route the web requests to the real host which serves the data
>    being sought.  The proxies are normally hosted on compromised user
>    computers.  The effect of this is to make the detection of the real
>    host for a piece of content much more difficult and to ensure that
>    the site remains up for as long as possible.
The backend/hidden site
>
>
> 3.  Introduction and Problem Statement
>
>    Computers used by Internet users, which in this case are customers of
>    an Internet Service Provider (ISP), can be infected with malware
>    which may contain and/or install one or more bots on a computer.
>    This can present a major problem for an ISP for a number of reasons
>    (not to mention of course the problems created for users).  First,
mentioning users here seems out of place plus you mention them so I would either remove or rephrase.
The can present a major problem for an ISP and their users ...
>    these bots can be used to send spam, in some cases very large volumes
>    of spam [Spamalytics: An Empirical Analysis of Spam Marketing
>    Conversion].  This spam can result in extra cost for the ISPs in
>    terms of wasted network, server, and/or personnel resources, among
>    many other potential costs and side effects.  Such spam can also
>    negatively affect the reputation of the ISP, their customers, and the
>    email reputation of the IP address space used by the ISP (often
>    referred to simply as 'IP reputation').
Again risk defined but given that these are risks to the ISP that may be appropriate as long as its defined one time and referenced in other places.
>
>    In addition, these bots can act as platforms for directing,
>    participating in, or otherwise conducting attacks on critical
>    Internet infrastructure [Emerging Cyber Threats Report for 2009:
>    Data, Mobility and Questions of Responsibility will Drive Cyber
>    Threats in 2009 and Beyond].  Bots are frequently used as part of
>    concerted Distributed Denial of Service (DDoS) attacks for criminal,
coordinated
>    political or other motivations [The Gh0st in the Shell: Network
>    Security in the Himalayas] [The snooping dragon: social-malware
>    surveillance of the Tibetan movement].  For example, bots have been
>    used to attack Internet resources and infrastructure ranging from web
>    sites, to email servers and DNS servers, as well as the critical
>    Internet infrastructure of entire countries [Battling Botnets and
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 6]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    Online Mobs: Estonia's Defense Efforts during the Internet War]
>    [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad].
>    Motivations for such coordinated DDoS attacks can range from criminal
>    extortion attempts through to online protesting and nationalistic
>    fervor [Case Study: How a Bookmaker and a Whiz Kid Took On a
>    DDOS-based Online Extortion Attack].
>
>    While any computing device can be infected with bots, the majority of
>    bot infections affect the personal computers used by Internet end
>    users.  As a result of the role of ISPs in providing IP connectivity,
>    among many other services, to Internet users, these ISPs are in a
>    unique position to be able to attempt to detect and observe bot nets
>    operating in their networks.  Furthermore, ISPs may also be in a
>    unique position to be able to communicate to Internet users which are
unique position to be able to notify their customers of potential infection by
bots or other infections.
>    their customers, when customers' computers may have been determined
>    to have been or possibly have been infected with one or more bots.
>
>    From an end user perspective, knowing that their computer has been
>From an end user perspective, being notified that they may have an infected computer on their network is important information.
>    infected with one or more bots is very important information.  Once
>    they know this, they can take steps to remove the bot, protect
>    themselves in the future, and resolve any problems which may stem
>    from the bot infection.  Given that bots can drain local computing
Given that bots can consume vast amounts of local computing and network resources ...
>    and network resources, enable theft of personal information
>    (including personal financial information), enable the computer to be
>    used from criminal activities (that may result in the Internet user
>    being legally culpable), destroy or leave the PC in an unrecoverable
>    state via 'kill switch' bot technologies, it is important to notify
>    the user that they may be infected with a bot.
I haven't really seen a case where the "kill switch" was triggered by attempts to remediate an infection.
Additionally your redefining the risk here again.
>
>    As a result, the intent of this document is to provide a guide to
The intent of this document is to provide guidence to ISPs...
>    ISPs and other organizations for the remediation of these computers
>    infected with bots, so as to reduce the size of bot nets and minimize
remediation of bot infected computers ...
>    the potential harm that bots can inflict upon Internet infrastructure
>    generally, as well as on individual Internet users.  Efforts by ISPs
>    and other organizations could therefore, over time, reduce the pool
and other organizations can over time reduce the pool of ...
>    of computers infected with bots on the Internet, which in turn could
>    result in smaller bot nets with less capability for disruption.
>
>    The potential mitigation of bots is accomplished through a process of
>    detection, notification to Internet users, and remediation of that
>    bot with a variety of tools, as described later in this document.
bot infections with a variety ...
>
>
> 4.  Important Notice of Limitations and Scope
>
>    The techniques described in this document in no way guarantee the
>    remediation of all bots.  Bot removal is potentially a task requiring
>    specialized knowledge, skills and tools, and may be beyond the
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 7]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    ability of average users.  Attempts at bot removal may frequently be
>    unsuccessful, or only partially successful, and may leave a user's
unsuccessful or only partially successful leaving the system ...
>    system in an unstable and unsatisfactory state or even in a state
>    where it is still infected.  Attempts at bot removal can also result
>    in side effects ranging from a loss of data or other files, all the
>    way through partial or complete loss of system usability.
Attempts at bot removal can result in side effects from a loss of data to partial or complete loss of system usablility.
>
>    In general, the only way a user can be sure they have removed some of
>    today's increasingly sophisticated malware is by 'nuking-and-paving'
>    the system: reformatting the drive, reinstalling the operating system
>    and applications (including all patches) from scratch, and then
>    restoring user files from a clean backup.  However the introduction
restoring user files from a known clean backup...
>    of BIOS-based malware may mean that, in some cases, this will not be
of persistent memory based malware may meant that, in some cases, this may not be ...
>    enough and may prove to be more than any end user can be reasonably
>    expected to resolve [Persistent BIOS Infection].  Experienced users
Persistent memory infections.

>    would have to re-flash BIOS in their machines in order to remove
>    BIOS-based malware.  However, in some cases, not even 'nuking-and-
would have to re-flash or re-image persistent memory sections on their machines in order ...
>    paving' the system will solve the problem, which calls for hard drive
>    and/or complete computer replacement.
>
>    Devices with embedded operating systems, such as video gaming
>    consoles and smart home appliances, will most likely be beyond a
>    user's capability to remediate by themselves, and will typically
>    require the aid of vendor-specific advice, updates and tools.  Care
>    must be taken when imparting remediation advice to Internet users
>    given the increasingly wide array of computing devices that can be,
>    or could be, infected by bots in the future.
Many such devices have a "reset to factory defaults" switch which will be the main method to clear such devices if infected.
>
>
> 5.  Detection of Bots
>
>    An ISP must first identify that an Internet user, in this case a user
>    that is assumed to be their customer or otherwise connected to the
>    ISP's network, is determined to be infected, or likely to have been
>    infected with a bot.  The ISP must attempt to detect the presence of
>    bots using methods, processes, and tools which maintain the privacy
>    of the personally identifiable information (PII) of their customers.
>    The ISP also must not block legitimate traffic in the course of bot
>    detection, and must instead employ detection methods, tools, and
>    processes which seek to be non-disruptive, as well as being
>    transparent to Internet users and end-user applications.
You can't be totally transparent nor completely non-disruptive.
Nothing can be observed without affecting what your observing.
Perhaps rewrite with the concept of MINUMIZING such effects?
>
>    Detection methods, tools, and processes may include things such as
may include analysis of specific ...
>    analysis of specific network and/or application traffic flows (such
>    as traffic to an email server), analysis of aggregate network and/or
>    application traffic data, data feeds received from other ISPs and
>    organizations (such as lists of the ISP's IP addresses which have
>    been reported to have sent spam), feedback from the ISP's customers
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 8]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    or other Internet users, as well as a wide variety of other
>    possibilities.  It is likely that a combination of multiple bot
In order to validate any bot net detection source a combination of multiple bot
detection sources has proven to be an effective approach ...
>    detection data points will prove to be an effective approach in order
>    to corroborate information of varying dependability or consistency,
>    as well as to avoid or minimize the possibility of false positive
>    identification of computers.  Detection should also, where possible
>    and feasible, attempt to classify a bot in order to confirm that it
to classify the specific bot infection type in order to ...
>    is malicious in nature, estimate the variety and severity of threats
>    it may pose (such as spam bot, key-logging bot, file distribution
>    bot, etc.), and to determine potential methods for eventual
>    remediation.  However, given the dynamic nature of botnet management
>    and the criminal incentives to seek quick financial rewards, botnets
>    frequently update or change their core malicious capabilities.  As a
>    consequence, botnets that are initially detected and classified by
>    the ISP as one particular type of bot need to be continuously
>    monitored and tracked in order to correctly identify the threat they
>    pose at any particular point in time.
Not really, while it is helpful to provide as much information as possible to the victim, generic bot (or infection) notification has proven to be successfully.
>
>    Detection is also time-sensitive.  If complex analysis is required
It seems like you just said that above.
>    and multiple confirmations are needed to confirm a bot is indeed
>    present, then it is possible that the bot may cause some damage (to
>    either the infected computer or a remotely targeted system) before it
>    can be stopped.  This may mean that an ISP may need to balance the
>    desire or need to definitively classify and/or confirm a bot, which
>    may take an extended period of time, with the ability to predict the
>    strong likelihood of a bot in a very short period of time.  This
>    'definitive-vs-likely' challenge is difficult and, when in doubt,
>    ISPs should probably err on the side of caution by communicating when
I agree erring on the side of caution BUT that should be don't communicate with your customers unless your fairly certain they are infected (False positive rate of 5% or less)! Notifying customers just on "likely" (ie greater then 50%) will cause customers loose faith in such notification.
>    a likely bot infection has taken place.  This also means that
>    Internet users may benefit from the deployment of client-based
>    software protections or other software tools, which can enable rapid
>    performance of heuristically-based detection bot activity, such as
There is a risk here in that this teaches users to install software on their computer that may not be effective given todays botnet + root kit hiding abilities. Thus a false sense of security plus you've trained them to install software outside of normal OS maintenance. Would this even be included if it weren't the approach you choose?

>    the detection of a bot as it starts to communicate a bot net and
communicate to a bot net ...
>    execute some type of command.  Any bot detection systems should also
execute commands.
>    be capable of learning and adapting, either via manual intervention
>    or automatically, in order to cope with a rapidly evolving threat.
If done learning is done automatically you have just solved the turing test.
Computers don't learn.
>
>    As noted above, detection methods, tools, and processes should ensure
>    that privacy of customers' PII is maintained.  While bot detection
>    methods, tools, and processes are similar to spam and virus defenses
>    deployed by the ISP for the benefit of their customers (and may be
>    directly related to those defenses), attempts to detect bots should
>    take into account the need of an ISP to take care to ensure any PII
>    collected or incidentally detected is properly protected.  The
>    definition of PII varies from one jurisdiction to the next so proper
>    care must be taken to ensure that any actions taken comply with
>    legislation and good practice in the jurisdiction in which the PII is
>    gathered.  Finally, depending upon the geographic region within which
While this is true in many cases the customers PII is already at risk from criminal elements that want to exploit it. So being overly concerned about the privacy of PII (such as hiding PII from internal analysis teams) should be recommended against.
>
>
>
> Livingood, et al.        Expires August 16, 2010                [Page 9]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    an ISP operates, certain methods relating to bot detection may need
>    to be included in relevant terms of service documents or other
>    documents which are available to the customers of a particular ISP.
>
>    There are several bot detection methods, tools, and processes that an
>    ISP may choose to utilize, as noted in the list below.  It is
>    important to note that the technical solutions available are
>    relatively immature, and are likely to change over time, evolving
>    rapidly in the coming years.  While these items are described in
>    relation to ISPs, they may also be applicable to organizations
>    operating other networks, such as campus networks and enterprise
>    networks.
>
>    a.  Where legally permissible or otherwise an industry accepted
>        practice in a particular market region, an ISP may in some manner
>        "scan" their IP space in order to detect un-patched or otherwise
>        vulnerable hosts.  This may provide the ISP with the opportunity
>        to easily identify Internet users who appear to already be or are
>        at great risk of being infected with a bot.  ISP's should note
>        that some types of port scanning may leave network services in a
>        hung state or render them unusable due to common frailties, and
>        that many modern firewall and host-based intrusion detection
>        implementations may alert the Internet user to the scan.  As a
>        result the scan may be interpreted as a malicious attack against
>        the computer.  Vulnerability scanning has a higher probability of
>        leaving accessible network services and applications in a damaged
>        state and will often result in a higher probability of detection
>        by the Internet user and subsequent interpretation as a targeted
>        attack.  Depending upon the vulnerability being scanned, some
>        automated methods of vulnerability checking may result in data
>        being altered or created afresh on the Internet users computer
>        which be a problem in many legal environments.
I would strongly recommend against this as a common practice. You provided most of the risks that make this a dangerous course.

>
>    b.  An ISP may also communicate and share selected data, via feedback
>        loops or other mechanisms, with various third parties.  Feedback
>        loops are consistently formatted feeds of real-time (or nearly
>        real-time) abuse reports offered by threat data clearinghouses,
>        security alert organizations, other ISPs, and other
>        organizations.  The data may include, but is not limited to,
I think your "feed back loop" is really "trusted third party notification". While those may include feed back, as your well aware, there isn't that much feed back in most cases due to PII concerns. So most the time the trusted 3rd party gets a "THANKS we will take care of it" as opposed to yes we see some of those ip being reported as infected.
>        lists of the IP addresses computers which have or are likely to
>        have a bot running, domain names or fully qualified domain names
>        (FQDNs) known to host malware and/or be involved in the command
>        and control of botnets, IP addresses know to host malware and/or
>        be involved in the command and control of botnets, recently
>        tested or discovered techniques or detecting or remediating bot
>        infections, new threat vectors, and other relevant information.
>        Good examples of this include SNDS from Microsoft, XBL and PBL
>        from Spamhaus and the DSHIELD AS tool from the SANS Institute.
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 10]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    c.  An ISP may use Netflow [RFC3954] or other similar passive network
>        monitoring to identify network anomalies that may be indicative
>        of botnet attacks or bot communications.  For example, an ISP may
>        be able to identify compromised hosts by identifying traffic
>        destined to IP addresses associated with the command and control
destined to an IP address and control port associated with the ...
Most of the time the host associated with c and c has other legit traffic so having the control port helps a LOT when running potentially infected bot net reports.

>        of botnets.  In addition, bots can be identified when a remote
>        host is under a DDoS attack because computers participating in
>        the attack will likely be infected by a bot, frequently as
I would caution against FPs due to spoofing of source IP addresses.
With netflow you can check which router and interface the attack traffic is coming in from as method to reduce FPs.
>        observed at network borders.
>
>    d.  An ISP may use DNS-based techniques to perform detection.  For
>        example, a given classified bot may be known to query a specific
>        list of domain names at specific times or on specific dates (in
>        the example of the so-called "Conficker" bot), often by matching
>        DNS queries to a well known list of domains associated with
>        malware.  In many cases such lists are distributed by or shared
>        using third parties, such as threat data clearinghouses.
>
>    e.  User complaints: Because hosts infected by bots are frequently
>        used to send spam or participate in DDoS attacks, the ISP
>        servicing those hosts will normally receive complaints about the
>        malicious network traffic.  Those complaints may be sent to
>        RFC2142-specified [RFC2142] role accounts, such as abuse@ or
>        postmaster@ or to abuse or security addresses specified by the
postmaster is for email delivery issues and we shouldn't be encouraging people to use it for abuse unless no other contact info is available.
NOC or security should be encouraged instead if abuse@ doesn't work.
>        site as part of its WHOIS (or other) contact data.
>
>    f.  ISPs may also discover likely bot infected hosts located at other
>        sites; when legally permissible or otherwise an industry accepted
located on other ISPs networks; when legally ...
You mention industry accepted practice here as an or legally permissible but I think you mean and not or. It has to be legal or you shouldn't do it period. If it is an industry accepted practice shouldn't really come in to it. The first of us that started share such reports to other ISPs we were the first to do so. It wasn't the industry accepted practice at that time.

>        practice in a particular market region, it may be worthwhile for
in a particular geo-political area based on local laws. It is valuable for
ISPs to share evidence related to those likely bot infected hosts with the ...
>        ISPs to share evidence relating to those compromised hosts with
>        the relevant remote ISP, with security researchers, and with
>        blocklist operators.
>
>    g.  ISPs may operate or subscribe to services that provide
>        'sinkholing' or 'honeynet' capabilities.  This may enable the ISP
>        to obtain near-real-time lists of bot infected computers as they
>        attempt to join a larger botnet or propagate to other hosts on a
>        network.
>
>    h.  ISP industry associations should examine the possibility of
>        collating statistics from ISP members in order to provide good
>        statistics about bot infections based on real ISP data.
>
>    i.  An Intrusion Detection System(IDS) can be a useful tool to
>        actually identify to help identify the malware.  An IDS tool such
>        as SNORT (open source IDS platform) can be placed in a Walled
>        Garden and used to analyze end user traffic to confirm malware
>        type.  This will help with remediation of the infected device.
Some mention of within local laws and/or aup may be helpful here.
In fact maybe a strong statement at the beginning that say that for all of these detection methods ensure its legal and/or within AUP/ELUA.

>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 11]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
> 6.  Notification to Internet Users
>
>    Once an ISP has detected a bot, or the strong likelihood of a bot,
>    steps should be undertaken to inform the Internet user that they may
>    have a bot-related problem.  Depending upon a range of factors, from
>    the technical capabilities of the ISP, to the technical attributes of
>    their network, financial considerations, available server resources,
>    available organizational resources, the number of likely infected
>    computers detected at any given time, and the severity of any
>    possible threats, among many other things, an ISP should decide the
>    most appropriate method or methods for providing notification to one

Ideally the customer should be notified via as many methods as possible at nearly the same time if possible. While most ISPs could do more then one notification method most of the "bad guys" won't be able to spoof many different
notification types within a small amount of time.
I don't know anyone that has implemented this but it seems like a really good recommendation.
>    or more of their customers or Internet users.  Such notification
>    methods may include one or more of the following, as well as other
>    possible methods not described below
>
>    It is important to note that none of these methods are guaranteed to
>    be successful, and that each has its own set of limitations.  In
100% successful,
>    addition, in some cases, an ISP may determine that a combination of
>    two or more methods is most appropriate.  Finally, notification is
>    also considered time sensitive; if the user does not receive or view
>    the notification or a timely basis, then a particular bot could
>    launch an attack, exploit the user, or cause other harm.  If
>    possible, an ISP should establish a preferred means of communication
>    when the subscriber first signs up for service.  As a part of the
>    notification process, ISPs should maintain a record of the allocation
>    of IP addresses to subscribers for such a period as allows any bot
commonly used bot detection

>    detection technology to be accurately able to link an infected IP
to be able to accurately link an infected ...
>    address to a subscriber.  This record should only be maintained for a
>    period of time which is necessary, in order to maintain the
>    protection of the privacy of an individual subscriber.
>
>    One important factor to bear in mind is that notification to end
>    users needs to be defended against spoofing by third parties.  This
>    must be done to protect against the possibility of notifications
>    being spoofed and used by bots to deliver additional malware.
must be done to protect as well as reasonably possible against the possibility of legitimate notifications being spoofed and used by persons with malicious intent to perform additional malicious acts against the victims.


They may not be bots and they may not use this to "infect" with a bot in many cases "they" will be an AD that sells fake AV/scareware.

>
> 6.1.  Email Notification
>
>    This is probably the most common form of notification used by ISPs.
Is it? Do we have any surveys or stats on this? I think your correct but it would be good to have some kind of backup.
>    One drawback of using email is that it is not guaranteed to be viewed
>    within a reasonable time frame, if at all.  The user may be using a
>    different primary email address than that which they have provided to
>    the ISP.  In addition, some ISPs do not provide an email account at
>    all, as part of a bundle of Internet services, and/or do not have a
>    need for or method in which to request or retain the primary email
>    addresses of Internet users of their networks.  Another possibility
>    is that the user, their email client, and/or their email servers
>    could determine or classify such a notification as spam, which could
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 12]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    delete the message or otherwise file it in an email folder that the
>    user may not check on a regular and/or timely basis.  Bot masters
>    have also been known to impersonate the ISP or trusted sender and
>    send fradulent emails to the users.  This technique of social
fraudulent
>    engineering, generally referred to as 'phishing', often leads to new

Phishing is generally defined as attempting to gain user credentials or other sensitive information by spoofing a trusted source.
What your describing is a method used by some viruses such as beagle to spread by convincing customers to install it thinking it was a fix to some malware or other issue. This is commonly refered to as social engineering as you state but not phishing.

>    bot infestations.  Finally if the user's email credentials are
>    compromised, then a hacker and/or a bot could simply login to the
>    user's email account and delete the email before it is read by the
>    user.
>
> 6.2.  Telephone Call Notification
>
>    A telephone call may be an effective means of communication in
>    particularly high-risk situations.  However, telephone calls may not
>    be feasible due to the cost of making a large number of calls, as
>    measured in either time, money, organizational resources, server
>    resources, or some other means.  In addition, there is no guarantee
>    that the user will answer their phone.  To the extent that the
>    telephone number called by the ISP can be answered by the infected
>    computing device, the bot on that computer may be able to disconnect,
>    divert, or otherwise interfere with an incoming call.  Users may also
>    interpret such a telephone notification as a telemarketing call and
>    as such not welcome it, or not accept the call at all.  Finally, even
>    if a representative of the ISP is able to connect with and speak to a
>    user, that user is very likely to lack the necessary technical
>    expertise to understand or be able to effectively deal with the
>    threat.
Isn't this last statement true for ALL notifications methods.
I agree it is true, but it probably needs to be a caveat for all notification methods. You mention it else where but perhaps a special paragraph at the beginning that states this is true for all notification types.

>
> 6.3.  Postal Mail Notification
>
>    This form of notification is probably the least popular and effective
>    means of communication, due to both preparation time, delivery time,
>    the cost of printing and paper, and the cost of postage.

For ISPs that are already billing their customers there wouldn't need to be additional cost of postage, printing or paper it could be incorporated into the bill its self. The biggest risk here is delivery time and the fact that some customers don't review their bills (similar to the email issue identified above).
>
> 6.4.  Walled Garden Notification
>
>    Placing a user in a walled garden is another approach that ISPs may
>    take to notify users.  A walled garden refers to an environment that
>    controls the information and services that a subscriber is allowed to
>    utilize and what network access permissions are granted.  This is an
That is really the definition of a quarantine walled garden.
Walled garden's don't have to quarantine the user (much) to notify the customer.
They can be fairly leaky and still notify the customer of their infection.

>    effective technique because it could be able to block all
>    communication between the bot and the command and control channel,
>    which may impair the ability of a bot to disrupt or block attempts to
>    notify the user.
>
>    While in many cases the user is almost guaranteed to view the
>    notification message and take any appropriate remediation actions,

Exactly.
>    this approach poses can pose other challenges.  For example, it is
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 13]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    not always the case that a user is actively using a computer that
>    uses a web browser or which has a web browser actively running on it.
not always the case that a user is using a application that used the ports being redirected to the walled garden.

This is more of an application issue then the "computer".
>    In one example, a user could be playing a game online, via the use of
>    a dedicated, Internet-connected game console.  In another example,
>    the user may not be using a computer with a web browser when they are
>    placed in the walled garden and may instead be in the course of a
>    telephone conversation, or may be expecting to receive a call, using
>    a Voice Over IP (VoIP) device of some type.  As a result, the ISP may
>    feel the need to maintain a potentially lengthy white list of domains
>    which are not subject to the typical restrictions of a walled garden,
>    which could well prove to be an onerous task, from an operational
>    perspective.
Or design a leaky walled garden that allows most traffic without interference only redirecting the traffic needed to mitigate or notify.

>
>    The ISP has several options to determine when to let the user out of
>    the walled garden.  One approach may be to let the user determine
>    when to exit.

This is really the only viable approach. Any other approach encroaches on user
rights, drive up help desk calls ($) and generally be unacceptable to your users.
>        This option is suggested when the purpose of the
primary purpose of the
>    walled garden is to notify users and provide information on
>    remediation only, particularly since notification is not a guarantee
>    of successful remediation.  It could also be the case that, for

No you can still let the user determine when to leave since you have notified them you have reduced your liability for any malicious traffic that may be allowed out when they request exiting the walled garden.
>    whatever reason, the user makes the judgment that they cannot then
>    take the time to remediate their computer and that other online
>    activities which they would like to resume are more important.  Exit
>    from the walled garden may also involve a process to verify that it
>    is indeed the user who is requesting exit from the walled garden and
>    not the bot.
If you mean requesting some kind of credentials before they exit I would advise against that as it is an avenue for phishing.
>
>    Once the user acknowledges the notification, then the user decides to
the notification, decides to remediate and exit the walled garden or exit the walled garden without remediating the issue.
>    either remediate and then exit the walled garden, or exit the walled
>    garden without addressing the issue.  Another approach may be to
>    enforce a stricter policy and require the user to clean the computer
>    prior to permitting the user to exit the walled garden, though this
>    may not be technically feasible depending upon the type of bot,
>    obfuscation techniques employed by a bot, and/or a range of other
>    factors.  Thus, the ISP may also need to support tools to scan the
>    infected computer and determine whether it is still infected or rely
>    on user judgment that the bot has been disabled or removed.  One

Scanning is risky and should be identified as such.
Port scanning or vulnerability scanning is dangerous as you identified else where.
Anti-virus scanning is also risky if the ISP initiates it as that means you have taken some level of control (and responsibility) for that infected machine.
A better method would be to use SNORT or similar tool to passively watch for packets indicating an continued infection.
Another good approach is just to keep track of whom was put into the walled garden for which infection and if they keep showing up as infected via the trusted third party reports then you can assume they are unable/unwilling to remediate and take what ever additional actions you deem appropriate.
>    challenge with this approach is that if the user has multiple
>    computers sharing a single IP address, such as via a common home
>    gateway device which performs Network Address Translation (NAT).  In
>    such a case, the ISP may need to determine from user feedback, or
>    other means, that all affected computers have been remediated, which
>    may or may not be technically feasible.
>
>    Finally, when a walled garden is used, a list of well-known addresses
>    for both operating system vendors and security vendors should be
>    created and maintained in a white list which permits access to these
>    sites.  This can be important for allowing access from the walled

While this is possible in the cases where the ISP can provide links to tools that are known to effectively remove the infection you only have to whitelist that URL/site while the user is in the walled garden then let them out once they determine that they think they are clean and they can get OS/AV updates without the WG needing a large whitelist.

>    garden by end users in search of operating system and application
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 14]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    patches.
>
> 6.5.  Instant Message Notification
>
>    Instant messaging provides the ISP with a simple means to communicate
>    with the user.  There are several advantages to using IM which makes
>    it an attractive option.  If the ISP provides IM service and the user
>    subscribes to it, then the user can be notified easily.  IM-based
>    notification can be a cost effective means to communicate with users
>    automatically from an IM alert system or via a manual process, by the
>    ISP's support staff.  Ideally, the ISP should allow the user to
>    register their IM identity in an ISP account management system and
>    grant permission to be contacted via this means.  If the IM service
>    provider supports off-line messaging, then the user can be notified
>    regardless of whether they are currently logged into the IM system.
>
>    There are several drawbacks with this communications method.  There
>    is a high probability that subscriber may interpret the communication
>    to be spam, and as such ignore it.  Also, not every user uses IM
>    and/or the user may not provide their IM identity to the ISP so some
>    alternative means have to be used.  Even in those cases where a user
>    does have an IM address, they may not be signed onto that IM system
>    when the notification is attempted.  There maybe also be a privacy
>    concern on the part of users, when such an IM notification must be
>    transmitted over a third-party network and/or IM service.  As such,
>    should this method be used, the notification should be discreet and
>    not include any PII in the notification itself.

Isn't this true for email, sms and possibly other methods.
Again if so it could become part of the opening statement rather then tied to just one notification type.
>
> 6.6.  Short Message Service (SMS) Notification
>
>    SMS allows the ISP send a brief description of the problem to notify
>    the user of the issue, typically to a mobile device such as a mobile
>    phone or smart phone.  Ideally, the ISP should allow the user to
>    register their mobile number and/or SMS address in an ISP account
>    management system and grant permission to be contacted via this
>    means.  The primary advantage of SMS is that users are familiar with
>    receiving text messages and are likely to read them.  However, users
>    may not act on the notification immediately if they are not in front
>    of their computer system at the time of the SMS notification.
>
>    One disadvantage is that ISPs may have to follow up with an alternate
>    means of notification if not all of the necessary information maybe
>    conveyed in one message, given constraints on the number of
>    characters in an individual message (typically 140 characters).
>    Another disadvantage with SMS is the cost associated with it.  The
>    ISP has to either build its own SMS gateway to interface with the
>    various wireless network service providers or use a third-party SMS
>    clearinghouse (relay) to notify users.  In both cases, an ISP will
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 15]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    typically pay on a per-message basis to send SMS notifications.  An

No in most cases the ISP would use the customers SMS providers SMTP to SMS gateway and wouldn't encore additional costs for an sms msg.

>    additional downside is that SMS messages sent to a user may result in
>    a charge to the user by their wireless provider, depending upon the
>    plat to which they subscribe.  Another minor disadvantage is that it

did you mean platform or feature set here?
>    is possible to notify the wrong user if the intended user changes
>    their mobile number but forgets to update it with the ISP.

Again this applies to more then just sms, certainly to email accounts and probably other notification methods.
>
>    There are several other drawbacks with this communications method.
>    There is a high probability that subscriber may interpret the
>    communication to be spam, and as such ignore it.  Also, not every
>    user uses SMS and/or the user may not provide their SMS address or
>    mobile number to the ISP.  Even in those cases where a user does have
>    an SMS address or mobile number, their device may not be powered on
>    or otherwise available on a wireless network when the notification is
>    attempted.  There maybe also be a privacy concern on the part of
>    users, when such an SMS notification must be transmitted over a
>    third-party network and/or SMS clearinghouse.  As such, should this
>    method be used, the notification should be discreet and not include
>    any PII in the notification itself.
>
> 6.7.  Web Browser Notification
>
>    Near real-time notification to the user's web browser is another
>    technique that may be utilized for notifying the user, though how
>    such a system might operate is outside the scope of this document.
>    Such a notification could have a comparative advantage over a walled
>    garden notification, in that it does not restrict traffic to a
>    specified list of destinations in the same way that a walled garden
>    by definition would.  However, as with a walled garden notification,

As I pointed out elsewhere a walled garden doesn't have to restrict traffic to a specified list. Just redirect the web traffic long enough to notify.

>    there is no guarantee that a user is at any given time making use of
>    a web browser, though such a system could certainly provide a
>    notification when such a browser is eventually used.  Compared to a
>    walled garden, a web browser notification is probably preferred from
>    the perspective of Internet users, as it does not have the risk of
>    disrupting non-web sessions, such as online games, VoIP calls, etc.
>    (as noted in Section 6.4).

Again a leaky walled garden doesn't have this issue.
>
> 6.8.  Considerations for Notification to Public Network Locations
>
>    Delivering a notification to a location that provides a shared public
>    network, such as a train station, public square, coffee shop, or
>    similar location may be of low value since the users connecting to
>    such networks are typically highly transient and generally not know
>    to site or network administrators.  For example, a system may detect
>    that a computer on such a network has a bot, but by the time a
>    notification is generated that user has departed from the network and
>    moved elsewhere.
>
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 16]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
> 6.9.  Considerations for Notification to Network Locations Using a
>       Shared IP Address
>
>    Delivering a notification to a location that Internet access routed
>    through one or more shared public IP addresses may be of low value
>    since it may be quite difficult to differentiate between users when
>    providing a notification.  For example, on a business network of 500
>    users, all sharing one public IP address, it may be sub-optimal to
>    provide a notification to all 500 users if you only need one specific
>    user to be notified and take action.  As a result, such networks may

In cases like this to assist the business network you describe providing a date/timestamp, source port of the infected system, and malicious sites it was visiting often helps them find the infected system.
>    find value in establishing a localized bot detection and notification
>    system, just as they are likely to also establish other localized
>    systems for security, file sharing, email, and so on.

One thing I don't see mentioned anywhere in the notification section is what I call the respect factor. Give your customer respect. Do not talk down to them or make them feel as if they have done anything wrong remember these are victims and you would like to build trust with them!

>
>
> 7.  Remediation of Computers Infected with a Bot
>
>    This section covers the different options available to remediate a
>    computer, which means to remove, disable, or otherwise render a bot
>    harmless.  Prior to this step, an ISP has detected the bot, notified
>    the user that one of their computers is infected with a bot, and now
>    may provide some recommended means to clean the computer.  The
>    generally recommended approach is to provide the necessary tools and
>    education to the user so that they may perform bot remediation
>    themselves, particularly given the risks and difficulties inherent in
>    attempting to remove a bot.
>
>    For example, this may include the creation of a special web site with
>    security-oriented content that is dedicated for this purpose.  This
>    should be a well-publicized security web site to which a user with a
>    bot infection can be directed to for remediation.  This security web
>    site should clearly explain why the user was notified and may include
>    an explanation of what bots are, and the threats that they pose.
>    There should be a clear explanation of the steps that the user should
>    take in order to attempt to clean their computer and provide
>    information on how users can keep the computer free of future
>    infections.  The security web site should also have a guided process
>    that takes non-technical users through the remediation process, on an
>    easily understood, step-by-step basis.
>
>    In terms of the text used to explain what bots are and the threats
>    that they pose, something simple such as this may suffice:
>
>          "What is a bot?  A bot is a piece of software, generally
>          installed on your machine without your knowledge, which either
>          sends spam or tries to steal your personal information.  They
>          can be very difficult to spot, though you may have noticed that
>          your computer is running much more slowly than usual or you
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 17]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>          notice regular disk activity even when you are not doing
>          anything.  Ignoring this problem is not really an option since
Ignoring this problem is risky to you and your personal information ..
>          your personal information is currently at risk.  Thus, bots
>          need to be removed to protect your data and your personal
>          information."
>
>    It is also important to note that it may not be immediately apparent
>    to the Internet user precisely which devices have been infected with
>    a particular bot.  This may be due to the user's home network
>    configuration, which may encompass several computers, where a home
>    gateway which performs Network Address Translation (NAT) to share a
>    single public IP address has been used.  Therefore, any of these
>    devices can be infected with a bot.  The consequence of this for an
>    ISP is that remediation advice may not ultimately be immediately
>    actionable by the Internet user, as that user may need to perform
>    additional investigation within their own home network.

You mentioned this in the notification section not sure it is needed here too.
>
>    An added complication is that the user may have a bot infection on a
>    device such as a video console, multimedia system, appliance, or
>    other end-user computing device which does not have a typical Windows
>    or Macintosh user interface.  As a result, diligence needs to be
which does not have a user feed back interface such as a web browser or email client.
>    taken by the ISP where possible such that they can identify and
>    communicate the specific nature of the device that has been infected
>    with a bot, and further providing appropriate remediation advice.
Mentioned in the notification process probably not needed here.
>
>    There are a number of forums that exist online to provide security
>    related support to end users.  These forums are staffed by volunteers
>    and often are focussed around the use of a common tool set to help
>    end users to remediate computers infected with malware.  It may be
>    advantageous to ISPs to foster a relationship with one or more
>    forums, perhaps by offering free hosting or other forms of
>    sponsorship.
>
>
> 8.  Guided Remediation Process
>
>    Minimally the Guided Remediation Process should include options
>    and/or recommendations on how a user should:
>
>    1.  Backup personal Documents, for example: "Before you start, make
>        sure to back up all of your important data.  (You should do this
>        on a regular basis anyway.)  You can back up your files manually
>        or using a system back-up software utility, which may be part of
>        your Operating System (OS).  You can back your files up to a USB
>        Thumb Drive (aka USB Key), a writeable CD/DVD-ROM, an external
>        hard drive, or a network file server."
>


I would argue that the FIRST step in Guided remediation process is getting the customer cleaned but understand the desire to backup before preforming the cleaning. However it has to be the 2nd step if you put backup first. Most bot software is going to prevent the OS and antivirus steps until the customer is uninfected.

>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 18]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    2.  Download OS patches and Anti-Virus (A/V) software updates.  For
>        example, links could be provided to Microsoft Windows updates at
>        http://update.microsoft.com/microsoftupdate/v6/
>        default.aspx?ln=en-us as well as to Apple MacOS updates at
>        http://support.apple.com/kb/HT1338?viewlocale=en_US.
>
>    3.  Explain how to configure the computer to automatically install
>        updates for the OS, A/V and other common Web Browsers such as
>        Microsoft Internet Explorer, Mozilla Firefox, Apple Safari,
>        Opera, and Google Chrome.
>
>    4.  The flow should also have the option for users to get
>        professional assistance if they are unable to remove the bots
>        themselves.  If purchasing third party assistance, then the user
>        should be encouraged to pre-determine how much they are willing
>        to pay for that help.  If the computer that is being remediated
>        is old and can easily be replaced with a new, faster, larger and
>        more reliable system for three or four hundred dollars, the it
>        makes no sense to spend five or six hundred dollars to fix the
>        old computer, for example.  On the other hand, if the customer
>        has a brand new computer that cost several thousand dollars, it
>        might make perfect sense to spend the money in attempting to
>        remediate it.
>
>    5.  To continue, regardless of whether the user or a knowledgeable
>        technical assistant is working on remediating the computer, their
>        first task should be to determine which of multiple potentially-
>        infected machines may be the one that needs attention (in the
>        common case of multiple computers in a home network).  Sometimes,
>        as in cases where there is only a single directly-attached
>        computer, or the user has been noticing problems with one of
>        their computers, this can be easy.  Other times, it may be more
>        difficult.  If the user is behind a home gateway/router, then the
>        first task may be to ascertain which of the machines is infected.
>        In some cases the user may have to check all machines to identify
>        the infected one.
>
>    6.  User surveys to solicit feedback on whether the notification and
>        remediation process is effective and what recommended changes
>        could be made in order to improve the ease, understandability,
>        and effectiveness the remediation process.
>
>    7.  If the user is interested in reporting his or her computer's bot
>        infection to an applicable law enforcement authority, then the
>        computer effectively becomes a cyber "crime scene" and should not
>        be mitigated unless or until law enforcement has collected the
>        necessary evidence.  For individuals in this situation, the ISP
>        should refer them to local, state, federal, or other relevant
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 19]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>        computer crime offices.  (Note: Some "minor" incidents, even if
>        highly traumatic to the user, may not be sufficiently serious for
>        law enforcement to commit some of their limited resources to an
>        investigation.)  In addition, individual regions may have other,
>        specialized computer crime organizations to which these incidents
>        can be reported.  For example, in the United States, that
>        organization is the Internet Crime Complaint Center, at
>        http://www.ic3.gov.
>
>    8.  Users may also be interested in links to security expert forums,
>        where other users can assist them.
>
>
> 9.  Professionally-Assisted Remediation Process
>
>    It should be acknowledged that, based on the current state of
>    remediation tools and the technical abilities of end users, that many
>    users may be unable to remediate on their own.  As a result, it is
>    recommended that users have the option to avail themselves of
>    professional assistance.  This may entail online or telephone
>    assistance for remediation, as well as working face to face with a
>    professional who has training and expertise in the removal of
>    malware.

This can be recommended but shouldn't be part of an "upsell" as that could be
seen as potential revenue.

>
>
> 10.  Sharing of Data from the User to the ISP
>
>    As an additional consideration, it may be useful to create a process
>    by which users could choose, at their option and with their express
>    consent, to share data regarding their bot infection with their ISP
>    and/or another authorized third party.  Such third parties may
>    include governmental entities that aggregate threat data, such as the
>    Internet Crime Complaint Center referred to earlier in this document,
>    to academic institutions, and/or security researchers.  While in many
>    cases the information shared with the user's ISP or designated third
>    parties will only be used for aggregated statistical analysis, it is
>    also possible that certain research needs may be best met with more
>    detailed data.  Thus, any such data sharing from a user to the ISP or
>    authorized third party may contain some type of personally
>    identifiable information, either by design or inadvertently.  As a
>    result, any such data sharing must be enabled on an opt-in based,
>    where users review and approve of the data being shared and the
>    parties with which it is to be shared.

Unless the ISP is already required to provide said information due local laws or judicial requirements (subpoena)...

>
>
> 11.  Security Considerations
>
>    This document describes in detail the numerous security risks and
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 20]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    concerns relating to bot nets.  As such, it has been appropriate to
>    include specific information about security in each section above.
>    This document describes the security risks related to malicious bot
>    infections themselves, such as enabling identity theft, theft of
>    authentication credentials, and the use of a computer to unwittingly
>    participate in a DDoS attack, among many other risks.  This document
>    also describes at a high level the activities that ISPs should be
>    sensitive to, where the collection or communication of PII may be
>    possible.  Finally, the document also describes security risks which
>    may relate to the particular methods of communicating a notification
>    to Internet users.  Bot networks and bot infections pose extremely
>    serious security risks and any reader should review this document
>    carefully.
>
>    In addition, regarding notifications, as described in the Section 6,
>    care should be taken to assure users that notifications have been
>    provided by a trustworthy site and/or party, so that the notification
>    is more difficult for phishers to mimic, or that the user has some

I think you are talking social engineers not phishers.

>    level of trust that the notification is valid, and/or that the user
>    has some way to verify via some other mechanism or step that the
>    notification is valid.
>
>    Lastly, as noted in Section 10, any sharing of data from the User to
>    the ISP and/or authorized third parties must be done on an opt-in
>    basis and with a clear by the user of the data to be shared and with
>    whom it is to be shared.
>
>
> 12.  IANA Considerations
>
>    There are no IANA considerations in this document.
>
>
> 13.  Acknowledgements
>
>    The authors wish to acknowledge the following individuals for
>    performing a detailed review of this document and/or providing
>    comments and feedback with had helped to improve and evolve this
>    document:
>
>    Mark Baugher
>
>    Richard Bennett
>
>    James Butler
>
>    Vint Cerf
>
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 21]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    Alissa Cooper
>
>    Jonathan Curtis
>
>    Jeff Chan
>
>    Roland Dobbins
>
>    Dave Farber
>
>    Eliot Gillum
>
>    Joel Halpern
>
>    Scott Keoseyan
>
>    The Messaging Anti-Abuse Working Group (MAAWG)
>
>    Jose Nazario
>
>    Gunter Ollmann
>
>    David Reed
>
>    Joe Stewart
>
>    Forrest Swick
>
>    Robb Topolski
>
>    Eric Ziegast
>
>
> 14.  Informative references
>
>    [Battling Botnets and Online Mobs: Estonia's Defense Efforts during
>    the Internet War]
>               Evron, G., "Battling Botnets and Online Mobs: Estonia's
>               Defense Efforts during the Internet War", May 2005, <http:
>               //docs.google.com/
>               gview?a=v&
>               q=cache%3AbyUMj6Djlb8J%3Awww.ciaonet.org%2Fjournals%
>               2Fgjia%2Fv9i1%2F0000699.pdf>.
>
>    [Case Study: How a Bookmaker and a Whiz Kid Took On a DDOS-based
>    Online Extortion Attack]
>               Berinato, S., "Case Study: How a Bookmaker and a Whiz Kid
>               Took On a DDOS-based Online Extortion Attack", May 2005, <
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 22]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>               http://www.csoonline.com/article/220336/
>               How_a_Bookmaker_and_a_Whiz_Kid_Took_On_a_DDOS_based_Online
>               _Extortion_Attack>.
>
>    [Cyberspace as a Combat Zone: The Phenomenon of Electronic Jihad]
>               Alshech, E., "Cyberspace as a Combat Zone: The Phenomenon
>               of Electronic Jihad", February 2007, <http://
>               www.memrijttm.org/content/en/report.htm?report=1822>.
>
>    [Emerging Cyber Threats Report for 2009: Data, Mobility and Questions
>    of Responsibility will Drive Cyber Threats in 2009 and Beyond]
>               Ahamad, M., Amster, D., Barret, M., Cross, T., Heron, G.,
>               Jackson, D., King, J., Lee, W., Naraine, R., Ollman, G.,
>               Ramsey, J., Schmidt, H., and P. Traynor, "Emerging Cyber
>               Threats Report for 2009: Data, Mobility and Questions of
>               Responsibility will Drive Cyber Threats in 2009 and
>               Beyond", October 2008, <http://smartech.gatech.edu/
>               bitstream/1853/26301/1/CyberThreatsReport2009.pdf>.
>
>    [Persistent BIOS Infection]
>               Sacco, A. and A. Ortega, "Persistent BIOS Infection",
>               March 2009, <http://www.coresecurity.com/files/
>               attachments/Persistent_BIOS_Infection_CanSecWest09.pdf>.
>
>    [RFC1459]  Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
>               RFC 1459, May 1993.
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC2142]  Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
>               FUNCTIONS", RFC 2142, May 1997.
>
>    [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
>               9", RFC 3954, October 2004.
>
>    [Spamalytics: An Empirical Analysis of Spam Marketing Conversion]
>               Kanich, C., Kreibich, C., Levchenko, K., Enright, B.,
>               Voelker, G., Paxson, V., and S. Savage, "Spamalytics: An
>               Empirical Analysis of Spam Marketing Conversion",
>               October 2008, <http://www.icir.org/christian/publications/
>               2008-ccs-spamalytics.pdf>.
>
>    [The Gh0st in the Shell: Network Security in the Himalayas]
>               Vallentin, M., Whiteaker, J., and Y. Ben-David, "The Gh0st
>               in the Shell: Network Security in the Himalayas",
>               February 2010, <http://www.infowar-monitor.net/wp-content/
>               uploads/2010/02/cs294-28-paper.pdf>.
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 23]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    [The snooping dragon: social-malware surveillance of the Tibetan
>    movement]
>               Nagaraja, S. and R. Anderson, "The snooping dragon:
>               social-malware surveillance of the Tibetan movement",
>               March 2009,
>               <http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-746.pdf>.
>
>
> Appendix A.  Document Change Log
>
>    [RFC Editor: This section is to be removed before publication]
>
>    -07 version:
>
>    o  Corrected various spelling and grammatical errors, pointed out by
>       additional reviewers.  Also added a section on information flowing
>       from the user.  Lastly, updated the reviewer list to include all
>       those who either were kind enough to review for us or who provided
>       interesting, insightful, and/or helpful feedback.
>
>    -06 version:
>
>    o  Corrected an error in the version change log, and added some extra
>       information on user remediation.  Also added an informational
>       reference to BIOS infection.
>
>    -05 version:
>
>    o  Minor tweaks made by Jason - ready for wider review and next
>       steps.  Also cleared open issues.  Lastly, added 2nd paragraph to
>       security section and added sections on limitations relating to
>       public and other shared network sites.  Added a new section on
>       professional remediation.
>
>    -04 version:
>
>    o  Updated reference to BIOS based malware, added wording on PII and
>       local jurisdictions, added suggestion that industry body produce
>       bot stats, added suggestion that ISPs use volunteer forums
>
>    -03 version:
>
>    o  all updates from Jason - now ready for wider external review
>
>    -02 version:
>
>    o  all updates from Jason - still some open issues but we're now at a
>       place where we can solicit more external feedback
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 24]
>
> Internet-Draft     Remediation of Bots in ISP Networks     February 2010
>
>
>    -01 version:
>
>    o  -01 version published
>
>
> Appendix B.  Open Issues
>
>    [RFC Editor: This section is to be removed before publication]
>
>    A question has been raised about whether this should change from
>    Informational to BCP.
>
>
> Authors' Addresses
>
>    Jason Livingood
>    Comcast Cable Communications
>    One Comcast Center
>    1701 John F. Kennedy Boulevard
>    Philadelphia, PA  19103
>    US
>
>    Email: [e-mail]
>    URI:   http://www.comcast.com
>
>
>    Nirmal Mody
>    Comcast Cable Communications
>    One Comcast Center
>    1701 John F. Kennedy Boulevard
>    Philadelphia, PA  19103
>    US
>
>    Email: [e-mail]
>    URI:   http://www.comcast.com
>
>
>    Mike O'Reirdan
>    Comcast Cable Communications
>    One Comcast Center
>    1701 John F. Kennedy Boulevard
>    Philadelphia, PA  19103
>    US
>
>    Email: [e-mail]
>    URI:   http://www.comcast.com
>
>
>
>
>
> Livingood, et al.        Expires August 16, 2010               [Page 25]

 [e-mail]
(coffee != sleep) & (!coffee == sleep)

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.