FTC Demands Info From PCI Auditors On Breached Companies' Compliance 101
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
joek (Score:3)
Re: joek (Score:3, Funny)
Yeah,and PCI express is much faster anyway.
Re: (Score:3, Insightful)
I had a retail company that ran credit cards. We had to "'pass" an "audit" yearly. Took $99 to pass, simple as that. They supposedly did "auto" testing on the IP address for our store. Which was a dynamic IP address to start with and was not static. Small ma-n-pa retail shop. So while they had an IP address when I first logged into their website, they continued testing that one IP address after it had changed dozens of times and still continue to test that old Comcast IP address even though the store
Re: (Score:2)
I did IT consulting for SOHO to small business customers for years.
I have set up many credit card machines and somewhere along the line these tests became required.
It really is a total scam. They just run a glorified nmap scan of your network and try to find all of the things that are open.
In my experience, every open port, no matter what, was flagged and assigned some kind of positive point value... Get enough points and you "fail".
My general practice was to turn off any external facing services, queue up
Re: (Score:2)
Since no one else did yet and you seem to be oblivious to this fact, allow me to be the first to say so:
While PCI audits aren't perfect, people like you are the bigger problem. You're too god damned lazy to read (and probably too stupid) to understand or even act on the feedback provided by the report so instead you cheat to pass the test.
One of the most confusing aspects of PCI audits for noobs like yourself is the fact that applications installed using package managers (as opposed to compiled from sourc
Re: (Score:1)
One of the most confusing aspects of PCI audits for noobs like yourself is the fact that applications installed using package managers (as opposed to compiled from source) will often have inferior version numbers, despite the fact they're still safe since security patches are back-ported.
Which is why people work around the increasingly useless audits. You either spend ten minutes prepping for it, or you spend weeks arguing that yes, RedHat backported a resolution to that security problem six fucking years ago, you dickless felchers.
Re: (Score:1)
I work for a managed service provider and, among many other things, I provide support for linux-based clients who failed their PCI-DSS audit. Addressing a failure which is based on miss-matched versions is as easy as pointing to the changelog documentation for your currently installed package and highlighting to the auditor the part of the changelog which specifically addresses the security vulnerability found in the audit report. It usually takes me ~1min per item to address such failures. Like someone
Re: (Score:2)
Often those audits are based purely on a blind external scan, so while you get the false positives due to backported security fixes you can also get false negatives where the banners have been turned off or changed.
To do the job properly, you really need access to the host so you can audit it thoroughly and determine whats installed, how its installed and wether it has backported patches or similar but a lot of clients don't want to do that... They think that a completely blind test is "more realistic", des
Re: (Score:3, Insightful)
They failed my wife's company web site for PCI compliance, not because it wasn't PCI compliant, but they hit the honey pot (advertising an old version of mysql) I installed to create filter block lists for the intrusion filtering. So I pre-filtered the pointless PCI scanning service and the problem went away.
The PCI-DSS specs are written by incompetents. They exude incompetence. The documents seem to encourage an understanding that as long as you write down a bunch of procedures, your computers will be secu
Re: (Score:2)
I did not cheat the test. The test was a fraudulent, claiming to identify flaws in my network that were not present.
What I want is for the payment processing industry to adopt well understood cryptographic methods to enable customers to pay vendors, without exposing usable credentials to the vendor and to cease with the blackmail tactics that they use as a substitute.
Re: (Score:2)
Well, you did "cheat" the test. A scan is just a scan, it isn't 'fraudulently' doing anything, it's just reporting a possible problem. It's up to you to justify any listening port with a business reason and demonstrate appropriate controls for the service.
Of course it's not immediately clear what sort of compliancy tests you are doing. If it's just Tier 3 then you probably not paying much f
Re: (Score:2)
The PCI can is indeed awful, because (1) the actions it has people take have no effect on the underlaying insecurity of the payment card systems and (2) it comes with a 'pay us or we have the banks charge you more transaction fees' threat for this useless service . The payment card industry needs to fix its crappy, insecure payment cards first before accusing businesses, who have no control over the payment card industry that the cause of insecurity it their fault for not paying for a PCI scan.
Re: (Score:2)
It's not entirely clear what you mean by "payment card industry". The "payment card industry" is everybody, including "businesses" and there's an awful lot of existing infrastructure all that has to keep working. It sounds like you are complaining about card schemes (Visa, MasterCard, Amex) but the Tokenisation stuff they've come up with via EMVco is pretty good, it's just there's an awful lot of inf
Re: (Score:2)
PCI as in the PCI in PCI-DSS and the associated companies responsible for plaintext magstripe credentials still being in use today.
Saying "We're EMVco and we're so awesome for developing chip & pin" while mag stripes are still accepted everywhere and the mostly pointless chip & signature is what is foisted on the public is pretty bloody disingenuous.
We have a business with a store and at no point have we been given the option of buying or using payment equipment that can only be placed in a secure c
Re: joek (Score:2)
And then they charge more, or just fail you anyways because they must know more than you or you'd be in that business yourself. It's lame, but it's also really easy for online sites to offload PCI compliance through almost every processor out there, so there's no reason to store the cc info yourself.
PCI DSS is a mixed bag (Score:2)
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.
Re: (Score:2)
PCI-DSS is responsible for the ease of committing payment card fraud, by occupying the space that could otherwise be occupied by a comptent organization taking effective steps to improve the security of payment mechanisms.
The PCI-DSS specs are a huge compromise... If they made them too tough then the vast majority of companies would be completely unable to be compliant with their existing systems, and would basically have to build an entire new network for dealing with card data. If you make something too difficult then noone will do it at all, and noone would ever enforce that because the card companies actually want people to use cards.
So what you have instead is a baby step, PCI-DSS may not be very good but it's better th
Re: (Score:2)
From your description, your work in $JURISDICTION$?
But , does this ruling apply to $OTHER_JURISDICTION$?
I don;t live in America, and have no desire to visit America, or to conduct business with anyone whose contract law is based in America.
Do I need to concern myself with someone called "FTC"?
Re: (Score:2)
Well, this is either a complete fabrication or someone is selling PCI audit stickers for $100. I can guarantee PWC isn't charging $100...
I can give you a degree from Kenosis University for $100 too.
Re: (Score:1)
PCI compliance is a joke anyway. 100% security theater.
I'm a PCI qualified security assessor for a smaller firm, not one of the ones that was included in the above list. For one thing, compliance is not necessarily the same thing as security. And while there are some subrequirements of questionable effectiveness, none of them would qualify as 'security theater'. If I had to level a criticism on the entire system, it's this: The rigor of testing from firm to firm, and willingness to interpret requirements in ways that are beneficial to lazy sysadmins varies grea
Re: (Score:2, Funny)
I'm a PCI qualified security assessor for a smaller firm
I'm a prince from Nigeria too! We should meet up for coffee sometime and discuss our strategies. You seem to be flying under some sort of legal banner that makes it easier for you to take money from unsuspecting people. I'd like to learn how you do this.
Re: (Score:2)
PCI compliance is a joke anyway. 100% security theater.
I'm a PCI qualified security assessor for a smaller firm, not one of the ones that was included in the above list. For one thing, compliance is not necessarily the same thing as security. And while there are some subrequirements of questionable effectiveness, none of them would qualify as 'security theater'. If I had to level a criticism on the entire system, it's this: The rigor of testing from firm to firm, and willingness to interpret requirements in ways that are beneficial to lazy sysadmins varies greatly. When assessor firms are trying to win contracts, they may not leave enough hours to sufficiently test an environment, so they cut corners and miss things. Companies that don't see eye to eye with their QSAs (for example, we break the news that a very expensive configuration is not compliant) will ditch them, and shop for someone who will agree with them. This isn't allowed, but I haven't heard much in the way of enforcement.
To the article's point, what both assessed companies and the FTC need to understand is that assessments are a point in time. They may have recently gotten a clean report on compliance, but they probably still were not PCI compliant at the time of breach. And just because you're PCI compliant doesn't mean that you won't get breached. Like any other compliance measure, it is simply the cost of entry to be a standard-bearer of major card brands.
What you didn't mention is that the companies are being subject to blackmail. Pay $100 and get a PCI stamp of approval, or pay a higher per-transaction credit card fee. How this is not illegal is beyond me.
Re: (Score:2)
Bullshit. What part of credit card handling involving a third party processor, doesn't requires the $100 charge in return for reduced transaction fees? The standard isn't public. It's the work of a cartel. I can read it, but I have no democratic influence over its contents. Once I have transferred my credit card processing fully to a third party (I have), I still have to pay the protection money to avoid the higher charges.
Re: (Score:2)
Speaking as someone who has been in charge of PCI compliance (it was v2, not v3) for a small company, I disagree, but I understand why you would think so.
Many of the PCI requirements are simply common sense. You'd want to run your security that way anyway.
There are a few provisions of the PCI DSS where security people could have an honest disagreement with the actual requirements. In those cases, you could present compensating controls which mitigate the issues, which would make it harder for you to convi
Re: (Score:1)
As I posted anonymously above, big companies can buy and bully their way into PCI compliance.
Small companies can't literally afford to take it as a joke. At the company I worked for, we had enough money budgeted for one PCI audit. If we failed the audit then our company would be out of business. Two people including myself were hired because we didn't have enough personnel to have any hope of passing.
As a result you see breaches at large companies who have clearly shopped around for the most useless auditor
Re: (Score:2)
A different consideration can be summed up in the idea that PCI Compliance makes a company "impossible to be hacked" in the same sense that being an "important and secure government agency" makes the FBI "impossible to be hacked". A frequent view is that PCI DSS means nothing at all because even fully-compliant companies can be hacked.
The middle ground is the concept that PCI Compliance just makes the company less likely to be breached and the recognition that common sense isn't all that common (despite t
Re: (Score:2)
My read:
PCI compliance makes you less likely to be breached -- but you still can be breached.
PCI compliance mitigates the damage caused by said breach -- but you're still responsible.
Re: (Score:2)
PCI compliance is merely showing that you have done a due diligence and audited check of your security against (mostly) sound security principles.
Reality is... PCI can't stop all attacks. Not much can, truth be told, unless you're an NSA level operator, and even they suffered an Edward Snowden. The proper process and security program can stop some of the attacks and mitigate the damage of successful attacks.
In terms of legal liability, IANAL so it is hard to say what effect it will have, but it could redu
Re: (Score:1)
Auditors are easily suppressed or evaded. I had an auditor once who asked excellent questions and was able to piece together a lot despite lots of obfuscation. A call to his boss and he got back in line. Despite 12 months of CC numbers with CCV and expiry being stored in a plaintext file on the server, no negative findings. This is for a backend gateway, not a merchant (ie you'd expect the rules to apply even more). PCI-DSS is an absolute lie. It exists for the purpose of insurance and marketing. It is true
Re: (Score:2)
I think what you're saying is a serious problem with the enforcement system, and I know companies do this.
I do want to be careful though. One place I worked, they said that PCI was a joke for the reasons that you stated, but I know they said that just because they couldn't be arsed to do PCI for real and knew we wouldn't be able to skate by.
So, it is important to differentiate the actual process of having audits and standards with how those audits are run. I agree that we need a new process for enforcemen
Re: (Score:2)
Re: (Score:2)
Just because you are compliant, does not mean you're secure.
That said, PCI compliance is an obstacle to business and most of the PCI accreditors are not very technically minded so a lot of companies blag their way through by misleading their QSA...
Conflict of interest (Score:2)
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
This happens all the time (see The Big Short) (Score:2)
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.
Commie fascism! (Score:3, Funny)
Re: (Score:3)
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?
Because the invisible hand is very good at stealing from us?
Pay to win. (Score:3)
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.
We'll help you fix things to pass. We're audited (Score:3)
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.
Re: (Score:2)
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.
If it was PCI, that was a pass (except convenience (Score:3)
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 documen
Re: (Score:2)
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.
Re: (Score:2)
Well, they can't just walk in there, tell you that you fail, and walk out. I mean, you *could* do that, but you don't want a standard to immediately put you out of business if you have a flawed, but good faith effort to comply. PCI is not about hitting a target and nothing else. You want an auditor to work with you to get you back into shape.
Of course, you're probably suggesting that the "help" isn't from improvements, but rather from gaming the system. In that sense, it is possible for that to happen.
Re: (Score:2)
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.
Wanna know a surefire way to short-circuit that bullshit from happening? Hold the asshats "helping" you pass legally liable for the systems they certify as compliant.
I know that will likely never happen, and we'll continue this political ass-kissing game of validation by palm grease.
In light of that, what needs to happen is companies that suffer massive breaches stand up and sue the living shit out of the org that certified them as compliant.
Re: (Score:1)
Yeah! (Score:3)
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? (Score:2)
Any idea what "PCI DSS assessments" means? Don't utilize that new fangled thing called a hyperlink to let anyone know.
Re: (Score:2)
This is the Information Superhighway 2.0, where everything is toll roads. You're supposed to go "Hey Google, what's a PCI DSS assessment?" to your smartphone instead of using that archaic mouse to click a link to an actual authority of the topic.
Re: (Score:2)
its probably things like this: http://csrc.nist.gov/publicati... [nist.gov]
= determining needed password length based on assumption of using 300 baud modem connection to the server etc
I got stuck doing PCI compliance before .... (Score:2)
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
Re:I got stuck doing PCI compliance before .... (Score:4, Informative)
A small family owned business can't be PCI compliant UNLESS they outsource the compliance. PCI compliance for any on-premises card information handling requires multiple individual staff (one IT person can't 'audit' himself) responsible for different roles.
Honestly it all makes a lot of good sense.
Once you switch to an external card processor, life gets pretty simple. PCI compliance is on them not you. For example, an online business with a webstore, the staff never have to touch card information, so you are compliant as long as your procedures stipulate that you don't.
For a more retail place, bring in a payment terminal, and its pretty much plug and play.
As soon as you start entering card numbers into your own computer, then you have to start taking steps to ensure the computers aren't pwned. Virus installed and up to date, firewalled, secure network, etc. But if you don't want to deal with it, don't enter card information into your computers, and just use a payment terminal.
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
In a mom and pop, it's probably all of them anyway, and the one LAN server they talk to is PART of their local area network. (Think larger businesses, where one department might handle cards but another doesn't. The computers from the other department shouldn't be on the same lan. All the computers should still be able to talk to your WSUS server though.
Sufficient segregation can be achieved with VLANs and a router. It's not that they aren't allowed to talk to your WSUS server, its that the 30 workstations in marketing can't talk to them. Then you just have to audit your server for PCI compliance but allows you to ignore those 30 marketing PCs for PCI compliance.
and I wanted some kind of way to do remote administration or maintenance on these boxes,
A typical VPN setup should have been fine, especially if you restricted the inbound ip ranges.
You definitely made the right choice using an external processor; you probably could have gotten through without fudging (and your network would have been genuinely slightly more secure if you'd done something along the lines of what i outlined.)
(I remember them always flagging a "warning" because our firewall allowed connections through ports necessary for regular business operations.
I'm not sure what this would be. Why would your firewall have wide open public facing to systems that were handling card data?
Re: (Score:2)
A small family owned business can't be PCI compliant UNLESS they outsource the compliance. PCI compliance for any on-premises card information handling requires multiple individual staff (one IT person can't 'audit' himself) responsible for different roles.
Honestly it all makes a lot of good sense.
on paper, in reality you end up with clueless non technical pencil pushing rubber stampers playing golf with C level people.
Re: (Score:2)
Yes and no. It's a good set of requirements, if read and implemented by competent IT people looking to achieve security.
But you are also right, if its read by a team of lawyers looking to minimally slide through, and audited by a team of lawyers looking to let you slide through those loopholes for their rubberstamped "PASS"... then yes, you end up with with a worthless rubber stamped facsimile of a secure system.
Re: (Score:2)
Wrong. Just wrong. You're still responsible for PCI compliance for any systems that host the site, even if the payment link is done via a redirect, iFrame, etc.
Your PCI compliance amounts to little more than signing off that you aren't touching card data at all. And that you are using a PCI compliant party to handle it.
Yes, you have some obligations to ensure that your site isn't pwned, and redirecting your customers to a fake payment gateway. But that doesn't require you have dedicated baremetal server running in the locked down PCI-DSS compliant wing of the data center. It requires some routine minimal security configuration and maintenance that you should be do
re: open ports on firewall (Score:2)
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 k
Re: (Score:2)
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
PCI like SSL certs and tld's (Score:2)
cheap way to print money from nothing,
Hey FTC you should hit up security metrics (Score:2)
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
Re: (Score:1)