When an ISO 27001 auditor is knocking at your office door, that is not the time to check whether the latch on your window works. It's time to take a deep breath and review some important guidelines on how to handle an audit. First off, keep your eyes on the prize. Remember that the auditor is going to be asking about your organization's security policies (sometimes referred to as "controls"), how you adhere to those policies, and whether you can provide records that demonstrate your adherence -- all with the end goal of certifying that the overall system works and certification is warranted. The auditors will be representing an accredited certification firm and the audit itself is meant to demonstrate to all concerned parties (i.e., stakeholders) that you are following good security practice. As Unix admins, we're probably all well schooled in the basics of security and the three-legged stool on which it rests (confidentiality, integrity and availability). Those same principles underly security standards such as ISO 27001. So, focusing on how you keep your systems in line with these principles, you should be in good shape for responding to audit questions. Before an audit begins, you should already have been schooled on what to expect. In general, auditors can talk to anyone, though one-on-one interviews will have been arranged ahead of time. They will want to have some interactions with a sampling of staff so that they get a well rounded picture of how well your security system works, but the "drive by" questions are likely to be very general in nature.
Good rules of thumb
Don't take the audit too personally. You are not being interrogated to uncover some wrong that you've done and you're not on trial nor are you under oath. The auditor's goal is to determine whether the overall security structure under which you are working represents good practice and is reliable. Understand that auditors are trained to be fair. They're impartial at worst. In fact, they might actually prefer to see your organization pass the audit. Their goal, however, is to impartially assess your security system and to promote good security practice in the process, not to catch you in some failing. Let the auditor ask the questions and don't volunteer information that he or she hasn't requested. Don't embellish your answers with any more details than are absolutely needed. Listen to each question and provide simple, straightforward answers. Ask questions if you're not sure what the auditor is looking for. Don't guess. If you don't know an answer, admit that you don't know, but also don't be afraid to consult other resources. If you don't remember how frequently accounts on your systems are reviewed (to be sure that they're still needed and still valid) but have a review schedule posted in your online documents, go ahead and refer to it. If you don't know how to report a security violation, but would ask your boss if you encountered one, just say so. And, if you are prepared to say who you would report a violation to if your boss was unavailable, so much the better. Don't take an audit as an opportunity to criticize your boss, your coworkers, or your company. Doing so is likely to have repercussions that you won't like. Don't criticize the audit process itself or argue with the auditors. Just make sure your answers are clear and move on.
And if that auditor hasn't quite turned your doorknob yet, ask yourself the following kind of questions to be better prepared: Where are the security policies that you're working under? Are they accessible to you? Do you know how to find them? Which policies apply to the work you specifically do? Are you aware of their major clauses and requirements? Where are records kept that show how you comply with your policies? Do you keep records that demonstrate, for example, when accounts are reviewed or disabled? Can you provide records that show that accounts on the systems you manage have been properly authorized? What is your policy on password aging (if you have one)? Can you demonstrate that it's in use? How often do you patch your systems? Do you keep a log showing when this work is done? How do you assess your systems for vulnerabilities? Do you retain scan reports? Do you follow up by addressing the vulnerabilities? How often do you review log files for evidence of problems? How long do you retain log files? Do your policies address this? How do you control root or other administrative access to your systems? The questions you should be asking yourself can be derived from the security policies that govern your organization and your role within that organization. The list above is probably a good start, but there may be many others that you can add to this list. Once you know what's required of you and can show that you meet those requirements, being visited by the auditor will feel more like a friendly chat than an interrogation.
Read more of Sandra Henry-Stocker's Unix as a Second Language blog and follow the latest IT news at ITworld, Twitter and Facebook.