Passing PCI Subversively
During our webcast on Thursday (with Jeremiah, Chris and Jordan), one of the things we were talking about was PCI. Namely, one of the things I brought up was a company who wanted to do the bare minimum to pass their audits. The easiest way I could come up with on the webcast was just to use a low cost (and I’m making the assumption it’s probably not super robust) ASV (approved scanning vendor). Theoretically, if the scanner doesn’t do a good job, and only finds a few small problems, it’s easier to pass. I know some companies are doing this, so it’s not a theory. But then I went home, and started thinking about it - perhaps there is a more subversive way, even.
Let’s say I’m a bad company, or just a company that wants to do the right thing, only after the holiday season (during which our company is in a quiet period for legal reasons). The last thing I want is to get fined for being compliant in one way (quiet periods) just to fail in another way (PCI). So I make the executive decision not to modify my code because too much revenue is potentially at risk, and leave the holes intact. But now I have the PCI threat. Do I have an option? Well, one thing I could do is simply get the IP addresses of the cheapo ASV I’m using (maybe by having them scan a few brochure-ware sites with no vulnerabilities while I log all the traffic). Once I get those IPs, I can simply block all access to my domain from those sites on my firewall, except for port 80. Then I just put up a WAF or a transparent proxy of some sort to give some fake content that is free of vulnerabilities.
So the ASV finds no vulnerabilities (because indeed, they are seeing something different from your real website). So you’ve effectively tricked the ASV into thinking your site is completely safe. Meanwhile you can go about your business and either never fix your vulns or fix them much later, at your leisure. If for some reason someone ever calls you out on it, you can say you were unaware of their IP addresses, but you saw some bad behavior and blocked it. It’s the ASV’s fault that they were unable to find the issue (and in reality, that is a true statement, because real attackers can and do use lots of IP addresses).
So that goes back to my real problem with PCI and that is that there is no way for normal people to alert the PCI “authorities” to the fact that there are vulnerabilities. If I find an issue with a site, it should be possible for me to communicate to the maintainers of PCI - and get them to investigate when there are security issues with someone’s site. Sure, a company can block an ASV - but they won’t block all their users, and if they would, they wouldn’t have much of a security problem, now would they?
November 11th, 2007 at 10:41 am
So, what kinds of issues are you talking about disclosing? And under what theory of disclosure?
Did you find these while poking around their site? if so, under what authority?
You don’t qualify for any sort of whistleblower status since PCI isn’t a government regulation.
I’m not saying I disagree with the general sentiment of companies having to be responsible, its a question of whose job it is to make sure it happens. Your only personal skin in the game is the $50 you’d be out if your credit card got stolen, and even there most times you wouldn’t have to pay it….
Your motivation is what then?
November 11th, 2007 at 12:33 pm
Great question - and not one that I think is easily answered. My feeling is that a lot of us see vulnerabilities without actually exploiting them. Let’s say my name is “O’Reilly” where the tick mark causes SQL errors. Or let’s say I enter “I <3 you” and see there’s a potential XSS hole. Etc… my point being, I don’t think it matters how you found the vulnerability, and indeed, if you hacked them chances are you probably will end up being sued or worse. But a lot of us come across these kinds of things all the time. I’d much rather have a forum to alert the PCI committee of the holes and let them decide what to do with it. Ultimately without something like that, it’s just smoke and mirrors, because the companies who don’t want to comply don’t have to.
But that’s not a true statement that my only skin in the game is $50. Exploits can take on all kinds of looks and feels. If I had kids, you bet I’d be a lot more concerned about their safety online than $50. If I used the same passwords in multiple places, it could mean huge amounts of liability depending on what I stored on those sites, including internal corporate secrets, like people tend to put on Google calendar and gmail, or worse. Granted, PCI is only interested in the payment card aspect of the law, but there’s a lot more at stake than that.
My personal motivation, is far less on the direct monetary losses side, and more on the consultant side, but I felt the same way back when I was just an interested security advocate - especially because losses as a merchant can impact other merchants. Think about recurring billing. If I have a nice recurring billing setup and another merchant looses the same credit card (because people use their credit card in more than one place) to an attacker, the account gets turned off, and I have to spin up my sales department to go retain that customer. There are tons of hidden costs, those are just a few.
November 11th, 2007 at 1:12 pm
You’re trying too hard. Some of the ASV’s allow you to mark parts of your site as “off-limits.” Just blacklist your vulnerable pages (assuming you don’t have holes across the board). Also, some of the scanner companies allow you to have trial runs to make sure they’re configured correctly, that’s a pretty easy way to get their IP address. At the prices they charge, no human ever looks at the results.
November 11th, 2007 at 1:50 pm
Even better point. So then the question is what is the spirit of PCI and is that within that spirit? If so, then what exactly is the point? Why should anything be off limits?
November 11th, 2007 at 2:58 pm
It seems that people have begun acting as if PCI compliance is some sort of mystical talisman. That it will secure their systems, ward off evil hackers and make their teeth whiter. It won’t.
PCI is an attempt to define a set common of security guidelines to help merchants and processors meet the compliance requirements of the payments members. The determination of compliance or non-compliance is still left up to the individual members. PCI compliance is important because it essentially offers a safe harbor provision if a breach should occur, and the merchant can prove they were compliant at the time of the breach.
Attaining PCI compliance isn’t like getting a certification to hang on ones office wall. It is an ongoing process. Passing the external scan is a point in time event that is only one part of overall PCI requirements and says nothing about the other facets. An entity can cease being PCI compliant at anytime.
As far as notifying PCI “authorities” about vulnerabilities, the PCI FAQ [1] states:
“”"
In case of a suspected breach, should the PCI Security Standards
Council be contacted directly?
No. In the event of a suspected account security breach, the business
entity should follow existing, brand-specific processes and procedures
for notifying the affected payment brand(s) and law enforcement
officials.
“”"
The PCI scanning procedures explicitly forbids your subversive approach. There won’t be any confusion about IP addresses. From [2]:
“”"
13. Arrangements must be made to configure the intrusion detection
system/intrusion prevention system (IDS/IPS) to accept the originating
IP address of the ASV. If this is not possible, the scan should be
originated in a location that prevents IDS/IPS interference
“”"
Furthermore, in the hypothetical situation, you’ve already most likely been less than truthful on the self-assessment to claim compliance. This is a common gamble. A single “No” answer means that you aren’t compliant. So, why go through the effort of actually being compliant, when you can pretend to be compliant? Everything is fine as long as your luck holds.
But if (and when?) a breach occurs, that lack of compliance will come back in a bad way. The penalties can be severe: fines that can range up to half a million dollars, loss of future ability to process card transactions, full financial liability for the cost to members, cost to re-issue cards, cost to members to perform an investigation, etc.
Because after a breach, the members can request a forensic audit (see Visa’s discussion at [3]). Even though your cut-rate ASV claimed that you were compliant, the audit is quickly going to reveal you weren’t. And that could potentially be a really, really bad day.
[1] https://www.pcisecuritystandards.org/about/faqs.htm
[2] https://www.pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1-1.pdf
[3] http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf
November 11th, 2007 at 3:42 pm
@Gregory - thank you for your well thought out response. However “The PCI scanning procedures explicitly forbids your subversive approach.” is incorrect, as I never said IPS/IDS - I said Firewall and transparent proxy. And I completely agree that this only works until you’re compromised, but statistically I think most companies believe they are safe, especially if it’s just a short term fix, until the hackers prove them otherwise.
November 11th, 2007 at 4:07 pm
@RSnake - sorry, I wasn’t more clear. I was focusing on the fact that the ASV has to tell you their IP address so you can’t very well claim ignorance later.
But WAF versus IPS is an interesting argument. I know that some would claim that a WAF is acting as an IPS and should be disabled when scanning. For example, something like running mod_security on a Apache reverse proxy. Personally, I can see both sides of the issue. It probably depends on how integrated the solution is and whether it fails open or close.
November 11th, 2007 at 4:36 pm
@Gregory - understood. But I think that’s a probably an important comment. What about load balancers? If I send the ASV to a secure website through load balancing, that clearly isn’t an IPS, but it provides complete security from that ASV.
Also, one additional comment about your first comment “As far as notifying PCI “authorities” about vulnerabilities, the PCI FAQ [1] states:
“””
In case of a suspected breach, should the PCI Security Standards
Council be contacted directly?” Those are different things actually. The first is talking about a consumer telling PCI that a website has a vulnerability and the second is about the website thinking they were breached. I really was talking about the case where I find a vulnerability in a retailer.
November 11th, 2007 at 6:25 pm
I’m glad you blogged this — this is one of a handful of more interesting topics that came up during the talk that I’d like to see something happen with.
How hard would it be for the PCI Council to set up some sort of anonymous whistle-blowers line.
It’s in their best interest to provide a truly anonymous method of reporting problems if it will encourage people to send in tips, which will increase the security of their approved sites, which will decreasing the amount of losses they collectively suffer.
@Jeremiah — I know for a fact there’s at least one well-known vendor who either doesn’t have anyone read the reports, or doesn’t have anyone with a clue read the reports. I’ve seen an alert that reported a Linux-specific vulnerability on a host that was identified as running AIX in an same scan. Whoops.
November 12th, 2007 at 5:22 pm
Both the IP address issue and load balancer issue are addressed in the PCI documentation that is provided to ASV’s. From the “PCI Security Scanning Procedures” document:
“Merchants and service providers have the ultimate responsibility for defining the scope of their PCI Security Scan, though they may seek expertise from ASVs for help. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible.”
That statement makes it very clear that it is not the responsibility of the ASV to ensure that the information provided by the customer is accurate, nor will it be the ASV who pays the price if it isn’t. PCI Compliance is not only something that gets the credit card issuers off of your back, but it may also provide a safe harbor from fees and lawsuits if something does go wrong. As a result, a business who employs deceptive techniques to gain the appearance of compliance, without actually becoming PCI compliant, will lose out on those protections and could pay a hefty price in the end. Getting a passing ASV scan report is not the same as being compliant, and the passing report is something that would be validated as a part of an internal audit that would inevitably occur after a system breach/information disclosure.
As far as load balancers go, this topic is addressed in the “Technical and Operational Requirements for Approved Scanning Vendors” document which states:
“The ASV should obtain written assurance from the customer that the
infrastructure behind the load balancers is synchronized in terms of
configuration. The configuration and the customer’s assurance must be
clearly documented in the scan report.
If the ASV cannot obtain customer assurance, the components must be
individually scanned from an internal location (behind the load balancers).”
So if you are a company who is willing to lie in writing and say that the infrastructure behind the load balancer is synchronized, when in reality it isn’t, then you could obtain a passing report through deceptive techniques. But again those techniques could eventually come back and bite you.
I felt compelled to post because it is very important to recognize that the business and not the ASV will ultimately pay the price for this type of deception, if there is one to be paid.
November 15th, 2007 at 5:25 pm
Rsnake, this is the same issue i am talking about it my previous post with scanalert. However, you created a bigger picture and amplify the magnitude of the problem. Nice one!!