If I ask to an average skilled information security professional what a firewall is, I am pretty sure that he will be able to answer my question and describe with great detail concepts as packet filter, application proxy and stateful inspection.
I am afraid that the situation would be completely (and dramatically) different in case I would decide to ask him what a Next Generation Firewall (abbreviated as NGF and sometime also referred as Application Firewall) is, and most of all what a Web Application Firewall (abbreviated as WAF) is and how it is different from a traditional UTM or Firewall or also from a Next Generation Girewall.
Although NGF and WAF are becoming quite familiar for information security professionals (their presence is constantly growing in parallel with the growing skill of the average user, more and more aggressive in circumventing the traditional security bastions, and in parallel with the growing sophistication of Web threats and the consequent influence of compliance -think for instance to PCI-DSS– into the design process of a security infrastructure), the confusion reigns and, for my experience, I can state with no fear, that too many professional and end-users confuse and overlap Next Generation and Web Application Firewall.
In case of an Application (AKA Next Generation) and Web Application Firewall, a noun adjective (Web) is a little thing, but it makes a huge difference. I will try to explain why with this quick Q&A
Q: What is a next generation firewall?
A: A Next Generation Firewall (aka Application Firewall) is a security device, evolution of a stateful firewall, that is application aware, i.e. capable to recognize and block applications according to specific patterns and fingerprints peculiar of the application itself. Its security paradigm is to prevent users from bypassing the layer of defense by mean of consolidated methods such as mapping the malicious application on standard ports known to be accepted, or using anonymous proxies (such as the well known TOR). Unlike a traditional firewall, which enforces the access control by mean of the “IP Address – Port/Protocol“ paradigm, a Next Generation Firewall enforces the “user – application” paradigm: in a traditional firewall security model, policies allow or deny specific protocols for specific IP addresses, in an application firewall security model, policies allow or deny specific applications for specific users authenticated in external repositories (Active Directory, LDAP or Radius). Of course Single-Sign-On is also possible (for instance with Active Directory).
Q: What is a web application firewall?
A: A Web Application Firewall is a security device whose main task is to protect web portals and web application by inspecting the XML/SOAP semantics of the flowing traffic and also inspecting HTTP/HTTPS for typical attacks at layer 7 such as SQL Injections, Buffer Overflow, Cross Site Scripting (XSS), File Inclusion, Cookie Poisoning, Schema Poisoning, Defacements, etc. Web application firewalls also provide protection against DDoS but do not enforce access control in the traditional meaning of the term. They only protect the server farm behind them, adopting signature based or anomaly detection algorithms but, unlike a network IPS they focus on HTTP/HTTPS. They act like proxy and, because of their ability to inspect HTTPS traffic (by importing the original certificate of the target server), they may perform also other functions such as SSL offloading and server load balancing. Also important: a web application firewall do not inspect (and should not allow) other traffic than HTTP/HTTPS.
Q: What is the difference between a NGF and a WAF?
A: This is a million dollar question: a NGF is a user and application oriented firewall, a WAF is a server and HTTP/HTTP oriented security equipment (no I cannot call it a firewall). They are very different as far as their role and deployment are concerned: usually the best deployment for a NGF is to protect outgoing traffic from misuse by users; the only deployment for a WAF is in front of the target server farm to protect incoming HTTP/HTTPS traffic. Typical location for a WAF is in a dedicated DMZ and obligatorily behind a traditional traffic that should deny other traffic than HTTP/HTTPS).
Q: I want to deploy a NGF, do I need to deploy it in conjunction with a traditional firewall?
A: It depends, although the original NGFs were conceived as dedicated devices, preferably deployed in conjunction with a “traditional” stateful firewall, the current technology trend is to bring the application control features on top of stateful inspection (and UTM) functions, so definitively nearly all the security vendors are now able to provide application control as native functions or with additional licenses. On the other hand application control corresponds to a stateful inspection brought to layer 7 of the ISO/OSI Model (At this link an interesting comparison of the different implemenations).
Q: I want to deploy a WAF, do I need to deploy it in conjunction with a traditional firewall?
A: Absolutely yes. A WAF does not provide access control neither is capable to check other protocols than HTTP/HTTPS (by default not even to forward them);
Q: I have an IPS, do I need a WAF as well?
A: A traditional Network IPS scans all the traffic on the network so it cannot have the same granularity and depth for HTTP/HTTPS threats than a WAF. An optimal comparison is done in this article by SANS, which states, among the other things: where IPSs interrogate traffic against signatures and anomalies, WAFs interrogate the behavior and logic of what is requested and returned. A WAF acts as a reverse proxy (although, like an IPS, several WAF technologies may also active in passive mode), instead an IPS typically listens to traffic in transparent mode.
Q: So definitively when do I need to deploy a NGF and when do I need to deploy a WAF?
A: Deploy a NGF when you want to protect your network from misuse by users avoiding bandwith hogging and usage of insecure applications which could bring malware inside the organization. Deploy a WAF, in conjunction with traditional Firewall, IPS or UTM, when you have to protect your web applications (and partially also the back-end databases) from HTTP/HTTPS threats.
So, at the end, if you will need to enhance your security level you will not have to chooes between a WAF and NGF, but simply to decide which is the best device according to your needs. In this case the following table may be helpful!
Today some more details about the Citi breach were revealed and it looks like it is not connected with the RSA breach.
The investigation is still in place, but data collected so far show the kind of attack performed is pretty much more “traditional” then a SecureID clonation: the attackers were able to bypass the perimeter security systems by logging on the site reserved for credit card customers (but no one has explained so far how) were they were able to exploit some vulnerabilities on the Home Banking Web Site.
Once inside, they leapfrogged between the accounts of different Citi customers by inserting vari-ous account numbers into a string of text located in the browser’s address bar. The hackers’ code systems automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data.
It looks like application and database security is a curse and a bless for the infosec arena. Although not fully mature in my opinion, it is one of the most promising sectors (in which there are grand maneuvers under way by the vendors), but in the same way, application in(security) has been the indirect reasons for several events this year: Sony (in some of the suffered breaches) and Epsilon have been victims of SQL Injection, and if for a moment we forget the breaches (real leading actors of this 2011) and pass to consider malware, we must necessarily mention LizaMoon which has flooded an impressive number of databases all over the world with SQL Injection, infecting more than 1,500,000 URLs.
Unfortunately these kinds of attacks are not simple exercises in style but are often the first stage of more complex Cybercrime operations. If the stolen Data immediately usable (such as Credit Card Numbers and corresponding CVV codes), they are sold in the Black Market Bazaar. In other circumstances, when the stole information is not enough to gain immediate profit, the targets become victims of tailored spear-phishing campaigns (which could potentially last for several years) aimed to gain the missing pieces of the puzzle (read information) necessary to perform the malicious actions.
That is the reasons why, if not already done, Enterprises need to make application security a key foundation for the development of secure business application and services: educating the developers with secure development guidelines, implementing adequate countermeasures with Web Application/Database Firewall, periodically probing the security level of the infrastructure with Vulnerability Assessment and Penetration Test and, last but not least, performing a constant patching.
This corresponds to implement an application oriented modern form of the Deming Cycle, more poetically summarized by the expression “performing Application Housekeeping”.
- Application Security: What’s Next? (paulsparrows.wordpress.com)
- Citigroup Breach and RSA Breach: A Possible Connection? (paulsparrows.wordpress.com)
Per un giorno mi ero ripromesso di non parlare dei problemi di sicurezza dell’Androide ma non ce l’ho fatta… Non si sono ancora sopite del tutto le polemiche relative al modello di sicurezza dell’Android Market (io invece mi ero quasi sopito) che oggi è trapelata la notizia di una grave vulnerabilità di tipo XSS esistente, dalla sua origine, nella versione Web dell’Android Market. Prima della sua scoperta da parte di Jon Oberheide (ricercatore di sicurezza non nuovo a questo genere di scoperte), la vulnerabilità in questione era sfruttabile inserendo codice malevolo all’interno del campo “Description” nella finestra di pubblicazione delle applicazioni.
La falla nel sistema di input consentiva di eseguire il codice in questione nel dispositivo client nel momento in cui l’utente ricercava l’applicazione nel mercato (e quindi il browser leggeva il campo in questione).
Dopo la segnalazione la vulnerabilità è stata sanata, ma senza dubbio, per il povero androide, continua a piovere sul bagnato.
Piccola nota romantica: il ricercatore cacciatore di taglie informatiche ha scoperto la vulnerabilità e l’ha segnalata a Google pochi giorni prima del Pwn2Own 2011, ricevendo una taglia di 1337 $. L’avesse svelata durante il contest avrebbe ricevuto in premio 15.000 $, quindi un ordine di grandezza in più di quanto meritatamente spillato nella circostanza al gigante di Mountain View.