Re: On another security note... (of sorts)

On 7/19/10 10:21 AM, valdis.kletni...@vt.edu wrote: ... my credit card is declined and flagged (I find out later) by my bank's anti-fraud group because it's being used 3 states away from where it's usually used. ... Or in my recent case, I used my card multiple times in California in April, and

Re: On another security note... (of sorts)

On Mon, 19 Jul 2010 08:06:08 EDT, "J. Oquendo" said: > Maybe naivete on my part, but I don't see how customers would have > issues if the scenario/framework was concisely explained. It's one thing to be sitting in my office rationally discussing what my bank does to prevent credit card fraud, and

Re: On another security note... (of sorts)

On 7/16/10 11:17 PM, Dobbins, Roland wrote: The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined),

Re: On another security note... (of sorts)

On Jul 19, 2010, at 8:06 PM, J. Oquendo wrote: > Here is a semi-universal solution... Throw an N-Byte field into the TCP > protocol and label it "dirty" the dirty bit. ;> --- Roland Dobbin

Re: On another security note... (of sorts)

Dobbins, Roland wrote: > > The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined), skillset shortages/con

Re: On another security note... (of sorts)

On Jul 16, 2010, at 9:42 PM, Lamar Owen wrote: > I'm sure the collective wisdom here is capable of pulling the task off at > least in theory; The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined),

Re: On another security note... (of sorts)

On Thursday, July 15, 2010 02:40:50 pm Michael Holstein wrote: > > Why is it that network operators can't work together > > on instances like this and have a "botnet killswitch" > Trust (or lack thereof). That's certainly one of the biggest non-technical reasons. Others go by the acronyms NIH

Re: On another security note... (of sorts)

Sean Donelan wrote: > > Damned if they do, Damned if they don't. > > It seems like every 4-6 weeks people alternate between ISPs are bad > because they don't try to prevent X, Y or Z; and then 4-6 weeks later > ISPs are bad because they tried to prevent A, B or C. It doesn't matter > what A, B, C

Re: On another security note... (of sorts)

On Thu, 15 Jul 2010, valdis.kletni...@vt.edu wrote: On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said: RFP anyone.. Botnet Mitigation for Networks surely collectively it would and CAN work. A nice idea, but consider if a more automated tool/system was created to behead a botnet (50,000 null0

Re: On another security note... (of sorts)

On 7/15/2010 11:40 AM, Michael Holstein wrote: >> Why is it that network operators can't work together >> on instances like this and have a "botnet killswitch" > Trust (or lack thereof). If networking tools were designed properly it wouldn't matter... its about designing tools for the intentiona

Re: On another security note... (of sorts)

> Why is it that network operators can't work together > on instances like this and have a "botnet killswitch" Trust (or lack thereof). Cheers, Michael Holstein Cleveland State University

Re: On another security note... (of sorts)

On Thu, Jul 15, 2010 at 1:03 PM, wrote: > > Hint: Why do many sites refuse to accept automated BGP feeds from Cymru's > bogon list or RIR services? > The same reason many sites don't follow best practices and let spoofed packets leave their network, etc?

Re: On another security note... (of sorts)

On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said: > RFP anyone.. Botnet Mitigation for Networks surely collectively it would > and CAN work. A nice idea, but consider if a more automated tool/system was created to behead a botnet (50,000 null0 routes to blackhole all the nodes? Or accept colla

On another security note... (of sorts)

While on another list (security list that some of you guys are on) there is a discussion about a particular botnet that the "BP approach" of containment is occurring. Not a big deal, we've all seen them from time to time. I read with interest on how volunteers are scrambling to contain this botn