I downloaded and listened in on the web application security talk that Jeremiah Grossman (WhiteHat Security (coordinators of the talk), Robert “RSnake” Hansen (SecTheory), Chris Paggen (Cisco) and Jordan Wiens (Network Computing) had. This was an unscripted roundtable discussion and it was very interesting to me, as I’m not so skilled in the areas that they discussed (getting there, more on that in later posts). Full info on the talk can be found at:
http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html
For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.
Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.
One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.
That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.
An update on this were posted by RSnake (one of the participants) on the 11/11-07.
Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case 
More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.
Cheers,
