IDS mailing list archives
Re: IDS vs Application Proxy Firewal
From: Omar Herrera <oherrera () prodigy net mx>
Date: Mon, 27 Oct 2008 21:21:34 -0600
Hi Arian, Arian J. Evans escribió:
Omar -- you have a very nice, well-thought-out, post below. Yet, philosophically, I could not agree with you less. BAD (behavioral anomaly detection) can be approached as either a blacklist or a whitelist. Though, to be fair, the cases for whitelisting in BAD fashion are fewer, and since in BAD you are talking statistical inference or deduction, there is a fuzzy, slippery slope between "black" and "white" listing.
True, my examples were only assuming bad detection, but white listing through automatic software has its flaws. You are not guaranteed to get a complete white list with an automatic tool because it can only take into account what it sees and what it measures. So this activity is time dependent and unless you try to guess if good or bad, you will end up reacting anyway. White lists should have human intervention to include as much context information to be effective, in my opinion.
I have used BAD's for years. I "wrote" my first network one for my apps on top of Network Instruments product "Expert Observer". I even ran it by folks like Marty R back in the early snort days. Marty even said it wouldn't work :) but his objection to the approach (like most against BAD) was context-specific. It did work well for me. I did not stop any compromises from starting, however.... I caught many in progress in time to shut them down or mitigate the damage from compromise quickly, if not completely. I did this in a way that no other commercial technology available at the time (that I was aware of) could by making sure my BAD alerted me to violations of our implied business case/rules.
Sure, using BAD is not necessarily bad :-). My argument is that white listing might prove more effective, and I recognize that it comes at a price (a price that some don't want or can't pay, like most individuals).
I /emphatically/ *do not* think that whitelists work for many people in the app space. The inherent problem is that the problem is too large and volatile. Business rules -- while fairly finite and "white' are implemented in software in a very dynamic and volatile fashion. Attempting to whitelist in a static fashion fails in the web software world in most cases. Attempting to whitelist in a dynamic fashion has been shown to fail over and over again as well. (Auto-learning engines may mature to solve this some day, but for now...no)
I've seen white listing schemes fail because they try to be generic. As soon as you get specific on your business the task gets much simpler. The problem is that you want to provide a solution (as a software/hardware or as a service) so that it will work for everyone you will inevitably get into these complexities. Take for example firewall rules; you see templates for common scenarios everywhere, yet most companies end up putting their own rules because they need to adapt them to their needs. That's the spirit of white listing, whether we are talking network, application or O.S. layer. Hey, it even works at user level, when we tell kids not to talk to anyone they don't know, rather than telling them not to talk to suspicious people :-).
I get the premise behind the superiority of whitelisting and why one might suggest this. Heck.... I have been down this promising path myself. The failure is that it tends to break down at the implementation level both with initial technical implementation -- and more importantly -- the ongoing care and feeding (operational) level required to keep whitelisting working. Blacklisting and signature solutions are far from perfect as any of us who fought through the IDS tuning of the 90's experienced fully. And yet we still used them because simple protocol whitelisting and enforcement was still a challenge then, and may still be today. Whitelisting business case of custom applications is exponentially more challenging.
Totally agree. The tools for whitelisting need a lot of improvement. Since we need to maintain whitelists ourselves, it would really help if tools were created with support and deployment in mind. Black list is easier for us, but not for the vendor, they had to put all this infrastructure to do their analyses and deploy signatures updates as fast as they can and with the least number of false positives and negatives. That's the reason why black list was as success, it is definitely more convenient for the end user and will allways be. The question we have about this Good vs. Bad approach basically: is blacklisting still good enough for all/some scenarios (i.e. provides a good cost-benefit balance)? I concur with you with application white listing. Once designed and deployed is most painful to put filters on it and maintain them, and if you have a mix of home made and commercial applications the task becomes a nightmare. I still think that there should be no excuse for not trying at least of implementing good filters at the design phase, but talking about administration some application level firewall might help. Different from their lower layer cousins, I see many people using application firewalls primarily as a black list device, using predefined detection signatures for XSS, SQL injection and the like, but many application level firewalls can also be used with white lists. You could define filters for inputs and outputs here, of both home made and commercial applications. I wouldn't use white lists for every application also. For example, I'll put filters for a home made Web application that is critical for business but not for the office package deployed in every workstation, simply because I don't have all the knowledge to do it and it might not be worth the effort.
I think Blacklisting wins here though the pragmatic simplicity that it is all we can reasonably afford to implement and keep working today. I will fully admit I could be wrong here, and if blacklists prove unable to provide reasonable compensating control for software defects and a measurable level of protection from common attacks -- I'll eat my words in a few years. Right now (2008) we are already seeing the first automated-bot-driven and mass-scale attacks against webapps and every one of them would have been trivial to defeat with blacklists.From here I cannot predict what the futurewill hold. Not all working with this problem agree with me of course.
We will probably need to wait and see. We have to see if black listing is still cost effective for different scenarios. For me it looks like for some it is not (e.g. protecting custom made applications and dealing with custom malware). But white lists have problems on their own as well. Even if we know that they might be more effective in some cases, maybe the time, resources and effort tu put them is to much for some scenarios (I also think this is the case for protecting commercial applications, as well as individuals and small businesses in general). Blacklist does seem more pragmatic, at least for the end users (but someone has to create those lists anyway). There was a point during the mass propagation worms and now with specific targeted attacks with custom malware where some thought that vendors might not be able to hold the pace of criminals, mass propagation and fast creation of variants of attacks was one of the reasons, lack of information was the other (e.g. 0-days - you can't black list that which you don't know yet).
This is a vigorous running debate on the WASC lists, the OWASP lists, and even the SC-L (secure coding list). Ironically, given the end of your post, it is the hardcore software-security technologists that I think are driving the whitelisting argument, and I think that their recommendations fail due to lack of business pragmatism on their part. :) The app/software space problem is exponentially more complex. However, I have trouble deciding if it is different in *kind* or *degree* from the network IDS/IPS/NBAD space. I do hope those of us in webapp detection and protection land don't go re-inventing the wheel, and all the IDS/IPS guys sit on the sidelines laughing at us. Maybe they'll join in with us on the software IDS/firewall problem soon... Cheers,
In the end I don't believe that either of them will win over the other. I think that each will find specific environments for which they are better suited and provide the best cost-benefit balance for users. The application issue is a big one indeed and my favourite for custom made applications is white listing :-). I don't see vendors taking the time to create signatures for our home made applications. Anomaly detection might help but I believe it will be allways incomplete due to lack of context information, with a critical application such as e-banking or flight control in an airport I wouldn't take my chances (vendors won't be held liable if something happens, but as personnel in charge of security we could be). Also, I see people with different opinions from all sort of backgrounds. I like the white list approach because I work more on the business side, with regulations and control procedures. I haven't seen people more involved in software development too enthusiastic about the white list approach, because in involves time and resources for them, and this is a big problem. They don't get enough time to finish functionality many times, let alone implement security controls, so automated solutions with black lists and anomaly detection are better liked by them, since they are apparently cheaper and don't affect development times so much. But the cause of the problem is not solved. White listing requires resources, time and effort, but also forces you to try solve the main problem (you need to document what you want, what you need, what you approve) that's what I like. But time will tell... :-) Cheers, Omar Herrera ------------------------------------------------------------------------ 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. ------------------------------------------------------------------------
Current thread:
- Re: IDS vs Application Proxy Firewal, (continued)
- Re: IDS vs Application Proxy Firewal Omar Herrera (Oct 27)
- Re: IDS vs Application Proxy Firewal Stefano Zanero (Oct 28)
- Re: IDS vs Application Proxy Firewal Omar Herrera (Oct 28)
- Re: IDS vs Application Proxy Firewal Stefano Zanero (Oct 28)
- Re: IDS vs Application Proxy Firewal Ashish Kamra (Oct 29)
- Re: IDS vs Application Proxy Firewal Stefano Zanero (Oct 29)
- RE: IDS vs Application Proxy Firewal Kamra, Ashish (Oct 29)
- Re: IDS vs Application Proxy Firewal Stefano Zanero (Oct 29)
- Re: IDS vs Application Proxy Firewal Omar Herrera (Oct 27)
- Re: IDS vs Application Proxy Firewal Damiano Bolzoni (Oct 28)
- Re: IDS vs Application Proxy Firewal Arian J. Evans (Oct 28)
- Re: IDS vs Application Proxy Firewal Omar Herrera (Oct 28)
- Re: IDS vs Application Proxy Firewal Arian J. Evans (Oct 29)