Re: PCI DSS & Firewalls

Marcus J. Ranum wrote:
> Victor Williams wrote:
>> 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?
>
> mjr.
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.

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"...

True story...

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.