Audits may not always be your favorite activity, but there are a few things you can do ahead of time to prepare and make it less painful.

Many administrators go through what I call the "audit fire drill" when they hear they're about to undergo an audit. My desire is to help eliminate some of the panic when preparing for an audit by giving you some tips to follow.

First, understand the purpose and scope of the audit. Not all audits are created equal. If you're about to go through a SOX (Sarbanes Oxley) audit, the focus will be on financials. If the audit is against the Payment Card Industry's Data Security Standard (PCI DSS), then the focus is for all parts of your organization that process and store credit cards. Or it may be an internal audit that's focused on your processes and supporting documentation. Understanding its purpose will help you know where to focus your energy in preparing for the audit.

Next, look at the results of the last audit. Were items noted as areas of concern? If yes, then address those items because they're sure to be examined during this audit. (I'm surprised how many administrators fail to do this step!)

You also need to review process documentation. If your process documentation is out of date (in other words, the document doesn't match your current process), the auditor will cite you. Better that there be no documentation than inaccurate documentation.

And while you may not know exactly what the auditor will be examining, there are some things that are pretty standard. You'll want to address the obvious:

• Security-relevant system values set to best practices; where they can't be, have the business justification in hand.
• Remove inactive profiles.
• Eliminate profiles with a default password.
• Ensure no end users have a non-expiring password. Be ready to explain the service accounts that must have a non-expiring password.
• Remove excess capabilities, and have a business justification for the users who retain special authorities—especially *ALLOBJ special authority.

Another aspect in preparing for an audit is to put yourself in the mindset that you may have to do some translation or education. What I'm really trying to say is that the vast majority of auditors are not IBM i-savvy and they may not ask you for information using the "right" term. Rather than lose patience or respect for them, go with the situation and try to make the best of it. Here are some of the commonly misused terms and their translations:

• User account = User profile
• Admin or root = QSECOFR
• Admin rights = Users with *ALLOBJ special authority or a member of QSECOFR
• Access controls = *PUBLIC authority, private authority, authorization list settings
• Logging = Auditing

I know it's frustrating when an auditor asks for something that just doesn't apply to the IBM i world. For example, I've heard them ask for who can decrypt passwords or how do you protect the file containing passwords. In the IBM i world, we don't have to worry about that because there is no facility to decrypt passwords. In fact, the passwords aren't actually stored. The folks at IBM in Rochester have done a nice job helping us out in that area by adding information to Chapter 3 in the V7R2 IBM i Security Reference manual about how IBM i deals with passwords. Once you open the manual, search for "Password Encryption and Storage."

Another topic auditors ask about is what file integrity monitoring software you use. I'm sure most of you would like to look at the auditor as if they had three heads because of that absurd question. It's absurd because IBM i audit entries are stored in journal receivers, and as we all know, you can't alter the contents of a journal receiver. This is clearly stated in a section of the V7R2 IBM i Knowledge Center titled "Using journals to monitor object activity."

Final Thoughts

Part of the frenzy in preparing for the audit is due to the fact that many administrators let the system lapse back into a non-compliant state, meaning that the areas of the system that they know the auditor will examine have to be cleaned up or else there will be audit findings. My recommendation is to put processes in place that will allow the system to be in perpetual compliance. I've been saying for many years that compliance is a lifestyle, not a one-time event. In fact, PCI DSS version 3.0 now requires you to prove that you are checking that the configuration is in compliance. Their term is "security as business as usual." If you're constantly checking, you'll eliminate—or greatly calm—the "audit fire drill."