The Do's and Don'ts of Working with Auditors
by Carol Woodbury
SOX, PCI, ISO… You're going to have to work with auditors eventually.
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.
CAclubindia
