Slashdot Mirror
FTC Demands Info From PCI Auditors On Breached Companies' Compliance
Trailrunner7 writes: The Federal Trade Commission has sent an order to nine of the larger companies that do PCI DSS assessments, demanding that the organizations turn over detailed information on how they conduct those audits, how often they actually declare a company non-compliant, and many other details. The FTC on Monday said it has sent orders to nine of these companies, including Mandiant, PricewaterhouseCoopers, and Verizon Enterprise Solutions, requiring that they provide details of how they handle those assessments. Specifically, the FTC is very interested in how many companies were deemed PCI compliant in the year before they suffered a data breach. Many companies that have been victims of data breaches over the years have touted the fact that they were PCI compliant at the time of their breaches. This has not escaped the FTC's notice
PCI compliance is a joke anyway. 100% security theater.
This could get interesting. It always bugged me a bit that you’re paying a company (you’re their client) to give you a stamp of approval, and the only thing you need to avoid a bunch of liability is that stamp of approval. Doesn’t seem like there’s any disincentive to them to just pass you if you give them enough money. Maybe they fail you, you pay a bunch of hush^Wconsulting money for them to help you get compliant, then they pass you.
There’s definitely a lot of good things in PCI-DSS, but there’s a difference between getting a bunch of checkmarks on a list versus actually incorporating the security recommendations into your development cycle and systems design.
How dare the dead hand of state interference meddle with an industry that has gone to all the trouble of developing a ceremonial 'self regulation' procedure?
If the compliance company won't help you pass, they wont be in business long. Compliance companies want customers to pass, so they get hired again and not black listed.
This is why nobody is failing.
Great idea for the FTC to do this, and very appropriate. The breach business is getting out of hand.
Unfortunately, in a situation like this, it is common, if not habitual, for organizations to be compliant with
the standard, or the government rules, and rest there. Those standards, such as PCI in this case, should be
regarded as the minimum they have to do, not the maximum.
We'll "help you pass", and help you be more secure, by telling you where some of your vulnerabilities are and giving you pointers on how to fix them.
The PCI DSS company is itself audited. The company I work for is preparing for our annual audit right now and we're improving our scanning in order to pass the test. Those improvements are improvements in how well we scan our customers.
Any idea what "PCI DSS assessments" means? Don't utilize that new fangled thing called a hyperlink to let anyone know.
Only the State obtains its revenue by coercion. - Murray Rothbard
This is how it was for the company I worked for a few years ago. The auditor walked in said "it's secure but it doesn't meet the standard" and I had to spend the next 3 days reworking my network setup in order to pass.
That's why it's security compliance and not security. You get what you measure, and you're measuring the minimum.
This could get interesting. It always bugged me a bit that you’re paying a company (you’re their client) to give you a stamp of approval, and the only thing you need to avoid a bunch of liability is that stamp of approval. Doesn’t seem like there’s any disincentive to them to just pass you if you give them enough money. Maybe they fail you, you pay a bunch of hush^Wconsulting money for them to help you get compliant, then they pass you.
There’s definitely a lot of good things in PCI-DSS, but there’s a difference between getting a bunch of checkmarks on a list versus actually incorporating the security recommendations into your development cycle and systems design.
The financial crisis was made possible by a willful negligence on the part of ratings agencies and big banks who paid to have their financial instruments rated.
The Enron crisis had the same hallmarks.
This shit is still going on in a lot of places. Glad to see the FTC putting it's teeth into some of it.
Make sure everyone's vote counts: Verified Voting
At a previous job (small "family owned" business), they really didn't even handle credit cards very often. But every once in a while, they'd get the walk-in or phone in customer who wanted to pay with one. As the only I.T. guy on staff, I was tossed the mandate to "do the PCI compliance thing, since our bank says we need to start doing it".
I had to do kind of a crash course in it (while they signed us up with a company who would certify us "compliant" after I jumped through all of their hoops).
It's been a while now, but as I recall -- I was able to skip a huge test full of compliance questions simply by telling them we used an outside card processor over the Internet and didn't store any card data locally. I still had to make sure their monthly "penetration testing" passed/didn't find issues, and had a much shorter (25 questions or so?) compliance test to fill out annually.
They complained about several issues that seemed fairly pointless in our situation, although I understood the logic behind about 80% of it. (I remember them always flagging a "warning" because our firewall allowed connections through ports necessary for regular business operations. And I believe one of their demands was that "any computer connecting to the card processing site had to be isolated from the rest of the local network". That was, IMO, overkill and created as many security issues as it solved, since we had Microsoft's WSUS running to push security patches to the workstations automatically, once approved by me -- and I wanted some kind of way to do remote administration or maintenance on these boxes, via the normal procedures used to access any other systems on the LAN.)
So basically, I tried to comply with anything listed that was reasonable -- and "fudged" things on a couple line items. I imagine that's how most companies treat this stuff?
The PCI DSS standard explicitly allows for alternative methods of meeting the security goal, so as long as it's demonstrably secure it should pass. However, if the standard security practices aren't in place, you do have document why it's secure without the expected measures.
If this was for PCI, the auditor may have made an error, or (likely) there was an error in communication. It would be correct to say "this is secure and therefore will pass, but since it's non-standard you'll need to send in documentation to each auditor. It may be more convenient use standard practices rather than documenting non-standard practices. "
He was from IBM and not very flexible. If he didn't like it, I had to change it and most of the changes were down to network seperation. The end result was rather solid so aside from a few 12 hour days, I have no complaints.
cheap way to print money from nothing,
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
I think the FTC just hit a jackpot. For sure lots of ripe low hanging fruit to be plucked in the PCI theatre/shakedown arena.
I've personally had issues with Security Metrics. Noticed after the fact an online purchase was conducted entirely in the clear. I contacted the "secured by" banner to complain. Responses I got back were priceless. First they said they were NOT complaint even though their own site still showed they were. When I brought this up all I got was silence followed by no action taken to correct admittedly invalid assertion of certification.
Then months later they told me they were NOW compliant and found no vulnerabilities even though anyone buying something from the site never sees a secure page. All facts trivially confirmed with seconds of manual effort. Even when I brought it up over a series of months, being very polite giving them plenty of time to respond/correct it was like talking to a brick wall.
Nobody cares and nobody seems to have a REASON to care.
From PCI gods to ASAs on down everyone in the chain explicitly disclaims responsibility for their own (in)actions.
At its best it's prescriptive and incorporates some sound practices. At its worst, it's as bad as you say.
At least one cynical person has suspected it's all just a way for the card issuers to shift liability to merchants ("Your Honor, we will show the defendant was out of compliance with the following vague language ...").
At least it's better than HIPAA but that's setting the bar pretty low.
The reason we kept getting flagged for open firewall ports is because the only connection in or out of the Internet was via that firewall and router. So any outside "penetration testing" had to test against the firewall and whatever it saw behind it.
The rules we had configured were to allow certain ports to forward to specific servers though .... nothing related to the workstation in the office running the card processor's software. But their automated testing didn't care. It wasn't intelligent enough to know that those ports led to things like our in-house Exchange server, or ability to connect to a terminal emulation session to a Unix box running an ancient software package for sales and CRM. They just said, "point us to your IP address so we can test it" and that's the only IP we had to give them.
The reason we kept getting flagged for open firewall ports is because the only connection in or out of the Internet was via that firewall and router. So any outside "penetration testing" had to test against the firewall and whatever it saw behind it.
Yeah, I suspected this was the case after I posted.
But that is essentially why they were "only" warnings. You get the list of open ports, and you sanity check each one.
Imagine if you were the actual online processor handling webstores... your front facing web server is GOING to be open on the HTTPS port for communications with the various embedded iframes or whatever widget you are using for your customers.
They'll do the pen-test and they'll flag that port open with a warning.
You'll get the report, see that HTTPS is open, and rubberstamp it as a-ok, because you know that port is supposed to be open.
If the report comes back with another port open, though, that will be flagged as well, and you might do a double-take, hey... that is NOT supposed to be open.
In your case, the open ports list you know are port forwarded to legitimate services on diffrent machines, so you can disregard them. But if that warning list came in one year with a port you weren't aware of... you'd follow up, and investigate it. That is the point of the port flagging and warning... not because you can't have open ports and be in compliance, but because you should be aware of each one, what it is for, and where it goes.
Comment removed based on user account deletion