Whether you're working with an auditor who's performing an internal or external Sarbanes-Oxley (SOX) audit, a Payment Card Industry (PCI) audit, a SAS 70 audit, an ISO audit, or any other type of audit, some fundamental "do's" and "don'ts" exist. Since every organization has to go through some type of audit these days, I thought some tips for working with an auditor might be helpful.

Do Your Homework

Audits go much more smoothly if you have done your homework before the auditors arrive. Here are some of the ways you can prepare for an audit:

Understand the Scope of the Audit

Understanding the purpose and scope of the audit is critical to passing the audit. Audits do not come in "one size fits all." While one auditor performing an external audit may ask for a list of all users with *ALLOBJ special authority, the SOX auditor working on your account may examine all of your documentation on creating user accounts for each system in your organization. Understand the purpose of the audit (external, SOX, PCI, etc.) and prepare accordingly.

If your organization has gone through an audit of this type before, start your preparations by looking at last year's results. While the auditor may not look at the exact same things again, it will help give you an idea of what to expect. Pay particular attention to the issues that were listed as needing remediation (fixing). The auditor will most assuredly be checking to ensure that these have been addressed. In addition, look for items that didn't require remediation but were listed as lesser issues. I've seen auditors require remediation for those. The best course of action is to fix those issues as well. If you don't have time or resources to accomplish that, at least write a formal work plan to address the issue or a risk-acceptance statement if you have no intention of ever addressing the issue. Finally, if you don't have time to write a formal statement of work to address the issue and it's something you do intend to address in the future, spend some time thinking through what you will do if you are required to remediate the issue. This way, you'll be prepared to discuss with the auditor your remediation solution or your methods for mitigating the risk should the topic arise.

Understand the Laws and Regulations That Apply to This Audit

If you are being audited against a specific law or regulation—such as the Graham-Leach-Bliley Act (GLBA) or SOX—I recommend that you (personally) read that law or regulation. For example, systems storing credit card numbers are subject to the regulations of the Payment Card Industry (PCI). The PCI sends out auditors to ensure regulations are being followed. If you're about to undergo a bank audit, your company needs to comply with the GLBA or perhaps Basel II.

Why understand the laws and regulations? Knowledge is power, as the saying goes. Knowing the laws or regulations associated with the audit will help you better understand and better prepare for what the auditor will be examining during the audit. Links to the more popular laws and regulations can be found here.

Do Be Prepared

Being prepared for an audit before you go into it will greatly assist in getting through it more quickly. Here are some ways you can prepare.

Have Your Security Policy Ready

One of the documents an auditor may request is your security policy. Large or small, all organizations need a written security policy. It doesn't have to be complex or long-winded, but it does need to be a written policy that has management approval. Why? A security policy documents the organization's stance on issues such as classification of data, data access, appropriate use of technologies such as email and the Internet, etc. Without a written policy, there can easily be conflict within the organization and disagreement over what data should be protected or what services should be allowed. And, from an auditor's point of view, without a written policy there is no way for him or her to know whether or not the organization is following its policy because the implementation cannot be compared to the organization's policy..

Perform an Assessment

Rather than let your auditor discover your system's vulnerabilities or a process that is not documented accurately, it is far better to discover them yourself prior to the audit. In addition, some laws such as the Health Insurance Portability and Accountability Act (HIPAA) and PCI's Data Security Standard require a periodic assessment of your systems and networks. Performing an assessment allows you to discover areas of weakness (i.e., vulnerabilities) and determine what to do about them. When vulnerabilities are discovered, they should analyzed to determine the risk level they pose to the organization. Once that's been done, three options exist:

• For high-risk vulnerabilities, issues should be remediated (fixed) soon if not immediately.
• For vulnerabilities whose risk is low or can be mitigated, a risk acceptance statement should be written, documenting why the vulnerability does not constitute a significant risk to the organization, why the impact to the business outweighs the risk, or what mitigating factors are in place or being put in place to lower the risk to the organization.
• For vulnerabilities that are too risky to accept but cannot be fixed right away, a work plan should be created. If the vulnerability is discovered by the auditor, a documented work plan will show the auditor that you understand the issue and plan to fix it.

What do you measure your system against? Security "best practices." One example of best practices is the PCI's Data Security Standard. Other examples include CobiT and ISO 27001. For translation from these best practices to i5/OS settings, check out the iSeries Security Reference manual available from the System i Information Center as well as the book I co-authored with Patrick Botz, Experts' Guide to OS/400 and i5/OS Security.

Secure Your Data Appropriately

Based on your organization's security policy, you'll want to make sure that your organization's data is secured appropriately. This means that access—both through an application's menu environment and through direct access (such as command line access)—is appropriate and matches the requirements of the data access and data classification sections of your security policy. Be prepared to show proof that you have in place both menu controls and access controls that support the implementation of your policy.

Secure Your System Appropriately

Securing your system constitutes more than just setting the appropriate authority on data files. User profile configuration, system values, and TCP/IP auto-start values all need to match your policy. However, just because they match your policy doesn't mean they satisfy the auditor's requirements, especially system value settings. Unfortunately, many auditors have little or no knowledge of OS/400 or i5/OS. Auditors may come prepared with a checklist of "appropriate" system value settings. Often, this list is out-of-date and contains required settings that no longer make sense for today's system configurations. This is why risk acceptance statements need to be written for system values (and other security configuration items) that cannot be set to the value recommended by best practices. In the risk acceptance statement, explain the disruption to productivity, the function that will break, etc. along with any mitigating controls you are taking to reduce the risk of the value not being set to the most secure setting.

Document Your Processes

Auditors look for processes that will assure them that appropriate controls are in place to ensure the integrity, accuracy, or privacy of the data being examined. The processes required may vary slightly, but the ones I see auditors require on a consistent basis include these:

• Change management documents how objects (programs and files) get moved into production. This includes the process programmers go through to gain access to modify data on a production system.
• "Patch" management documents how fixes (PTFs, in i5/OS terms) get applied and tested.
• Request for user access documents the process an employee or manager has to go through to request new or additional access to an application, system, or network.
• Inactive profiles documents how and when inactive profiles are managed.
• Save strategy documents the schedule for how and when data is saved.
• Disaster recovery documents how the organization would recover from various types of disasters.

These processes need to be documented (along with the other processes deemed critical to your business). Auditors will also look for evidence that these processes are being followed. An auditor may literally watch people perform their jobs to see if they are following the exact steps documented in the process. Therefore, it is vital that the process documentation is up-to-date and matches the actions actually performed.

Be Ready for the Auditor's Arrival

If, prior to their visit, the auditors request a specific set of reports to be generated or other information to be gathered, have the reports and information available upon their arrival. Making auditors wait for reports or information provides them with free time to think of other reports to run or other areas of the organization to examine. Have those reports and information ready for them the minute they arrive!

Provide a Focal Point

Consider providing a focal point for all audit questions. Some organizations, such as banks, can go through numerous audits each year. Various auditors may request similar reports. The focal point can provide process documentation or the reports generated for a prior audit without having to bother IT. In addition, the focal point can provide guidance to users who have never participated in an audit. The focal point can educate these users about appropriate ways to answer auditor questions and interact with auditors.

The Don'ts

Now that we've reviewed what you should do, let's review what you should definitely not do.

Don't Be Mean

Auditors are people. Treat them as such. You may not enjoy the fact that you have to go through an audit, but that's not the auditors' fault. They're just trying to do their job.

Don't Guess

If the report that your auditor is asking you to produce or the type of information requested doesn't make sense to you, ask a clarifying question. It's (quite) likely that the auditor is asking for information using terms that are more widely used in a Windows or UNIX environment. As such, you may have to "translate" these into i5/OS terms. To do that, you may need to ask for an example or for further explanation of the type of information the auditor is asking you to gather.

Don't Be Over-Zealous

Don't provide more information than is asked for. If you're asked to provide a report of all of the users with *ALLOBJ special authority, don't hand the auditor a report of all users on the system (unless of course, all users actually have *ALLOBJ!). Reports with more information than requested can confuse the auditor or prolong the audit by causing the auditor to investigate other areas that might have otherwise been left alone.

Don't Answer for Someone Else

When questioned by an auditor, do not answer for any process or action that is not your responsibility or for which you do not have direct knowledge. Processes and situations can change, and you do you not want the responsibility of providing an inaccurate or misleading answer to the auditor.

Don't Elaborate

While you must answer any question the auditor asks, you don't need to elaborate outside of the specific question being asked. Now is the time to be literal and answer only the question asked. For example, suppose the auditor asks, "Do you update production data?" If the answer is "no," say only that. Don't say, "I don't, but Joe and Sally access production systems and update data all the time."

Don't Lie

Lying is never a good idea. Lying to or misleading an auditor can land you and your organization in serious legal trouble.

Don't Be Surprised

If the auditors discover something significant, don't be surprised when it's reported to the company's board of directors. Changes to the Statement on Auditing Standards—specifically, Communicating Internal Control Related Matters Identified in an Audit as published by the American Institute of Certified Public Accountants—require that auditors report findings "to communicate, in writing, to management and those charged with governance." "Those charged with governance" are typically the board of directors or a committee of directors or partners, etc. In the past, these reports may have stopped at the IT director, but no longer can this be the case. I don't know about you, but this type of "attention" is not the type I crave! This is all the more reason to perform that assessment and fix as many issues as possible before the auditor shows up.

Don't Kid Yourself

Just because you've passed an audit does not ensure that your systems or data are secure. Auditors come with varying degrees of knowledge of the applications, operating systems, and networks they audit. Just because an auditor does not specifically look at the access controls of files containing private or company confidential data does not mean that the security configuration of the file is set accurately or securely. In addition, the scope of the audit could have been limited based on time and resources so that only certain aspects of the organization were audited. Ultimately, the security of your data, systems, and network are your responsibility.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security policy compliance and assessment software as well as security services. Carol is the former chief security architect for AS/400 for IBM in Rochester, Minnesota, and has specialized in security architecture, design, and consulting for more than 16 years. Carol speaks around the world on a variety of security topics and is coauthor of the book Experts' Guide to OS/400 and i5/OS Security. 

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR