To paraphrase, yet again, the illustrious quote of Forrest Gump and his momma, "An IT auditor's checklist is like a box of chocolates. You never know what you're gonna get." Oh, sure, we know that there will be mostly chocolate-covered things, and some of those things will be crunchy, and some of those things will be chewy. Some things you'll like; others you might not. But until you actually bite into the piece, you're only guessing. The same is true of the IT audit checklist with which your auditor will technically introduce himself or herself.

The checklist will almost always have a large section that deals with your IBM i system values, such as Security Level (QSECURITY) and Password Expiration Interval (QPWDEXPITV). You can also expect to see sections on things such as communications, library authorities, user profile setup and maintenance, and physical security (e.g., is the computer room door locked, is there proper fire retardant, is the log book signed, etc.).

The commonalities will be there, but then the checklists can diverge dramatically depending upon the opinions and technical knowledge of the auditor. Your best bet to offset this unpredictable "box of audits" is to have an understanding of what auditors potentially look for and to develop your own thorough checklist.

The Auditor's Proprietary Checklist

To an auditing firm, a good and current technical audit checklist is a highly prized piece of intellectual capital and is among the most important tools of an IT auditor. Typically, the checklist has been developed over the course of many years with input from several top-tier auditors and is strictly guarded as a trade secret. After all, a good audit checklist and audit reporting boilerplate is about all you need to go into the IT audit business. Having some technical knowledge of the computing platform to be audited is nice, but from my experience, it's certainly not a requirement.

There are several different flavors of checklists that direct the focus of an IT audit. There are general IT audit checklists to direct the collection of general IT audit information. There are platform-specific checklists, which are what we, as IBM i managers typically are confronted with. It is the IBM i technical checklist that can also be our nemesis when we're confronted with the checklist's opinion as to the best way to secure our i.

Different auditors will have their own version of an IBM i technical audit checklist. Often, auditors with advanced knowledge of the system will customize the checklist to suit their tastes and opinions. Regardless, each audit checklist conveys the auditor's interpretation of the proper system settings and configuration options. The ultimate goal is to determine your risk profile based on how well your system matches the benchmarks that the checklist imposes.

Most audit checklists in use today were created many years ago and give no consideration to the many enhancements that IBM has introduced over the years with each new OS release. In the early 1990s, an article about how to audit an AS/400 was posted on the web. I tried to find that article for reference in this article, but it appears that it's now removed. The article has made its way into the checklists many auditors use today. As an example of its datedness, the article makes reference to securing OfficeVision documents and as to where people put the keys for the old AS/400 physical key locks. So if your auditor asks you about your OfficeVision documents, you'll know where some of that checklist originated. The checklist wasn't bad, but it's hopelessly outdated.

One IBM i audit checklist item you will see is an evaluation of the Limit Device Sessions (QLMTDEVSSN) system value. The secure setting for the audit checklist says that the value should be 1, indicating that a user can be logged on to only one workstation session at a time. But the setting on every i system that I've ever seen is 0, for "do not limit device sessions." There are various technical and business reasons why you might prefer the setting 0 over the setting 1, but now you have to make your case as to why your setting is contrary to the audit checklist. If you can effectively make the case, most auditors will accept your business and technical reasoning for an item such as this and focus on the more important issues.

Figure 1 presents a typical snippet of a good audit checklist designed to capture information on the main system values of interest in an IT audit.

Auditors: Not the Technical Experts?

After dealing with IT auditors from several different firms, I can tell you that it's clear that very few of them are IBM i technical experts. Yes, there are some excellent IBM i technical expert auditors around, and if you get one, it'll be either a blessing or a curse, depending on your point of view. But generally, your auditor will have a limited knowledge of the i architecture and capabilities and will rely on the checklist. If the checklist item says a system setting is supposed to contain a certain value, and it doesn't contain that value, you're in violation of the checklist, and therefore, your risk profile is affected.

Your auditor isn't required to be an IBM i expert. IT auditors need to evaluate many different computing platforms with various operating systems. They can't be an expert on all hardware and software. But I do think auditors should know the basics of the system. Yes, there is an integrated database, yes there is a full suite of TCP/IP services available, and no, the database-related, security-related, and network-access–related events aren't logged unless the client specifically starts logging the information.

A few years ago, I taught a three-day IBM i security audit workshop to a large group of IT auditors from various large and small audit firms, as well as many internal auditors from local companies. It was so refreshing to see these people take three days out of their billable time to learn about how to audit the i system. I recall that when we discussed the fact that the IBM i has no FTP log, their jaws just dropped to the floor. Surely I was mistaken. Not one of them knew that there's no logging of any network transactions unless the customer has written or bought exit point programs for FTP, ODBC, DDM, Remote Command, and so on. They know that now and can perform a much better audit because they took part in some platform-specific training. I wish more auditing firms would follow their example.

Different Types of Audits

IT audit checklists are different depending on the entity performing the audit and the purpose of the audit. Public companies in the U.S. are audited for SOX compliance. SOX compliance in the IT arena means that the auditor will probably be using the COBIT framework as the basis for determining checklist items and proper settings. You can read all about COBIT at the ISACA website.

Companies that process credit cards may be subject to an audit for compliance with the Payment Card Industry Data Security Standard (PCI DSS). Banks and other financial institutions are audited by the Office of the Comptroller of the Currency (OCC), the FDIC, and various other federal and state agencies.

Companies in the health industry are subject to HIPAA privacy requirements enforced by the U.S. Office for Civil Rights.

Depending on the auditing body, the checklist will contain different items. For example, a PCI audit will be concerned about protecting credit card data, whereas a SOX audit will be mainly concerned with ensuring that proper controls are in place to protect a company's financial reporting data.

Inconsistency Between Auditors

Auditors will each have their own hot buttons. Two auditors will typically have very different ideas when it comes to what's important and what's not. At times, this inconsistency is seen even within the same auditing firm: two completely different sets of priorities. One auditor might come in with an audit result that'll cost your company significant time and money to remediate, whereas another equally expert auditor will come in with an audit result that'll cause you to make some minor changes. Based on these differences, I've seen some companies choose to change their external auditing firms.

One auditor might tell you that you need to use SSL to encrypt all Telnet traffic; another auditor might not even have SSL on her radar. One auditor might require that you remove command-line access from all users; another might not know there's such a thing as a command line. The disparity can be overwhelming and very costly. It's important that your internal consulting auditors communicate with your external auditors to ensure that you don't get the runaround on these costly and at times ridiculous checklist requirements.

The Checklist Is Not Always Right

Here are a few of the more "interesting" checklist requirements I've seen from different auditors.

• Set the QSECOFR password to *NONE.
• Delete the QSECOFR user profile.
• Encrypt every database file on the system.
• Provide a list of every command run from the command line for every user for the previous 12 months.
• Remove *ALLOBJ special authority from all user profiles.
• Provide a list of users who have database administrator rights.

Each item is a real requirement presented by auditors to IBM i managers. Most of these are technically impossible. Those that are technically possible are ridiculous. The scary thing is that these requirements didn't come from Joe's Audit Service. They came from auditors from the largest audit firms in the world.

If you run into a similar request, I would suggest you inquire of the auditor, "What other company has done this?"

Common Hot Buttons

Recently I've seen some common hot buttons for IBM i auditors. I don't know why these items are making their way onto the checklists, but it's a hopeful trend because these are all steps in the right direction (in my humble auditing opinion). Some of these hot-button items are:

• Reduce command-line usage to IT staff only.
• Audit and report commands run from the command line.
• Audit all ODBC traffic.
• Enforce read-only ODBC. Preauthorize and audit all exceptions.
• Encrypt Telnet and FTP traffic.
• Reduce the number of users with *ALLOBJ special authority.
• System value QSECURITY minimum level 40.

Figure 2 shows some additional common checklist items.

If I Had a Checklist

Having a current and technically accurate checklist should be one of the goals of each IT auditor—as well as the IT pros whose shops will be audited. I haven't published a full-blown checklist here, because of the size and scope of a full IBM i checklist. But I can point you to a great checklist. In fact, I believe this is the finest IBM i checklist on the planet.

The IBM i security software vendor PowerTech has had this checklist on its website for several years now: the System i Compliance Guide. At this site, you'll find a massive amount of information on IBM i security and compliance. It's organized and searchable.

For many years, I worked at PowerTech, as the original founder and president and, in later years, as a security specialist and auditor. In February, I left PowerTech for greener pastures, but the work that the staff at PowerTech did on the online Compliance Guide was awesome and was meant to be shared by all in the IBM i and IT auditing communities. There is some PowerTech product information and marketing material in the guide, but it's limited and doesn't interfere with the guide's usefulness.

If all IBM i auditors used this guide as their checklist, your audit would be much more technically sound and therefore of much greater benefit to you and your organization.

Dan Riehl is the president and security specialist for the IT Security and Compliance Group, LLC (SecureMyi.com). Dan has performed IBM i security assessments for many of the largest corporations in the world. He regularly visits customer sites to perform these assessments and to help them understand and plan for fixing the holes in current security implementations. Dan's articles appear regularly in System iNEWS, where he has been a technical editor and author for over 20 years. He is the writer and editor for System iNetwork Systems Management email newsletter and regularly teaches classes and seminars on IBM i security and other technical topics.