Birmingham? I think I know this guy - we have a client based there and are three years into a war with their PCI auditor, who are dangerously incompetent. They were adamant that we should be able to decrypt PANs (credit card numbers) - we still haven't complied, as we quite deliberately don't store them and just transit them.
It's not a phishing scam, this is pretty much state of the art in the UK - and try being a 32 year old "kid" company director while the 55 year old "security engineer" who seems to have never used a computer and thinks a network is a maritime term plays the "seniority" card in front of a client of the same generation.
The sad thing is I've seen two retailers drive themselves hard into the ground over the last eighteen months by listening to this variety of chumbly wotsit rather then someone who actually knows what the hell they're talking about.
One spent about £8M on their PCI auditor over six months, then went bust, blaming us, the platform provider - who are PA-DSS and ISO certified. The auditor blamed us too, then folded up shop and moved to Spain.
PCI compliance sales is often much worse than SEO. The economics of selling SEO services revolve around spending money to make things better.
Conversely every unsolicited interaction with a PCI auditing firm I've had has been a thinly veiled threat of how many times over we'd be personally bankrupted if an application were flawed.
"Look at these people. People like you. They had a nice app and then their app accidentally leaked the names of some child users and now they're in prison on Mars. It'd be a real shame if somebody were to test your application and find a flaw like that and you hadn't hired us. A real shame."
This is precisely why, despite being a software security consultant, I don't cold email folks. Even if they don't perceive it as a threat, it feels too much like one to even write such an email.
If you don't like my HN comment, at least read that reddit post. We need PCI because of the crap observed from that reddit post.
"Speaking of PCI, I remember having to tell the PRESIDENT of the company I used to work for that "No, I will not print out the customer database with full CC+3, including their name, address, and phone number. You could ruin the business." Took a while to really make him understand that."
> If you need a PCI Auditor, make sure they have a background like me
Maybe you're being flagged for the blatant self-promotion? I can't say for sure, as I wasn't the one who clicked 'flag'. You may want to tone it down a bit.
My bullshit detector was sitting firmly at maximum until your post, now I'm not so sure. I thought that surely and auditor couldn't be asking for plain text passwords, let alone the rest, and maybe this was just a massive troll by the OP.
Perhaps not.
I've dealt with Data Protection before but I'm not sure of the legality around attempting to get others to breach the law. This 'audit' sounds very much like a phishing scam so perhaps there's legislation that would put this situation outside the law?
In any case, I am always extremely cautious about naming and shaming so you should think carefully about answering calls to do so, but there does come a point where whistle-blowing on a massive potential security problem this sort of audit is encouraging is in the public interest.
I wouldn't dare name and shame. The worst one liked to sign off phone calls with us and the cliebt with a legal threat in our direction and a horror story in the clients'.
Like I said, there are good PCI QSAs out there, but there are also plenty who'll make you want to jump off a bridge.
In my opinion it's made the entire standard a total joke. Bully the web provider, ignore the bricks and mortar "write the credit card number and cvv in a ring binder 'process'". Does the retailer no good either, apart from making them feel secure, as that cost so much it must have been good, right? Right?!
How on earth was that spent? That's more than two orders of magnitude more than any PCI audit that I'm aware of (and since the regular requirement is to do that annually the number is even more insane).
The auditor was also a solutions provider. The client was like a deer in headlamps, and had no internal counsel and went utterly paranoid - they had deep pockets, but not enough to avoid a cashflow crisis. To be fair I don't know the precise figure but inferred it from the CVA debtors sheet and some other drama I won't go into, but it's a large multimillion sum. They had an aged epos system that was replaced, new computers for everyone, etc etc.
I don't know how often I haven't been asked to either recommend something, some party, some solution or even to solve a problem myself but I'm extremely strict about this, I simply won't do it.
The conflict of interest is such that I think that any auditor / company that doesn't understand this basic principle should not be in this business at all.
Networks, System Hardening, Boundary Protection, Access Control. Nothing in the PDF says anything unreasonable. The naysayers just don't want to open up the PDF and READ.
I've worked with about eight or nine. Two of them are jaw drops in horror. A bunch are "err, what?", but get the job done vaguely competently if in a very procedural fashion. Quite often it's totally nontechnical people with backgrounds in finance/filing who do the assessment. Finally, there are two outfits we've worked with that we liked - one well enough to come audit us.
Oh, also, the big automated platforms like SM and TW are pretty poor.
The way it's set up right now, if you're lucky enough to be deemed a QSA by the PCI council, congratulations, you are now legally welcome to blackmail and extort. Zilch oversight, it's the Wild West, and snake oil salesmen abound.
We had a very good experience with the folks at Security Metrics in Utah. Very reasonable people. And. We had some compensating controls and non standard things to be done. They were very much willing to work with us instead of against us.
I had a mixed experience with them - their automated scanner can be painful with misdetection, but their support usually makes up for it, even if they're slow to respond. I've not used them for anything other than the quarterly scans.
Hi Tom, very biased here, but I interned at MWR InfoSecurity and the team there seemed to be consistently very high quality (like finding 0-days in Chrome, Windows Kernel, etc) - would definitely recommend looking at them.
The OP reported the auditor with the appropriate authorities and hopefully they'll revoke their certification.
Alternatively, I'd report the auditor to the police for attempting to acquire personal user data, a clear violation of data protection acts and user privacy.
Indeed, truth is not always an absolute defence in the UK. Also the law varies depending in which jurisdiction you are in in the UK; e.g. England & Wales vs Scotland vs Northern Ireland.
The Credit Card companies should be smarter than that but they're the idiots that invented that "VBV/3D" validation (which teaches people to fall for scams) with "partners" that don't even have a valid SSL certificate
My New Zealand bank (.co.nz) sends you to a page on 'securesuite.co.uk' with their logo and asks for personal details, which goes against pretty much every best practice ever.
> they're the idiots that invented that "VBV/3D" validation
No - that's not idiocy, it's actually clever when you realize it's not intended as additional security, but a mechanic to shift the risk from the Credit Card Co's/banks to the card-holder - saving them millions in the process.
Having worked for a company that did PCI compliance in the UK (not it's core business), and therefore alongside a lot of people who had worked at other companies in the sector, I can tell you that this is definitely not the state of the art in the UK in my experience.
Most of the major companies doing this in the UK seem to be doing a very good job of it, I think the problem is with the much smaller, cheaper companies. I don't know if they are the majority, I hope not.
A ridiculous percentage of sites have very poor SEO. And you get developers arguing that SEO is bullshit all the time, but clearly there are ways to improve SEO... not hosting identical content on multiple URLs (or using Canonical URLs), having Semantic HTML, making sure your content in the URL / Page Title / Meta Description match terms you're targeting, and getting links back from solid referring sources... all valid. To just dismiss all SEO as junk... it's flippantly short-sighted. There are plenty of sites out there that need better SEO... often as a result of developers not knowing to ask Marketing for copy, or what keywords should be, or not looking at the whole picture.
"I get a 200 when I hit the URL, site is done, let's go home, Gents!" Yeah, look... we're on a team, we need to work as a team and that means having teammate's backs when there are things that impact their performance that they may not fully understand.
PCI Compliance... is one of these times. Developers will say things like, "Oh, we use Stripe so we're fine... we don't need certification." Or, "Oh we build the site using PCI Best Practices..." or even incorrectly go so far as to say they can certify something as being PCI Compliant. They can't. There are a limited number of places that can certify PCI Compliance, and it's really up to your company's legal team to determine if you need it or not. If you seek insurance, you're going to need it.
Occasionally, to get certification, you deal with -- as someone else said here -- someone who isn't technical and who is just trying to cross off questions on their form. The best way to deal with this situation isn't to just dismiss them outright. Without certification your site shuts down. You going to tell the COO / CMO / CEO etc. that the site you built isn't able processes payments any more? Who do you think will be the first one shown the door?
So... look, you don't want to fight with bureaucrats. They are dangerously non-technical people doing work that is "technical" and you need to deal with them. When you encounter one, you need to go out of your way to empower that person with alternatives. This auditor is asking for some flat out dangerous information, offer him dates when passwords were changed and your password policy -- which more often than not isn't setup on your servers. How many servers have simple Root passwords, even at the production level? Far, far too many. Because developers / DevOps didn't go that extra mile to make sure the passwords had to be reset ever X days, had to be unique, had to be complex, etc.
Sure, the guy doing the audit is dumb, but just because he's dumb doesn't mean you're perfect. Take the opportunity to learn best practices & requirements, enact true best practices, and suggest alternatives. If the alternatives don't satisfy the requirements, keep trying. It's not like PCI compliance standards are hidden, go read up on what the requirements are and come up with your own plan to satisfy them -- then work to communicate that plan with your C-team & legal tema, so they have your back, and can help you in dealing with the auditor. Auditors have bosses too. Everything can be escalated, and depending on how you play this you can have the auditor on your side or not through the escalation. Which way do you think is easier?
The issue is that there are, and especially used to be, a lot of very scammy SEO companies. The issue was that a non-technical client couldn't tell it was a scam - Google et al used to be a lot quieter about good SEO practice.
I'm entirely confident someone in that company felt PCI was a non-issue because they were to "use stripe". It's certainly not a safe deployment however.
> Do you contend that you still need PCI Certification even if you're only using Stripe?
Yes, if you have BOP or other form of liability insurance, one of the questions is frequently, "Are you PCI DSS Compliant?" If your legal team feels comfortable with your self-assessment for certification... sure, go with that. When it comes to your business, I think 3rd Party Audits can be quite helpful.
Here's an example question I pulled from an RFP just yesterday:
A) "Yes, we are compliant, and verified through self-assessment..."
B) "Yes, we are compliant and verified annually with XYZ Certification Company..."
But look, my main point was that with all of this there are non-technical considerations that play in. One team doesn't have all the answers, it takes a variety of disciplines working together to make a company run. Dismissing people who say PCI compliance is not just a technical issue shouldn't be the automatic response.
EDIT:
Let me follow up with another example... let's say you're the developer of an eCommerce system. You set it up to use Stripe and you've done everything correctly in terms of selecting a PCI Compliant hosting partner, etc.
What happens when customer support decides to, after processing a refund, help the customer re-order something? They take the customer's credit card over the phone, and create a new order for the user using the admin tools of the site... they're being helpful and accelerating the re-order process. But... presto you are no longer just a shop that just uses Stripe. How do we ensure that data is being handled correctly, that our staff haven't written down CCs or haven't stored them somewhere?
3rd Party audits can help a company uncover issues like this. And you, as the developer, don't want the liability of saying, "Yes we filled out the self-assessment and everything was great!" because you don't have visibility into how the tools you built get used after you hand them over to the client.
It's worth reading the actual guidelines for self-assessment if you have time, then you know for yourself if something is BS or not. Note that if you don't fall nicely into one of these categories, you don't qualify for self-assessment. (Check out A-EP for stores that exclusively use Stripe.)
So what can a developer do to their code to prevent someone in another part of a company from taking a phone call and writing down someone's credit card number? "Self assessed" or not, I'm failing to see how this can be prevented (or, more precisely, can be prevented by someone in the software development team). Not allowing certain IPs from entering credit card info at all? That's the only thing I can think of off the top of my head.
The other response was good, but yeah to be clear you don't want to go blocking your customer service IPs... that's just going to impede sales / returns / their ability to do their job.
You want to encourage your company as a whole, development and legal and everyone else, to take part in regular 3rd party audits and training around PCI Best Practices.
My point at the start of this was just that it doesn't do any good to dismiss this as "scammy" or think that one team can do this by themselves.
There's no "dev solution" here -- it's gotta be a company solution. (=
Part of the solution is that the admin functions do not collect credit card details at all. So through the admin site/app a customer service rep can't do an actual purchase.
That won't stop a customer service rep from using the retail site though.
I suppose you could monitor the retail site's log files and throw notifications when a customer service IP makes a purchase. Maybe also throw notifications when a customer's repeat business comes from a different IP (though this could be noisy).
Trying to block customer rep access to the retail site might be pretty tough. You'd need to really lock down a rep's workstation because they could be remoting into their home machine... assuming the rep was out to steal cards. At this level of paranoia I would expect all calls to be "monitored for quality assurance".
Hmm... there's an idea for a call center application addon. Use voice to text and machine learning to identify calls where a credit card number is asked for and/or spoken. This could be pretty easy once the voice to text is right (basically looking for strings of digits, maybe with long pauses between groups or "ok", "got it", "yeah").
PCI DSS compliance is a company-wide legal issue and thus needs buy-in from all relevant management and legal teams. Period. Self certification is mostly useful for small companies that might not even have a customer service "department", maybe just one or two people.
I may have misread the post I was replying to, but the poster seemed to be implicating the developer(s) as being culpable or at-fault for PCI non-compliance if some of these other things happened, which just didn't seem reasonable. That's what I was questioning, and yes, of course PCI compliance (as with other sorts of legal issues and whatnot) really are 'entire-company' issues. Devs can't/shouldn't be blamed if someone violates corp policies.
Much like the other replies to your comment, it's a whole company issue.
Many companies have had issues where 'customers' (read people committing fraud) come into a retail location and replace equipment with hacked readers. Your company needs to have measures to prevent things like this from occurring. It's not just 'credit card' security any more, it's protection against a number of human and computer equipment attacks.
this is strictly anecdotal, but i just was notified of a pending charge to my credit card, for ~$1000. The charge was from stripe, and I've only ever had transactions processed through stripe for 1 transaction, with 1 vendor.
so either the vendor screwed up, or something is insecure..
Well, if the auditor wants to play willy-measuring tactics: I've been using Unix since 1982 (Bell Labs Version 7, since you asked), and I rather suspect that I've more experience than he has.
UNIX and derived/lookalike systems like Linux have _always_ stored passwords one-way encrypted. I have precisely no idea how he expects the sysadmin to provide a list of plaintext passwords, short of replacing the passwd utility with a hacked one that stores the pre-crypt version somewhere for retrieval, or asking staff to email their plaintext passwords to the poor sap he's badgering.
Either way, a massive security breach. The whole point of one-way encryption is that there is no persistent trace left of the original plaintext password. This guy's way of auditing security recalls the Spanish Inquisition's way of auditing witchcraft. Damned if you do; damned if you don't.
His company's far better off using a payments provider with a clue - and a competent auditor.
I see responses like this from developers, and -- no offense -- it really doesn't advance the conversation.
The guy asking these questions is a bureaucrat, he's running his game book. Just telling him he's dumb and you're smart won't get you the certification your company needs.
In this case, yes I think these questions are insane. But you could respond like:
> A list of current usernames and plain-text passwords for all user accounts on all servers
We use Linux servers that store passwords using a one-way encryption. If we show you how we validate that all passwords are 16 characters long, contain special characters, are not passwords previously used, and are changed every 30 day, would that suffice for the password complexity scan we assume you are trying to perform with this password data you requested?
> A list of all password changes for the past six months, again in plain-text
See answer 1, we require all users to change their password every 30 days; passwords older than 30 days expire and can not be used.
> A list of "every file added to the server from remote devices" in the past six months
We use XYZ System for change management. Here are the change logs. We monitor log ins using ABC System. Here are the logs.
> The public and private keys of any SSH keys
Providing this information would violate our security policies. Our policies can be found in the attached PDF. Please let us know what compliance issue you are attempting to verify here so we can brainstorm alternate methods of providing the details. We change keys yearly.
> An email sent to him every time a user changes their password, containing the plain text password
See previous response, giving this would violate our security policies. We programmatically ensure complex passwords, and that passwords expire every 30 days. We can show you how the server is configured if you'd like.
End with, "For next steps, can we get someone from your technical team on the phone with one Security Lead to discuss these responses?" If they aren't game, just find another service provider. These questions are batshit, but they strike me as "first pass" questions sent over by someone junior. Find a way to get up the ladder a bit and everyone will be happier.
There are other service providers. Sorry I didn't read the comments in the StackExchange post.
There are other vendors. I think that'd be my next step -- go to my legal team or C-team, explain that answering these questions would put the company in danger, and suggest we consult with another vendor from the approved PCI list.
(Sorry I don't know if this is actually the list to go off of -- scans vs. audits, just my point is that there are public lists of approved companies to choose from.)
I had a client who just had some random dude telling them he could certify them as PCI Compliant... he was in no way authorized to do that. Was fairly hilarious how it played out; he'd been "certifying them" for years and even went so far as to give them a graphic they could display on their website. There are people who pray on ignorant businesses, but with a little research it's not terribly hard to educate yourself on what's real and what's BS.
EDIT: Just read the StackExchange post... Yeah, run. Guy is a nut job, like the random dude who had been advising one of my old clients. That call with him -- around how he wasn't really someone who could certify PCI Compliance -- was one of my favorite calls ever. He basically melted into a rant about, "I know good security, I have never had any of my servers hacked... well only like 2 but those weren't my fault!" Then said he'd get off the phone to do some research... and never called again, didn't even bother sending my client a bill for his services. Wish I had recorded it.
BUT... just because there are nut jobs out there, doesn't mean this is something companies should ignore. PCI Compliance is important.
We used to have plain PCI installed. Now, most of our servers have been upgraded to PCI Express. Shall I provide you a hardware report proving that PCI Express is installed and functioning?
Hmmm... perhaps the auditor should be informed that if he persists in requesting for user account and passwords in the guise of a security audit, you will have no choice but to report him to the FBI or MI5 as a suspected phishing scam operator who may have already compromised prior clients in similarly.
Does nobody find it unprofessional, perhaps even untrustworthy, to not only discuss the private dealings you have with other companies but also copy+paste e-mails? Even if they're idiots? I don't think you want to go down that road... "Well I thought the guy from Company X was an idiot, so why was it wrong for me to repost our private conversation?"
In this case, the company in question is run by dangerously incompetent idiots who’s advice, if followed, would result in their clients not only exposing themselves to serious risk if they ever were targeted by a real hack but would result in instant compliance failure if they were ever put through the compliance procedures of a competent agency. If a major contract was on the line, that kind of thing could put a company out of business.
Ordinarily I'd agree with GP but you are right that this is an unusual situation with potential for very detrimental legal consequence.
What's being asked for is absolutely a breach of the UK Data Protection Act and the providing company would be immediately legally liable for revealing this information.
I see this public discussion (bearing in mind no names have been revealed) quite invaluable in raising awareness of this sort of harmful request.
One thing you learn the good way or the hard way when you start to run companies is that any email should be considered part of a public audit trail, regardless of whatever unenforceable boiler-plate .sig text the legal beagles insist is appended. It can all end up in the public record as part of court evidence, or from man-in-the-middle capture, or Snowden-style whistle-blowing...or invent your own scenario.
In this case, the auditor was asking the poster to do something rather illegal, and certainly extremely unwise, to the point of compromising both the poster's career and his employer's business. Given those points, I'd say that publishing the emails constitutes fair self-defence, and the auditor - to put it bluntly - is very lucky that the poster was too professional to name and shame both himself and his company.
Almost all security audits in an enterprise/corporate setting are done in good faith. This is a person they hired and I'm assuming have spoken on the phone with so it's not unsolicited.
Trust me, I've had similar things happen. I don't know how there can be security auditors who don't even understand how password encryption works but I've had to explain it a few times. It's awful.
The security community has a whole lot of idiots in it who figured out that they can get a CISSP and turn themselves into a security auditor and get paid extremely well while getting to enjoy acting like tyrants. In reality they're not fit to manage a McDonalds.
It seems that the auditor wanted a fancier designation and decided upon "security auditor".
It is also possible that the auditor in question worked in a (physical) security agency in past life and failed to understand that computer security is not quite the same.
That seems to be the only plausible explanation for demanding actual plain-text passwords (past/present/whatever) and so on.
Oh, that old chestnut. Actually have exactly that at a client, guy used to run physical security at their stores and is now head of infosec but he's a lovely bloke and knows he's out of his depth, and has chosen good expert outside advice - we actually met the QSA we like through them.
Thing is in some regards PCI is quite analogous to physical security, as a lot of it is about documented process and auditability. Hell, a chunk of it is physical security.
So that progression isn't so bad, and as usual, you just get people who are willing to acknowledge their own shortcomings and work with others to resolve or mitigate against them, and those who don't.
How does that make it a troll? PayPal has a bad reputation in some respects, but not for having weak data security, right? It's mainly for always siding with someone requesting a chargeback.
Yeah, this person doesn't seem to understand that PayPal is a huge merchant provider for a lot, and I mean, a lot, of people. And that doesn't mean "using paypal" when you go to a website. They handled invoicing at my last job.
It's not a phishing scam, this is pretty much state of the art in the UK - and try being a 32 year old "kid" company director while the 55 year old "security engineer" who seems to have never used a computer and thinks a network is a maritime term plays the "seniority" card in front of a client of the same generation.
The sad thing is I've seen two retailers drive themselves hard into the ground over the last eighteen months by listening to this variety of chumbly wotsit rather then someone who actually knows what the hell they're talking about.
One spent about £8M on their PCI auditor over six months, then went bust, blaming us, the platform provider - who are PA-DSS and ISO certified. The auditor blamed us too, then folded up shop and moved to Spain.
PCI experts are the new SEO experts.