How do I give our security auditor the information he wants? (2011)

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.

Was with you until this end comment.

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?

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).

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."

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.

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.

One should expect that any email they send will at some point be posted for public consumption and compose emails accordingly

Email is not a secure or private means of communications, the faster people learn and accept this the better off everyone will be

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.

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.