> I believe the question was pretty clear, > and so is the answer: > > + No -- today's networking products do not solve for this problem space. > > (Problem == client side payloads obfuscated to be later > de-obfuscated and executed utilizing some scripting foo)
I think everyone can agree on this. > So, a "trustworthy network IPS" doesn't solve, > for this (or other webappsec issue). It is but one component of an overall security architecture. You can scrutinize each piece individually and say it doesn't solve a problem and leave it at that, or you can look at how several components together can reduce your risk. As I mentioned, the network IPS is not really designed to solve this particular problem. In fact, during my years at NFR, I spent many conversations trying to convince various industry wonks that the client-side war cannot be won solely at the perimeter. We were among the few vendors who did not try to hoodwink customers into believing our network solution also protected them at the host/AV/webapp level. But, for its part, network IPS can at least help the cause with these actions: - alert/prevent unusual behavior as a result of a compromised client, - ensure your own web servers don't exacerbate the risk by being compromised, - perhaps do some limited NAC and rogue application prevention - look for telltale signs of very basic/common client-side vulnerabilities, thus reducing the garbage that the more specialized software must examine, - forbid certain file types (JS, ASX, etc.), if you so choose (very effective, although almost nobody can afford to do this anymore), - some limited DOM processing, as some other vendors have chimed in with. > An endpoint IPS might. I have limited experiences > with these (they won't, obviously, solve for the > webappsec issues leading to the planting and > distribution of said obfuscated hostile code). There is a lot of work being done in this arena, and I'd agree with the original poster that it's probably where some of the most thorough client-side prevention is/will be done. > > A "locked down browser"? Where do I get one of those? > Speaking from one security professional to another, it is sufficient to just say "do it yourself" and you should know what I mean. (Use NoScript, Tamper Data, a virtualized browser, trust no sites by default, disable all the fun features, etc. and generally degrade your browsing convenience in the name of security.) I realize it's tougher when you're responsible for 1000's of users. However, it seems a bit like you're subscribing to the Perfect Solution Fallacy; just because we all know the concept of a secure browser is comical does not mean that current measures are totally worthless. This thread was destined to become hypothetical from the get-go. BTW yes, my company does have a product (in beta now) that is relevant to this part of the discussion. It is called ZoneAlarm Forcefield. However, I work on the network IPS side and really haven't played with it much, so I don't yet know how much of this theoretical stuff it does or aspires to do. > The DOM-proxy thing is technically feasible, > sure. However with the advent of rich media > and other web 2.0 stuffs both the technology > and the performance overhead of this problem > is getting much harder, much faster than the > feasibility of an inline DOM-based parser. > > I like your comment about yesterday's news; > if things don't improve I too expect in the next > few years we'll see some changes to the browser > model sooner than we will see > inline-browser-emulation-for-security solutions. Hmmm... interesting. Like maybe a completely virtualized, remote browsing experience, via some kind of ASP that hosts all the browsers? That could be cool. I doubt anyone will ever protect people from themselves, though, and in that sense phishing and data leakage will always, always be around. > > Not that someone won't try it. > Exactly what I was thinking... not saying it's the greatest idea since sliced bread, but it'll eventually be feasible, and once it is, someone will productize it. And lots of people will buy it, primarily because it will promise a point solution for a distributed problem. -MAB > ciao > > -- > Arian Evans > software security stuff > > > > On Thu, Feb 14, 2008 at 1:18 PM, Mike Barkett > <[EMAIL PROTECTED]> wrote: > > You're really talking about the difference between client-based > protections > > and server-based protections. Let's not throw the baby out with the > > bathwater; network IDS/IPS does much more than just "AV style malware > > signatures for malicious web server issues." Most of today's IPS > products > > can quite deftly clean out a vast array of types of malicious activity, > > whether automated or not, across a bevy of network protocols, not just > web. > > > > Regarding inline JS inspection, I've said it before and I still believe > that > > one day there will be a full DOM proxy product that is capable of > running > > inline. Yes, its speeds will lag other network devices, and yes, > browser > > attacks will probably be yesterday's news by then anyway, but it would > be > > foolish to suggest that it is theoretically impossible to do. In the > > meantime, if you have embraced defense-in-depth and gotten yourself a > > trustworthy network IPS, a thorough endpoint solution, and you use only > > locked down browsers, then you'll be ok. > > > > -MAB > > > > > > -- > > Michael A Barkett, CISSP > > IPS Security Engineering Director > > Check Point Software Technologies > > +1.240.632.9000 Fax: +1.240.747.3512 > > > > > > > > > -----Original Message----- > > > > > > > > > Are any current network based IDS/P systems able to unwind > > > obfuscated web script to examine the final javascript product? > > > It would seem they would have to have a javascript engine to > > > do so and issues with reassembly, iterations, and delays > > > would preclude them from doing it inline. > > > > > > Without this capability, it would seem that network based > > > IDS/IPS is destined to digress to AV style malware > > > signatures for malicious web server issues and that the only > > > reliable place to do IDS/P would be on the host. > > > > > > We've been seeing more and more obfuscated web script and > > > according to a recently released IBM report, the majority > > > of exploits are taking this path. > > > > > > http://www.iss.net/x-force_report_images/2008/index.html > > > > > > Thoughts? > > > > > > -- > > > Gary Flynn > > > Security Engineer > > > James Madison University > > > www.jmu.edu/computing/security > > ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw to learn more. ------------------------------------------------------------------------
