Re: [fw-wiz] PCI DSS & Firewalls
- From: Victor Williams <bwilliam13@xxxxxxxxxxxxxx>
- Date: Thu, 02 Apr 2009 19:34:20 -0500
Marcus J. Ranum wrote:
Victor Williams wrote:Good question. Have you read it? I'll defer to what Paul already stated, and some of the outtakes of the standard that he posted.PCI DSS is pretty sad. They could have taken another already-established standard with some brains behind it and adopted it instead...
What makes you think they didn't?
I will 2nd the notion that the only thing it is doing is making a lot of other people (QSA's included in that bunch) a lot of money. When the CC processors themselves aren't even following the PCI "standard"...
I was told by qualified PCI external scanner companyA 3 weeks ago that a part of our web app needed to change because their scanner tool detected a "possible" vulnerability. Upon 2 weeks of code review of this particular app, it was proven out that what the scanner was "possibly" detecting was in fact a false positive. The code and the design behind it was solid. The funny thing about the issue is that the app in question was considered non-production, and had no exposure whatsoever to credit card information. None. However, it had to be scanned because the IP address in question belonged to the same block that was being used for production apps--something if you ask 3 QSA's, they will all give you different answers on. The production system had the EXACT same code, was scanned by the same external scanner, and was never flagged. Now, were we able to send our findings/exception to the scanner and have them negate the failing score? Nope. It doesn't work that way. You have to remove the "possibly" offending code, regardless. There is no review process. Why is this important? Because your acquiring bank will be sent your failing score if you fail to fix it within X amount of time. At that point, they will then do one of a few things; have you bring in a QSA to do an audit and make you remediate any issues, or if you put it off/refuse, have you stop taking credit cards as payment...or just freeze your accounts so you "can't" do any business with credit cards. Either way, you're out money...because your 3rd-party scanner couldn't tell bad source code / bad behavior from good, or false positives from actual positives--keep in mind you're still paying them too. So what's the workaround? Schedule your re-scan for after-hours, put up a dummy site instead on the same IP address, let the scan run and let it pass, put your original site back up. You pass...you're green across the board again. Seem like a solid process? It's worthless. That's only a subset of the "standard."
If you're (your company as well) actually concerned about security, you won't waste your time with PCI or even reading it. If an exec asks you "are we PCI compliant?", the only thing you should tell him is, "Hire companyX and have them come and tell us." Someone already commented about good design and coding, and good QA before deploying being the best/easiest way to make sure you're not prematurely vulnerable, and following best-practices thereafter for your implementation of X. Assuming you do that, PCI is nothing but a distraction, and is indeed a bunch of checkboxes. The QSA's I've encountered don't want to hear about your exceptions, or don't have enough knowledge to tell you if they are good or bad judging by your business and the processes it requires.
firewall-wizards mailing list