[nsp-sec] [ OT ] MacOS X malware

[Smith, Donald]

I agree with the basic concept but will let others decide on how to
implement it with the least end user effect.
This is one of the reasons I run netflow reports on systems reported
here.
I could run reports for everything reported here but do try to validate
the src ips are actually up to something (not spoofed).
I would appreciate it if others that have the ability to validate some
of the reports would also write in stating that the src ips were
validated (or not...).

This isn't a trust issue it is an input validation/verification issue.

ps. plz don't kick me off the list either:)


RM=for(1)
{manage_risk(identify_risk(product[i++]) &&
(identify_threat[product[i++]))}
Donald.Smith at qwest.com giac 

> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net 
> [mailto:nsp-security-bounces at puck.nether.net] On Behalf Of 
> Joel Rosenblatt
> Sent: Thursday, April 03, 2008 12:02 PM
> To: Rob Thomas
> Cc: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] [ OT ] MacOS X malware
> 
> ----------- nsp-security Confidential --------
> 
> Hi,
> 
> At the risk of getting booted off this list, how about adding 
> a column before the comment field that was a confidence value 
> - let's say from 1-5.  That way we 
> would only have to download 1 all-inclusive file and we could 
> each decide how close to the edge we want to run.
> 
> I realize that this will be a BPITA  for all of us with 
> automated systems that parse this file (myself included) - 
> but it may be a much better way of doing it 
> than having separate files that may have to be merged.
> 
> My 2 cents
> 
> (please don't boot me off :-)
> 
> Joel
> 
> --On Thursday, April 03, 2008 12:13 PM -0500 Rob Thomas 
> <robt at cymru.com> wrote:
> 
> > ----------- nsp-security Confidential --------
> >
> > Hi, team.
> >
> > It's a concept we've discussed in the past.  It has challenges, but
> > we'll give it another round of noodling.
> >
> > Thanks,
> > Rob.
> >
> >
> > John Fraizer wrote:
> >>
> >> Agreed.
> >>
> >> It would be very cool if one of those feeds included 
> things that had nasty stuff like this but also happened to 
> have the "services" bit set and as a result
> >> were not listed in DDoS-RS.
> >>
> >> John
> >>
> >> David Freedman wrote:
> >>> ----------- nsp-security Confidential --------
> >>
> >>> I think there is a very valid point here,  RBLs maintain 
> lists of varying levels of "questionability" which are implemented on
> >>> and entirely "opt-in" basis, whereby if you do not agree 
> with the listing you simply do not use the list.
> >>
> >>> I suggest Cymru adopt a similar set of "more 
> questionable" feeds which we can choose to use or not 
> (providing we don't complain what is on them or ask for
> >>> anything to be removed without a damn good reason)
> >>
> >>> Dave.
> >
> > --
> > Rob Thomas
> > Team Cymru
> > The WHO and WHY team
> > http://www.team-cymru.org/
> >
> >
> >
> > _______________________________________________
> > nsp-security mailing list
> > nsp-security at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/nsp-security
> >
> > Please do not Forward, CC, or BCC this E-mail outside of 
> the nsp-security
> > community. Confidentiality is essential for effective 
> Internet security counter-measures.
> > _______________________________________________
> 
> 
> 
> Joel Rosenblatt, Manager Network & Computer Security
> Columbia Information Security Office (CISO)
> Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> http://www.columbia.edu/~joel
> 
> 
> 
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
> 
> Please do not Forward, CC, or BCC this E-mail outside of the 
> nsp-security
> community. Confidentiality is essential for effective 
> Internet security counter-measures.
> _______________________________________________
> 
> 


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.