For many information security professionals, a visit from an auditor is perceived as something to be feared or endured. However, an experienced auditor can offer many benefits, such as a neutral and honest review of an organization's security posture, validation and support of the company's efforts, and useful advice on how to mitigate gaps and meet requirements.
If a requirement can't be implemented, it shouldn't be in a policy or standard.
That being said, based on my many years of experience as a senior auditor and after assessing a wide variety of organizations, I want to share some real-world, useful tips on how infosec pros can collaborate with auditors to make an IT audit -- such as with the Health Insurance Portability and Accountability Act or the Payment Card Industry Data Security Standard (PCI DSS) -- as useful, painless and efficient as possible for both the auditor and the organization being audited.
Below are four tips organizations can use to ensure successful organization-auditor collaboration.
Before they come on-site, most auditors will request a variety of information -- e.g., network diagrams, system inventories, control descriptions – and infosec pros should provide as much of this as possible. The more an auditor understands about an organization's environment before he starts, the more efficient and timely the audit will be. If an auditor does not receive adequate information in advance, he must learn about the organization from scratch upon arrival, which not only makes for a longer audit, but may also lead to auditor misunderstandings or confusion.
In advance of an auditor's visit, an organization should also ask the auditor which experts (e.g., developers, system administrators, network administrators) he will need to meet with. The organization must ensure its experts come to the formally scheduled meetings with equipment (such as laptops) and passwords that enable them to access the systems the auditor needs to see. It is important to note that auditors have a schedule and budget, and therefore appreciate not standing around or finding out last minute that a key employee is not available.
An information security team should also learn the basics of the standard the organization will be audited against, and be cognizant of the unique attributes of the environment that is to be assessed. For example, if an organization is being audited against the PCI DSS, it is important to know what the organization's cardholder data environment (CDE) is, because not only does the CDE determine what will be assessed during a PCI audit, but it can also vary significantly from one organization to the next. This knowledge will help infosec pros understand what systems and processes are likely to be assessed when the auditor arrives.
Once on-site, one of the first and most important tasks for an auditor is to determine what systems and processes are in scope for the audit. Infosec pros can help the auditor accurately and efficiently do this by clearly identifying and documenting how sensitive information (such as credit card information or medical data) flows through the organization -- auditors love data flow diagrams!
After the first day on-site, an organization should ask the auditor to clearly explain what he considers to be in scope for the audit. If they disagree with the scoping or don't fully understand it, the organization should calmly discuss the scoping with the auditor until they reach an agreement.
Avoid red flags
More on audit planning and preparation
Audit management: Five strategies to streamline the PCI audit process
Ensure audit success with sound security audit procedures
How to select a set of network security audit guidelines
IT security auditing: Best practices for conducting audits
Certain actions by an organization will make an auditor nervous, which will likely result in increased scrutiny and time on-site. More specifically, it is critical to never lie or make up information during an audit; this is a major red flag. If an auditor thinks he is being lied to or misled, he will perceive this as a significant risk to himself and his employer, and therefore dig deeper in order to reduce the risk. Never assume auditors aren't technical and won’t understand your systems. Many auditors have significant "hands on" technical experience and have assessed many different environments and technologies. It's OK to tell an auditor, "I don't have an answer for you right now, but I will get you one as soon as possible."
Another red flag for an auditor is if an organization is not confident in knowing where sensitive information is stored and/or how it moves throughout the organization. From an auditor's perspective, the implementation of security controls is highly dependent on an enterprise's understanding of where its sensitive data is. If an auditor believes a company is not fully aware of its sensitive data, he will likely assume the measures used to protect the data are not correctly or fully implemented, and will therefore further scrutinize the controls. Security pros can prevent this by clearly identifying and documenting how the sensitive information subject to the audit flows through the organization.
A final red flag to be aware of is if controls are mentioned in policies and standards but are not consistently implemented. For example, if an organization's policy states systems must have strong passwords and the auditor's hands-on assessment reveals many systems have weak passwords, he may doubt the organization's capabilities, causing him to inspect the controls more thoroughly than usual. Security pros can prevent this from happening by verifying that all requirements in their organization's policies and standards have been implemented; if a requirement can't be implemented, it shouldn't be in a policy or standard.
At the beginning of an audit, I highly encourage those being audited to request that the auditor report any significant gaps as soon as they are determined. This will minimize surprises for the organization and allow for prompt remediation -- something all auditors like to see. And, depending on the circumstances, an auditor may allow certain gaps to be fixed on the spot (e.g. removing an unnecessary software program from a server or enhancing the password policy on a server).
If a security manager doesn't understand why an auditor thinks there is a gap, he should ask for an explanation; perhaps the auditor misunderstood something. A good auditor will always clearly explain why there is a gap and the intent of a specific requirement. If there's a strong technical or business reason why a gap can't be mitigated, the organization should ask if a compensating control is possible.
The ultimate goal of an auditor is to collaborate with and improve the security of the organizations he assesses. It's much better for an organization to have an auditor find a gap and help fix it than to have a malicious person find it and exploit it.
By following the advice in this piece, information security professionals can significantly help their organizations have a useful, painless and efficient information technology-focused audit -- and learn a few things in the process.
About the author:
Steven Weil, CISSP, CISA, CISM, CRISC, QSA, is a senior security auditor at Coalfire Systems. He has 17 years of experience in information security design, implementation and assessment. He has audited complex, challenging organizations such as universities, government agencies and large payment processors.
Editor's note: The views and opinions expressed in this article are those of the author and do not necessarily reflect the opinions or practices of the author's employer.
This was first published in January 2014