undefined

points

[-]

> PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks.

My personally most hated compliance ruleset. I've been in Healthcare for over a decade, I'm a HIPAA/data security expert, and PCI compliance is genuinely harder and more nonsensical than HIPAA.

And to be honest, for every ONE healthcare place I've seen that would fail a HIPAA audit, I've seen 20 companies that would fail PCI compliance and by a wider margin. The number one PCI issue I've seen *literally* everywhere is recording/writing down card numbers with CVV. It's strictly forbidden by the rules, and every snall and medium business breaks that rule constantly.

by CodesInChaos2 hours ago|

parent|

[-]

What kind of business writes down credit card numbers (even without CVV)?

Online payments (e.g. e-commerce) usually send such data directly to the PSP, or encrypt it with a PSP controlled key.

And in person payments (e.g. stores and restaurants) use a payment terminal/device, which is presumably PCI DSS compliant and doesn't store such information.

by randerson3 hours ago|

prev|

[-]

I've implemented PCI-DSS and have 12 years of level 1 audits behind me. I actually find their rules to be sane, pretty good security practice. Internally, we made many of the controls standard across the board even for out-of-scope systems because they were sensible and we'd already built the tooling for it. If you implement it well, once you're compliant it is easy to stay compliant.

And yes, there is plenty of incentive to keep things out of PCI scope. I'd say that is PCI working as intended. Why would you want a larger attack surface that touches your credit card data?

by kstrauser7 hours ago|

prev|

[-]

I despise PCI-DSS. A friend owns a small business and has a credit card reader. Due to that, we had to build out a separate LAN so that the reader is on its own precious network, and have to pay an external auditor for a quarterly scan of our external IP. Bullshit past findings were things like “your VPN server supports old encryption algorithms”. “But our clients don’t support them. They select the newer algorithms!” “But they could!” “What do you care? Those clients aren’t even on the same LAN as the scanner.” “PCI-DSS lol!” I have no way of knowing, but I bet the firewall might’ve accidentally blocked the scanning IP from reaching the VPN server port on the retest and called it a day, but surely not.

Basically, Visa and friends externalized their own shitty security and made every other company in the land responsible for wrapping their janky hardware in electronic bubble wrap. A real security framework would’ve said “don’t make a credit card scanner so weak that it can’t survive being on the same LAN as a printer”. Instead, the whole country has to waste billions of dollars mitigating that risk for them.

by akerl_7 hours ago|

parent|

[-]

> Bullshit past findings were things like “your VPN server supports old encryption algorithms”. “But our clients don’t support them. They select the newer algorithms!”

Given that downgrade attacks are a massive category of attacks for network protocols, and in fact modern protocols go to great lengths to make them impossible, that doesn’t sound very bullshit at all.

by CodesInChaos2 hours ago|

parent|

[-]

The whole VPN requirement sounds like bullshit to me. The terminal should use secure TLS connections to the servers it communicates with, without relying on the security of the (local) network at all.

by akerl_1 hours ago|

parent|

[-]

Last I checked, a VPN isn’t required by PCI (or really any other compliance regime). The parent commenter’s infrastructure had a VPN. And once you have a VPN and you’re showing it to the auditors as part of your in-scope infra for PCI, asking you to remediate findings for insecure algorithms allowed in the server config is rational.

by kstrauser57 minutes ago|

parent|

[-]

Eh, not really. The VPN was on the same router that gave the card scanner access to phone home to the credit card company. They weren’t related at all. You couldn’t connect to the scanner’s LAN through the VPN. But since they had the same public IP, the vuln scanner counted them as in scope.

But in reality, why’s that a problem? Is the credit card scanner so tacitly busted that it can’t coexist with other hosts? Does it not use TLS? Doesn’t it pin TLS certs so that it’s not subject to MITM? Is it listening on ports with vulnerable services? There’s no excuse for the scanner being that delicate. It should be able to service an office LAN. And yet, the PCI-DSS group managed to push the responsibility for their hardware onto the network owners rather than making their own hardware robust. That’s nuts.

by kstrauser1 hours ago|

parent|

prev|

[-]

It wasn’t a requirement. They have a VPN server for remote access. The network scan found it and complained even though it’s not related.

by kstrauser7 hours ago|

parent|

prev|

[-]

If a client doesn’t support an algorithm, you can’t force a downgrade to it. A compensating control is that the clients are managed and only support the newest algorithms, and aren’t vulnerable to a downgrade attack.

Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.

by unethical_ban4 hours ago|

parent|

prev|

[-]

Why doesn't every bar with a POS system need a separate vlan for their register?

by bob10294 hours ago|

parent|

[-]

If you process < 20k online transactions per year you can skip a lot of the requirements.

by chopete33 hours ago|

prev|

[-]

We recently did PCI-DSS level2 and it was pain in the right place to complete the scans and gaps their scripts find. It took 6 months to complete the audit.