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 is what regulated capitalism is all about, weeding out charlatans and enforcing good practices.
Even Milton Friedman would ask that companies perform a cost-benefit analysis of attempting to avoid security costs, and government oversight, or the cost of operating under a consent decree would figure into that.
the audits even more intrusive, time consuming, and expensive. This is going to hurt.
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.
What they'll find is that practically all the non-phishing breaches happened to companies employing Microsoft and other proprietary products across the enterprise.
Given the closed source nature of proprietary software vendors, it is impossible to know how many zero-day (and other) exploits on server software. Therefore the vulnerabilities that PCI compliance is designed to prohibit will always be present; it's a cost of doing business with proprietary software. Especially from certain vendors that have a long history of producing substandard products in terms of security.
Numerous studies have confirmed this so it's curious why the FTC doesn't just use that data instead of going through the expense of these interviews.
The way the summary just says the same thing as the headline a couple more times is very much like the process of figuring out how to fill in the ****ing compliance forms.
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
I know at my old (now defunct) company, we took the PCI audits very seriously. When I say very seriously, I mean that we made sure nothing obvious stood out when they were there. So yeah, it could easily be that they don't really do all that much.
The most corrupt and prolific PCI audit firm, Trustwave, some how managed not to be included in the audit? Way to go FTC.
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.
This is wholly situational dependent.
If you are a massive company with a ton of money and lawyers to throw around, then yes, it is a joke. It doesn't matter how long the audit takes. You can keep paying auditors more and more money until you pass, or even switch to a new auditor. You can even have your lawyers put pressure on the auditors.
If you are a small company and you can't afford to waste time and money by dragging on the audit for any longer than absolutely necessary, then it is far from a joke. If you don't pass the audit and you cannot afford two audits, then your company is out of business. That is no joke.
Where you see breaches happen is at large companies. You do not see breaches at small businesses who have spent a significant portion of their revenue just on their PCI audit.
Unfortunately, I have to post this anonymously to protect my identity, but it is wholly true. The PCI audit does have a lot of checklist items that when checked give you no additional security but small operators have to outlay not only a significant amount of money for the audit but a significant amount of money for programming work and additional staff in some cases, as a percentage of their revenue.
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
Articles should spell out what their 3 letter initials mean.
I'm still trying to figure out why they want to audit my Peripheral Component Interconnect to see if it has a Direct Sequence Spreadspectrum (802.11b) card.
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 once had a traditional credit card machine. They forced me to use their partner PCI compliance service. I was tired of dealing with the non-problems they emailed me about so I finally figured out an easy way to make it 100% foolproof: iptables DROP their scanning IP block.
Holy shit, now I'm 100% passing with no warnings! I laughed at how incredibly stupid and useless such a "service" was and never heard from them again. Then I dumped that stupid card terminal and never looked back.
Everyone knows that scope reduction is the only economically realistic way for most businesses to become PCI compliant.
Hackers don't give a rip about scope!
So merchants can either spend 9 months a year EVERY year as Target did to maintain their now obviously worthless "PCI certification"
or PCI council be damned; build an absolutely secure but non-compliant environment.
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.
Face it: you will *never* control Rick.
It's burdensome security theater. Every year I do the annual assessment and go through 30-40 pages of clicking "yes". I don't even bother reading the questions anymore because exceptions and explanations are automatically rejected with no recourse to have a human with common sense review them.
We need an open source standard that replaces PCI with something that's actually secure.
I work for a company that is in clear violation of PCI compliance with no real solution. We sell things that are often backordered for days/weeks/months. Customers want the items because we're the only supplier. We store all credit card information until the items come in, then we process it and wipe it.
The only alternatives are to charge up front for the stuff, which we can't do because customers get pissed when they get charged and the item hasn't shipped or we can wipe the card information and call them to manually recapture it over the phone once we have the items in stock. Not very practical due to the volume and the low margin. We'd need a call center about 20 times the size of our current setup.
We open a connection once a day (automated), transfer all these numbers to and from our server that captures the CC Info to begin with. They sit on a server with no other network connection than this brief transfer window. Once they're processed they are wiped. I feel like it's about as secure as we can get.
If anyone has a better solution, I'd love to hear it.
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.
First, our network hardware is specified by an outside vendor. We have no choice but to use the equipment we're given to employ the system we use for our non-credit-card-processing part of our business. (Sucks, but that's how it is if we want ongoing support.) We weren't going to go to the expense of creating a dedicated network and internet service just for a digital POS to run credit cards.
Second, we got one too many, "OH NOES! YOU MUST CHANGE THIS, THIS, AND THAT," such as open ports which our system requires to be open and similar issues. And on certain issues, our support vendor (who doesn't give a flying frak about our processing credit cards since we don't use the vendor's solution,) absolutely refused to address the issues causing some of the fails.
No we can't change vendors. But since we accept credit cards at only one point and we have fist fulls of DID phone numbers, we rolled back to using a phone line credit card machine and got a machine that can handle chips at the same time.
Which works for us just as well, and we don't have the hassle of dealing with PCI intrusion testing. (We still do PCI compliance, but it is ever so much simpler without the internet component. And I highly recommend any small business either do the same or go with Square or other such companies where one doesn't have to screw around with it.)
PCI: Protecting the hardlines of America.
(And don't get me started on how PCI shifts responsibility away from CC companies and CC equipment vendors onto the merchants, or that it is impossible to be PCI compliant and have a breach because the last step of certification essentially says if you have a breach you must not have been PCI compliant.)
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