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:24:08 PST

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

    Forwarded from: security curmudgeon <jerichoat_private>
    Cc: "Deus, Attonbitus" <Thorat_private>
    > > > I think the main reason for the knee-jerk criticism from the
    > > > likes of Schultz is that they work largely in a theoretical
    > > > rose-colored world of security, where all problems are solved
    > > > after a cup of coffee and a bit of pontification. Those who
    > > > actually work in the operational end
    > >
    > >Heed your own insults Tim. Your proposal falls in the category of
    > >theoretical rose-colored solutions. Hopefully you enjoyed your coffee
    > >as you pontificated.
    > When Gene unilaterally dismissed the strikeback concept in News
    > Bites, there was no public information available- my whitepaper was
    > not published, nor were any of my presentations.  No attempt to
    > contact me
    Please don't make the mistake of thinking you are the first to
    consider strikeback, write about it, propose it, or even implement it.
    If I write about some buffer overflow concept and don't provide much
    information, it's fair to say you can intelligently respond to it
    because there is already considerable information on the topic, yes?
    > was made, and no research was done to substantiate his stance. I
    > certainly expect this type of behavior from the general public, but
    > not from a security researcher in a position to editorialize to a
    > national (worldwide?)  audience.  To me, that is irresponsible.  
    > Was I
    I did no research on it either, and plan to read your paper this
    weekend. So far, from what I have seen, there has been absolutely *0*
    new input brought up. No new ideas gets the same response as others.
    > problem - most of the people reading this now were not infected by
    > Code Red or Nimda.  It is perfectly understandable that many here
    > have the "secure your systems and get on with it" mind set.  But the
    > persistence of old worms and the introduction of new ones is a
    > growing problem- and one that should be considered now.  I have been
    > and still am willing to wade through
    I agree now, more than ever. I am tired of the worms and I would love
    to have the ability to strikeback at servers hitting me. But that just
    can't happen until the idea is fleshed out more and all scenarios are
    > >Who defines "relentless" attacks? Is one worm spamming your web
    > >server with 6 hits every 30 minutes as it tries to spread
    > >"relentless"? Is it really threatening your machine or stealing
    > >your bandwidth? What if is the same 6 hits every 5 minutes? Or even
    > >every minute? Is that really a "relentless attack" or is that an
    > >annoyance? Is your answer the same as everyone elses?
    > YOU define it!  WE define it! The fact that you asked the question
    > in the
    Exactly my point. What YOU define may different than what I define or
    what WE define as a collective group. Without some form of standards,
    more liability will end up on YOUR shoulders and mine for striking
    back. That is not what you want clearly.
    > host of other questions!  We try to address questions like this in
    > the whitepaper... And note that we call it a whitepaper, not the
    > Strikeback Bible, because it is collection of concepts, ideas, and
    > processes that might help solve a problem and is not a "here are all
    > the answers" text.
    Out of curiosity, have you read Schwartau's and other
    posts/papers/comments on strikeback as a foundation for your own? Have
    you read past criticism of their writings? I specifically mention him
    for a reason.
    > Some of the issues are addressed in the whitepaper- others are not;
    > but they can be.  We can figure this out if we try. BTW, the wp is
    > at if you have not looked
    > at it.
    it's currently loaded in my browser, just haven't had a chance to read
    it yet =)
    > >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.
    > Having it come to mind is simple, but actually *making* the ISP
    > react is quite a different matter.  And you have now just introduced
    > the exact same
    Preaching to the choir here. I'm one of those nutjobs who complain
    about every single piece of spam, every worm/virus that hits us. I'm
    tired of their lack of reactino and indifference.
    > questions- what is an attack?  How much is too much?  If you do a
    > port scan from your "mission critical" machine, does the ISP get to
    > pull your plug?  Is is different for each ISP?  And if I maliciously
    > hack into your machine to steal your customer's information and your
    > ISP (or mine) does not catch it and pull the plug, is it not now
    > their fault?  And if you secure the hell out of all your machines,
    > but your ISP has to hike rates 50% to cover their expenses of this
    > new duty, are you willing to pay that though you don't feel you
    > personally need it?
    Until all of these questions (and more?) are answered to the
    satisifaction of legilators and the masses.. strikeback remains a
    topic for coffee and pontification i believe.
    > >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.
    > So, if I think you are attacking my machine, and I call your ISP,
    > you expect them to just kill your connection?  I see as many
    > problems with this concept as you do with mine.
    Not blindly, no. If you provide logs and my ISP has multiple
    complaints, they should contact me or pull my plug until it is
    resolved. This is being said with a lot more in mind that I haven't
    typed out. Factoring in the type of system, who the customer is, etc
    .. should all weigh in on how the ISP reacts. My comment was made
    because I feel that it is easier to define parameters for that kind of
    reaction and would readily be accepted by more people before
    strikeback would.
    > >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.
    > I guess we disagree... Well, I agree that something can and should
    > be done at the ISP level, but I don't agree that the ISP staff
    > should be the ones making the decision.  I would much rather
    > capitulate to a framework that you and other security people lay out
    > that outlines the important questions than to have arbitrary
    > employees of the ISP do it.
    The difference is.. the ISP is *already* in a legal position to do
    exactly what I propose, while the security geeks are not. My solution
    is one that is closer to being implemented tomorrow rather than in 5
    years after congress butchers the idea beyond belief (read: dmca).
    > Of course, we could combine the ideas and have the ISP's deploy a
    > strikeback framework that the community builds.
    Using a tiered approach where it escalates would be great. First the
    complaints to the ISP.. then the ISP monitoring.. then the ISP
    shutting down or possibly moving to strikeback.
    > While there a many questions to all of this, the only way for us to
    > get an answer is to talk about it and explore the possibilities- and
    > that is my intention in all of this.
    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:00 PST