Re: [ISN] Why I should have the right to kill a malicious process on your machine

From: InfoSec News (isnat_private)
Date: Sat Jan 18 2003 - 01:21:50 PST

  • Next message: InfoSec News: "Re: [ISN] Why I should have the right to kill a malicious process on your machine"

    Forwarded from: H C <keydet89at_private>
    Cc: jerichoat_private, thorat_private
    I agree w/ most of Jericho's hypothetical solutions, and will snip
    those portions for brevity's sake.
    > Heed your own insults Tim. Your proposal falls in the category of
    > theoretical rose-colored solutions. Hopefully you enjoyed your
    > coffee as you pontificated.
    While this may be true to a degree, it's also abundantly clear that at
    least some of those making comments against Strikeback are doing so
    w/o reviewing...well, anything on the subject.  Gene in particular has
    not reviewed Tim's paper.
    > There are several issues that you do not clearly address in such a
    > way to sell this idea.
    To some extent, I think this is central to the concept.  I'm not
    saying that I fully agree, 100%, w/ what appears in Tim's whitepaper.  
    But I am saying that there are issues that need to be sorted out w/
    regards to both the conceptual and technical implementations of this
    I've seen commments on other sites that refer to a "state run" or
    "state sponsored" organization being responsible for handling this.  
    NOT a good idea, folks.
    > If you find yourself asking what else can be done to stop these
    > problems, one answer that comes to mind is simple. ISP's need to be
    > more reactive to complaints about abuse on their network. Their
    > customers already sign an agreement stating they will follow an
    > Acceptable Use Policy. Every AUP I have seen covers malicious
    > activity like you describe, and puts the liability on them. If your
    > system attacks mine, be it from automated worm or not, and I report
    > that activity to your ISP.. they need to kill your conneection until
    > the problem is solved. If they read the logs I sent, they can then
    > make the determination if it is a serious problem, contact you, or
    > monitor your traffic to find their own verification of the activity.
    > Once they find it, they pull your plug and problem is solved
    > temporarily. While this system is not flawless, it is certainly more
    > feasible and responsible than any strikeback proposal.
    Of course, some of the same arguments apply to this solution, as well.  
    Does log files sent from someone to "abuseat_private" or
    "securityat_private" constitute a violation of the AUP?  Probably not.  
    As someone who had to deal w/ "abuseat_private" emails for a while,
    I saw quite a bit of...let's just say "clueless users of BlackICE and
    That aside, though, logs can also be forged in such a way as to push
    past the ISP's threshold and get them to disconnect the system...even
    if it's not actually the culprit.  Open up a few Yahoo or HotMail
    accounts, forge some logs, and send them in...if it's enough, maybe
    you can get the ISP to disconnect the system first, ask questions
    The same arguments of the "human factor" apply.  Given your examples,
    it looks as though w/o refinement, strikeback will have only extremely
    limited may only work against specific worms on specific
    However, one potential outcome of strikeback is to raise the bar.  
    Look at the current landscape...corporate, home, and gov't
    users/admins don't seem to have caught on that they need to secure and
    monitor their systems.  If the bar is raised, maybe they can get to
    the point of actually putting a little more effort in on the front end
    (there seems to be an even greater lack of basic troubleshooting and
    IR skills).  Maybe it's better to raise the bar w/ something like
    strikeback, rather than wait for the malware authors to raise the
    ISN is currently hosted by
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Sat Jan 18 2003 - 03:53:02 PST