Category Archives: Misc

Watch your SaaS: Partial parameter checking or The case of the unfinished homework

  Posted by
on
Reply

“Laws are like sausages. It’s better not to see them being made.”

- Otto von Bismarck

I’m not sure how many of you have kids or how diligent they are with their homework but I’m sure you’ve heard stories of parents observing that their kids have finished their homework in a remarkably short period of time.  However, upon investigation, you quickly discover that your child has only finished half of their homework.

Sadly, this state of affairs can also true for SAAS providers offering web application scanning services.  Only half of the work gets done, resulting in rapid, but inaccurate scans and potentially vulnerable websites that are given clean bills of health by the scanning company.

Taking shortcuts

Properly configured web vulnerability scanners should test parameters by locating all of the parameters on a page and then making attacks against individual parameters at a time.  So if there are 10 parameters, you do an attack against parameter 1 and put acceptable values into the other 9 parameters to successfully complete the form request.

Why can’t you just attack all 10 at once?  Well, let’s say that parameter 1 is vulnerable and parameters 2 -10 have good filters. If you attack parameter one with an attack that works (i.e. the application does not recognize it) and parameter 2 with an attack that trips the filter in the application, the application will quite likely appear to not be vulnerable.

Now the problem is that if you are testing various attacks (SQL Injection, Blind SQL Injection, Cross Site Scripting, etc.) you will have dozens of attacks of each class against each parameter.  Your total attacks per parameter will exceed 100 and if you have 10 parameters on a page (which you will likely have in a signup form, for example), you will have over a thousand attacks for that page. On top of that, some of these attacks, like blind SQL, will have multiple requests per attack.

Performance vs comprehensiveness

Many SaaS vendors want to complete scans fast to make them look more impressive. The problem is that in order to accomplish, you have to cheat.

To speed up a scan, you might only test the first parameter or the first three or whatever and then skip testing the rest of the parameters.  If the customer doesn’t test the site and doesn’t get hacked, no one is the wiser if those untested parameters are vulnerable.

Does this matter?  Is it possible that one of parameters 4-10 is vulnerable if 1-3 are not?  In a word, yes.  Different parameter types (dates, text fields, numerical values, etc.) will have different filters.  Just because a developer got 1 right doesn’t mean that he got them all correct.  We’ve seen numerous cases where one parameter is 100% clean and others are full of holes.  You have to thoroughly test every parameter.

Letting those POSTs get away with murder

Since dealing with forms on web pages can be difficult and there is a possibility that they could modify data in the database behind the web application, some SaaS solutions don’t even attack them. So this means all the inputs from the forms never get tested.

On many of the sites we have tested over the last decade, the form inputs sent over POST have been some of the most critical attack points with some of the worst vulns and often the most important areas to test on a website. Not testing them is the same as locking your doors, but leaving your windows wide open.

How can you assess your vendor

Ask your vendor the hard questions, such as:

1. How many parameters do they attack per page? Are there limits they impose.

2. Ask them to demonstrate that only one parameter at a time gets attacked while the other fields having good data. Heck, ask them to put these answers in the Statement of Work (SOW).

3. Confirm that they attack forms and POST data. Ask them to demonstrate it or test it yourself with a trial.

Julian Assange – Hacker of the Year?

  Posted by
on
Reply

On Dan and Jim’s recent podcast, I learned that Julian Assange had been declared Hacker of the Year. Assange is certainly a person that elicits strong opinions out of people, one way or another.

Much ink has been spilt over personal privacy in the modern age – most of it has been over whether we have any expectation of personal privacy in our lives.  I emphasize the word personal because it is generally agreed that it would be nice if we had personal privacy.  That is I really do not want my credit card data, my health data and my banking information splattered all over.  Without getting too far into this, I can agree that many of us have made the affirmative decision to, wittingly or unwittingly, to broadcast a ton of personal information about ourselves on the Internet through Facebook, Foursquare and the like.  The argument is generally about whether we have any hope of maintaining the privacy of our personal information in this day and age.

But that is not what is interests me about Assange and his potential copycats.  The area of privacy that Assange has threatened is more corporate privacy.  I should say enterprise because this would include government and nonprofit but corporate privacy sounds better.

Assange, as we know, has facilitated the dissemination of private enterprise communications for all the world to see.  His motivations are very clear; he seeks to expose wrongdoers by providing evidence of evil deeds.  For the sake of argument, let us agree that, in the words of Richard Nixon, “mistakes were made” by the enterprises exposed by Mr. Assange.  Let us also assume, for the sake of argument, that Mr. Assange’s motives were pure and he does this for the sole purpose of punishing the wicked and discouraging bad behavior in the future.  While i have not met Mr. Assange, I actually have no reason to doubt this.

My question is this: do we have any right to or expectation of corporate privacy?

This is a trickier question than one of personal privacy.   Almost all enterprises have policies that explicitly state that our communications over media owned by them (e.g. E-Mail) are owned by the enterprise.  Having said that, there is an implicit expectation of the confidentiality of certain communications between parties in the corporate world.

Some examples come to mind where corporate privacy is beneficial to us as a society.

  • Communications About Personnel
  • Personal Information (e.g.Health Information)
  • Corporate Secrets
  • Sensitive Information

Now I am sure that Mr. Assange would agree with most or all of these points.  I have never met Mr. Assange and can’t state with any certainty how he would respond but a possible response would be that he should be trusted to weigh these risks and decide what and should not be published based on the benefits of the dissemination and the potential harm.

I would also point out that we are entering a brave new world of whistleblower disclosures.  journalists have long reported on instances of whistleblowing but they very carefully extract documents as opposed to disseminating vast quantities of microdata as Mr. Assange has.  Additionally, journalists (at least in the US) are exposed to potential litigation if they cause harm by their actions.  Mr. Assange has intentionally (by his own admission) set up in jurisdictions to minimize his risk of litigation.

My question is, is that really how we as a civilized society (or at least a society striving to be civilized) wants a decision that has potentially significant impact on corporate privacy to be made?

For the sake of argument, let’s look at another decision that we make.  Punishment.  There are millions of criminals in this country and others that violate the understood morals of the society in which they live.  Do we allow individuals to decide to punish them?  If I see someone stealing an old woman’s purse, do I grab him and lock him in my basement?  Of course the answer is no.  We have a codified system of laws and a judicial system made up of individuals who effect judgement and punishment of criminals.  We do not leave these decisions to individual people or groups of people.

One can argue that Mr. Assange is basically a whistleblower (or a facilitator of whistleblowers).  A whistleblower is someone who reports wrongdoing.  There is some degree of legal protection for whistleblowers both in the US and internationally and I am personally certainly  on board with the idea of exposing evildoers.

I guess that my question is whether dumping E-Mails on the Internet is the optimal way to do this.  The question is, is there a better solution?  The irony is that I think that the security community has actually already come up with a better solution.  When a security researcher discovers a vulnerability, most will contact the vendor. The vendor is supposed to investigate the claim and crate and release a patch before the researcher releases the exploit.  Now this system doesn’t always work perfectly but it at least allows the responsible party to do the right thing before the world knows that their system can be hacked.

Maybe this is a better model for whistleblowers.   If a crime is committed, the evidence can be sent to the appropriate government authorities with a reasonable deadline for action.  The government should be able to act while using its resources to scrub the communications and minimize the damage to corporate privacy.  If the government fails to act and cannot convince the Assange’s of the world of their reasoning, then all bets are off.  This problem, of course, becomes much trickier if the wrongdoer is the government but the government does have mechanisms to investigate itself.  This idea is admittedly a Devil’s Bargain but it may be better than the situation we find ourselves in today.  If Mr. Assange and his imitators continue to have success, it may be better for governments to try to strike deals with them rather than risk widespread dissemination of confidential information.

Tales from the Web Scanning Front: Why is This Scan Taking So Long?

  Posted by
on
Reply

As CEO, I’m constantly emphasizing the importance of customer support and trying to attend several support calls each week to stay on top of our support quality and what customers are asking.

Surprisingly, application scan times are one of the most common issues raised by customers.  Occasionally, scans will take days or even weeks.

At this point, I would say that in almost all cases, there is an issue that lies within the application’s environment as opposed to a something within the software.

First some background on web application security scanners. Web scanners first crawl websites, enumerate attack points and then create custom attacks based on the site.  So, for example, if I have a small site with 200 attackable inputs and each one can be attacked 200 ways, with each attack requiring 2 requests, I have 200*200*2 or 80,000 requests to assess that site.

Now NTOSpider can be configured to use up to 64 simultaneous requests so depending on the response time from the server, you can run though requests very quickly.  Assuming, for example, 10 requests a second, that’s 600 per minute, 36,000 per hour and you can get through that site in 2.22 hours.

The problem is that quite often the target site is not able to handle 10 or even 1 request per second.  Some reasons can include:

  • Still in development - The site is in development and has limited processing power and/or memory.
  • Suboptimal optimization - The site is not built to handle a high level of traffic and this has not yet shown up in QA.  We were on the phone with a customer last month who allowed us to look at the server logs and we saw that one process involved in one of our requests was chewing up 100% of the CPU for 5 seconds.  Another application was re-adding every item to the database each time the shopping cart was updated (as opposed to just the changes) and our 5,000 item cart was severely stressing the database.
  • Middleware  Not to bash any particular vendor (Coldfusion) but some middleware is quite slow.

So let’s look at our 80,000 request example from above and assume that our site can only handle 1 request per second.  Our 2.2 hour scan time balloons to 22 hours.  For our 5 second response in bullet 2, we get to 4.6 days for our little site.  The good news is that NTOSpider can be configured to slow itself down so as to not DOS the site (this is our Auto-Throttle feature).  The bad news is that it will take some time.

So what’s a poor tester to do?

  • Beefier hardware  If you are budgeting for a web scanner,  consider spending a couple of extra thousand dollars on some decent hardware to test your apps. (Note – a modern laptop with optimal ram for the OS you are running – 32-bit OS = 4 Gigs of ram / 64-Bit OS = 8 Gigs of ram – will solve 90% of all performance issues.)
  • Scheduling  In some cases, you can schedule scans so that even if they are longer, you can still get things done in time.
  • Segmenting  In some cases, if you know that only a portion of the site has changed, you can target the scan to test only that subset and dramatically reduce scan time.
  • Code Augmentation  Not to put too fine a point on it, but if a single request is taking 5 seconds to process, a hacker can DOS your site by hand.  You might want the developers to look at adjusting the code.

 

A non-security geek way to question the Iran drone hack

  Posted by
on
Reply
So, over the past few days we’ve seen several articles about the recent/potential hacking of one of our military UNAV planes over Iran.  Naturally the security geek in me has been piqued to learn more details about how this was done.In the latest information, one of the Iranian engineers talks about jamming the command and control signals to the plane and forcing it to go into auto-pilot mode. Then hacking the plane at its weakest point, aka its GPS system. As a security minded person, I can make lots of arguments on the technical and security related challenges of these statements. However as a big radio frequency (RF) and remote control (RC) enthusiast, I  wanted to talk to a few points of this proposed attack and what may or may not be possible.
Command and Control Jamming- If  you are into RC planes and are big on electronics then finding out that there are kits out there already to build your own small scale UNAV system is nothing new. U-Nav.com (www.u-nav.com) has been in business for years and makes some of the best solutions for building solutions on the small scale.  Their latest kit includes using XBee based radios or modems to send command and control information to the UNAV system from the ground station.  As described in the Iranian attack, once this signal is jammed, the software goes into auto-pilot mode.  This auto-pilot mode usually instructs the aircraft to fly home or to a pre-determined GPS waypoint and hover (fly in circles) around the waypoint until the command and control connection are re-established or perform a controlled crash (typically a flat spin) once power has been depleted to the craft.

Reading up on the latest Info-warfare solutions that we theorize that Iran has at their disposal, it looks as if they have the proper surface-to-air platforms to use to perform this attack. Just keep in mind that jamming most RF signals is entirely possible, just by broadcasting “noise” on the same set of frequencies that the RF receiver is trying to listen in on.

GPS Jamming – GPS jamming is extremely easy.  Heck you can now find complete kits on the Internet to perform just about any jamming you need.  Worried about privacy issues, install a jammer. Worried that law enforcement has installed a GPS or Lo-jack tracker on your car, install a jammer. Yep, its that easy.

Note – Just remember that it is illegal for you to build or use one in the US (as well as many other countries).

Waypoint Hacking – This is the most interesting point of the Iranian hack. According to some of the articles, Iran claims to have altered the GPS signal going to the UNAV system and giving the plane enough information to land safely at a location in Iran.  What is impressive here are the technical challenges to perform this hack:

  • Pushing updated data to the craft – The part I struggle with the most, is the claim that a ground-based tracking station/platform was used to performed this attack.  As I stated, jamming is rather easy.  But jamming while also updating coordinates is complex… especially when doing this to a craft that is above your elevation, fling at 200+ MPH, and you are overriding a signal coming from a satellite that is located above both you and the target. I’d love to hear from any military types on this capability.  But as stated, its one heck of a hurdle to overcome.
  • Knowing the Waypoint to Spoof/Alter – To have the plane land at a location of your choosing assumes you know where its original destination was located at to begin with.  Since Iran stated they analyzed several previously crashed aircraft, I’ll have to assume they were able to gather this information through these or more traditional information gathering efforts..aka – everyone in the region knows all the planes come from 1 or 2 bases.
  • Overriding The Waypoint – The other part I struggle with in the articles is the statement that Iran chose where to land the plane. This basically assumes that they tricked the plane into thinking it was over Afghanistan instead of Iran and was to land at its pre-determined waypoint.  All jokes aside about both places being mostly desert, still the locations are not identical.  To do this part of the attack, you have to overide not only the physical location but also important factors such as the topology of the landing site… aka altitude, approach angle, and wind direction.

It is these last three challenges that make me question the validity of the “hack” that took place, at least as described so far.  But since I know the challenges, I’m also eager to hear on the techniques and solutions to overcome these hurdles. As always, I’ll wait to hear more before giving a final verdict, but just wanted to open up a discussion on the basic hurdles that needed to be overcome for this attack to work.

Assessing risk before you buy software: Is company risk inversely related to company size

  Posted by
on
Reply
Software purchase risk assessment
I recently stumbled across this article which got me thinking about the risks organizations take when they buy technology products and what kind of risk assessment process is conducted. Our company sells application security assessment software to people who are experts at managing IT security risk, so I’m curious to hear what others think.
11 Companies On the Edge in 2012
#8 on the list.
Hewlett-Packard. Stock decline: 38 percent.
“HP is on its third CEO in less than two years, with the turnover reflecting strategic confusion that has impaired earnings, enraged shareholders and raised concerns that HP is too unwieldy to be run effectively. With operations in many business and consumer markets, HP has numerous competitors that have been nibbling market share, leading to disappointing results likely to continue into 2012. Some analysts worry that a heavy focus on acquisitions in recent years has left holes in HP’s new-product pipeline. New CEO Meg Whitman may enjoy a bit of a honeymoon, but she’ll need to prove herself by the second half of 2012.”

First, I’d like to clear the air in the spirit of full disclosure.

  1. I have nothing against technology conglomerates and believe that they fill an essential role in our economy.
  2. At various times in my own company’s history, HP and its subsidiaries have been customers, partners and vendors.
  3. I have personally purchased and used many HP products over the years and am a fan of Meg Whitman for her work at eBay.
  4. My company directly competes with HP in the application security space as I mentioned.
  5. I am co-CEO of a privately held company that has been profitable for over six years.  Now on with the post.

The common wisdom seems to be that when purchasing technology products there is little or no risk with large firms and significant risk with smaller firms.

In my experience, this isn’t really true.

Let’s look at the varying types of risk in purchasing technology (this is not specific to application security technology)

  • Technology and Support Team Risk – With any technology, particularly complex technologies, there is a huge risk that the team responsible for creating that technology will change for the worse, and later versions of the product will get worse over time after the customer has spent a significant amount of money for a perpetual license where the product is supposed to last 3-5 years or more.  Customers expect to be able to get ongoing support for the product that they have purchased. This is particularly important with more complex products.
In building application security software, for example, building and maintaining a team of top developers is crucial because the industry-specific knowledge requried to create a leading product requires years of coding and domain expertise as is the case in many industries.
  • Bankruptcy Risk – Obviously, if a company goes bankrupt and is dissolved, there will be no further upgrades or support.
  • Strategic Risk – Companies can decide that the product purchased by the customer does not meet its overall strategy and end-of-life the product. Upgrades will be limited and support will likely wither during the last years of the product’s life.
  • Layoff Risk -When companies effect layoffs, products can suffer, which impacts both the technology on an ongoing basis as well as the support.
  • Risk of Sale – When private companies sell to larger companies, there is always the risk that technology and support teams will leave. This can even be the case if their shares vest over time if there are significant cultural or power conflicts or if the incentives are insufficient.

Let’s look at these risk factors by firm size, profitability and recency of technology acquisition:

Unprofitable Private Companies

  • Technology and Support Team Risk – Generally this risk is less because the core team has a significant equity stake in the company and will stay so long as the company has funding.
  • Bankruptcy Risk – This is the most significant risk. Pre-profitable companies rely on investors to fund losses and investors can be fickle. If funding dries up, the company can be forced to sell (in which case the team may leave) or liquidate.
  • Strategic Risk – Smaller companies typically have few products so this is a minimal risk.
  • Layoff Risk –  Smaller companies can cut back on growth if they cannot raise funds, harming development and support.
  • Risk of Sale – This is a significant risk.

Profitable Private Companies

  • Technology and Support Team Risk – Generally low because of equity incentives. Support can suffer with rapid growth.
  • Bankruptcy Risk – Less than for unprofitable private companies for obvious reasons.
  • Strategic Risk – Again, generally a minimal risk.
  • Layoff Risk – This can be a risk, although less than for unprofitable private companies.
  • Risk of Sale – This is the most significant risk. Most private companies do not go public and there is always the risk that the founders of a profitable private company of sufficient size will cash in and move to an island, harming the technical and support capabilities behind the product.

Large Company with Newly Acquired Technology

  • Technology and Support Team Risk – This is a significant risk.  Technology companies suffer significant attrition in their technical staffs post-acquisition.  Some founders leave because it is more lucrative to be an entrepreneur and some leave because they no longer have to work. For others, the work at large companies is not challenging enough and the entrepreneur in them feels stifled.
  • Bankruptcy Risk – Generally minimal.
  • Strategic Risk -This is a small risk short term.  See below for the longer term risks.
  • Layoff Risk – This is potentially a significant risk depending on the financial profile of the company.
  • Risk of Sale – Less of a risk than for smaller companies.

Large Company with Longstanding Technology

  • Technology and Support Team Risk – After a while, the creators of the technology leave and are replaced by a team that wants to work at a larger company.  This can be good or bad but is generally somewhat stable.
  • Bankruptcy Risk – Generally minimal.
  • Strategic Risk – This is a huge risk.  Large companies go through strategic review constantly.  Many products exist as parcels in larger groups controlled by a single executive or executive team.  When turnover occurs, priorities change and centi-million dollar acquisitions can be written off like week old bananas.  We were partnered with a company that wrote off a $150 million acquisition after 3 years because it didn’t make strategic sense.
  • Layoff Risk – When large companies are in financial trouble, they tend to cut across the Board which can significantly impact product quality and support both from a pure numbers as well as a morale standpoint.
  • Risk of Sale – Less of a risk than for smaller companies.

To sum up, the issue of company risk in technology purchases is far more complex than is ordinarily assumed.  The saying, “no one ever got fired for buying IBM” may not necessarily be true.  Conversely, I’m not arguing that buying from small companies because they are small makes any more sense than buying from large companies because they are large. IT professionals must evaluate the risks of the companies with whom they are doing business on a case by case basis.

Announcing SQL Invader

  Posted by
on
2

Today, we announced SQL Invader, a new free GUI-based tool that enables testers to easily and quickly exploit a SQL Injection vulnerability, get a proof of concept with database visibility and export results into a csv file. In just a few clicks, users will be able to view the list of records, tables and user accounts on the back-end database.

Tools like this are still critical for comprehensive application security testing and can help organizations remain a step ahead of the bad guys. SQL Injection has been the dominant method used in this year’s high-profile web application attacks; with millions of sites attacked in 2011.

We created this tool because our customers and the community at large have expressed a need. We want to always contribute to the community as much as we can. Although SQL Injection is well documented and there are tools to discover the vulnerabilities, it has been very difficult to determine if the vulnerability can actually be exploited because most existing SQL Injection testing tools are executed from a command line, lack an intuitive user interface or are no longer supported.  Without the ability to clearly demonstrate the exploitability of a vulnerability, remediation efforts are often delayed and friction between security and development teams surfaces. We designed NTO SQL Invader so that penetration testers and developers can quickly and easily leverage a vulnerability to view the list of records, tables and user accounts on the back-end database.

SQL Invader works as a standalone solution or with NTOSpider and enables you to:

  • Paste the injectable request straight from an application scan report
  • Control how much information is harvested.
  • View data in an organized manner using tree control and data grids.
  • Leverage logging data in CSV file

 

Surviving the Week – 11/18/2011

  Posted by
on
Reply

This week was a busy one for me, as I’m finally done traveling for awhile and and got back to working on NTOSpider6 and our growing team. I should be able to keep up with this weekly post again, and will keep you all informed about the important news in web app security.

 

Twitter shortened links – Security bad practice?

  Posted by
on
Reply

As as spend more time using twitter, I understand the need for shortened URL’s and make heavy use of them. But, when I am viewing a tweet I always hesitate before clicking on those links knowing that they could be easily used to hide some sort of XSS or SQL Injection payload in the redirect.

It would be a great way to target accounts of twitter followers to even attack Intranet sites as well as public facing sites. Maybe some good proof of concept hacks will need to be created to demonstrate. Will leave that for another day.

I am sure some of these link shortening providers have put some effort into blocking XSS payloads from the URL’s they shorten, but its easy enough to have the short URL point to a page on the bad guys site which will perform a 302 with the payload in the Location header. This story/video on Help Net Security from a couple years ago tried to warn us.

I wish links didn’t count against the 140 char limit on twitter so these shortened URLs wouldn’t be as needed. Oh well, looks like another instance where features trump security.

(Now time to use bit.ly to make a short link of this blog post so I can tweet it)

Response to WAF/IDS/IPS Effectiveness Report

  Posted by
on
Reply

For those of you who know me as well as Dan, you know that we have spoken quite often on our podcast (Information Security Place Podcast) about the effectiveness of today’s current technologies used by Web Aware Firewalls (WAFs) and Intrusion Detection/Prevention Solutions (IDS/IPS).  I’m rarely one to say “I told you so”, but Larry Suto’s latest report on the effectiveness of these technologies, does  kind of do that for me.

For more information about the study:

In the WAF effectiveness report, Larry illustrates the need to properly train a WAF solution on the application it is protecting to gain effective or consistent protection from the app.  According to the report, it took an average of 3.5 hours by a WAF savy technician to train or tune the WAF solution to get an effective level of protection for the test application.  As noted in the report, this is significantly more time spent, than the average organization spends on their production WAF installations.

One issue to note, is that many WAF solutions are leveraged to protect more than one application once they are in production, so can it be safe to say that an organization should plan to spend 2-3.5 hours per application they plan to place behind a WAF to gain that consistent level of protection for all their applications? It could be a safe assumption since many applications are not identical or leverage completely different technologies.

One element of the report I really think Larry does an effective job at illustrating is the lack of effectiveness that a traditional IDS/IPS brings to the table.  Since these technologies are not designed to specifically look for your application’s vulnerabilities they require custom rulesets to be created to be effective at protecting your applications.

As announced earlier last month, NT OBJECTives released NTODefend to assist organizations in creating those custom rule sets for both WAF and IDS/IPS solutions. In the report, Larry was able to illustrate the effectiveness of NTODefend at creating custom rulesets that are unique to each of your organizations applications. In both instances, the rules created by NTODefend provided a substantial improvement for all of the platforms that can currently leverage our technology. Note, in some instances the IDS/IPS solutions actually became just as effective if not more effective than some of the WAF solutions, after applying our rules.

All in all, the report goes to show that even with these technologies in place, organizations are still required to perform ongoing testing to find vulnerabilities and then train their WAF or IDS/IPS solutions to protect their applications. Thankfully, at NT OBJECTives we have solutions to help you do just that… NTOSpider and NTODefend.

Is your WAF effective? Independent research study

  Posted by
on
Reply
There has been a lot of discussion, articles and analyst reports about WAF’s over the years (some listed below). The truth is that WAF’s aren’t perfect, but I believe that they are an essential part of a comprehensive application security defense strategy. The WAF technology has been maturing and improving over the last few years. There is even more good news in a just-released in-depth study, by Larry Suto, security consultant, where he tested six WAF’s and two IPS’s for their effectiveness at blocking application vulnerabilities.

Two of the most interesting findings in the report are:

  • A properly tuned IPS can be as or more effective than WAF solutions at blocking security vulnerabilities. After seeing the results of this study, the IPS vendors have agreed that their devices can, in concert with NTOSpider/NTODefend be counted as a WAF for PCI compliance purposes.
  • Automatically generated filters from dynamic application security tools (DAST) can improve vulnerability blocking effectiveness by as much as 39% for a WAF and as much as 66% on an IPS.
Why are WAF’s Essential?
For me, the bottom line is that we can’t ignore the fact that there are known vulnerabilities in production applications. Ideally, these would all be fixed in the source code, but the reality is that they can’t always be fixed immediately, they might take months to fix or they might not be able to be fixed at all in the foreseeable future. In these instances, a WAF is very practical solution as a temporary patch for the vulnerability. I mean, if someones sitting out there in public with no pants, someone please hand them a towel!
The other painful truth about WAF’s is that they take time to train and configure. Most security teams are short on time and short on resources. The people on the front lines whom I speak with tell me they would love to be able to better train their WAF’s more quickly. Here’s the good news
  • With about 3.5 hours of expert tuning, most WAF’s can perform fairly well.
  • When you add DAST generated custom filters, both WAF’s and IPS’s are excellent at blocking vulnerabilities
  • One of the things, that makes NTODefend unique is the ability to confirm that the filters are blocking unwanted traffic and allowing desired traffic. During his study, Larry was able to play with this false positive detection functionality in NTODefend. He was pleased to see that it does in fact shows if the WAF/IPS is blocking good traffic – pardon the promotion :-)
As you would expect, a handful of other vendors (including NT OBJECTives)  provided tools for Larry to use to complete the report. Anyone who has every tried to do a study knows that it takes a lot of work, and Larry does not receive any payment from any vendor to complete these studies. No study is perfect, but given his finite amount available time and resources, I believe Larry tried to implement the fairest study he could.
For more information about the study:
Good articles that discuss the use of WAF’s & IPS’s