[Dshield] Possible solution for ISP (was DShield's public goals)

Blanchard, Joe Joe.Blanchard at bsci.com
Fri Jan 13 21:10:00 GMT 2006



Hi

Interesting topic. One thing I believe being missed is the current
mechanics for simuliar items. Lets take, for instance, Spam. While
this is not a common list shared by all ISPs, it seems to have become
such a burden that a few bother enforcing such. If it were truly the
case, then those household names associated with spam would not
be able to re-register with other ISPs. But, assuming that they (ISPs)
did adhere to some common list, what would prevent those diehards (users)
from getting access under alternate means? I don't imagen we'll see
finger printing as part of a sign up contract anytime soon. 
My own opinion in this matter is user awareness. If some of the
providers require a signed contract that holds a user liable for damages
(security deposit maybe?) perhaps those folks would be a bit more
cautious. Regardless, you still have those ISPs outside the US that
seem more than willing to offer service no questions asked. Until those
companies see any profit from such, you'd have better luck getting
the software and OS companies to secure their code better.

Regards, 
-Joe Blanchard




> ----------
> From: 	list-bounces at lists.dshield.org[SMTP:list-bounces at lists.dshield.org] on behalf of Laura Vance[SMTP:vancel at winfreeacademy.com]
> Sent: 	Friday, January 13, 2006 12:49 PM
> To: 	General DShield Discussion List
> Subject: 	Re: [Dshield] Possible solution for ISP (was DShield's public	goals)
> 
> Then we will discuss. :)
> 
> The specific operating systems will become irrelevant to the ISP, 
> because they will not have to support the cleaning or disinfecting of 
> the machine.  That would be done by a 3rd party that has been certified 
> as ok to do so by the ISP group.  This could also remove all tech 
> support issues that arise from anything other than connection-specific 
> issues.  If a user has a problem that doesn't deal directly with their 
> connection to the Internet, the support would go to one of these 3rd 
> party companies (Best Buy, CompUSA, Geeks on Call, Joe's Linux Computer 
> Repair, Ma's Mac Shop, etc).  Half of the time, the ISP will tell the 
> user to reinstall their OS anyway when there is a more serious problem 
> than resetting a configuration tool, so these companies being part of 
> the list of companies allowed to certify the user/machine could be a 
> simple process.  Do they know how to install/update a virus scanner?  Do 
> they know how to check settings?  Do they know how to reinstall an OS?  
> If they can do those things, they would be allowed to certify that users 
> are ready to go back online... and possibly even remove them from the 
> "bad" list if the ISP's don't want that responsibility.
> 
> The idea that one individual or one organization has to keep up with the 
> list is a little off the mark with what I'm thinking.  My idea is that 
> it's a real-time system that all participants can update the 
> information.  The only centralized administration would be adding and 
> removing login's (ISPs and repair companies).  If user X gets booted 
> from ISP Y, then he tries to connect to ISP Z.... ISP Z will see that he 
> was booted and let him know how to get off the list (restating what ISP 
> Y should've already told him).  User X then does what is necessary 
> (Geeks on Call, whatever), then decides that he wants to go with ISP 
> A... ISP A will check and see that he's OK now and he gets signed up.... 
> all real-time... all up to the user.  If Geeks on Call doesn't update 
> his record from "bad" to "educated", then it's user X's responsibility 
> to call Geeks on Call and tell them to update his record.  The data will 
> only get stale if the user allows it to get stale.  Unlike the credit 
> reporting agency or the TSA, it doesn't take forms in triplicate to 8 
> different agencies to get taken off the list... the company that fixed > 
> user X can adjust his status in the database immediately.... very likely 
> before user X leaves the shop... or the Geek on call can log in with 
> their handheld and update the list... or call the office and have 
> someone there do it.  In case your wondering, only authorized users will 
> have a login to the system, and that login security would be tight.
> 
> The reason that a central database would be good is because it would 
> prevent a situation where ISP A really wants to keep their users secure 
> and allow full access both inbound and outbound, so they limit access to 
> infected machines.  Several people have already brought up the case 
> where the user that was limited will just go to a different ISP that 
> doesn't care.  If there were a centralized system, users would be less 
> able to jump from ISP to ISP without cleaning their computer.  You could 
> almost compare it to the licensing system that was mentioned earlier, 
> but instead of fishing license comparison, compare it to drivers 
> license.  If you do enough bad, your license is revoked.  If you move to 
> a different city/county/state/country, your record follows you, so 
> likely will not get a license.  Again, the TSA tries to foretell evil, 
> this only bases on actual activity.  DMV's don't deny you a license 
> because you *might* hit a school bus, just like this one will not deny 
> you ISP access because you *might* get infected.  The TSA comparison is 
> completely invalid, because the TSA system is preventive, this one is 
> not.  It doesn't try to magically figure out if you're going to get 
> infected, it waits until you do.  The TSA cannot wait until someone 
> bombs an airplane, the system that I'm talking about has the luxury of 
> waiting for evidence in the form of activity logs before they are put on 
> the list.  The only thing that's the same about this system and the TSA 
> system is that they are both computer systems that track people... other 
> than that, they are completely different.  There are millions of 
> computer systems that track people, but almost none of them are like the 
> TSA system.
> 
> 


More information about the list mailing list