[Discussion] What are we making? -- CLIENT Side
David Glosser
david.glosser at gmail.com
Sun Oct 19 17:50:18 UTC 2008
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