alioth wrote:
Most PCI-DSS audits are somewhat barebones. If the company is using something like Worldpay to take credit card transactions, and doesn’t store or see the PANs themselves, then there’s no external audit at all. Most companies these days who take recurring payments use tokenization, and never see the cardholder data. So they don’t need an external audit. Given Garmin’s core business ins’t banking, I would expect they are using tokenization and are not holding any cardholder data such as PANs themselves.
Hm. Did not think that they might just outsource payment…
Most PCI-DSS audits are somewhat barebones
Not my experience at all. That bloody cartel gave us so much hassle we had to stop payment processing and hand it out, in our case to Paypal who take 2.5% or so.
Did not think that they might just outsource payment…
Most big firms don’t, because of the margin lost. If you have in-house IT worth a damn, you may as well do it yourself.
Also I wonder how outsourcing payment processing is possible with repetitive payments e.g. monthly database subs. Every firm I have ever known that does that is storing your CC details.
arj1 wrote:
“Protecting all systems against malware and performing regular updates of anti-virus software. Malware can enter a network through numerous ways, including Internet use, employee email, mobile devices or storage devices. Up-to-date anti-virus software or supplemental anti-malware software will reduce the risk of exploitation via malware.”
So? I’m pretty sure they have – like any major company independent of card payment – some anti-virus-software installed and do “regular updates”. So they are most likely fully compliant to PCI-DSS.
The idea that installing normal anti virus software is a solid protection against malware is - somehow cute …
PCI-DSS doesn’t check for AV software, IME, and anyway I don’t recall a single case of AV software picking up anything in the last 10+ years, at home or at work. This is across AVG, the M$’s own Defender, and Kaspersky. That could of couse be due to good procedures on our part 
But we do filter our incoming emails through Messagelabs, £450/year!
PCI-DSS gets you to fill in a massive questionnaire, and does a port scan. If they find you are running other services e.g. email on the same IP they object. It’s really quite daft. They do run some commercial penetration test suite.
I reckon somebody got somebody at Garmin to run some attachment, sent over say a support chat facility. Very hard to guard against that sort of attack. Basically the machines used for that need to run a throwaway VM, or some equivalent setup. Many firms block their employees from executing attachments which then means you cannot send a screenshot of some problem to support, which is dumb.
Peter wrote:
I reckon somebody got somebody at Garmin to run some attachment
Probably a JavaScript on a website: https://www.bleepingcomputer.com/news/security/garmin-outage-caused-by-confirmed-wastedlocker-ransomware-attack/
However, they did manage to compromise devices used by employees of over 30 major US private firms using fake software update alerts displayed by the malicious SocGholish JavaScript-based framework delivered through dozens of hacked U.S. newspaper websites.
How would that work? Did somebody apply an update without first checking it on a machine which is non-critical? Or was the JS an external link (that’s bad practice, but not uncommon) and that server got infected?
JS runs client-side (it’s an interpreted language running in a browser) and has no more access to the server than any other code running at the client.
Peter wrote:
Also I wonder how outsourcing payment processing is possible with repetitive payments e.g. monthly database subs. Every firm I have ever known that does that is storing your CC details.
We have customers with monthly subs and we don’t store any CC data. As I said earlier, tokenization. We hold a unique token that allows us to charge a credit card. The token is useless for anyone else other than ourselves, so even if there were a breach, the attacker wouldn’t be able to do much with the token. We don’t store PANs, expiration dates, CVVs or anything like that.
Many companies use services such as Worldpay for handling credit/debit card transactions. We do. We could do our own CC handling, but why bother when Worldpay do it relatively inexpensively for our volume, and banking is not our core business? As for Garmin, why would they want to handle the gory details of credit cards themselves when farming it out to Worldpay would be a tiny percentage of their costs, and gets rid of all the headaches of dealing with credit cards, and tokenization more or less completely de-risks doing recurring payments.
Some years ago we did credit card processing (bill handling) for another company, in that case we were handling PANs, CVVs etc. on behalf of our customer, so we had a PCI DSS ROC. The audit was lengthy, but I got the impression that had we not been doing things properly, it wouldn’t have been hard to pull the wool over the eyes of all the auditors we had during that period (all sent by an Extremely Large Well Respected organisation). If a company wants to take short cuts on this they could do despite auditors. And there’s evidence that this happens: a lot of these companies that get breached and leak millions of credit card holder details have been fully audited and been given a ROC (report of compliance).
Peter wrote:
JS runs client-side (it’s an interpreted language running in a browser) and has no more access to the server than any other code running at the client.
Cross site scripting vulnerabilities can be used to make you (as an example) think you’re downloading something from a trusted source, but are instead getting it from your attacker.
XSS defences have to be done server-side, so how does JS come into this? If Garmin were relying on JS i.e. client-side data validation…
JS comes into it because it’s things like a Javascript injection attack that can be used as part of the exploit that allowed whatever it was to get in, to get in.
Don’t forget there are hundreds of clients running inside Garmin’s network, and this attack looks like it was actually specifically targeted at Garmin. A bit of social engineering, an XSS vulnerability (not necessarily in Garmin’s estate, but someone else’s who may be considered ‘trusted’ and therefore is useful as part of the social engineering exploit) and you open paths for people to get malware into the network when they think they are getting something from a trusted source. If on top of that you have a monoculture (Windows-only), and too many people with too many privileges, and you’re behind on your Windows patching, then you have a problem.
