pci dss - Our security auditor is an idiot. How do I give him the information he wants?

A security auditor for our servers has demanded the following within two weeks:

• A list of current usernames and plain-text passwords for all user accounts on all servers


• A list of all password changes for the past six months, again in plain-text


• A list of "every file added to the server from remote devices" in the past six months



• The public and private keys of any SSH keys


• An email sent to him every time a user changes their password, containing the plain text password

We're running Red Hat Linux 5/6 and CentOS 5 boxes with LDAP authentication.

As far as I'm aware, everything on that list is either impossible or incredibly difficult to get, but if I don't provide this information we face losing access to our payments platform and losing income during a transition period as we move to a new service. Any suggestions for how I can solve or fake this information?

The only way I can think to get all the plain text passwords, is to get everyone to reset their password and make a note of what they set it to. That doesn't solve the problem of the past six months of password changes, because I can't retroactively log that sort of stuff, the same goes for logging all the remote files.

Getting all of the public and private SSH keys is possible (though annoying), since we have just a few users and computers. Unless I've missed an easier way to do this?

I have explained to him many times that the things he's asking for are impossible. In response to my concerns, he responded with the following email:

I have over 10 years experience in security auditing and a full
understanding of the redhat security methods, so I suggest you check
your facts about what is and isn't possible. You say no company could
possibly have this information but I have performed hundreds of audits
where this information has been readily available. All [generic credit

card processing provider] clients are required to conform with our new
security policies and this audit is intended to ensure those policies
have been implemented* correctly.

*The "new security policies" were introduced two weeks before our audit, and the six months historical logging was not required before the policy changes.

In short, I need;

• A way to "fake" six months worth of password changes and make it look valid


• A way to "fake" six months of inbound file transfers


• An easy way to collect all the SSH public and private keys being used

If we fail the security audit we lose access to our card processing platform (a critical part of our system) and it would take a good two weeks to move somewhere else. How screwed am I?

Thanks for all your responses, It gives me great relief to know this isn't standard practice.

I'm currently planning out my email response to him explaining the situation. As many of you pointed out, we have to comply with PCI which explicitly states we shouldn't have any way to access plain-text passwords. I'll post the email when I've finished writing it. Unfortunately I don't think he's just testing us; these things are in the company's official security policy now. I have, however, set the wheels in motion to move away from them and onto PayPal for the time being.

This is the email I've drafted out, any suggestions for stuff to add/remove/change?

Hi [name],

Unfortunately there is no way for us to provide you with some
of the information requested, mainly plain-text passwords, password
history, SSH keys and remote file logs. Not only are these things
technically impossible, but also being able to provide this
information would be both a against PCI Standards, and a breach of the
data protection act.
To quote the PCI requirements,

8.4 Render all passwords unreadable during transmission and storage on
all system components using strong cryptography.

I can provide you
with a list of usernames and hashed passwords used on our system,
copies of the SSH public keys and authorized hosts file (This will
give you enough information to determine the number of unique users
can connect to our servers, and the encryption methods used),
information about our password security requirements and our LDAP
server but this information may not be taken off site. I strongly
suggest you review your audit requirements as there is currently no way
for us to pass this audit while remaining in compliance of PCI and the
Data Protection act.

Regards,
[me]

I will be CC'ing in the company's CTO and our account manager, and I'm hoping the CTO can confirm this information is not available. I will also be contacting the PCI Security Standards Council to explain what he's requiring from us.

Here are some emails we exchanged;

RE: my first email;

As explained, this information should be easily available on any well
maintained system to any competent administrator. Your failure to be
able to provide this information leads me to believe you are aware of
security flaws in your system and are not prepared to reveal them. Our
requests line up with the PCI guidelines and both can be met. Strong
cryptography only means the passwords must be encrypted while the user
is inputting them but then they should be moved to a recoverable format

for later use.

I see no data protection issues for these requests, data protection only
applies to consumers not businesses so there should be no issues with this
information.

Just, what, I, can't, even...

"Strong cryptography only means the passwords must be encrypted while
the user is inputting them but then they should be moved to a
recoverable format for later use."

I'm going to frame that and put it on my wall.

I got fed up being diplomatic and directed him to this thread to show him the response I got:

Providing this information DIRECTLY contradicts several requirements
of the PCI guidelines. The section I quoted even says storage
(Implying to where we store the data on the disk). I started a
discussion on ServerFault.com (An on-line community for sys-admin
professionals) which has created a huge response, all suggesting this
information cannot be provided. Feel free to read through yourself

https://serverfault.com/questions/293217/

We have finished moving over our system to a new platform and will be

cancelling our account with you within the next day or so but I want
you to realize how ridiculous these requests are, and no company
correctly implementing the PCI guidelines will, or should, be able to
provide this information. I strongly suggest you re-think your
security requirements as none of your customers should be able to
conform to this.

(I'd actually forgotten I'd called him an idiot in the title, but as mentioned we'd already moved away from their platform so no real loss.)

And in his response, he states that apparently none of you know what you're talking about:

I read in detail through those responses and your original post, the
responders all need to get their facts right. I have been in this
industry longer than anyone on that site, getting a list of user
account passwords is incredibly basic, it should be one of the first
things you do when learning how to secure your system and is essential
to the operation of any secure server. If you genuinely lack the
skills to do something this simple I'm going to assume you do not have

PCI installed on your servers as being able to recover this
information is a basic requirement of the software. When dealing with
something such as security you should not be asking these questions on
a public forum if you have no basic knowledge of how it works.

I would also like to suggest that any attempt to reveal me, or
[company name] will be considered libel and appropriate legal action
will be taken

Key idiotic points if you missed them:

• He's been a security auditor longer than anyone else on here has (He's either guessing, or stalking you)


• Being able to get a list of passwords on a UNIX system is 'basic'


• PCI is now software


• People shouldn't use forums when they're not sure of security


• Posing factual information (to which I have email proof) online is libel

Excellent.

PCI SSC have responded and are investigating him and the company. Our software has now moved onto PayPal so we know it's safe. I'm going to wait for PCI to get back to me first but I'm getting a little worried that they might have been using these security practices internally. If so, I think it is a major concern for us as all our card processing ran through them. If they were doing this internally I think the only responsible thing to do would be to inform our customers.

I'm hoping when PCI realize how bad it is they will investigate the entire company and system but I'm not sure.

So now we've moved away from their platform, and assuming it will be at least a few days before PCI get back to me, any inventive suggestions for how to troll him a bit? =)

Once I've got clearance from my legal guy (I highly doubt any of this is actually libel but I wanted to double check) I'll publish the company name, his name and email, and if you wish you can contact him and explain why you don't understand the basics of Linux security like how to get a list of all the LDAP users passwords.

Little update:

My "legal guy" has suggested revealing the company would probably cause more problems than needed. I can say though, this is not a major provider, they have less 100 clients using this service. We originally started using them when the site was tiny and running on a little VPS, and we didn't want to go through all the effort of getting PCI (We used to redirect to their frontend, like PayPal Standard). But when we moved to directly processing cards (including getting PCI, and common sense), the devs decided to keep using the same company just a different API. The company is based in the Birmingham, UK area so I'd highly doubt anyone here will be affected.