![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
The joy of credit card audits
Big merchants like Target have to get an annual audit that their IT systems are secure for processing credit cards. The level of audit varies, depending on whether or not they store credit card info internally. For example, Amazon stores your credit card so they have a (theoretically) more stringent audit.
Small merchants, like a mom & pop coffee house, don't normally get audited, they just send in a questionnaire to Visa/Mastercard.
The problem is, every merchant that has been hacked has passed the audits. In one case, they were being hacked WHILE BEING AUDITED. And it wasn't noticed.
The issue is that the auditors are not doing a really comprehensive job. They look for some things and miss others, like the merchant who was storing unencrypted credit card info for five years.
And aside from auditors not looking thoroughly and trying to do penetration tests, any configuration change or network change or replacing the firewall or router on an otherwise compliant and safe network can introduce a host of vulnerabilities.
IT security is a moving target, and there is no easy solution. Visa/MC forcing merchants and vendors to replace their equipment with chip and PIN systems by October 2015 is a step in the right direction, but it's going to be expensive and while transitioning, bring in a host of vulnerabilities all on their own.
http://www.wired.com/threatlevel/2014/03/trustwave-target-audit/
Small merchants, like a mom & pop coffee house, don't normally get audited, they just send in a questionnaire to Visa/Mastercard.
The problem is, every merchant that has been hacked has passed the audits. In one case, they were being hacked WHILE BEING AUDITED. And it wasn't noticed.
The issue is that the auditors are not doing a really comprehensive job. They look for some things and miss others, like the merchant who was storing unencrypted credit card info for five years.
And aside from auditors not looking thoroughly and trying to do penetration tests, any configuration change or network change or replacing the firewall or router on an otherwise compliant and safe network can introduce a host of vulnerabilities.
IT security is a moving target, and there is no easy solution. Visa/MC forcing merchants and vendors to replace their equipment with chip and PIN systems by October 2015 is a step in the right direction, but it's going to be expensive and while transitioning, bring in a host of vulnerabilities all on their own.
http://www.wired.com/threatlevel/2014/03/trustwave-target-audit/
no subject
no subject
I suspect that the companies/auditors have to follow, more or less, a script set by the PCI authorities: check X, Y, Z. If they are a creative and flexible tiger team, they might look at A, B, C. But looking in other areas takes time and represents no bonus for their report, and that time could be spent at another client performing another audit. So it could be that the structure of the audits is constricted.
But I think the big problem is that seemingly minor changes can result in invalidating the audit, and if the audits are only conducted annually, that's trouble. Walmart, after a hack, now audits twice a year. I think ideally, assuming a large enough IT dept that took security seriously, you'd have an in-house tiger team that's constantly testing your system, trying to break in. But few corps are going to spend $300k+ annually for a business unit that doesn't produce revenue.
I am a horrible person when it comes to testing vendor claims. I'll set out to break things, and because I have 30 years experience with computers and am an evil bastard, I'll usually win. At my previous employer, I found out that the ERP vendor, though their software used SQL Server as its data store, it did not use it correctly. Specifically, relational database servers use a transaction log to maintain database and transactional integrity. When you change data, it's written to the log first, then when the system has time, it's written to the tables. IF you use it properly. If power is lost, when the server comes up and the database is in the process of starting, it walks through the transaction log and if a transaction has been written (committed) to the database it's deleted from the log, if it was in the process of updating the database but didn't complete (uncommitted transaction(s)), it backs the changes out of the database in order to maintain database consistency.
Because the ERP system did not use proper coding techniques, they didn't use the log properly and if you suffered a crash during a long-running process, to ensure integrity you needed to restore data to the point BEFORE THE PROCESS STARTED.
In a meeting with the IT director and the ERP manager, while I was telling them about the problems with the ERP system and the ERP manager saying that he thought they'd fixed that problem, I told them that I wanted to spin up a copy of the system, start a long process, and pull the power plug on the database server and see if it recovered. The ERP manager almost had a stroke.
I didn't get to do my test, they're still running the same POS ERP system, and apparently it's a constant joy (in the Chinese 'interesting' sense). And the three of us from that meeting are no longer there: the ERP manager took an early retirement after getting pissed off by the director, the director resigned "in lieu", and my contract wasn't renewed about two years later.
no subject