From the responses received so far, it seems like most are focusing on the endpoints. There was a paper from just over a year ago that is tangentially related. http://web.proetus.com/reference/bns.html Interesting concept that could come into play at just this sort of situation, except direct action to the host isn't taken but alerts automatically passed to the upstream provider, who can then filter. It's all conceptual, though. On Sunday, May 18, 2003, at 07:33 PM, Rob Shein wrote: > What is being done with respect to Fizzer is rather different from > "engaging > the attacker" or even scanning large sections of the internet to find > compromised hosts in pursuit of fixing them. The method being used is > neither active nor aggressive, and here is the key difference. I > think the > likelihood of harming others is far less in this scenario, and I doubt > that > there is even a potential legal issue either, for that matter. As the > virus > reaches out for an update from a known location, here there was the > opportunity to cause the virus to elegantly commit suicide; there is > no way > that the code would accidentally be run on an uninfected machine > except with > the direct participation of that machine's owner. > > -----Original Message----- > From: Dan Hanson [mailto:dhansonat_private] > Sent: Saturday, May 17, 2003 12:28 AM > To: incidentsat_private > Subject: A question for the list... > > > As part of incident handling and response, most of us have had to > respond to > virus infections that have affected networks and hosts. Reports are > circulating that members of the IRC operator community have > distributed code > through the update mechanism of the Fizzer virus. The code reportedly > attempts to remove the virus from the host. The latest information > seems to > indicate that the "update" code was removed until further testing can > be > done and more discussion regarding the legalities of this are had. > > At last year's Blackhat conference in Las Vegas, Tim Mullen presented > what > turned out to be a very controversial proposal. Briefly, he questioned > why > it would be inappropriate to strike back and disable (if not remove) a > worm > from hosts that are clearly not being adequately managed. > > The discussion, both in the session, and after, included those who > felt that > this was simply vigilanteism that has no place in the current world, > and > those who feel that there is a responsibility for someone to do > something to > try to maintain, if not improve, the security situation for those > connected > to the Internet. > > http://online.securityfocus.com/columnists/98 > http://www.blackhat.com/html/bh-usa-02/bh-usa-02- > speakers.html#Timothy%20Mul > len > http://www.securityfocus.com/columnists/134 > > It seems to me that a group finally took it upon themselves to do > exactly > what Tim was suggesting the community consider. But it appears that > they > have done it without any consultation of the community in general, and > if I > have read the reports correctly, with no authorization. > > Here is a link for a report on News.com and it contains some opinions > by > legal folk. http://news.com.com/2100-1002_3-1003894.html?tag=lh > > A bunch of ideas for discussion pop-up to me... some of these may not > be > totally on-topic for this forum, if you can tie something back into > incident > response, I'll likely allow it through. > > -What are the implications down the road? > > -Are there concerns that organizations have with this trend? Legal? > Precedure? > > -Is this any different than a similar activity that installs malicious > code > on the target host? > > -The approach that Tim advocated was significantly less intrusive than > the > approach taken with the Fizzer virus, Tim's approach made no > significant > changes on the targeted host, simply blocked the ability of Nimda to > replicate (if I remember correctly), and notify the owner that they > have > been compromised and where to go to find help in removing the > infection. The > approach taken to actually modify the system to remove Fizzer seems to > go > significantly past that. Why was the reaction to Tim's advocacy of > discussion so hostile, and to date, I have seen no negative criticism > of the > Fizzer removal. > > -Is this a catalyst for a group (IETF?) of some kind to debate these > issues > to find a resolution? I think that most people would agree that the > increasing risk that these distributed networks pose to every Internet > connected host is grave, and a better method is required to deal with > them. > Are there other ideas that don't get us into "arms races" with malcode > writers. > > -If this becomes standard practice, will this force the communication > and > update channels underground/encrypted (the "arms race" that I > mentioned) > > -What are some of the strategies that organizations are implementing to > control their exposure to these communication channels? > > -If a command can be given in a channel to "shut down" the network of > hosts, > what is the view on the legality of doing this? If you had a host on > your > network that was suddenly shut down by a well meaning (or not so well > meaning third party), what would your response be? > > I am not advocating the validity of one side over another, I just find > it > curious how similar the idea of Tim's, and the actual attempt to > remove the > virus, are. > > As an aside, I would like to keep the discussion on this civil. If > posts > become to flamey to oneside or the other (i think both sides have valid > ends) they will likely be rejected. > > D > > ----------------------------------------------------------------------- > ----- > *** Wireless LAN Policies for Security & Management - NEW White Paper > *** > Just like wired networks, wireless LANs require network security > policies > that are enforced to protect WLANs from known vulnerabilities and > threats. > Learn to design, implement and enforce WLAN security policies to > lockdown > enterprise WLANs. > > To get your FREE white paper visit us at: > http://www.securityfocus.com/AirDefense-incidents > ----------------------------------------------------------------------- > ----- > > > > ----------------------------------------------------------------------- > ----- > *** Wireless LAN Policies for Security & Management - NEW White Paper > *** > Just like wired networks, wireless LANs require network security > policies > that are enforced to protect WLANs from known vulnerabilities and > threats. > Learn to design, implement and enforce WLAN security policies to > lockdown enterprise WLANs. > > To get your FREE white paper visit us at: > http://www.securityfocus.com/AirDefense-incidents > ----------------------------------------------------------------------- > ----- > > -- Andy Shelley Cbeyond Communications andyat_private ---------------------------------------------------------------------------- *** Wireless LAN Policies for Security & Management - NEW White Paper *** Just like wired networks, wireless LANs require network security policies that are enforced to protect WLANs from known vulnerabilities and threats. Learn to design, implement and enforce WLAN security policies to lockdown enterprise WLANs. To get your FREE white paper visit us at: http://www.securityfocus.com/AirDefense-incidents ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Tue May 20 2003 - 12:38:15 PDT