[Discussion] What are we making? -- CLIENT Side
Matt Jonkman
jonkman at jonkmans.com
Mon Oct 20 18:05:16 UTC 2008
As for scope: here's my plan. I definitely want us to push every idea
and sub-project we can here. We'll get it all on the list and consider
it all as a whole.
Down the road, closer to the time we'll start major coding, we can take
the entire list and as a community (maybe voting-style, who knows) and
whittle down to what we want in the initial release, what down the road,
what needs to be a separate project (and spawn those subprojects), and
what is just not feasible.
So keep the discussion going, lets not limit based on what might seem to
large a scope. We may end up moving our focus to be right in the middle
of feature X, we just don't know. We have time, lets explore everything
for a while and see where we end up.
Matt
Martin Holste 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
> <mailto: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>
> > <mailto: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>
> <mailto:rslade at vcn.bc.ca <mailto:rslade at vcn.bc.ca>>
> > slade at victoria.tc.ca <mailto:slade at victoria.tc.ca>
> <mailto:slade at victoria.tc.ca <mailto:slade at victoria.tc.ca>>
> > rslade at computercrime.org <mailto:rslade at computercrime.org>
> <mailto: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>
> > <http://victoria.tc.ca/techrev/rms.htm>
> > blogs.securiteam.com/index.php/archives/author/p1/
> <http://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>
> > <mailto: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>
> > <mailto: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
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
>
--
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------
PGP: http://www.jonkmans.com/mattjonkman.asc
More information about the Discussion
mailing list