[Discussion] What are we making? -- CLIENT Side
robert.jamison at bt.com
robert.jamison at bt.com
Tue Oct 21 22:44:17 UTC 2008
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
-----Original Message-----
From: discussion-bounces at openinfosecfoundation.org
[mailto:discussion-bounces at openinfosecfoundation.org] On Behalf Of Matt
Jonkman
Sent: Sunday, October 19, 2008 12:48 PM
To: Martin Holste
Cc: discussion at openinfosecfoundation.org; rMslade at shaw.ca
Subject: Re: [Discussion] What are we making? -- CLIENT Side
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-monito
r.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