[Discussion] What are we making? -- CLIENT Side

CunningPike cunningpike at gmail.com
Mon Oct 27 19:34:58 UTC 2008


I would like to see some aggregation of alert categorizations from sguil
consoles. This could provide information on false positives, new spyware
hosts etc.

CP


On Fri, 2008-10-24 at 11:45 -0400, Matt Jonkman wrote:
> Martin Holste wrote:
> > I like the idea, but are there really that many different actions to be
> > taken, and aren't they going to be org specific?  If I know that an IP
> > is spamming, I don't just want to block them from emailing, I want to
> > block all access from that IP since it is untrustworthy. 
> 
> I want the ip reputation data to be categorized. For instance the IP
> would have a reputation number in spam, phishing, malware host, CnC,
> known bot, scanner, etc. Maybe stuff to cover underground forums, whatever.
> 
> There'd be an average score amassing all of the categories, and the end
> user could weight each category to be more an influence on the average,
> or even just make block decisions on a few categories they're interested
> in.
> 
> That make sense? So if I ran a mail farm I could weight the spam
> category very high, or just look at that alone. Or if I were protecting
> a net of users I'd probably take the average but weight the CnC and
> Malware hosts higher.
> 
> Matt
> 
> 
>  But I do think
> > there is a lot of value in developing and distributing better language
> > for describing why the given IP/host is now on the list and other
> > descriptions.  I'm more for giving orgs the most information that we
> > can, and leaving it to them to implement the actual blocking decisions.
> > 
> > --Martin
> > 
> > On Wed, Oct 22, 2008 at 5:35 PM, Blake Hartstein <urule99 at gmail.com
> > <mailto:urule99 at gmail.com>> wrote:
> > 
> >     What if we focus on developing and distributing a better language for
> >     communicating actionable events?
> >     The idea is to make all intelligence more valuable and immediate. If I
> >     see this input event, alert, network, ISP, javascript, URL, how does it
> >     impact me, and what do I do about it? Instead of just collecting and
> >     distributing, the goal is to direct the actions for (ISP takedown,
> >     firewall, admin action, more). This enhances all of the prior research
> >     we've already done.
> > 
> > 
> >     Blake
> > 
> > 
> > 
> >     robert.jamison at bt.com <mailto:robert.jamison at bt.com> wrote:
> >     > It seems we're a split camp with:
> >     >
> >     > [Keynesian CAMP]
> >     > Client Side Product/Service with ability to protect/detect
> >     compromise on
> >     > grannyx home user
> >     > *scope most thoroughly represented by Martin's " RFC: Proposal for
> >     > Analysis Framework"
> >     >
> >     > [Supply Side CAMP]
> >     > Focus on server side protection for net critical assets
> >     > *Andre/Jack "What is absolutely horrible in its current state is
> >     > IDS/IPS" / "Client side is simply not possible due to political and
> >     > religious issues."
> >     >
> >     > Additional notes gathered (I've just caught up on my reading;-)
> >     >
> >     > (a) Consideration for re-write defanging capability as inline
> >     protection
> >     > (b) Efficiency in stream storage--essentially normalize data
> >     inspection
> >     > so it doesn't have to be redone by multiple engines
> >     > (c) XML vs. Binary distribution of verbose alerts vs. instruction
> >     > inferred datapoints
> >     > (d) Consideration for extending existing project Bro
> >     >
> >     > Anything I'm missing?
> >     >
> >     > Rob
> > 
> > 
> 




More information about the Discussion mailing list