Re: Question
Why were they downvoted?
"physical access to a terminal" - okay, fair enough.
"back office server" - storing plain-text credit card records? Strike one.
"head office PC" - storing plain-text credit card records? Strike two.
"plugging their own lappy into a live LAN socket in store"? No VLAN? No traffic encryption? No port-isolation? Strike three.
" (or weakly password-protected in-store Wi-Fi)" Strike four.
"infected website payload downloaded on the back office PC by staff at lunchtime etc" (See above)
None of those but literally access to a terminal should mean compromise. And even that means compromise of the terminal, no compromise of the entire system. Anything else is not only poorly-designed but not PCI-DSS compliant at all.
NOBODY - at any kind of office or otherwise - should be able to see the plain-text credit card data on their PC. From merchants to a central secured network with full encryption, which then submits to the bank over a similar encrypted channel, sure. But nobody should be using the credit card data itself (sales records and APPROVED/REFUSED are another matter entirely and should be on an entirely different system) at all except the bank. Hell, most of the retail-store systems you see just talk straight out to the bank over secured channels that the company has no control over.
That you can put ANYTHING on a POS network and have it sniff traffic, or compromise other ports, or do anything but talk over an encrypted channel to a bank is ridiculous. And certainly there should be no bog-standard office PC which has access to that data, even in theory for a large retail chain. Maybe a mom-and-pop shop, but they talk to the bank direct and the attack vectors are elsewhere in that case.
Honestly... just shouldn't be happening. And certainly shouldn't be CLOSE to a network that allows any kind of software update / attack / compromise of the system by a third-party. Their bank will have their ass on their PCI-DSS disclosures if that's even possible.
Biting the hand that feeds IT
