One sec, starting a relationship with $CPEvendor... I'll let you know how this goes.
"Yes, every customer I went to had malware. That's okay, right?" ;) On Oct 22, 2016 5:56 PM, "Mark Andrews" <ma...@isc.org> wrote: > > In message <CAC6=tfYKBWBXMFHJo617q_qOMuOjEtoTDGK2pepfrMw3CybFuw@ > mail.gmail.com> > , Josh Reynolds writes: > > > > And then what? > > They get in someone to clean up their network. When they say it > is clean you reconnect them. If this happens more often than once > a year you charge them a months fees per additional incident. Have > the year timer start when reconnect is requested. You give them > what data you have to backup the claim. > > > The labor to clean up this mess is not free. Who's > > responsibility is it? The grandma who got a webcam for Christmas to watch > > the squirrels? The ISP?... No... The vendor? What if the vendor had > > released a patch to fix the issue months back, and grandma hadn't > installed > > it? > > > > Making grandma and auntie Em responsible for the IT things in their house > > is likely not going to go well. > > > > > Making the vendor responsible might work for the reputable ones to a > point, > > but won't work for the fly by night shops that will sell the same > products > > under different company names and model names until they get sued or "one > > starred" into oblivion. Then they just change names and start all over. > > > > The ISPs won't do it because of the cost to fix... The labor and > potential > > loss of customers. > > > > So once identified, how do you suggest this gets fixed? > > > > On Oct 22, 2016 5:11 PM, "Mark Andrews" <ma...@isc.org> wrote: > > > > > > One way to deal with this would be for ISP's to purchase DoS attacks > > against their own servers (not necessarially hosted on your own > > network) then look at which connections from their network attacking > > these machines then quarantine these connections after a delay > > period so that attacks can't be corollated with quarantine actions > > easily. > > > > This doesn't require a ISP to attempt to break into a customers > > machine to identify them. It may take several runs to identify > > most of the connections associated with a DoS provider. > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > --94eb2c030b6c594dc5053f7b994f > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > > <p dir=3D"ltr">And then what? The labor to clean up this mess is not > free. = > > Who's responsibility is it? The grandma who got a webcam for > Christmas = > > to watch the squirrels? The ISP?... No... The vendor? What if the vendor > ha= > > d released a patch to fix the issue months back, and grandma hadn't > ins= > > talled it?</p> > > <p dir=3D"ltr">Making grandma and auntie Em responsible for the IT > things i= > > n their house is likely not going to go well.</p> > > <p dir=3D"ltr">Making the vendor responsible might work for the > reputable o= > > nes to a point, but won't work for the fly by night shops that will > sel= > > l the same products under different company names and model names until > the= > > y get sued or "one starred" into oblivion. Then they just > change = > > names and start all over.</p> > > <p dir=3D"ltr">The ISPs won't do it because of the cost to fix... > The l= > > abor and potential loss of customers.</p> > > <p dir=3D"ltr">So once identified, how do you suggest this gets > fixed?</p> > > <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Oct 22, > 2016 5= > > :11 PM, "Mark Andrews" <<a href=3D"mailto:ma...@isc.org";> > marka= > > @isc.org</a>> wrote:<br type=3D"attribution"><blockquote > class=3D"quote"= > > style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"><b= > > r> > > One way to deal with this would be for ISP's to purchase DoS > attacks<br= > > > > > against their own servers (not necessarially hosted on your own<br> > > network) then look at which connections from their network attacking<br> > > these machines then quarantine these connections after a delay<br> > > period so that attacks can't be corollated with quarantine > actions<br> > > easily.<br> > > <br> > > This doesn't require a ISP to attempt to break into a customers<br> > > machine to identify them.=C2=A0 It may take several runs to identify<br> > > most of the connections associated with a DoS provider.<br> > > <font color=3D"#888888"><br> > > --<br> > > Mark Andrews, ISC<br> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > > PHONE: <a href=3D"tel:%2B61%202%209871%204742" > value=3D"+61298714742">+61 2= > > 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > =C2= > > =A0INTERNET: <a href=3D"mailto:ma...@isc.org";>ma...@isc.org</a><br> > > </font></blockquote></div><br></div> > > > > --94eb2c030b6c594dc5053f7b994f-- > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
