Ensure audit success with sound security audit procedures

A security review doesn't have to be a sink-or-swim proposition.

By George Wrenn

We've all seen them before, those blue suits carrying shiny leather briefcases: Auditors. They march into our shops, asking question after question, touching and probing everything connected to a CAT 5. They check for everything from industry best practices to security standards to government regulations. The result is usually a thick report that grades your security program as pass or fail. The CISSP exam is nothing compared to this pressure.

But, auditors -- whether they're internal or third parties -- are a security professional's friends. They are a second set of eyes, looking at your policies, infrastructure and practices and verifying the areas in which you're doing well, and those that need work. Most importantly, they tell you how well you're complying with standards and regulations, such as ISO 17799 and Sarbanes-Oxley.

IT audits may be stressful, but they don't have to be. A few simple steps will help you handle auditors, avoid common mistakes and reduce -- if not eliminate -- the stress.

Whether you're dealing with internal reviews or external specialists, the key to surviving a security audit is starting on the right foot.

Begin by scheduling a meeting with management to select a security audit response team -- a person or group that has the authority to facilitate the auditors' needs and respond to their inquiries.

The size of your enterprise and the scope of the audit will determine the size of your response team. For departmental and program audits, a point person may suffice. For broader internal and most third-party audits, you'll want a security audit response team composed of representatives from key departments, management and internal auditors.

Having the right people on your audit response team is critical. People who either have the answers on hand or can quickly investigate issues and report back to the auditors can help move an audit along faster.

Next, schedule a short meeting with the auditors. This will familiarize your organization with the audit process and set a good foundation. It will also help you determine the time commitments and resources you'll need to support the auditors.

During the meeting, you'll want to ask:

  • Which type of audit is being conducted?
  • Which methodology will the auditors follow? Will they measure you against your company's security policies, industry standards (ISO 17799), laws (HIPAA, GLBA, Sarbanes-Oxley) or a combination?
  • What is the scope of the audit, and which systems will be examined?
  • What documentation and materials will the auditors need?
  • What dates do the auditors plan to be on site? How long will it take to complete the audit?
  • What support and special considerations do the auditors require (e.g., private offices and workspace, telephones and faxes, network access)?
  • With this basic information in hand, it's time to collect the materials you'll need for the audit.

Documentation is king

Documentation is the key to explaining how your security program works. The auditors will use this documentation as a guide for reviewing and measuring your security program.

Common audit documents describe the system, security policies, operational procedures, network and system diagrams, process charts, change control procedures, process definitions, security scans/reports, test results and, of course, logs. If your organization has been audited in the past, you probably already have most of the information and materials you need. But, they will likely need updating, since no two audits are exactly alike -- especially if you're switching auditors.

It's the audit response team's job to sift through this mountain of paperwork and check each document for relevance. You want to be thorough, but don't over-document.

The end product should be logically organized and placed in a binder for the auditors. The easier you make it for them to find information, the smoother the audit will go.

Set the tone

Prepare a formal presentation to introduce the auditors to the process or system they will be reviewing. Every environment is unique, and an overview will make their jobs -- and yours -- easier.

Include slides of all systems, networks and applications being audited. Be specific. Don't just tell them your front-end Web server is Apache 2, but also that it proxies traffic to a J2EE application server, and that both servers run on Red Hat Linux.

Explain your applications and processes and how they relate to the business. Don't just say what's in your infrastructure. Sometimes systems, architectures and configurations don't make sense to outside observers until they're put into context.

Cover the major areas of security. Include identification, authentication, authorization, confidentiality, nonrepudiation, integrity, cryptography, audit and availability for each system. Explain how your security program addresses these needs and what the controls are for each.

Don't try to hide the ugliness in your infrastructure. Auditors will find it anyway. Highlight the areas that need improvement, as well as your strengths. Candor will reduce the likelihood that your presentation will be viewed as a smokescreen.

Supporting documents should back up everything noted in your presentation and be included in the documentation binder.

The auditors will have plenty of questions. The key to surviving their interrogation is to provide answers that reference the presentation or documentation. For example, if they ask about controls that separate account requests from approval and setup, your answer should be something like, "As mentioned in the presentation and supported by the account control document on page 27 of the binder, our process requires that an approval be granted by product operations prior to the MIS group setting up an account." This type of response shows that you know your own policies and processes.

Not knowing an answer isn't a sin. Don't answer questions with vague or misleading statements that can't be substantiated. It's OK to defer answering until you've had time to do research. Just say, "I don't have an answer now, but I'll investigate it and get back to you." Honest answers followed by strong evidence are always better than going out on a limb.

Support your auditors

Auditors should never be given root or administrative access to servers without a chaperone. However, depending on the type of audit and the auditors' methods, you may need to provide them with restricted access to systems and/or the data center. Supervising the auditors shows due care and will reflect well on your organization.

Auditors will inspect devices and software, but they will spend more time reviewing policies and interviewing employees and users. An administrative liaison is instrumental in helping auditors find documents that weren't included in the binder, as well as setting up interviews and meetings with key staff members.

Escorting and supervising your auditors gives you the opportunity to see the things they look at and hear the questions they ask your users. You can engage them in conversations about trends and standards, and answer any questions as they move through the system. Auditors appreciate this level of cooperation.

Receiving the report

Insist on a wrap-up meeting at the end of the auditors' site visit. Request a draft copy of any reports that will be issued and review them for accuracy (read: "sneak peek at what's coming"). Most auditors are willing to provide a draft and maybe even a short conference call to go over the findings. Once you receive the draft report, ask if you "passed."

In addition to their observations during their site visit and the documentation you have provided, they may follow up with a few more questions or request additional information. Responding quickly shows professionalism and saves money, since delays often end up as billable hours. Some audit reports will have a management response section in which you can rebut or respond to findings. Use this opportunity to describe what your group is doing to correct security deficiencies. Exercise caution, though, since a response will also give the auditors something to look for when they return for the follow-up.

Fixing the problems

Immediately following the audit, develop a remediation plan to address any deficiencies or recommendations made by the auditors. Major audits are usually performed annually, while focused audits happen more frequently. The initial audit -- even if you change auditing firms -- serves as a performance benchmark from which auditors will measure improvement or slippage since their last visit.

For every finding that requires remediation, you should have a clear idea of what changes to the system or policy would be acceptable, the criticality of these changes and how much time you have to correct them. Even if you can't complete the remediation before the next audit, the steps you take now will show you're working toward improvements.

Finally, you need to control your managers' expectations following the report's release. Celebrate specific successes and systematically root out failures. Make sure they understand that having passing grades in one area doesn't mean you can forget about shortcomings in others. And, don't let them believe that throwing money at the problem will solve everything; focused remediation plans will bolster their confidence in you.

About the author
George Wrenn, CISSP, is a technical editor for
Information Security and a security director at a financial services firm. He's also a fellow at the Massachusetts Institute of Technology.

This was last published in March 2004

Dig Deeper on IT security audits and audit frameworks