spin off of my most recent post...
I think we all can conclude that (all things considered) code review is the best method, either or both static analysis at compile-time or dynamic analysis at actual run-time. But what about if an immediate (without necessarily monkeying with the code) is required; and in consideration of long term strategy... That’s when WAF might just be most appropriate. The trade off is when WAF actually needs to be put in BLOCKING mode since all know vulnerabilities and fixes have been applied; thus, no business interrupt would be noticed from the application.
Alright, I’m not dispelling the importance/benefit/necessity of code review at all but let’s take a quick peak solely at WAF and Dynamic Profiling technology. The theory is a behavior based approach; unlike a static/manual fix code review under application normal cycles. While developers can write code to protect against vulnerabilities and present day attack methods, it will not necessarily secure the application for tomorrow’s threats. Gee-whiz am I going off on an IDS/IPS and vulnerability/PEN testing tangent?
The premise is alike in that understanding the path/source leads to better code reviewing or better detection.
As it turns out selecting a WAF is much like selecting an IPS vendor (for in-line as well as out-of-band monitoring) yet less like a firewall product. So, here’s what you need to know:
Throughput and latency [actually how much, not if] is on the top of requirements; but deployment flexibility including software or appliance-based; and in virtual hosting environments plays particular importance. WAF’s runs on the following modes:
Passive – for just listening
Bridge – sending TCP resets when malicious activity is detected
Router – like server not really recommended as a routing function
Reverse-proxy – most common operating at Layer 4-7
Embedded – within the application (typically for very small/non-complex deployment)
So, look into SSL accelerators and webcache integration features or HTML compression other than sound-but-simple policy rules.
But the squeeze spot on attack characteristics that any WAF’s should be able to tackle include: input validation and invalid request, injection flaws, buffer overflows, cross site scripting (GET and POST), broken authentication, cookie poisoning, forceful browsing, parameter tampering, and of course SQL injection.
This is particularly significant if the WAF is asked to (hopefully in limited cases where packets are encrypted over HTTPS/SSL) inspect packers SSL termination and decryption is a option often enabled. Remember, a good WAF architecture will also consider both REQUEST and REPLY vulnerabilities.
Conclusion, WAF is complementary to all other application security practices/processes… PCI 6.6 actually puts the two in comparison of a single solution when in fact, layered defense would tell you otherwise. So, I would speculate that once the industry adapts one of the solution [WAF or code review] it won’t be long till the other is also a requirement (not just best practice). Oh, and if you thought IDS/IPS implementation was a cake-walk, you’re in for a treat—but do purge through.
Alright, I’m not dispelling the importance/benefit/necessity of code review at all but let’s take a quick peak solely at WAF and Dynamic Profiling technology. The theory is a behavior based approach; unlike a static/manual fix code review under application normal cycles. While developers can write code to protect against vulnerabilities and present day attack methods, it will not necessarily secure the application for tomorrow’s threats. Gee-whiz am I going off on an IDS/IPS and vulnerability/PEN testing tangent?
The premise is alike in that understanding the path/source leads to better code reviewing or better detection.
As it turns out selecting a WAF is much like selecting an IPS vendor (for in-line as well as out-of-band monitoring) yet less like a firewall product. So, here’s what you need to know:
Throughput and latency [actually how much, not if] is on the top of requirements; but deployment flexibility including software or appliance-based; and in virtual hosting environments plays particular importance. WAF’s runs on the following modes:
Passive – for just listening
Bridge – sending TCP resets when malicious activity is detected
Router – like server not really recommended as a routing function
Reverse-proxy – most common operating at Layer 4-7
Embedded – within the application (typically for very small/non-complex deployment)
So, look into SSL accelerators and webcache integration features or HTML compression other than sound-but-simple policy rules.
But the squeeze spot on attack characteristics that any WAF’s should be able to tackle include: input validation and invalid request, injection flaws, buffer overflows, cross site scripting (GET and POST), broken authentication, cookie poisoning, forceful browsing, parameter tampering, and of course SQL injection.
This is particularly significant if the WAF is asked to (hopefully in limited cases where packets are encrypted over HTTPS/SSL) inspect packers SSL termination and decryption is a option often enabled. Remember, a good WAF architecture will also consider both REQUEST and REPLY vulnerabilities.
Conclusion, WAF is complementary to all other application security practices/processes… PCI 6.6 actually puts the two in comparison of a single solution when in fact, layered defense would tell you otherwise. So, I would speculate that once the industry adapts one of the solution [WAF or code review] it won’t be long till the other is also a requirement (not just best practice). Oh, and if you thought IDS/IPS implementation was a cake-walk, you’re in for a treat—but do purge through.
No comments:
Post a Comment