Who's auditing the auditors? (it should be you)

First published 30 September 2011 on Viryatechnologies.com

A recently published issue with a Security Auditor has highlighted just how much potential there is for the worst to happen when information is requested by someone with a level of authority. In this particular case, the person being asked for the information had the sense to challenge the request, but it's easy to believe that many others would have simply attempted to comply.

The Security Auditor in question was insisting that the following be provided;

  • A list of current user-names 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 an SSH keys
  • An email sent to him every time a user changes their password, containing the plain-text password.

It should be pretty clear to most that this presents a huge security issue, but faced with a Payment Card Industry (PCI) Auditor making the request, how many would simply assume that he “must know what he's doing”?


The data requested is actually very difficult to obtain from a Linux based server (as was the case) unless you've been pro-actively logging it (don't, ever!). Despite the auditor's claims, any system that stores user passwords in a retrievable form (and plain-text logging certainly falls into that category) would fail PCI compliance instantly.

It, of course, would be a logical assumption to assume that the auditor was in fact attempting to “socially engineer” the user as part of his audit. As, however, this particular auditor insisted on the information to the point of the user changing payment provider it seems unlikely.

The point of this article, however, is not to simply examine the mistakes of this auditor, but to look at the wider picture. What happens when someone with an air of authority and conviction in their statements asks for something you should not provide? Will you know what's OK to disclose, and what isn't?


Authority and Competence

Whilst the two are not mutually exclusive, they are also not necessarily both present. It can, however, sometimes be a little difficult to tell, especially when the person requesting data is showing absolute conviction in what they are saying. Looking at our linked case, when told that many of the things he'd requested were impossible, the auditor stated that;

“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.”

Leaving aside the fact that what he was asking isn't feasibly possible, this one sentence could be sufficient to convince you that he knows what he is talking about. Especially when it comes to an important event such as a PCI audit, it's very easy to assume that the other person knows better.

Unfortunately, simply challenging the person making the request often won't be enough. Very few audits are likely to contain 'trick' questions, if the request is being made it's because they truly believe that it's correct. Indeed, after being pointed to the discussion thread the auditor responded that

“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.”

Ignorant, but very convincing, especially to the uninitiated. Of course, those with a little more experience may note the severe errors in his statement (retrieving plain-text passwords from Unix servers hasn't been 'basic' since the 1970's).

In situations such as this, you need to examine your internal policies, raise the issue further up the chain, but never ever comply (even using fake data) with requests that pose a security risk. The most important thing to do is ensure the security of the system, the data requested in this case poses an enormous security risk, the auditor would not only be able to connect to the server at will, but could also authenticate as any user on the system.


Recognising Dangerous Requests

This point is the absolute crux of the issue, it doesn't matter whether you assume authority or not if you don't know how to recognise the dangerous requests.

There are so many types of data that could be requested that it's impossible to list them all here. There are, however, two main categories into which the really dangerous items fall;

  • Security
  • Data Protection

There may be some serious cross-over between the categories, as a failing in Security could easily lead to Data Protection issues.


Any request that would allow the requester to authenticate against your systems needs to be very carefully considered. The risks won't always be as obvious as in this case (where the auditor could log in as any user and wants to be kept up to date with their passwords), but it's important that you spot the risks and take action to mitigate them.

This may mean flat-out refusing to comply with a request (but explain why!) or creating a dedicated but very limited account for the auditor to use.

Requests for items such as Private keys also need to be considered very, very carefully. The auditor may simply want to check that all keys require a password, but the risks posed of passing an unsecured keypair to a third party cannot be understated. Depending on the set up of your server, this could allow the requester to upload any file, make changes to the file system, authenticate against your system or even completely wipe your system!


Data Protection

Data Protection issues are likely to occur wherever access to personal information is requested. This may simply be in the form of full access to a database, or it might be in the form of a request to have an export emailed across.

Consider both the requirement and the ramifications carefully, there will undoubtedly be occasions when third parties do require access to data, but these need to be balanced carefully with the risks.

If an occasion does occur where information needs to be supplied, you have to both exercise due diligence and keep a record to show the steps you've taken. Never, ever, email data across in plain text, ensure that it is encrypted with the requestors public key.

Only ever send the data that is absolutely required, it may be easier to simply email a full export of that database table, but you'll be unnecessarily exposing data. You need to be truly anal about protecting this data, question what information is required and why it's needed before you comply. If not all fields are required, remove them from the export.

Again, if you are in any doubt you should always challenge the request, and raise it at as high a level as seems appropriate.



Many experienced administrators will easily spot requests that should not be complied with, but the reality of our computer-dependant world is that many business systems run without an experienced administrator. Security of the system and the data it contains is the responsibility of every user, at every level and is not something that should be left as “an IT job”.

If you receive a request for data from anyone, no matter their level of authority, it is your responsibility to assess it before you comply. The person making the request is likely to believe that what they are asking for is correct, but it doesn't mean that they are necessarily right, no matter their experience or level of authority.

Every user of your system has trusted you to store their data, so you need to strongly consider whether or not any type of disclosure is appropriate. If complying with the request would necessitate compromising security (i.e. by storing passwords in a retrievable format) the answer should always be no!

It'll never be an easy situation, in the case we linked to the company was undergoing a compliance audit and could have been denied payment processing services if they failed. In the event, as a result of the incompetence displayed by the auditor they switched payment processing services rather than lowering their security to comply with a dangerous request. Regardless of the circumstances, you need to consider the implications of complying in a completely detached manner, and don't be afraid to say no!

Never forget to consider the reasons why this data may or may not be needed. An Auditor saying “I need full access to your system” is not sufficient justification, you need to ask which areas they need to access and why. Why give them full access to your system if you are able to grant access only to the areas they actually need?

Ensuring that you are willing to challenge such requests will also help to protect you from falling prey to social engineering. If you are in the habit of vetting any request for information, no matter the authority of the requester, you are far less likely to be fooled into disclosing privileged information to an attacker.