[Discussion] What are we making? -- CLIENT Side
David Glosser
david.glosser at gmail.com
Sun Oct 19 18:15:21 UTC 2008
Getting the information out could be in multiple formats - static
stuff like XML, null routes, dns blocklists, even the dreaded
host-file...
More dynamic stuff could be BGP, DNS (or partner with opendns), etc.
On Sun, Oct 19, 2008 at 2:06 PM, Martin Holste <mcholste at gmail.com> wrote:
> Yes, exactly, well put. What about chartering a CVE-inspired protocol for
> our blacklists? I think someone mentioned there was an IETF draft or
> something for that that didn't get off the ground. A specification could be
> as simple as a DTD for XML blacklists like:
>
> <blacklist>
> <ip ID=1>
> <date_added />
> <list_id />
> <date_added />
> <date_of_first_offense />
> <address>x.x.x.x</address>
> <added_by />
> <reason />
> <confidence />
> <date_last_blocked />
> </ip>
> </blacklist>
>
> Or whatever--you get the idea. I think that the really cool part would be
> if the "reason" tag referred to an actual event uploaded in a snortsam-like
> way to a community event database.
>
> Providing a standard blacklist definition would make it much easier for orgs
> to write their own filters for what blacklist items they want to block on,
> which would lead to higher adoption rates. To further accelerate adoption,
> the community could even parse other publicly available lists at the start
> and republish them in the new standard until those sources natively publish
> in the standard.
>
> --Martin
>
> On Sun, Oct 19, 2008 at 12:50 PM, David Glosser <david.glosser at gmail.com>
> wrote:
>>
>> How about if a subset of the data (IP blacklists, domain blacklists,
>> etc) is made available to the googles of the world, Granny's isps,
>> browser-plug-in writers of the world, and desktop-based software. Then
>> granny can be protected on the desktop, her ISP, etc.
>>
>>
>>
>>
>> On Sun, Oct 19, 2008 at 1:18 PM, Martin Holste <mcholste at gmail.com> wrote:
>> > I vehemently agree with Matt about the necessity of staying out of the
>> > client-side arena. I think that if we're going to actually produce
>> > anything
>> > of value, we need to narrow the scope to start with. My vote is that we
>> > consider notifying Granny that there's something bad on her PC out of
>> > scope
>> > until we figure out how to notify Granny's ISP's network security admin
>> > that
>> > there's something bad. If we can figure out how to reliably find
>> > successful
>> > compromises and get that information output as actionable intelligence
>> > to
>> > the netsec community, the rest will come in time.
>> >
>> > For instance, if we can get to the point where we're %99.99 sure that a
>> > given URL is bad, then we could work on setting up an alliance with a
>> > place
>> > like Google, which already has an infrastructure for end-user
>> > notification
>> > of bad sites (as in, the "this site may harm your computer" displayed
>> > under
>> > links to sql injected pages). I'm sure Neils Provos would be interested
>> > in
>> > hints from this group. I would say that blackhat SEO is 80% of the
>> > malware
>> > infection vector right now, so that would be huge.
>> >
>> > Someday even farther in the future, we could use a platform like OSSEC
>> > HIDS
>> > to deliver our blacklists, or a browser plugin, but that is a carrot on
>> > a
>> > stick for another day.
>> >
>> > The point is that we need to start by doing one thing and doing it well:
>> > provide the most accurate method of network-based detection and
>> > prevention
>> > of compromises to date by leveraging the collective wisdom of the
>> > community.
>> >
>> > On Sun, Oct 19, 2008 at 11:48 AM, Matt Jonkman <jonkman at jonkmans.com>
>> > wrote:
>> >>
>> >> Martin Holste wrote:
>> >> > I'm guessing that the intent is to be the "detection" component of
>> >> > the
>> >> > Trusted Internet Connection (TIC)
>> >> >
>> >> >
>> >> > (http://taosecurity.blogspot.com/2007/12/feds-plan-to-reduce-then-monitor.html),
>> >> > in which the mandate is to protect all federal assets, especially the
>> >> > federal desktop environment.
>> >>
>> >> Certainly a sound approach to tackle such a problem. Glad I don't have
>> >> to solve that one, it's huge among gov't agencies. Especially in the
>> >> US,
>> >> but surely similar everywhere.
>> >>
>> >>
>> >> Even if DHS has different goals, I think
>> >> > that this group could do a great service by providing the TIC's
>> >> > protection geared toward the client-side, and I think for most
>> >> > sectors,
>> >> > that's where the most imminent threats lie. Again, I'm certainly not
>> >> > saying that defending servers is out of scope, just that IDS has
>> >> > historically been about defending servers as the primary goal, with
>> >> > clients secondary, and I think that needs to be reversed now.
>> >>
>> >> I agree. At emerging threats we've been lately heavy into
>> >> post-infection
>> >> signatures in our research. There are many vulnerabilities out there in
>> >> client apps, but I'd venture to say that a very high percentage of the
>> >> infections out there aren't the result of a remotely exploitable
>> >> vulnerability. Most come from users clicking on email attachments,
>> >> installing fake software/codecs, and visiting websites with hostile
>> >> code.
>> >>
>> >> We've tried many times to write effective signatures to detect hostile
>> >> html/java/gifs, etc. It's just not feasible as is. Code is too flexible
>> >> for signature-based approaches. You can say the same thing a hundred
>> >> ways, especially in html.
>> >>
>> >> So how can we go after client side?
>> >>
>> >> I really REALLY am not excited about trying to make a windows client.
>> >> Not only does that open up a huge responsibility in support and the
>> >> inevitable bluescreens, but I have had a difficult time over the years
>> >> believing that any process on ANY os (especially windows) could be
>> >> trusted and independant enough to watch itself. Take into account how
>> >> easy it is for trojans and rootkits to shut down antivirus, or blind
>> >> it.
>> >> And these are products with hundreds of the most skilled coders around
>> >> working on them.
>> >>
>> >> I know we're sharp as a community, but I don't think that's a battle we
>> >> want to get in to. So how can we do it at the network layer?
>> >>
>> >> Sandboxing?
>> >>
>> >> Virtual emulators?
>> >>
>> >> Or do we continue the thinking that for any infection to be of any use
>> >> to anyone it has to generate traffic? It has to call home, send spam,
>> >> report stolen information, something. So we concentrate on detecting
>> >> and
>> >> stopping the post infection?
>> >>
>> >> What does everyone think about that?
>> >>
>> >> Matt
>> >>
>> >>
>> >> >
>> >> > --Martin
>> >> >
>> >> > On Sat, Oct 18, 2008 at 9:31 PM, Andre Ludwig <aludwig at packetspy.com
>> >> > <mailto:aludwig at packetspy.com>> wrote:
>> >> >
>> >> > I doubt the intent of the DHS is to simply do good, they are most
>> >> > likely
>> >> > much more focused on producing technology that allows them to
>> >> > detect/mitigate/prevent attacks against critical components.
>> >> > This
>> >> > of
>> >> > course means detecting attacks that fly below the threshold of
>> >> > detection
>> >> > for todays technology. If it comes to "doing good" or detecting
>> >> > state
>> >> > sponsored attacks against critical components (think custom
>> >> > attacks
>> >> > against unknown vulns), i'm going to go out on a limb and say
>> >> > they
>> >> > would
>> >> > rather protect the critical component vs the enduser.
>> >> >
>> >> > What you are discussing still has value and merit but im not so
>> >> > sure
>> >> > it
>> >> > is what should be focused on, but of course I am not the person
>> >> > to
>> >> > decide such things.
>> >> >
>> >> > Andre
>> >> >
>> >> >
>> >> > Rob, grandpa of Ryan, Trevor, Devon & Hannah wrote:
>> >> > > Question: what are we making? Oh, yeah, I read the blurb: "The
>> >> > OISF has been
>> >> > > chartered and funded to build a next-generation intrusion
>> >> > detection and prevention
>> >> > > engine. This project will consider every new and existing
>> >> > technology, concept and
>> >> > > idea to build a completely open source licensed engine."
>> >> > >
>> >> > > OK, we're making an IDS. But I think we need to be more
>> >> > specific.
>> >> > In particular,
>> >> > > we need to answer the question of "who."
>> >> > >
>> >> > > Since the DHS has provided money, I suspect there would be an
>> >> > automatic
>> >> > > assumption that this is a heavy-duty device intended for use to
>> >> > protect major
>> >> > > servers and nodes in the critical information infrastructure.
>> >> > (Whatever that
>> >> > > means.) This kind of thing is built by professionals, for
>> >> > professionals. Trained
>> >> > > people.
>> >> > >
>> >> > > However, given the current computing environment, I think it
>> >> > would
>> >> > be relatively
>> >> > > easy to make a case that such a device is not going to do all
>> >> > that
>> >> > much good. That
>> >> > > a more accessible device, intended for "Grannyx" users, would
>> >> > actually do more to
>> >> > > protect the infrastructure. After all, it isn't major nodes on
>> >> > the net that make up
>> >> > > botnets, it's the little guys. Protect them, and you reduce
>> >> > the
>> >> > threat. This is the
>> >> > > "low hanging fruit" for the blackhats, so protecting that crop
>> >> > is
>> >> > going to give us
>> >> > > the greatest benefit for the commitment of resources.
>> >> > >
>> >> > > This makes a difference. Not, perhaps, in terms of questions
>> >> > about multithreading
>> >> > > analysis streams using graphics co-processors. But certainly
>> >> > in
>> >> > most other areas.
>> >> > >
>> >> > > We've talked about extensibility. If we create a standard
>> >> > template or format for
>> >> > > signatures, the "who" makes a difference. Professionals need a
>> >> > warning and a
>> >> > > packet. Grannyx users need a warning, no packet, a clear
>> >> > explanation of what and
>> >> > > how important, and a recommended course of action. Makes a
>> >> > difference to the
>> >> > > template.
>> >> > >
>> >> > > In terms of my recommendation of a paran-o-meter, it makes a
>> >> > difference.
>> >> > > Actually, I see huge debates over initial settings: do we keep
>> >> > it
>> >> > low to keep from
>> >> > > crying wolf, or keep it high to keep people as safe as
>> >> > possible.
>> >> > But one thing that
>> >> > > should be done is make the paranoia settings not-quite-obvious
>> >> > up
>> >> > front, so that
>> >> > > somebody needs to know a little about the implications before
>> >> > they
>> >> > start fiddling
>> >> > > with settings.
>> >> > >
>> >> > > Heck, if it's a professional device, we don't need to worry
>> >> > about
>> >> > the interface at
>> >> > > all. If it's for Granny, we definitely do.
>> >> > >
>> >> > > It also makes a difference in terms of the technology to be
>> >> > included. If it is for
>> >> > > professionals, we can throw in everything. If for Granny, we
>> >> > need
>> >> > to make a
>> >> > > careful choice about maximum protection for minimum performance
>> >> > drain.
>> >> > >
>> >> > > ====================== (quote inserted randomly by Pegasus
>> >> > Mailer)
>> >> > > rslade at vcn.bc.ca <mailto:rslade at vcn.bc.ca>
>> >> > slade at victoria.tc.ca <mailto:slade at victoria.tc.ca>
>> >> > rslade at computercrime.org <mailto:rslade at computercrime.org>
>> >> > > I'm getting so absent-minded that sometimes in the
>> >> > middle
>> >> > of
>> >> > > victoria.tc.ca/techrev/rms.htm
>> >> > <http://victoria.tc.ca/techrev/rms.htm>
>> >> > blogs.securiteam.com/index.php/archives/author/p1/
>> >> > <http://blogs.securiteam.com/index.php/archives/author/p1/>
>> >> > > _______________________________________________
>> >> > > Discussion mailing list
>> >> > > Discussion at openinfosecfoundation.org
>> >> > <mailto:Discussion at openinfosecfoundation.org>
>> >> > >
>> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> > >
>> >> > >
>> >> >
>> >> > _______________________________________________
>> >> > Discussion mailing list
>> >> > Discussion at openinfosecfoundation.org
>> >> > <mailto:Discussion at openinfosecfoundation.org>
>> >> >
>> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------
>> >> >
>> >> > _______________________________________________
>> >> > Discussion mailing list
>> >> > Discussion at openinfosecfoundation.org
>> >> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >>
>> >> --
>> >> --------------------------------------------
>> >> Matthew Jonkman
>> >> Emerging Threats
>> >> Phone 765-429-0398
>> >> Fax 312-264-0205
>> >> http://www.emergingthreats.net
>> >> --------------------------------------------
>> >>
>> >> PGP: http://www.jonkmans.com/mattjonkman.asc
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Discussion mailing list
>> > Discussion at openinfosecfoundation.org
>> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>> >
>> >
>
>
More information about the Discussion
mailing list